[cgiapp] XSS

Barry Moore barry.moore at genetics.utah.edu
Wed Feb 6 19:06:49 EST 2008


Sorry for the second post.  I decided that this topic has diverged  
enough it should be a separate thread.  Reply to this one instead if  
you see it in time.

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://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>




More information about the cgiapp mailing list