Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: b0iler (b0iler_at_eyeonsecurity.net)
Date: Tue Sep 24 2002 - 11:37:05 CDT
> Yahoo did that :) check:
> I think that the check should be in the end in the webapp, when
> `displaying' data - where the script is interpretable,
Again.. of course the best way would be if ALL web apps did not allow
scripting. But this is impossible. There will always be mistakes in web
applications which allow for XSS to happen. Not everyone is a security pro,
and even they have mistakes. I think you got the wrong idea of what this is
for. It is not to secure web apps, but to secure end users from bad web
apps. We cannot fix every problem in everybodies code, but we can prevent
these problems from effecting us (Sort of like stackguard, you cannot prevent
all problems, so you prevent the problems from effecting you. of course the
best solution would be to make all code secure, but this is impossible.)
The idea here is for the end user to be protected against all sites. Do you
trust the admin of every site you visit to not let any XSS problems exist?
Of course not.
> since on submission may be multiple escaped/encoded to bypass the webapp
> filter logic.
The web browser would send data. If that data is in the data it
recieves, then it will not interpret this data as any type of scripting. It
does not matter what type of encoding tricks are done, if it is the same data
passed to the script as is recieved then it is not interpreted. The only
thing which should be converted by default is url encoding and + into space.
There should also be both encoded and not encoded checks done on these.
To ensure that there is no way for an attacker to use the idea of the script
changing url encoding to ascii as a way to evade this protection. As I said
in the orignal post, other changes to the sent data on the web app end cannot
be checked, so if a web app changes anything else in the sent data, then
there is no way to check that it is the same data being recieved. This is a
major pitfall, but I still feel this could prevent alot of XSS from happening.
client side web languages to choose from it is a joke that web apps try to
yahoo and in geocities (a yahoo site), I doubt they are secure.
Watch out for a paper on "Methods of Evading Script Filters in Web
Applications" on my site.