Finding get/post inputs

[Ľuboš Katrinec]

Hello all,

I'm testing OWASP ZAP for a while and realized that it cannot find SQL injection on its own. I know I should do inputs manually on the site first but I'd rather let algorithm do its work. At least it could look for all get and post (by looking for forms) variables. I know I can attack, fuzzy and such a things but.. Is it somehow possible to let it find automagically?

Thanks and regards,

Lubos

[Simon Bennetts]

Hi Lubos,

Have you used either the Spider and Ajax spider to explore your application?
You'll need to have used at least one of those if you dont explore your app manually while proxying through ZAP.
If you have used them, did ZAP discover the GET and POST parameters? They should be shown in the Sites tree.
If not then can you give us some examples of HTML snippets containing them - we can then see if either Spider needs enhancing.

Many thanks,

Simon

[Ľuboš Katrinec]

Hello Simon,

I'm learning how to use OWASP ZAP on DVWA with low security level. I tried both Spider site and Ajax Spider site on http://localhost/dvwa/vulnerabilities/sqli/index.php. There is form with GET parameters but it didn't find any (checked both in Sites and Params tab). Particular snippet of the form:

                <form action="#" method="GET">

                        <input type="text" name="id">

                        <input type="submit" name="Submit" value="Submit">

                </form>

Once I enter the value manually ZAP immediately detect this and parameter is finally discovered. Has anyone experience with DVWA pentesting who could explain why its not found automatically by Spider

Thanks and regards,

Lubos

[Simon Bennetts]

Strange, I'll ping Cosmin and Guifre and see if they can help.

Cheers,

Simon

[Cosmin Stefan-Dobrin]

Hey Lubos,

I'll take a look later today at the code and try to see anything that might be wrong.

In the meantime, for the Spider, have you enabled the option to POST forms in the Spider section of the Options?

Cheers,

Cosmin

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ľuboš Katrinec]

Hi Cosmin,

yes, it's enabled (by default).

Lubos

[thc202]

Hi.

It seems to be an issue with the SpiderHtmlFormParser when handling the GET forms which have an action URI with a fragment identifier ("#"). The localURL that it's produced is something like "#?id=ZAP&Submit=Submit" (the fragment will be ignored once the localURL is normalised).

Best regards.

[Cosmin Stefan-Dobrin]

Hi,

The problem is the one that Ricardo has mentioned in the post above. I've created an issue for this and the fix will probably be included in the next weekly build.

Thanks for reporting this,

Cosmin
 

--
Cosmin

[Ľuboš Katrinec]

Hi there,

I'm not sure if the fragment identifier is the (only) issue. I removed the char from action attribute (just let empty string there) but it didn't help either. Spider doesn't find the parameter.

Lubos

[Guifre]

Hello,

I don't think our spiders support all the specifications described in
RFC3986. Maybe you can try to use the page URL in the action's
attribute value instead of using an empty string.

Best Regards,
Guifre.

[thc202]

Hi.

I'm not aware of any other issue that might prevent the correct spidering of DVWA (I'm using version 1.0.7).
I've tested with the (ZAP) version 2.0.0, after removing the fragments from the form's action on the pages "sqli" and "sqli_blind", the spider was able to submit the forms (and the active scan to attack those forms).

