Thursday, August 11, 2011

Another XSS vulnerability


Vulnerability located in the Shop for memory, an european specialist computer online supplier shop is a possible XSS attack candidate.. Date of writing their site had this vulnerability...
Keyword: <script>alert(document.cookie)</script>
Attack URL: http://www.shop4memory.com/search/?k=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E
For those who are new to XSS, it is
Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
How to get rid of Input validation errors:
(aka: sanity checking, input filtering, white listing, etc.)
Input validation is one of those things ranted about incessantly in web application security, and for good reason. If input validation was done properly and religiously throughout all web application code we’d wipe out a huge percentage of vulnerabilities, XSS and SQL Injection included. I’m also a believer that developers shouldn’t have to be experts in all the crazy attacks potentially thrown at a websites. There’s simply too much to learn and their primary job should be writing new code, not to become web application hackers. Developer should only have to concern themselves with the solutions required to mitigate any attack no matter what it might be. This is where input validation comes in play.
Input validation should be performed on any incoming data that is not heavily controlled and trusted. This includes user-supplied data (query data, post data, cookies, referers, etc.), data in YOUR database, from a third-party (web service), or elsewhere. Here are the steps that should be performed before any incoming data is used:
Normalize
URL/UTF-7/Unicode/US-ASCII/etc decode the incoming data.
Character-set checking
Ensure the data only contains characters you expect to receive. The more restrictive the rules are the better.
Length restrictions (min/max)
Ensure the data falls within a restricted minimum and maximum number of bytes. Limit the window of opportunity for an attacks as exploits tend to require lengthy input strings.
Data format
Ensure the structure of the data is consistent with what is expected. Phone should look like phone numbers, email addresses should look like email address, etc.