Prevent Cross Site scripting

If I added the following, would this prevent Cross Site Scripting issues: <cfif   urldecode(cgi.QUERY_STRING) contains "<" or     urldecode(cgi.QUERY_STRING) contains ">" or     urldecode(cgi.QUERY_STRING) contains "[" or     urldecode(cgi.QUERY_STRING) contains "]" or     urldecode(cgi.QUERY_STRING) contains "*" or     urldecode(cgi.QUERY_STRING) contains "(" or     urldecode(cgi.QUERY_STRING) contains ")" or     urldecode(cgi.QUERY_STRING) contains "\" or     urldecode(cgi.QUERY_STRING) contains "{" or     urldecode(cgi.QUERY_STRING) contains "}" or     urldecode(cgi.QUERY_STRING) contains "delete" or     urldecode(cgi.QUERY_STRING) contains "drop" or     urldecode(cgi.QUERY_STRING) contains "exe">            BAD STRING!     <cfabort>      </cfif> Thanks Jacob

Not necessarily, but this will help: Name: #htmleditformat(user_entered_data_I_dont_trust)# XSS from my understanding is when someone is able in inject HTML/JS into a page so it is executed and then they can manipulate the contents of the page and or make an Ajax call which will send any cookies the site has.   The easiest way for people to do that is when you have a text area or input field which is later displayed on an HTML page and special characters are not escaped. For instance, entering a name like <script language="javascript">alert('I\'m in!');</script> When that value was output in an HTML page, the script block would be executed in the security context of that page. Also keep in mind, the cgi.query_string only includes url vars, not form variables.  I prefer to sanitize them at the point of outputting them, not at the point of collecting them.  There may be a good reason to have some special characters in a form field. ~Brad If I added the following, would this prevent Cross Site Scripting issues: <cfif   urldecode(cgi.QUERY_STRING) contains "<" or     urldecode(cgi.QUERY_STRING) contains ">" or     urldecode(cgi.QUERY_STRING) contains "[" or     urldecode(cgi.QUERY_STRING) contains "]" or     urldecode(cgi.QUERY_STRING) contains "*" or     urldecode(cgi.QUERY_STRING) contains "(" or     urldecode(cgi.QUERY_STRING) contains ")" or     urldecode(cgi.QUERY_STRING) contains "\" or     urldecode(cgi.QUERY_STRING) contains "{" or     urldecode(cgi.QUERY_STRING) contains "}" or     urldecode(cgi.QUERY_STRING) contains "delete" or     urldecode(cgi.QUERY_STRING) contains "drop" or     urldecode(cgi.QUERY_STRING) contains "exe">            BAD STRING!     <cfabort>      </cfif> Thanks Jacob

> If I added the following, would this prevent Cross Site > Scripting issues ... No, that's not sufficient. First, there are other scopes that can contain XSS attack patterns. Second, you're better off following a "deny all, then allow" approach instead of what you're doing. You can't guarantee that you can identify every possible unsafe character or sequence. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Training: Adobe/Google/Paperthin Certified Partners http://training.figleaf.com/ WebManiacs 2008: the ultimate conference for CF/Flex/AIR developers! http://www.webmaniacsconference.com/

So what do you recommend instead? The built in xxs protection doesn't catch everything.

I'm not sure if you're directing that question at Dave or me, so I will clarify my recommendation just in case. ============================== Any time you embed text which a user/third party enters or has control over into another media, ensure that the potentially-unsafe text has any necessary meta-characters escaped. ============================== That means if you want to output a name from the database into a JavaScript variable, you should run it through jsstringformat to remove any single ticks etc. var users_name = '#jsstringformat(my_query.users_name)#'; If you are building an XML document out of user-entered form fields, use xmlformat. <root><employee>#xmlformat(form.name)#</employee></root> If you are outputting a message in an HTML page, use htmleditformat. <table>   <tr>     <td>       #htmleditformat(qry_message.message_text)#     </td>   </tr> </table> Any time you are evaluating a string as code like as in a JSON string returned from an external web service, use a JSON parser instead of just throwing it into an eval() function. I know those are all generic examples, but I don't think there is necessarily a "silver bullet" snippet of code you can paste at the top of your page that will catch everything.  In theory, if ALL data were properly escaped/sanitized according to the environment it was being embedded in, XSS attacks would not exist.  In my opinion, _most_ XSS attacks happen because programmers get lazy-- a sin I've certainly been guilty of myself. ~Brad So what do you recommend instead? The built in xxs protection doesn't catch everything.

