mpeters at plusthree.com
Fri Feb 8 10:40:27 EST 2008
Barry Moore wrote:
> Basically one version of an XSS attack would be for me to enter
> any other users machine that subsequently loaded those tainted pages.
> My JS code could do anything that they could do including contact your
> server on behalf of them and send data back to my server. Is this correct?
Yes. This is what XSS means. There are variations on this, but it's bascially
the same thing.
> Then the rational for you to html escape any input that comes from me
> and any other user is because that escaping would render the JS code
> in-operable. Is that correct?
Yes. Imagine you have a form that asks me a survey question and I enter my name as:
Michael <script>alert("p0wnd!")</script> Peters.
Then you log into the admin side of you application and see my survey result.
You will get p0wnd. Now imagine that I instead of doing a simple alert() I
inserted a <script> tag that pulls in some JS from my own server which adds some
helpful (to me, not you) methods into your page that makes it really easy for me
to get your cookie information and then sends it back to my server. Now I can
log in to your admin side and do whatever I want.
> So then is is safe to assume that if the data from your form never gets
> sent back to other users (i.e. it only gets analyzed by your server -
> such as a search form) or if you check for JS code in some other way,
> then that would also prevent this form of XSS?
No. Imagine this scenario: I use your search form and input some malicious
create a URL that will take me to that results page. Something like
and I post it in some forum or email group (like this one) and people click on
it. Now I have their information.
Plus Three, LP
More information about the cgiapp