Last Updated on April 3, 2021 by Dave Farquhar
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.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.