Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

False positives -- caused by insignificant HTML differences? #38

Closed
GoogleCodeExporter opened this issue Mar 17, 2015 · 1 comment
Closed

Comments

@GoogleCodeExporter
Copy link

I just ran Skipfish against a website on our staging server.  The scan took
a couple of days to run (10 million hits on DB driven site -- should have
used a smaller dictionary!), and came up with 3000 odd issues.

Scanning through, almost all issues are of the form:

#  http://xxxx/numbers/letters.html/-2147483649 
Memo: response to -(2^31-1) different than to -12345

I believe these to be false positives, as the responses seem to be the
same, except for two things:

1) A comment in the footer of the page source that looks like this:
<!-- Generated by Messiah Ltd. on Fri, 26 Mar 2010 08:31:15 +1300 in 23.7
milliseconds. -->

2) An image tag that is randomly selected (server-side) for each page view.

3) A small quote, also randomly selected per page view.

The scan was run using Skipfish version 1.11b.  It only just finished, and
I haven't yet scanned again with a newer version.





Original issue reported on code.google.com by leon.mat...@gmail.com on 25 Mar 2010 at 7:38

@GoogleCodeExporter
Copy link
Author

I would consider these substantial differences. Why is the comment block 
appearing 
and disappearing at random, for example?

Skipfish is using the differential approach to catch blind injection attacks; 
for 
example, if for one input, the page returns:

<span>No matches for 'foobar' found</span>

...but for another, does:

<span>[An error occurred processing this directive]</span>

...we want to be able to detect it. While skipfish permits a certain amount of 
subtle 
changes on the page, and only looks at word length distribution to build a 
signature, 
in your case, it has no way to tell this vulnerable case from the example of 
your 
service, where something around 16 words randomly appears and disappears on a 
page.

There is a check that tries to detect this by sending around 15 pre-fuzzing 
requests 
and comparing the responses, but there is only so far it can go.

My recommendation would be to disable the disappearing comment and QOTD 
functionality 
for the duration of the scan. Otherwise, I don't think this can be 
realistically 
fixed, unless skipfish is redesigned to use a signature-based approach, which 
is 
generally inferior.

Cheers,
/mz

Original comment by lcam...@gmail.com on 25 Mar 2010 at 7:58

  • Changed state: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant