This is in your inbox:
Hey there!
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.
https://yoursite.example.com/profile/jan?tab=<script>%70%72%6f%6d%70%74%28%64%6f%63%75%6d%65%6e%74%2e%64%6f%6d%61%69%6e%29</script>
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!
- Jan
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:
https://yoursite.example.com/profile/jan?tab=<script>alert()</script>
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.
But how?
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.
Your site follows best practices of using HTTPS and setting HTTPOnly and
Secure cookies, but with XSS, JavaScript can do all the clicking and typing
simply through code – and you might not even know it’s happening.
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.
– Jesse Campos
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.
