Websecurify 0.7RC1

[pdp]

...is available for download: http://code.google.com/p/websecurify/downloads/list

again, bug reports, feedback and honest opinion is what we are looking
at this stage :)

[saso]

1. i see a bug removing/deleting a workspace, i get an error that the
workspace cannot be deleted. it seems like this happens only to
workspaces that ware created in current session (so for example if i
close and reopen WS the they can be deleted).

2. about the crashes that also others report... i seems to get a crash
at the scan phase (both 0.6 and this 0.7 rc1), every time when i click
on the "login or initialize target" before i do the scan. if i just
input the target and click ok i get no crashes.

3. i contacted you some days ago via twitter asking about the "page
xss". are the improved xss checks already available in this build,
because i still don't see/get some expected detections.

[Petko D. Petkov]

Hi saso,

First of all, thanks for the feedback and the bugs. My comments on your 3 points are as follows:

1. Fixed! Although workspaces in 0.7 are incompatible with 0.6, there was a bug in the code which prevented all open workspaces from being deleted or renamed. However, if you ask why they are incompatible, well this is because Websecurify will stay unfrozen until version 1.0 which should come soon.
2. This bug is known and we are already working on it. The reason this happens is because the test launch dialog is modal while the browser is not. However, windows opened from modal dialogs are automatically made modal as well. The solution will be to either make the test launch dialog not modal or put the target initialisation code somewhere else or perhaps completely remove it and rely on the standard browser. Will see!
3. The short answer is no. The long answer is that the main priority is stability which hopefully will be sorted by version 1.0. Advanced checks exist but are not enabled in 0.7RC1. I am not sure what will be the situation for 0.7RC2. Will see!

Although the advanced XSS and SQLI checks are not enabled in 0.7RC1, you get an awesome auto screen-shooting functionality.

[saso]

3. about this xss... somehow i have the feeling that the problem is
not really that the checks are not advanced enough. first of all it is
probably my fault not explaining the issue with enough details and
also using this confusing "page xss" description for it. so i will try
to correct this mistake now :)

what i actually meant with "page xss" is probably better known as "xss
in path" where you can add a simple xss to the url (for example just
adding something as simple as ?'><script>alert(2)</script> to the end
of an url is enough to trigger my test). an example of it is where the
page for one or another reason includes the url (path) in its html
(for example using the $_SERVER['REQUEST_URI'] ).

i have noticed that modern browsers try to help protecting from such
xss by escaping the uri, so the above simple example will not work in
a modern browser (it will in IE6), but WS should still be able to
detect it since the web page code itself is still unsafe.

i did not look in the traffic log of WS for xss tests, so i don't know
what is going on, but is it possible that WS is testing for this
thing, but because it is based on mozilla it does not see it since it
gets automatically escaped?

On Jul 28, 1:56 pm, "Petko D. Petkov" <pdp.gnuciti...@gmail.com>
wrote:

[pdp]

well, this shouldn't be the case but will investigate. thanks for the
feedback. it is much appreciated.

[saso]

just a small update...

i am not that experienced in web development and testing, so when i
was playing now a bit more with the above issue i noticed that my
first assumption (that newer browsers are auto escaping possible
dangerous urls) is probably wrong. the situation was that i had a
small test server in an virtual machine on the local network and when
i opened the test page with all newer browsers the url from the
$_SERVER['REQUEST_URI'] was automatically escaped, but when i opened
that page with IE6 it was not, this is why i assumed browsers are
doing this.

i have later upload the same page also on a hosted sever, there
however i have noticed that the url was automatically escaped in all
browsers, even IE6. so i am assuming now that this auto escape is
happening on the sever side (a function of apache or php ?). anyway,
it is still a mystery to me why in that situation the url is not
escaped for IE6 (some bug or even a feature of apache/php ?). if i
will have some time to play with this a bit more and if i find some
more info i will write an update about it here...

the more important question for the WS is if it should be able to
detect such things and how? the code itself is vulnerable but
something is auto escaping it and making it safe. and so we come to
situations like above where it is sometimes detected and other times
not.

[Petko D. Petkov]

The websecurify scanning engine sends request almost raw. However, the browser may escape certain values so that they are compliant with the URL/URI specs. This is a common problem and almost aways you can find a workaround. If websecurify detects a problem it means that it exists at HTTP level. Please do keep me in the loop if you find something unusual.

Thanks for the feedback.

--
Petko D. Petkov | GNUCITIZEN.org
PGP Key ID: 0xF2FD757A