“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 which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email 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. Many popular guestbook and forum programs allow users to submit posts with html and javascript embedded in them. If for example I was logged in as “john” and read a message by “joe” that contained malicious javascript in it, then it may be possible for “joe” to hijack my session just by reading his bulletin board post.
“What are the threats of Cross Site Scripting?”
Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user (Read below for further details) in order to gather data from them. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. The post below by Brett Moore brings up a good point with regard to “Denial Of Service”, and potential “auto-attacking” of hosts if a user simply reads a post on a message board.
About Dinesh MistryI am a full time Security Professional, Ethical Hacker, and overall technology enthusiast. I also enjoy working on Search Engine Optimization as time permits.
I’m guessing the “auto-attack” he’s referring to in said post is actually what’s referred to as Persistent XSS, in which a user enters a strategically-crafted string (possibly including JS, VBS, ActiveX, etc) into a form that serves as database input via a web application. That database input may potentially be called by the web frontend as part of a dynamically-produced page (in the context of a SELECT statement made by the application), serving the script to the browser as parsed HTML. The script may contain a malicious payload, and can potentially compromise the browsing system (e.g. The newest version of the ASPRox botnet propagation tool features a form injector that allows this method to be exploited) This can be prevented by using one (or more) of the below tactics, which are listed in order of feasibility and effectiveness from greater to lesser:
- Validate form input within the web application code – there are libraries to make this reasonably easy.
- Validate database output to avoid dynamically producing a webpage that includes unexpected script content.
- Run a script to audit the contents of the database for unexpected special characters (primarily things like ‘<'). This is time and resource consuming, though periodic integrity checks are always a good idea.
As a web user, I highly recommend utilizing an addon such as noscript as a precautionary measure against Persistent Cross-Site Scripting.