king155 / skipfish

Automatically exported from code.google.com/p/skipfish
Apache License 2.0
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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