Closed GoogleCodeExporter closed 9 years ago
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
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:
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
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
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
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
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
Original comment by psii...@gmail.com
on 27 Feb 2013 at 1:49
Original issue reported on code.google.com by
thec4kei...@gmail.com
on 25 Feb 2013 at 10:22