views:

146

answers:

5

I'm new to ColdFusion, so I'm not sure if there's an easy way to do this. I've been assigned to fix XSS vulnerabilities site-wide on this CF site. Unfortunately, there are tons of pages that are taking user input, and it would be near impossible to go in and modify them all.

Is there a way (in CF or JS) to easily prevent XSS attacks across the entire site?

+1  A: 

please watch: http://www.petefreitag.com/item/759.cfm

Henry
A: 

The ColdFusion 9 Livedocs describe a setting called "scriptProtect" which allows you to utilize coldfusion's protection. I've have not used it yet, so I'm not sure how effective it is.

However, if you implement a third-party or your own method of handling it, you would most likely want to put it in the "onRequestStart" event of the application to allow it to handle the entire site when it comes to URL and FORM scope violations (because every request would execute that code).

Mike Oliver
not very effective, unfortunately.
Henry
+8  A: 

I hate to break it out to you, but -

  1. XSS is an Output problem, not an Input problem. Filtering/Validating input is an additional layer of defence, but it can never protect you completely from XSS. Take a look at XSS cheatsheet by RSnake - there's just too many ways to escape a filter.
  2. There is no easy way to fix a legacy application. You have to properly encode anything that you put in your html or javascript files, and that does mean revisiting every piece of code that generates html.

See OWASP's XSS prevention cheat sheet for information on how to prevent XSS.


Some comments below suggest that input validation is a better strategy rather than encoding/escaping at the time of output. I'll just quote from OWASP's XSS prevention cheat sheet -

Traditionally, input validation has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?

To elaborate - when the user enters a string like O'Malley, you don't know whether you need that string in javascript, or in html or in some other language. If its in javascript, you have to render it as O\x27Malley, and if its in HTML, it should look like O'Malley. Which is why it is recommended that in your database the string should be stored exactly the way the user entered, and then you escape it appropriately according to the final destination of the string.

sri
What are yo talking about? It doesn't matter if you filter on input or output. Ultimately if you've filtered on input, then the output will be fine OR you can store it raw and filter it on every request which seems wasteful.
Klinky
@Klinky - See my updated response. Input filtering *helps*, but isn't a sure-shot solution to XSS.
sri
Good points, your update and actually reading the OWASP in more detail makes it a bit more clear why escaping on output would be advantageous and more flexible. I would still say validation is a requirement on things that can be validated effectively, for example you don't want to accept user input of a string when your db or javascript is going to be expecting an integer. That would not be an XSS issue though.
Klinky
@Klinky - Agree, input validation is very important and should always be a requirement. I am only against considering that as the solution to XSS and other related injection problems.
sri
+1  A: 

One thing you should look at is implementing an application firewall like Portcullis: http://www.codfusion.com/blog/page.cfm/projects/portcullis which includes a much stronger system then the built in scriptProtect which is easily defeated.

These are a good starting point for preventing many attacks but for XSS you are going to end up going in by hand and verifying that you are using things like HTMLEditFormat() on any outputs that can be touched by the client side or client data to prevent outputting valid html/js code.

Daniel Sellers
A: 

Besides applying all the ColdFusion hot fixes and patches you can also:

  1. Not full proof but helps, Set the following under CFADMIN > Settings > "Enable Global Script Protection"
  2. Add CSRFToken to your forms http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
  3. Check http Referer
  4. Add validation for all User inputs
  5. Use cfqueryparam for your queries
  6. Add HTMLEditFormat() on any outputs
  7. Besides Peter Freitag's excellent blog you should also subscribe to Jason Dean's http://www.12robots.com
Pragnesh Vaghela