Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: b0iler (b0iler_at_eyeonsecurity.net)
Date: Tue Sep 24 2002 - 11:37:05 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > In the end disallowing javascript-like words?
    > Yahoo did that :) check:
    > http://www.ntk.net/2002/07/12/

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

    Also, disallowing javascript like words does jackshit. There are so many
    client side web languages to choose from it is a joke that web apps try to
    just filter javascript. I remember finding very simple XSS problems with
    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.