Previously we saw how some cross-site scripting (XSS) vulnerabilities allow
attackers to store malicious JavaScript in your database, which will be
executed when other users view your site.
There is another way attackers can use XSS to inject malicious JavaScript, called a
reflected XSS attack.
If your website takes any part of the HTTP request from a user and
displays it back to them, you could be enabling another vector by which
a malicious third-party could inject JavaScript. Let's see how.
Mal is a hacker who has noticed
that your site's search function passes search
terms in the URL.
He knows the search terms in the URL will get displayed back on the
search results page, and he wonders if they are escaped properly.
To test this, he crafts a URL with a snippet of JavaScript in the search parameter.
Sure enough, when he drops the URL in his browser, the injected
JavaScript is executed and the browser redirects to his malicious site.
Mal can now checks his server log and hijack Vic's session, since
the malicious redirect passed his session ID in the URL.
Now he has to trick someone into navigating to that URL.
Someone like Vic.
Mal sends Vic an email with a very tempting link, pointing at the crafted URL.
Vic clicks on the link. The page renders the search parameter in the HTML
without escaping it properly, which creates a new
<script>
tag on the page.
The script is executed immediately when the page loads...
...and Vic gets redirected to Mal's malicious website.