This is an interesting thread, and XSS is something that I haven't
really understood. Let me see if I'm understanding this correctly:
Basically one version of an XSS attack would be for me to enter
javascript code into a form on your web page. Then if you include my
form submission in other web pages then my javascript could execute
on 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?
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?
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?
Barry
On Feb 6, 2008, at 3:16 PM, Michael Peters wrote:
Mark Fuller wrote:
o Add the session id to the URL. This method has the most
problems, and
is not recommended.
What are the problems with the last option? ...
Google for XSS - Cross-site scripting attacks, as a starter.
I thought the problem with putting the session ID in the URL is that
the user might copy/paste the URL to others. When they try to use it,
the app would have no way to know it's not the real user?
While that is a problem (it holds true with any user identifiable
information
not just sessions. You need to especially watch what you put into
emails since
they will get forwarded) it's not XSS.
XSS is Cross Site Scripting. So you need 2 domains (hence the cross-
site) and it
involves Javascript (can also be ActionScript/Flash, VBScript, or
any other
future client-side scripting language). Basically it's problem of
people
embedding Javascript into a page that others will see. That
Javascript can steal
sessions, etc from the user who sees it. It doesn't matter if the
session id is
in the URL or a cookie, Javascript can see both.
This is why escaping any data that could potentially come from a
user is so
important.
<tmpl_var foo escape=html>
or
[% foo | html %]
--
Michael Peters
Developer
Plus Three, LP
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
