On 25-08-11 23:06, Javier Andalia wrote: > On Thu, Aug 25, 2011 at 4:07 PM, Andres Riancho > <andres.rian...@gmail.com> wrote: >> Frank, >> >> Thanks for your email, please see answers inline: >> >> On Tue, Aug 23, 2011 at 5:50 PM, Frank van der Loo >> <f.vander...@student.science.ru.nl> wrote: >>> Hi, >>> >>> I wrote my master's thesis on penetration testing tools/vulnerability >>> scanners and I noticed some problems with w3af (version 1.0-rc5) that > Several months have passed since that version. > >>> cause false positives and false negatives. Unfortunately, I don't have >>> the time nor the Python skills required to fix these myself, or I would >>> have sent a patch. >> No problem! Reporting is an excellent first step! >> >>> - only one input is used at a time, while in some cases (e.g. password >>> and repeat password) it is required that both fields contain the same >>> value, because only one input is used w3af will miss an SQL injection if >>> the password is inserted into the database unvalidated >> That's a very difficult case do address, but an interesting one >> for sure! I never thought about that edge case. Created ticket to take >> care about this: >> https://sourceforge.net/apps/trac/w3af/ticket/167513 >> >>> - some sites place the content of headers like Referrer and User-agent >>> on a page, this behavior is vulnerable to XSS that is not detected by w3af >> I think w3af should detect these if you set "fuzzableHeaders" to >> "Referrer" or "User-agent" in misc settings. Have you tried this? >> >>> - when the content of an input is used in a link (e.g.<a >>> href="index.php?page=<script>alert('XSS');</script>...) or as value in a >>> text field (e.g.<input type="text" >>> value="<script>alert('XSS');</script>...) this is detected as an XSS >>> vulnerability while it is in fact harmless, it should be checked where >>> the content of the input is and if it is parsed by the browser >> Hmmm.... in SOME cases it's harmless, in some others it's not. >> Example where it IS harmless: >> >> #1 Send http://host.tld/foo.php?bar=<script> >> #2 Application answers: >> .... >> .... >> <a href="http://host.tld/foo.php?bar=<script>">link</a> >> >> #3 Send http://host.tld/foo.php?bar=<script>" >> #4 Application answers: >> .... >> .... >> <a href="http://host.tld/foo.php?bar=<script>%22">link</a> >> >> In some other cases it's not: >> >> #1 Send http://host.tld/foo.php?bar=<script> >> #2 Application answers: >> .... >> .... >> <a href="http://host.tld/foo.php?bar=<script>">link</a> >> >> #3 Send http://host.tld/foo.php?bar=";><script>alert('xss')</script><a href=" >> #4 Application answers: >> .... >> .... >> <a href="http://host.tld/foo.php?bar=";><script>alert('xss')</script><a >> href="">link</a> >> >>> - related to the above suggestion, if the input is preceded by "> any >>> HTML-tag the input may be present in will be closed, "ensuring" the text >>> does not appear in a tag and is thus parsed by the browser (it should >>> still be checked if the text is in a tag, because if the web application >>> escapes or removes quotes, or replaces them by HTML entities this does >>> not work). >> I agree that in some cases we need to add more checks to the XSS >> detection, BUT at the same time... I would rather raise a red flag to >> the analyst and maybe he can identify a way of "escaping"/"exploiting" >> that specific XSS. >> >>> - textareas are not used by w3af, only textfields (<input type="text") >> I think we fixed this. Javier: do you recall? > Actually we do use textareas in w3af. Frank, can you please validate > it using our most recent version?
I've downloaded version 1.0-stable, which was updated at first start to version r4389. This version does indeed use textareas. >>> - when an HTTP POST is sent to a page, the name/value pair of the submit >>> button is not sent in this POST, only the other inputs; some pages check >>> if a form is sent by checking if the name of the submit button is >>> present in the HTTP POST >> This is a serious bug, we'll fix it. >> > I'm not sure this is happening. Again, can you please Frank reproduce > it with a more recent version? Abovementioned version (r4389) still does not send the name/value pair of the submit button. w3af claims it does 'The sent post-data was: "add-to-your-blog-php-submit-button=Save+Blog+Entry&blog_entry=<ScRIpT>alert(String.fromCharCode(CHf3))</SCriPT>".', however the name/value pair of the submit button is not visible in the traffic logged with a packet sniffer. Also, when the script uses 'if(isset($_POST["add-to-your-blog-php-submit-button"]))' as test the vulnerability is not discovered, while it is discovered when the script uses 'if($_SERVER['REQUEST_METHOD'] == "POST")' as test. >>> Regards, >>> Frank van der Loo >>> >>> ------------------------------------------------------------------------------ >>> EMC VNX: the world's simplest storage, starting under $10K >>> The only unified storage solution that offers unified management >>> Up to 160% more powerful than alternatives and 25% more efficient. >>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >>> _______________________________________________ >>> W3af-develop mailing list >>> W3af-develop@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/w3af-develop >>> >> >> >> -- >> Andrés Riancho >> Director of Web Security at Rapid7 LLC >> Founder at Bonsai Information Security >> Project Leader at w3af >> >> ------------------------------------------------------------------------------ >> EMC VNX: the world's simplest storage, starting under $10K >> The only unified storage solution that offers unified management >> Up to 160% more powerful than alternatives and 25% more efficient. >> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev >> _______________________________________________ >> W3af-develop mailing list >> W3af-develop@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/w3af-develop >> ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
