Last Updated: 2015-08-12 21:40:10 UTC
by Rob VandenBrink (Version: 1)
When you go through website security, Cross Site Scripting (XSS) is almost always discussed. Almost exclusively, Reflected XSS is the main topic, and it almost always covers the lion's share of the demonstrations and vulnerabilities found. Mainly because Stored or Persistent XSS is harder to find.
But Stored or Persistent XSS is an actual thing, and it is seen in the wild. In Stored XSS, data is stored, often in a back-end database, and the act of reading that data at a later time triggers the exploit.
Just this past week (I'm a bit behind, just back from vacation), Apple had a Stored XSS vulnerability in the iTunes and App Stores. If you named your device in a malicious manner, reading the device name in any subsequent invoices would trigger the exploit. So what you say - you just exploited yourself. Ahhh - but the not so obvious piece of this is that you likely also sent the exploit to anyone you purchase any product in the store from (for instance, App purchases).
There's no good way to know if anyone was actually exploited using this - really it depends on which browser and version they were running at the time. The bug was found and reported by the folks at Vulnerability Lab, so it's not clear if this was ever seen "in the wild". However, I'm sure that Apple wasn't thrilled about being a potential transit for malicious activity like this (it's since been fixed of course)
This does make a great example of how a Stored or Persistent XSS can work though - if you need to make the point to a client, someone in management or a developer, this makes a good example to trot out!
If you've seen something similar, a persistent XSS in real live (that you are able to talk about), please share using our comment form!