In many security job interviews, the interviewer will ask about cross-site scripting, also known as XSS. Most descriptions of it are overly complex, however. The best description of it that I’ve ever heard is just five words long: Code execution in the browser. That’s cross site scripting explained as succinctly as possible.

That succinctly sums up the problem: You don’t want someone to be able to inject their code into your site.

What cross-site scripting is and how to recognize it

The first time I ever saw XSS was at work. Three of us were testing an open-source application in a shadow IT project that went legit, and he was running known exploits against it. “Congratulations,” one of the other guys said. “You just hacked your own web browser.” Then we all laughed and he gave up. None of us caught the implication, but in our defense, it was 2002.

Cross site scripting means getting a site people trust to run your code. In a simple example, let’s say I could inject my Google Adsense code into a review of a popular product on Amazon. I would make a lot of money off those page displays. If I were more malicious, I could overwrite Amazon’s forms with my own, so you’re sending your traffic to me, instead of to Amazon.

The way you avoid XSS is by filtering out code in form-based input. HTML formatting tags for stuff like boldface and italics are reasonably harmless. But Javascript is bad, bad, bad.

The problem with most XSS demos is they pop up dialog boxes that look harmless, and get reactions like the one above. An effective demonstration needs to show something more nefarious, like overwriting the web page itself with something else that’s obviously bad, such as something that overlays itself on your legitimate site and siphons off something valuable.

That’s what bad guys do with cross site scripting. Not popping up random dialog boxes that say weird stuff.