This is in your inbox:
I’ve been using your site every day, love what you’re doing and want you to know that you’ve really made a huge difference in my life.
I really wish I could work there one day, but I’m just a student right now trying to learn cybersecurity. I wanted to help out, so I was exploring my profile page on your site and found my first vulnerability!
If you use the following link, it will take you to my profile page and a Cross-Site Scripting (XSS) alert will pop up.
I’m not looking for a reward or anything. Like I said, I just want to give back as my way of saying thanks for all you’ve done for me.
Let me know if you have any questions. I’d be happy to work alongside you and help as much as I can!
Are you going to click that link?
Of course not! You know better than that.
But you do need to verify the issue, so you’ll type it in manually, and just to be safe, change the script to a simple alert:
Yep, Jan was right!
So you inspect the source code of the web page and find exactly where the script gets injected so a patch can be made.
Oh yeah – your account has also been taken over.
Let’s go back.
Jan’s reported vulnerability was legitimate. It was safe.
But there was another vulnerability not reported – a stored XSS vulnerability – that executed just by visiting Jan’s profile.
It's not often discussed that the ultimate prize for XSS attackers aren’t cookies; the unauthorized actions, stolen private data and damage that can be caused are.
With bug bounty programs growing in popularity (a major plus), it’s becoming more and more common for non-security and executive staff to receive vulnerability reports to analyze – and quite often they come straight through email from untrusted sources.
On top of this, XSS is the most commonly found vulnerability in websites by security researchers around the world, and most reports include some kind of link to verify the issue.
What about vulnerabilities not found by researchers?
According to Netsparker’s most recent Web Security Scan Statistics, XSS was found to be much more common than SQL injection.
How much more?
There were over 1000% more XSS vulnerabilities than SQL injection vulnerabilities!
XSS is a major problem that isn’t going away by itself, no matter what hip framework your dev teams use, because automatic HTML escaping doesn't protect against all XSS vulnerabilities. As such, it's especially crucial to protect privileged accounts from attacks.
Here's one way you can do that: make sure you’re not logged into your account when verifying XSS vulnerabilities, or any vulnerability, for that matter. Better yet, use a new private window, or, if you want to be extra safe, prepare a fresh VM used only for testing reports. Doing so can greatly reduce the risk of an attacker taking control of your account through XSS vulnerabilities.
Hey! Did you know it’s totally possible to prevent XSS vulnerabilities in your applications before they become a major crisis?!
To see exactly how dev teams can save costs by boosting quality and efficiency while eliminating security risks, check out my in-depth course on XSS attacks and vulnerabilities so you can protect your company and your users that rely on it, or send me a message to get started immediately.
Hacking Websites With Cross-Site ScriptingWATCH NOW
Our first course covers everything you need to stop XSS from ruining your security:
Cross-Site Scripting (XSS) is the #1 most common appsec vulnerability that allows attackers to steal private data, hijack accounts and spread ransomware on your sites. This course teaches students to:
Discover critical XSS vulnerabilities in web applications.
Create, analyze and stop malicious exploits used by criminal hackers.
Fix XSS vulnerabilities in routine and emergency situations.
Stop costly vulnerabilities before they reach production using the latest best practices and techniques.