 | News Feed |
 | Jobs Feed |
Sections
|
| feed this: |  |
Pádraic Brady: Getting Ahead In Security By Watching The Neighbours
by Chris Cornutt January 18, 2013 @ 11:53:52
In his latest post Padraic Brady talks some about the recent security issues that happened with Ruby on Rails that allowed for remote code execution and how, if you use code blindly, you could be in for a similar fate.
Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.
These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().
He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).
To summarise…
Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.
voice your opinion now!
rubyonrails security vulnerability code execution yaml symfony2
PHPMaster.com: 5 More PHP Security Vulnerabilities
by Chris Cornutt November 13, 2012 @ 14:42:02
On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.
In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you're developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn't do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.
He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.
voice your opinion now!
security vulnerability tutorial phpini filterinput session fixation user
PHP.net: PHP 5.4.3 and PHP 5.3.13 Released!
by Chris Cornutt May 09, 2012 @ 07:10:36
The PHP project has released another update to both the 5.3.x and 5.4 revisions of the language correcting the bug that was found dealing with a flaw in CGI-based setups.
The PHP development team would like to announce the immediate availability of PHP 5.4.3 and PHP 5.3.13. All users are encouraged to upgrade to PHP 5.4.3 or PHP 5.3.13 The releases complete a fix for a vulnerability in CGI-based setups (CVE-2012-2311). Note: mod_php and php-fpm are not vulnerable to this attack. PHP 5.4.3 fixes a buffer overflow vulnerability in the apache_request_headers() (CVE-2012-2329). The PHP 5.3 series is not vulnerable to this issue.
Users are encouraged to upgrade their applications, especially those using CGI-based setups. You can find the latest source on the downloads page and the Windows binaries on windows.php.net.
voice your opinion now!
release bugfix cgi apache vulnerability attack
PHPClasses.org: PHP Vulnerability May Halt Millions of Servers
by Chris Cornutt January 12, 2012 @ 08:21:55
On the PHPClasses.org blog today there's a new post looking at the security vulnerability that effected not only PHP but lots of other languages making them susceptible to attack from the outside.
In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.
He goes on to explain why there's an issue with the array overloading and what PHP has done in recent releases to help correct the issue - the max_input_vars setting in the php.ini. He also points out that this is not a new issue - it was originally identified back in 2003 (with a video of the original presentation). He points out that the most recent releases of the PHP language have this fix in them and, if at all possible, you should upgrade to protect your applications.
voice your opinion now!
vulnerability server array overload upgrade
Script-Tutorials.com: Protection and Methodologies of Security Vulnerabilities in Web Development
by Chris Cornutt August 17, 2011 @ 11:16:07
On the Script Tutorials blog today there's a good summary post reminding you of some of the common security issues that your web application can face, mostly due to improper validation and filtering.
Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I'll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).
Security issues that made their list include:
- SQL injections
- Cross-site scripting/Cross-site Request Forgeries
- Remote & local file inclusion
- Displaying errors on production
- Including .svn (or any version control meta) files in the production release
voice your opinion now!
security vulnerability protection example
Ruslan Yakushev's Blog: ASP.NET vulnerability affecting PHP sites on IIS
by Chris Cornutt September 23, 2010 @ 08:50:46
As Ruslan Yakushev points out in this new blog entry, the same security issue that's effecting ASP.NET pages running on IIS web servers can still open up PHP scripts running on the same server.
Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.
The issue allows attackers to access the contents of various files on the server and could allow them to tamper with the data inside. Ruslan notes that, while Microsoft is coming up with a fix, one of the safest things you can do is either completely disable ASP.NET in the IIS server or use this workaround.
voice your opinion now!
iis vulnerability aspnet disable workaround security
Rafael Dohms' Blog: PHP Security Are you paying attention?
by Chris Cornutt October 02, 2009 @ 12:27:18
In a recent post to his blog Rafael Dohms reminds readers to not forget about the security of their applications because it can be "a huge mistake which can take a turn for the worse."
I have ran into lots of excuses for ignoring security in the past, one of them is the recurring "This is just a simple application, it has no sensitive data", this may be a valid point for the person repeating it like a mantra, especially because this person is generally suffering of great pressures , short timeframes and a lack of proper management ready to deal with web development. [...] Whatever the reason is for neglecting security the consequences can escalate much higher then the "non-sensitive data" of the application.
He looks at a specific case where a security issue was found in a large Brazillian mobile company's website that was caused by improper filtering on a $_GET parameter, leaving it open to possible attack. Through it, he could load the information for sensitive system-related files and found more on the machine than just the site he was working with.
voice your opinion now!
security opinion vulnerability
|
Community Events
Don't see your event here? Let us know!
|