News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Evert Pot:
Composer's bug now fixed
February 24, 2014 @ 12:38:06

Evert Pot has posted an update to a previous post around Composer's vulnerability around installing the wrong packages in the case of a conflict. In this latest post he points out, however, that the bug is now fixed.

As an update to my previous post, the composer security problem now appears fixed. Good to see that a quick response was possible after all.

The original issue was caused by the "replace" functionality, allowing the possibility for an incorrect package to be installed instead of the one requested. Other posts with more details include this one from Pádraic Brady and Nils Adermann. if you're a Composer user, it's highly suggested you update your currently installed version (run a "composer self-update").

0 comments voice your opinion now!
composer bug security vulnerability fix selfupdate

Link: http://evertpot.com/composer-bug-fixed

Pádraic Brady:
Composer Downloading Random Code Is Not A Security Vulnerability?
February 21, 2014 @ 10:04:52

In his latest post Pádraic Bradyhas posted a response to a recent post stating that in issue in Composer where the wrong package could be installed is not a security issue. Pádraic disagrees, here's why:

The problem here is quite simple. A user defines a composer.json file that requires the package bloggs/framework. Someone else creates a package on Packagist.org called evil/framework whose own composer.json states that it replaces bloggs/framework. Next, a group of poor random victims, potentially thousands, use composer to install applications with a dependency on bloggs/framework. Composer does some internal wizardry and installs evil/framework when certain conditions are met. The victims didn't request evil/framework but they get it anyway.

He suggests that this is a kind of remote file inclusion and possibly a remote code execution vulnerabilities. He points out that the manual steps suggested in the post aren't listed in the Composer documentation and fixes for it are still pending work.

Saying one thing, but acting like it's the other thing you don't want people to call it, makes me think it really is the other thing. Probably because it is. Users can fall victim to a replace and it's called "unintuitive", but if a package states that it replaces something that might lead to the unintuitive behaviour, it's an abuse.
0 comments voice your opinion now!
composer random code vulnerability security package

Link: http://blog.astrumfutura.com/2014/02/composer-downloading-random-code-is-not-a-security-vulnerability/

Pádraic Brady:
Getting Ahead In Security By Watching The Neighbours
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.
0 comments voice your opinion now!
rubyonrails security vulnerability code execution yaml symfony2


PHPMaster.com:
5 More PHP Security Vulnerabilities
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.

0 comments voice your opinion now!
security vulnerability tutorial phpini filterinput session fixation user


PHP.net:
PHP 5.4.3 and PHP 5.3.13 Released!
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.

0 comments voice your opinion now!
release bugfix cgi apache vulnerability attack


PHP.net:
PHP 5.3.10 Released (Security Fix - Recommended Upgrade)
February 03, 2012 @ 08:01:29

The PHP development team has officially announced the release of the latest version of PHP in the 5.3.x series - PHP 5.3.10:

The PHP development team would like to announce the immediate availability of PHP 5.3.10. This release delivers a critical security fix. [...] Fixed arbitrary remote code execution vulnerability reported by Stefan Esser, CVE-2012-0830.

It is highly recommended that users upgrade to this latest version to avoid falling victim to this recently introduced bug relating to the new "max_input_vars" setting added to protect from the overflow issue recently brought up in the PHP community.

0 comments voice your opinion now!
release security fix maxinputvars hashtable collision dos vulnerability


PHPClasses.org:
PHP Vulnerability May Halt Millions of Servers
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.

0 comments voice your opinion now!
vulnerability server array overload upgrade


Script-Tutorials.com:
Protection and Methodologies of Security Vulnerabilities in Web Development
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
1 comment voice your opinion now!
security vulnerability protection example


Ruslan Yakushev's Blog:
ASP.NET vulnerability affecting PHP sites on IIS
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.

3 comments voice your opinion now!
iis vulnerability aspnet disable workaround security


php|architect:
Possible vulnerabilities found in PHP session IDs
April 12, 2010 @ 08:29:00

Beth Tucker Long has posted a new warning about a possible issue with session IDs in PHP dealing with weak random numbers being generated by the language when making the IDs.

Seclists.org has posted an advisory titled "Weak RNG in PHP session ID generation leads to session hijacking." RNG stands for Random Number Generation, and the advisory is warning that not enough entropy is being used to seed the RNG; this, in turn, can lead to a reduced number of possible session IDs under certain specific conditions, thus making brute force session spoofing easier, if not bringing it into the realm of feasibility.

The threat is only marked at a "medium" level of severity, but it could still cause problems if you're not careful. There are specific conditions that have to be in place for it to be a problem including using the standard PHP session generation and that the app shares the information about remote users. To protect yourself you can either install Suhosin and don't use the result of set an external source for entropy to help randomize the session ID even more.

0 comments voice your opinion now!
sessionid vulnerability rng random number entropy



Community Events





Don't see your event here?
Let us know!


library list wordpress application threedevsandamaybe bugfix release introduction developer configure laravel framework interview community install language api podcast series code

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework