Oops, I just noticed I clicked on Reply instead of Reply all.
-------- Original Message --------
Subject: Re: [W3af-develop] Suggestions for improvement
Date: Fri, 26 Aug 2011 00:57:31 +0200
From: Frank van der Loo <f.vander...@student.science.ru.nl>
To: Andres Riancho <andres.rian...@gmail.com>
On 26-08-11 00:39, Andres Riancho wrote:
Frank,
On Thu, Aug 25, 2011 at 7:20 PM, Frank van der Loo
<f.vander...@student.science.ru.nl> wrote:
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.
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.
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