> So what do you recommend instead? The built in xxs protection > doesn't catch everything. I recommend that you consider accepting and storing "unsafe" strings, and escape them appropriately when displaying them. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Training: Adobe/Google/Paperthin Certified Partners http://training.figleaf.com/ WebManiacs 2008: the ultimate conference for CF/Flex/AIR developers! http://www.webmaniacsconference.com/

Why store junk? if you're going to store data shouldn't it be escaped/purified before you store it? then you're escaping it once as opposed to escaping it 1000's of times every time you display/output it? ----- Excess quoted text cut - see Original Post for more -----

How do you know it's junk?  Let's say you have a last name of "O'reilly" entered into a form field.  That string will break the following of code: <script language="javascript">   alert('#last_name#'); </script> You would not want to remove the tick from the name in the database, as now you have lost part of your data.  Instead you sanitize it at the time you output it with jsstringformat. Now, some of you are probably thinking, "Why don't you just escape it when you put it into the database?"  My answer to that is, "How do you know in what context that data might need to be displayed?"  If you escape the data for a JavaScript string at the time you store it, then it won't look right when you want to output it in HTML.  OK, so you might think you should escape it for HTML at the time you store it-- now you write a flex front-end for your app and wish to display it in Flash. There are reasons other than malicious attacks to clean your data, and it is my option that the interface responsible for displaying the data should also be responsible for cleaning it appropriately.  If that is done, "O'Reilly" won't be an issue and neither will XSS. If you are concerned about the performance implications of formatting the data over and over again you could cache static pages and serve them up.  If your data is ever-changing, I consider this overhead a small price to pay that comes with the business of storing and regurgitating data. ~Brad Why store junk? if you're going to store data shouldn't it be escaped/purified before you store it? then you're escaping it once as opposed to escaping it 1000's of times every time you display/output it? >> So what do you recommend instead? The built in xxs protection >> doesn't catch everything. > >I recommend that you consider accepting and storing "unsafe" strings, and ----- Excess quoted text cut - see Original Post for more -----

Sorry, you haven't convinced me, I appreciate what you're saying but having to cache the static pages after you've cleansed them doesn't seem right either.... Of course if you're relying on javascript to display as in ajax then you have a point. Andrew. ----- Excess quoted text cut - see Original Post for more -----

Displaying or using data now in one way doesn't necessarily mean that's how you or someone else may need or want to display or use it later. It has been my experience that storing data just as it was entered is the better solution all around. Once you strip information out that you deem unsafe for your current needs, you can't get it back later if/when you or someone else decides otherwise. .:.:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com http://cf4em.com Sorry, you haven't convinced me, I appreciate what you're saying but having to cache the static pages after you've cleansed them doesn't seem right either.... Of course if you're relying on javascript to display as in ajax then you have a point. Andrew. ----- Excess quoted text cut - see Original Post for more -----

> Why store junk? if you're going to store data shouldn't it be > escaped/purified before you store it? then you're escaping it > once as opposed to escaping it 1000's of times every time you > display/output it? As Brad pointed out, who's to say what's junk? It is impossible, practically speaking, to identify every possible "bad character" that may exist in your data, and you may want to use that data in different ways and different places. You may, in fact, want to use data in new ways in the future, only to find that you have new vulnerabilities for which your current data is unsanitized. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Training: Adobe/Google/Paperthin Certified Partners http://training.figleaf.com/ WebManiacs 2008: the ultimate conference for CF/Flex/AIR developers! http://www.webmaniacsconference.com/

Ok, point taken, I was thinking in the context of a forum application where one may have strict rules on user input and that input may go through complex validation that might be server intensive and probably would be unlikely that the data validation would require future review. If new vunerabilities were found the data could still be parsed and updated in the database once as a seperate call instead of every time it is outputed.    The primary objective should be as Dave said: "deny all, then allow". Andrew ----- Excess quoted text cut - see Original Post for more -----