Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
Prevent Cross Site scripting
Author: Andrew Grosset
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303799
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 -----
Author: Bobby Hartsfield
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303798
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 -----
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303797
> 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/
Author: Andrew Grosset
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303796
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 -----
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303793
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 -----
Author: Andrew Grosset
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303792
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 -----
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303783
> 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/
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303773
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.
Author: Ian Rutherford
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303772
So what do you recommend instead? The built in xxs protection doesn't catch
everything.
Author: Dave Watts
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303717
> 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/
Author: Brad Wood
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303697
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
Author: Jacob
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:56073#303696
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
|
May 24, 2012
|
Latest Fusion Authority Articles
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
