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 succinctly sums up the problem: You don’t want someone to be able to inject their code into your site.
The first time I ever saw XSS was at work. Three of us were testing an open-source application, 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.
XSS 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 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.