FP in cookie #2
Hello, arachni found few sql-i on different websites (cookies) and all of them are FP, one of them:
Is there anything for change to avoid such FP ?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by John on 21 Mar, 2017 05:35 PM
vuln:
Support Staff 2 Posted by Tasos Laskos on 22 Mar, 2017 05:08 AM
Can you attach the full issue data rather than just the vector please?
3 Posted by John on 22 Mar, 2017 11:27 AM
of course, sent it via email :)
Support Staff 4 Posted by Tasos Laskos on 22 Mar, 2017 01:41 PM
Got it, thanks.
Support Staff 5 Posted by Tasos Laskos on 24 Mar, 2017 01:44 PM
I tried to reproduce a few but I couldn't and I don't want to run a full scan against a production server.
I'll leave this issue open so if you come across any more such cases please let me know, I hope the new cases will be more clear-cut.
6 Posted by John on 24 Mar, 2017 01:50 PM
i've got two more already, they are same - in cookie with strange vector
Support Staff 7 Posted by Tasos Laskos on 24 Mar, 2017 01:51 PM
Same site?
8 Posted by John on 24 Mar, 2017 01:58 PM
no, anouther. I need some time to find scan logs, will send as soon as i find them
Support Staff 9 Posted by Tasos Laskos on 24 Mar, 2017 01:58 PM
Great, thanks.
10 Posted by John on 24 Mar, 2017 04:03 PM
sent via email
Support Staff 11 Posted by Tasos Laskos on 25 Mar, 2017 01:24 PM
You seem to be killing the DB and at some point during the gathering of the responses for the differential analysis the sites return errors and this leads to the data being corrupted and to the FP.
Problem is that you can't get around this. There are safeguard in place to prevent this to an extent, but if the error occurs at precisely the right time in the right way then you'll get an FP.
The only way to fix this issue is to lower the HTTP concurrency setting to a level that doesn't stress the server.
Also, since the DB gets shot, this can not only lead to FPs but to FNs too, since you're basically disabling the sites for a short while.
12 Posted by John on 26 Mar, 2017 05:31 PM
It can't be server stress because:
1. Reposnes are stable during whole scan
2. FP appear at same place every time i tried to rescan (all websites)
So it seems for me to be arachni-side problem still. Do you have any other ideas about such cases?
Support Staff 13 Posted by Tasos Laskos on 26 Mar, 2017 05:43 PM
Also, one of the pages in the JSON report you provided actually was for a DB error page, so I'm fairly certain I'm right.
In addition, the issues couldn't be reproduced individually so that also points to Arachni not being the issue, but to the server changing its behavior at some point during the scan.
If you get more such issues I would love to see them, but so far everything points to the problem being server-side rather than Arachni.
14 Posted by John on 26 Mar, 2017 05:46 PM
ok, i'll try tomorrow with lower concurrency level (what should i use? how much browsers in cluster?)
Support Staff 15 Posted by Tasos Laskos on 26 Mar, 2017 05:47 PM
I'd say play it safe and set HTTP concurrency to 5 and browsers to 2. It'll take a long time but could prevent the errors. It may not though, I can't know for sure.
16 Posted by John on 26 Mar, 2017 05:49 PM
ok, will send you results tomorrow
Support Staff 17 Posted by Tasos Laskos on 27 Mar, 2017 02:19 PM
Summary of e-mail discussion for posterity: Verified as a server issue, the DB started refusing connections and thus results for such scans are meaningless.
Tasos Laskos closed this discussion on 27 Mar, 2017 02:19 PM.