Because the domain name limited me to blog about PHP security only I moved to the domain suspekt.org that I own for many years now. Please update all your links and feeds to point to the new URL where I will continue blogging on a regular basis.

A friend of mine just sent me the URL to a flash game (for obvious reasons I will not share the link) which is part of a number of games with a price of 10.000 EUR in the end. One would believe that a game with such a price money is secure. Especially when the organising party is an internet provider.

But guess what... At the end of the flash game you can optionally submit your score to the highscore server, which results in a POST to the file submithigh.php with several parameters, one parameter saying score=XXXX. And of course you can submit whatever score you want. So now I lead the highscore with 10000 of about 900 possible points. I set it that high to ensure that the guys at the ISP will realize that this is faked, but imagine I had just increased the current highscore by 10. I seriously doubt anyone would have noticed and I would have won the competition without even decompiling the flash.

Continue reading "Flash Game - 10000 of 900 possible points?!?!?" ]]> http://blog.php-security.org/archives/94-Suhosin-0.9.21-XSS-Protection.html Fri, 30 Nov 2007 10:51:00 -0600 http://blog.php-security.org/archives/94-Suhosin-0.9.21-XSS-Protection.html

It has been a very long time since the last Suhosin extension has been released, but today this has changed with the release of Suhosin 0.9.21. Among the changes are two new features that will protect applications that put too much trust into the SERVER variables from several XSS (and SQL injection) attacks. These features are suhosin.server.strip and suhosin.server.encode.

suhosin.server.strip

When activated (which is the default) the SERVER variables PHP_SELF, PATH_INFO and PATH_TRANSLATED will be scanned for the characters < > ' " and `. All occurences will be replaced by ? characters. This stops a lot of XSS attacks, because many PHP applications consider these variables not tainted.

suhosin.server.encode

When activated (which is the default) the SERVER variables REQUEST_URI and QUERY_STRING will be scanned for the characters < > ' " and `. All these characters are usually encoded by the browser before they are sent and therefore many applications consider REQUEST_URI and QUERY_STRING safe. However some browsers like Internet Explorer will not encode these characters which results in lots of XSS vulnerabilities. Suhosin will protect applications that wrongly put too much trust into these variables by URL-encoding them within the variables.

If you have more ideas for simple features that can protect many scripts at once don't hesitate to contact us.

The speakerlist of DeepSec is very impressive, it includes Halvar Flake, Dave Aitel, David Litchfield, Martin Johns, Jeff Moss, Alexander Kornbrust and my co-worker fukami who will speak about Adobe Flash Security.

To add such a tainted mode to PHP has been discussed several times in the past. It was rejected for several reasons like the obvious huge speed impact and the danger of false positives and a false sense of security. And indeed the way CORE GRASP is implemented it looks like a huge memory and speed overhead that should be tested. In addition to that their query parser will for example wrongly detect quotes escaped by doubling as injection attack.

Aside from this there are several other possible problems in the code like a remote one byte stack overflow (that seems harmless due to memory alignment), wrong handling of the _SERVER superglobal in case of JIT and it also seems that control characters like linebreaks can be injected into the logfiles. Further analysis and a deeper look into the code is needed.

However it has to be taken into account that this is the very first public version of CORE GRASP, so maybe all these problems are gone soon and support for further database engines is added.

Unfortunately I had to take down all the proof of concept exploits that were developed during the Month of PHP Bugs. The reason for this is a new law in germany that is official since today. This new law renders the creation and distribution of software illegal that could be used by someone to break into a computer system or could be used to prepare a break in. This includes port scanners like nmap, security scanners like nessus and of course proof of concept exploits.

Today I learned about another CSRF redirector by another group of people in web application security called GNUCITIZEN.

Similar to the previous CSRF redirector it contains the same XSS vulnerability through the javascript URI scheme.

Example:

http://www.gnucitizen.org/util/csrf?..._url=javascript:alert(/.../);

Update: The bug is fixed for now...

Two major risks happen to exists with chris example:

1. Malicious people could misuse them as bouncers to attack other sites
   
2. Not every URL is a web page. Some can load plugins, display information and
   some can execute JavaScript.
   
   

Here is an example URL:

http://shiflett.org/csrf.php?csrf=javascript:alert(/I_AM_A_SECURITY_EXPERT/)

In Internet Explorer (and Safari) this will give you access to the domain (cookies, etc...). In Firefox you can still do other funny things.

So if you implement (javascript) redirector scripts, make sure you do a proper
whitelisting of the user delivered urls.

UPDATE: The above example for a simple XSS does no longer work. However there are still other XSS vulnerabilities like variable-width problems in the CSRF redirector and it is still an open bouncer for malicious persons.

The amusing thing this time is that their new fix that consists of blacklisting a bunch of legal characters from the session id, will most probably result in hundreds or thousands of broken sites. What is even more funny is that the commit comes from a Zend employee that blacklists the ':' character from being used in the session id. The last time I audited the Zend Platform session clustering module it used exactly this character within session ids. This basically means that the session clustering of the Zend Platform will no longer work with the next PHP versions.

And as a final comment to the commiter: You are blacklisting a bunch of legal characters. Whatever RFC you used for choosing the characters for your blacklist was the wrong one. PHP implements the Netscape Cookie standard that is defined here. That document described very clearly that all characters are allowed except whitespace and semicolon. So nearly all the characters in your list are legal. Thank you for breaking lots of sites.