« Web Application Security Professionals Survey Results | Main | Finally someone speaking about RIA (Rich Internet Applications) »

Attacking Permalinks

Everyone has seen urls such as http://site/2006/02/02 and you know that there's an application in the backend somewhere but figuring out how to attack those urls can be tricky. A few of you have probably tried attacking them by sending requests such as http://site/2006'>/02/02 and received a 404 page. I started thinking about this in conjunction with parameter identification. As an example you may be able to append things such as 'script.php?admin=true' and yield hidden administrative access (the classic example). Essentially you're appending a parameter and receiving a different application behavior. So I started to think 'in a url such as /2006/02/02 the '2006' portion states the year, what are some common year parameter names?'. I came up with 'y' and 'year'. The way that permalink url rewriting works is that your request for /2006/02/02 gets rewritten by the webserver and may be sent to a back end script such as 'index.php?year=2006&month=02&day=02'.

Knowing that permalink internal rewrites use standard parameters, and knowing that 2006 is a year I started tinkering around and sending requests such as http://site/2006/02/02?year=-1. Now if the parameter isn't used the same page will be served, however if the response is different, then the application has processed your additional appended parameter. When you append the 'year' parameter to the permalink the internal redirection will appear as 'index.php?year=2006&month=02&day=02&year=-1'. Many applications will merge both parameters and combine the data within them (concatenation) before the data is processed. The order of the merge of course may vary (in this case '-12006' vs '2006-1') so ease of exploitation of a potential vuln may vary from application/framework. In a nutshell you append additional 'guessed' parameters based off of the data format between the // and if the application acts differently, then you now have a vector exposed for security testing purposes.

PS: If you haven't noticed I use permalinks however use mod_rewrite redirects to static files, so don't bother poking around :)

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.


All Comments are Moderated and will be delayed!


Post a comment







Remember personal info?