OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Bill Pennington (billpboarder.org)
Date: Tue Jan 29 2002 - 19:15:57 CST

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

    You cannot simple check for the strings to be returned to you, while 99% of
    the time it will work you will run into jokers that reformat the output thus
    rendering it non executable. A good example is putting <pre> </pre> tags
    around output. Doing so will cause the script code to be displayed but not
    executed.

    the other area you have to watch out for are short strings that get returned
    (to short for a CSS payload) but together separated by a comment string (hey
    Sverre :-) ) get executed.

    Maybe I am just being a bit to picky about this but you should verify that
    the code actually executes and not that the string simply gets returned.

    ----- Original Message -----
    From: "James Fleming" <jamesfleming94588yahoo.com>
    To: "Shields, Larry" <Larry.ShieldsFMR.COM>; "'Sverre H. Huseby'"
    <shhthathost.com>
    Cc: <webappsecsecurityfocus.com>
    Sent: Tuesday, January 29, 2002 10:04 AM
    Subject: RE: How to test for Cross Site Scripting

    > Agree. Seems there is two ways to check if it was
    > successful. One is if the CSS was in the response
    > thats a dead give away. Examine response stream and
    > away you go. Second would be much more difficult. You
    > would need to search all possible outputs and given
    > the attack maybe pushing script in that only one other
    > user (admin) would run thats *really* difficult.
    >
    >
    > --- "Shields, Larry" <Larry.ShieldsFMR.COM> wrote:
    > > Sverre,
    > >
    > > It's a good point to make this clarification.
    > > However the question
    > > was how do you know if the test was successful.
    > > It's always difficult to
    > > know if there's going to be a problem somewhere down
    > > the line. You know
    > > you're successful if you can make it work. You can
    > > never know for sure,
    > > otherwise, unless you have full access to the code &
    > > architecture.
    > >
    > > In this regard, it's similar to other application
    > > testing. If you
    > > don't find a way to break the application, it
    > > doesn't mean there isn't a
    > > vulnerability. Just that you didn't find anything.
    > > Something all of us
    > > need to remember. =)
    > >
    > > -Larry Shields
    > > Internet Security Risk Assessment / Fidelity
    > > Investments
    > >
    > > >| >How do you know if a test was successful?
    > > >|
    > > >| If I am able to inject any of my own code
    > > that executes in the
    > > >| script, it has worked. Obviously the easiest
    > > for simple testing
    > > >| is to pop an "alert" window with a message in
    > > it.
    > > >
    > > >It should be noted that if you are _not_ able to
    > > insert code that
    > > >executes, it does not necessarily mean that the
    > > site is not
    > > >vulnerable. It just means that _you_ are not able
    > > to do it. Or maybe
    > > >it means that they successfully prevent script in
    > > the page you test,
    > > >but you can hardly know when your input will show
    > > up in another page,
    > > >or in an HTML formatted mail generated by the site.
    > > >
    > > >You can prove that they are vulnerable to CSS, but
    > > you cannot prove
    > > >that they are not. (I guess you knew that Larry,
    > > but I _know_ other
    > > >people don't, so I wanted to mention it.)
    >
    >
    > __________________________________________________
    > Do You Yahoo!?
    > Great stuff seeking new owners in Yahoo! Auctions!
    > http://auctions.yahoo.com
    >