Active Scan doesn't attack GET

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Active Scan any website with GET parameter vulnerabilities

What is the expected output? What do you see instead?
Attacked an URL of the type:
GET getfile.php?id=1
Expected : injection on the ID
Result : attacks through all the available attacks but doesn't try to attack 
GET (id) parameter

What version of the product are you using? On what operating system?
ZAP D2013-02-25 on Backtrack 5R3 lastest Java

Please provide any additional information below.

Original issue reported on code.google.com by thec4kei...@gmail.com on 25 Feb 2013 at 10:22

• Merged into: #543

[GoogleCodeExporter]

Thats strange!

Can you explain exactly how are you invoking the Active Scan?

I've just tried this by right clicking a single node in the Sites tree and 
selecting the "Attack / Active Scan single URL" and that worked ok.

Original comment by psii...@gmail.com on 26 Feb 2013 at 10:00

[GoogleCodeExporter]

These are the exact steps (i am testing this against LampSecurity's CTF7) :
1. Setup proxy and activate Session Tracking
2. Login to website and navigate to vulnerable page (or Spider, same results)
3. Leaf GET:newsletter&id=1 appears in the Sites tab
4. Set HTTP Session default value
5. Right-click Attack->Active Scan Single URL (all plugins checked in the 
Policy window)

Results are :
- All GET requests (as expected)
- All to address : http://.../newsletter&id=1

- First Requests try attacking HTTP headers
- When all HTTP Headers have been tried, 6 identical requests are made that are 
exactly identical to the original request intercepted by the proxy (Request 
displayed in the provided screenshot)
- Last request tries adding a / at the end of the URL

Original comment by thec4kei...@gmail.com on 26 Feb 2013 at 11:16

Attachments:

• Screenshot.png

[GoogleCodeExporter]

Currently, only the query parameters (newsletter?id=1) and POST 
(x-www-form-urlencoded) parameters are attacked by the active scanner.

Original comment by THC...@gmail.com on 26 Feb 2013 at 5:07

[GoogleCodeExporter]

By query parameters do you mean GET parameters (like the id parameter in the 
example) ?

That is what I understood and precisely the problem I am having, the id 
parameter isn't attacked.  (Checked by reading all attack requests)

Original comment by thec4kei...@gmail.com on 27 Feb 2013 at 8:54

[GoogleCodeExporter]

Very strange - the GET parameters like id _should_ get attacked.
I'll download the LampSecurity's CTF7 and try and reproduce this issue.

Original comment by psii...@gmail.com on 27 Feb 2013 at 9:09

[GoogleCodeExporter]

By query parameters I mean the parameters that are in the query component of 
the URI [1] (it really doesn't matter if the request method used is GET, POST 
or another one as long as the parameters are in the query component).

Note that the URI "http://.../newsletter&id=1" (the one that's not attacked 
correctly) doesn't have any query parameters, the "id" is placed in the path 
component of the URI [1].

[1] https://tools.ietf.org/html/rfc3986#section-3

Original comment by THC...@gmail.com on 27 Feb 2013 at 1:05

[GoogleCodeExporter]

Oh yes, I should have spotted that :)
ZAP currently just looks for parameters on the URL after a ?
So it would attack the id field in http://.../newsletter?id=1

So ZAP is acting 'as intended' even if its not what you want.

Note that I'm planning on enhancing ZAP to cope with 'non standard' urls like 
this

I'll raise an enhancement request to cover this then close this as a duplicate 
of the new one.

Original comment by psii...@gmail.com on 27 Feb 2013 at 1:09

[GoogleCodeExporter]

Original comment by psii...@gmail.com on 27 Feb 2013 at 1:49

• Changed state: Duplicate