I have a question I'm hoping you could help me with?

Unclean url's:


Clean url's (the equivalent urls once they have been 'cleaned'):


Explanation of clean/unclean url's here

My question:

As you can see in the examples of unclean and clean url's above they obviously differ slightly.

With the unclean url's it would be possible to test for a possible sql injection vulnerabilities by appending an apostrophe (') to the end of the url and so on...

for example http://example.com/products?category=2&pid=25' and then looking at the response lengths it returns.

I am aware that using clean/rest url's does not make it any less vulnerable to sql injection and is mainly used for SEO, usability and so on (although also making it more difficult for automated sql injection tools) , but how would you go about injecting these types of url and is there a particular, preferred/best method to use?

for example would the following work for injecting clean url's (using an apostrophe)?






and so on... or is there a preferred/better method.

Your help with this question would be much appreciated, many thanks

3 Answers 3


In my opinion, the main problem when a pentester faces a web application that uses clean URLs is to identify which parts of the URL are resources and which parts are parameters because usually parameters are what we test more deeply.

In this case, I think that the best option is to test all parts of the URLs assuming all parts are parameters:


The tick is just an example, the case is that all parts (including kb that is supposed to be a resource but could be a parameter also).

If there is a way to differentiate in blackbox testing resources and parameters I would like to know it.


There is no magic test for testing for sql injection. Some applications may be vulnerable when using a certain approach and others when using another.

There is a chance that http://example.com/kb/8'/41 would not work because apostrophes are blocked by an IPS, but http://example.com/kb/7%2B/41 would display the same result as http://example.com/kb/8/41 and this would give you the information that there is a problem there.

Just testing with quotes is a little better than not testing at all, but cannot be labeled as a security evaluation. Such a process involves a complex assesment of all the posible entry points in your application(parameters, cookies, headers, etc) and several other more complex tests.

If you have the possibility, the best solution is to use a white box approach and also review the code. This way you could clearly see if a certain parameter is properly sanitized or not.


Clean URLs can be implemented differently and therefore depends on what system is used. For example with rewrite rules in the webserver:

url.rewrite-final = (
  "^/system/test/(.*)$" => "/index.php?q=system/test/$1",
  "^/([^.?]*)\?(.*)$" => "/index.php?q=$1&$2",
  "^/([^.?]*)$" => "/index.php?q=$1",
   "^/rss.xml" => "/index.php?q=rss.xml"

As you can see, this regular expressions (.*) will also match ' or " and if the php script doesn't handle this input correctly, it can be vulnerable to SQL Injection.

Here is another example, where the clean URLs are implemented in the WebApplication itself (in this case with the python WebFramework django):

urlpatterns = patterns('',
    (r'^articles/2003/$', 'news.views.special_case_2003'),
    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),

As you can see here, the developer used expressions such as (\d{4}) which matches 4 digets like 1234, 2001, 1995, ... but not 12 or 12345 - and therefore also not 12'.

TL;DR This means, that you can inject them like non clean URLs, if the developer didn't use proper expressions.

edit: you can not know which part of the clean url are values and which are the keys, so you have to identify them with reason or just test them too.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .