Cross-site scripting or XSS can be a potent and swift attack. As the developer, you might even take it for a bug in your code and end up searching for bugs that aren’t there.
</code></pre> In the example XSS above, the attacker finds a loophole on the vulnerable website. So when a user searches for an unavailable resource on the vulnerable site, it redirects them to the attacker's page. The attacker then taps the current user's cookie and grabs their session. However, this vulnerability is common where a site's query action isn't filtered to check script injections through HTML. But even if there's a filtered query, an attacker can bypass this by resorting to desperate measures like sending links over to possible real-time users of a website. They can do this using any <a href="https://www.makeuseof.com/tag/social-engineering-makeuseof-explains/">form of social engineering</a> available to them. <span class="related-single">Related: <a href="https://www.makeuseof.com/what-to-do-after-phishing-attack/">What To Do After Falling for a Phishing Attack</a></span> Once victims click such a link, the hijacker can now successfully execute the XSS attack and steal relevant data from the victim. <h3 id="the-persistent-or-stored-cross-site-scripting">The Persistent or Stored Cross-Site Scripting</h3> <figure> <img src="https://static1.makeuseofimages.com/wp-content/uploads/2021/02/Stored-XSS-A-depiction-of-the-database.jpg" /> </figure> The stored XSS poses more threats. In this case, an attacker stores the script in a website's database, triggering a persistent execution of the stored script. The stored code can run on page load or after page load. Unlike the temporary form of XSS, a stored XSS targets the entire user-base of the vulnerable website. In addition to that, it targets the integrity of the affected website as well. During a persistent XSS, an attacker uses input fields such as comment forms to post the script into a website's database. But what if you protect POST fields with CSRF tokens? Unfortunately, stored cross-site scripting bypasses CSRF checks. That's because the attacker submits a form like every other user of the website. So, such a comment form sends the script to the database as it does all other comments. Such an attack can happen when input fields on a website don't use proper sanitizers for escaping scripts and HTML tags. Imagine a user posting the script below using a web comment form: <pre><code><body onload = maLicious()>