Following the steps that I've made (after removing the fragments):
1. Run ZAP (and ensure that the spider option "Process forms [...]" is enabled);
2. Disable the cookies in the client application (browser), the cookies will be managed by ZAP;
3. Go to ZAP and enable the option "Edit" > "Enable Session Tracking (Cookie)" (needed to have the spider send the cookie "security");
4. Access the DVWA, while proxying through ZAP, and login, the "Welcome" page is shown (I'm using the account "admin"; ensure that the security level is "low", if not change it);
5. Go to ZAP and ensure that the request were proxied through ZAP (look at the "Sites" or "History" tabs);
6. Go to "Session properties" dialogue [1] and exclude from the spider the following pages:
    - logout.php (example: \Qhttp://localhost/DVWA/logout.php\E), to not allow the spider to log out;
    - security.php (example: \Qhttp://localhost/DVWA/security.php\E), to not allow the spider to change the security options;
    - setup.php (example: \Qhttp://localhost/DVWA/setup.php\E), to not allow the spider to create/reset the database;
7. Delete all accessed pages except "index.php" (so the spider doesn't play with the login page/form);
8. Select the node "GET:index.php" and choose the option "Attack" > "Spider Site"; Wait for the spider to finish;
9. Check the "Sites" tab, there should be a leaf node "GET:sqli(Submit,Id)" under the node "vulnerabilities" (which means that the form was submitted);
10. Select the leaf node "GET:sqli(Submit,Id)" and choose the option "Attack" > "Active Scan single URL"; Wait for the scanner to finish;
11. Check the "Alerts" tab there should be a SQL Injection alert;

Let me know if those steps also work for you.

[1] https://code.google.com/p/zaproxy/wiki/HelpUiDialogsSessionSessprop

Best regards.

[Ľuboš Katrinec]

Hi thc202,

sorry for delayed answer. (I've lost lot of data including virtual machines due to corrupted hard drive so I had to build the env from scratch.)

I followed your scenario and it has successfuly found the parameters. I think the issue was in cookies. I didn't know about "Enable Session Tracking (Cookie)". I was thinking that cookies are tracked by default (I could see them in http sessions and have set active the logged one).

But now I have issue with finding the vulnerability, there is no SQL injection alert. One thing I spotted - after attack I'm logged out and admin password changed to 903a98d709fa4683aaaa036b84c125a6 (ZAP). I've played with lot of things but nothing helped. I also tried to exclude csrf site (where admin password can be changed but no success.

I'm hopeless, do you have any clue? I use "attack single URL" and I assume that some of the SQL attacks have changed the password but I don't understand why it doesn't include it to alerts then.

Kind regards,

Lubos

[Ľuboš Katrinec]

I think I've found the issue. One thing is that spider changes admin password when tampering with parameters => that's ok.

But another issue is with session cookies when active scanning. It uses 2 headers Cookie with different values so it never accesses authenthicated page. It seeem like a bug for me so far. I will test more deeply and file new thread once confirmed.

Lubos

[Ľuboš Katrinec]

thc202, could you please provide exact URL from active scan which reflected SQL injection vulnerability? I changed DVWA code so it bypasses cookie sessions so one doesn't have to login. Clicking "active scan single url" doesn't produce any alert (tested on dvwa/vulnerabilities/sqli).

L.

[thc202]

Hi.

Sorry for not answering sooner (answering to the previous messages too).

sorry for delayed answer. (I've lost lot of data including virtual machines due to corrupted hard drive so I had to build the env from scratch.)
I followed your scenario and it has successfuly found the parameters.

No problem and thank you for letting us know that you were able to spider correctly.

I think the issue was in cookies. I didn't know about "Enable Session Tracking (Cookie)". I was thinking that cookies are tracked by default (I could see them in http sessions and have set active the logged one).

The problem is that the cookie "security" is not managed by default by the "Http Sessions" tab and it's needed to have the security level set to "low".

I think I've found the issue. One thing is that spider changes admin password when tampering with parameters => that's ok.

It didn't happen to me but yes that's because of the spider submitting the forms.

But another issue is with session cookies when active scanning. It uses 2 headers Cookie with different values so it never accesses authenthicated page. It seeem like a bug for me so far. I will test more deeply and file new thread once confirmed.

Yes, it's issue 15 [1]. Although it shouldn't be sending different session cookies (most likely you were logged out after spidering).
To avoid this issue probably would be better to add a new "session" token, with name "security", to the list of session tokens so the "Http Sessions" tab can be used instead of using the "Enable Session Tracking (Cookie)" option.

thc202, could you please provide exact URL from active scan which reflected SQL injection vulnerability?

I'm attacking the "Sites" tree node "GET:sqli(Submit,id)" and the alert reported is "SQL Injection - UNION Based - MySQL".

I'm using the version 6 of the "Active scanner rules" add-on.

There's another add-on "Active scanner rules (beta)" [2] (can be installed through the marketplace [3]) that contains more SQL injection attacks which detect more SQL injections (including the page "sqli_blind" ("Sites" tree node "GET:sqli_blind(Submit,id)").

Clicking "active scan single url" doesn't produce any alert (tested on dvwa/vulnerabilities/sqli)

You need to select/attack the node that has the form request not the page itself ("GET:sqli(Submit,id)" instead of "GET:sqli").

Let me know if that worked.


[1] https://code.google.com/p/zaproxy/issues/detail?id=15
[2] https://code.google.com/p/zap-extensions/downloads/list?q=ascanrulesbeta
[3] https://code.google.com/p/zaproxy/wiki/HelpUiDialogsManageaddons

Best regards.

[Ľuboš Katrinec]

Hi,

indeed, I didn't realised that point - it didn't track the "security" cookie and therefore DVWA set it to hight by default.

I succeeded even without installing beta version of active scanner rules plugin. For successful attack I had to activate particular http session instead of enabling session tracking (because of the issue 15).

Thank you for great comments and help.

Lubos

[thc202]

Hi.

That's great!

Best regards.