RE: [WEB SECURITY] Cross Site Scripting

["White, Dain P" <dainw@xxxxxxx>]

Speaking "from the trenches" so to speak as a developer, and not as a
security expert like the fine folks on this list - - In that world, I
have to be able to provide WYSIWYG capabilities for content, supporting
drag and drop, etc. That alone is enough to send me running to the
hills. The challenge is to create a system that supports WYSIWYG
editing, but prevents malicious code to be inserted - - I've classified
my approach to solve this problem as a "greylist".

First, the input (as a big ol' blob) is split into chunks, and each
chunk tested to see if it is content, or markup. My system only allows
certain tags, so if those are found they are parsed and re-written to
remove anything that isn't critical to the function of the tag (like
OnError, etc). All unsupported tags are removed. That's what I call the
whitelist portion of the system.

The next step in the process is to take the content that will be shoved
back into the re-written tag and pass it through a series of regex
filters that look for "bad patterns". That's the blacklist portion. Note
that at this point, the content that is being tested for the bad
patterns is the variable values of the approved and re-written tags
(like '/images/site/picture.jpg', or 'this is alt text').

The result of these two interactions is what I call a greylist. This
system only fires off when I have to support WYSIWYG editing
capabilities, the rest of the time all markup is removed, datatypes and
lengths are enforced and whatever survives these sanity checks is then
HTMLEncoded.

Whatever makes it through that gauntlet is then turned into an array
before passing into the stored procedure to defeat SQL injection, and
generally nothing is displayed on the site until it has been approved.

~Dain

Dain White, Web Coordinator
Office of Student Affairs
Washington State University
dainw@xxxxxxx * 1-509-335-6673



-----Original Message-----
From: Hoffman, Billy [mailto:billy.hoffman@xxxxxx] 
Sent: Thursday, September 20, 2007 11:08 AM
To: Sergii Khomenko; 'Mad Unix'; websecurity@xxxxxxxxxxxxx
Subject: RE: [WEB SECURITY] Cross Site Scripting

No no no no  NO!

 

Sergii is describing black list input validation. This is *not* a good
solution to securing a web application (though I suppose it is better
than nothing at all). <img src=. onerror=alert('xss')> will bypass the
filter for <script> and still allow code execution. And that's the
problem with blacklists, they attempt to define everything that is bad.
The problem is this list is very large and changes every time someone
figures out a new way to do something bad. This is why magic quotes is
not a defense against SQL injection because you can perform SQL
injection without needing to use a single quote.

 

Inputs in web application should be validated using white list input
validation. For example, if an input is a US ZIP code, your web
application should only accept inputs that are 5 digits long (or
perhaps, 5 digits followed by a dash, followed by 4 digits)

 

Recently I've been trying to think of a better way for the average Joe
to understand Blacklists/whitelist. I used to talk about metal detectors
at airports, and how they are a blacklist for metal. As soon as
terrorists decide they can use ceramic knives, your metal detector stops
working. Unfortuantely this analogy freaks people out, and I really
don't have a good real-world equivalent for whitelist input validation.
Do you just get naked at the airport? :-)

 

Please stop advising people to use blacklist input validation. 

 

Billy Hoffman

--

Lead Researcher, HP Security Labs

HP Software

Phone: 678-781-4845

________________________________

From: Sergii Khomenko [mailto:sergey.khomenko@xxxxxxxxx] 
Sent: Thursday, September 20, 2007 10:45 AM
To: 'Mad Unix'; websecurity@xxxxxxxxxxxxx
Subject: RE: [WEB SECURITY] Cross Site Scripting

 

To reduce the risk and to prevent such an attack on your website, all
form information that is entered, should be checked for html code like
this <script>script code goes here</script>. Basically, your website
should not accept any script code from anyone on the web and especially
storing the code in the db and then outputting it to somebody else.

 

When you add validation for your input fields, you can run free web
vulnarability scanners like www.acunetix.com <http://www.acunetix.com/>
to see if you still have the vulns.

 

Hope this helps.

 

Sergii Khomenko

 

________________________________

From: Mad Unix [mailto:madunix@xxxxxxxxx] 
Sent: Thursday, September 20, 2007 10:53 AM
To: websecurity@xxxxxxxxxxxxx
Subject: [WEB SECURITY] Cross Site Scripting

 

Our security consulting compay he discoverd on our web server the
following risk:

 

Cross Site Scripting 
Risk: High

Description of Vulnerability

The Cross-Site Scripting attack is a privacy violation that allows an
attacker to acquire a legitimate user's 
credentials and to impersonate that user when interacting with a
specific website. 
The attack hinges on the fact that the web site contains a script that
returns a user's input 
(usually a parameter value) in an HTML page, without first sanitizing
the input. 
This allows an input consisting of JavaScript code to be executed by the
browser when the script returns this input 
in the response page. As a result, it is possible to form links to the
site where one of the parameters consists of malicious 
 JavaScript code. This code will be executed (by a user's browser) in
the site context, granting 
it access to cookies that the user has for the site, and other windows
in the site through the user's browser. 

 

 

--------------

Can any one tell me more about this effect and how to observe and
resolve this issue, since is be given as high risk.

Thanks



-- 
madunix

madunix@xxxxxxxxx 


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]