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. >>>>>>> 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 >>>>>> >>> >> > > ------------------------------------------------------------------------------ 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
