If you haven’t yet met cross site scripting or XSS for short, it’s probably only a matter of time. And if your enterprise is running a web site that allows users to enter data, for example as search terms, consider XSS as a threat to be tackled now, not later. The short version of what XSS does is this: it uses vulnerabilities in a web application (such as a dynamic website) to let an attacker send malicious content via the application to another end-user victim. What can web application owners do to stop it?
Cross site scripting is not limited to scripting and does not have to involve multiple websites. But to keep things simple, here is a common scenario:
- A hacker infects your web page with content that can trigger actions in another user’s web browser. JavaScript, Java and Flash are all possible mechanisms.
- An innocent visitor visits your web page and uses the search or query function you provided.
- The visitor gets an answer back, to which the malicious content is appended.
- The malicious content that has now found its way into the innocent visitor’s browser triggers one or more actions, often unknown to that visitor.
Even if your own web page or application is not negatively affected by the content, the reputational damage to your organisation of can be devastating. Protection starts with good programming practice to properly validate or escape data, i.e. make sure what a visitor sends matches what you ask for. Additional precautions include the creation of a whitelist to test an input against a list of possible correct inputs and its counterpart, the blacklist, to define a set of known bad inputs to help filter out malicious content. Recently, the Content Security Policy concept has also been gaining in popularity. With its standard HTTP header, it allows web owners to restrict the types of content that browsers may load on the page concerned.