Frank, On Thu, Aug 25, 2011 at 8:27 PM, Frank van der Loo <[email protected]> wrote: > On 26-08-11 01:11, Andres Riancho wrote: >> >> Frank, >> >> On Thu, Aug 25, 2011 at 7:57 PM, Frank van der Loo >> <[email protected]> wrote: >>> >>> On 26-08-11 00:39, Andres Riancho wrote: >>>> >>>> Frank, >>>> >>>> On Thu, Aug 25, 2011 at 7:20 PM, Frank van der Loo >>>> <[email protected]> wrote: >>>>> >>>>> On 25-08-11 23:06, Javier Andalia wrote: >>>>>> >>>>>> On Thu, Aug 25, 2011 at 4:07 PM, Andres Riancho >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Frank, >>>>>>> >>>>>>> Thanks for your email, please see answers inline: >>>>>>> >>>>>>> On Tue, Aug 23, 2011 at 5:50 PM, Frank van der Loo >>>>>>> <[email protected]> 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. >>>> >>>> That's good news :) >>>> >>>>>>>> - 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. >>>> >>>> Very interesting. Could you send us an HTML to reproduce? >>> >>> <html> >>> <body> >>> <?php >>> //if ($_SERVER['REQUEST_METHOD'] == "POST") >>> if (isset($_POST['sbm'])) >>> { >>> echo $_POST['inp']; >>> } >>> ?> >>> <form name="frm" method="post" action=""> >>> <input type="text" name="inp"><br> >>> <input type="submit" name="sbm" value="submit"> >>> </form> >>> </body> >>> </html> >>> >>> This simple PHP-script reproduces the problem. If you run w3af against >>> this >>> script it will not find the XSS vulnerability that is present in this >>> script. However, if you uncomment the first if-statement and comment the >>> second if-statement w3af will find the vulnerability. >> >> Copy-Pasted the PHP, run w3af (without any special configuration) and >> the XSS was found: >> >> """ >> Cross Site Scripting was found at: "http://localhost/index.php";, using >> HTTP method POST. The sent post-data was: >> "inp=<SCrIPT>alert("lqH0")</SCrIPT>&sbm=submit". This vulnerability >> affects ALL browsers. This vulnerability was found in the request with >> id 131. >> """ >> >> Attaching PCAP where you can also see that the submit is sent. > > That's strange. It doesn't here > > frank@darkstar:/tmp/w3af$ ./w3af_console > w3af>>> target > w3af/config:target>>> set target http://localhost/test/button.php > w3af/config:target>>> back > w3af>>> plugins > w3af/plugins>>> audit xss > w3af/plugins>>> back > w3af>>> start > Found 1 URLs and 2 different points of injection. > The list of URLs is: > - http://localhost/test/button.php > The list of fuzzable requests is: > - http://localhost/test/button.php | Method: GET > - http://localhost/test/button.php | Method: POST | Parameters: (inp="") > Scan finished in 0 seconds. > w3af>>> version > w3af - Web Application Attack and Audit Framework > Version: 1.0-stable-4286 (from SVN server) > Revision: 4389 > Author: Andres Riancho and the w3af team. > > Only when I change the if-statements w3af detects the vulnerability.
Good you confirmed this. I found a bug! But it's not in the process of parsing/injecting/etc. It's in the way we print stuff to the console. I'll explain this to Javier tomorrow (it has something to do with the unicode change he did a couple of weeks ago). >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/w3af-users
