XSS Attacks: The Next Wave
snyk.io
snyk.io
Be very suspicious of articles like these.
This Google Doc has tracked almost all "sinks" and "sources" for DOM-based XSS[1]. They aren't by any means limited to the URL (usually accessed by the `document.location` object).
[1] https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...
This seems like a fairly obvious idea to me, but I'm not a frontend developer, so I'm looking for someone to tell me why this doesn't already exist :)
To take a really degenerate example, media sites tend to have so many third-party JS integrations (maps, multiple analytics providers, ad systems etc etc) that you can't write a useful, security-improving CSP :/
Which means talking to marketing about their preferred analytics tool, asking the business if they really want these ad networks etc etc.
Hmmm...assuming your back end has all the requisite validation and other security in place, how can a SPA cause an XSS? Are there any purely client side attack vectors (XSS or otherwise) that need to be considered if your back end is fully protected?
https://example.com/login?vulernable-param=evilcredentialste...
If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.
DOM-based XSS is when JavaScript running on the client takes data from a "source" (URL parameter, DOM content, cookie, LocalStorage, etc), manipulates it, and then executes it on a "sink" without properly escaping it. Examples of "sources" and "sinks"[1].
I've reported DOM-based XSS on a website that parses user-generated comments for URLs then converts the comment by adding hyperlink markup to the URL. It was done insecurely, so I managed to use combinations of spaces and other HTML attribute delimiters to inject an "onMouseOver" attribute and collect a bounty (about $2000 IIRC). In my case, the payout was large because the data was stored on the server (therefore it was persistent XSS), but with URL fragments, it's possible for the server to never see the content that is passed to the "source".
[1] https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...
Nope, nope, and nope. In a DOM based attack via a GET request, an attacker can place the payload after a hash (the pound, ergo anchor reference): http://foobar.whatever/foo?bar=tender#<XSS VECTOR>
No browser sends either # or anything after it to the server, thus the only way to detect this attack is to have some active script in the DOM which sends the document.location to the server but of course if the attacker knows about that and if they can get to the DOM before that script, well, it's over.
What I learned only recently: With many modern javascript frameworks many of the assumptions you may have had about XSS in the past are obsolete. The strategies that worked in the past - proper escaping of untrusted input - don't necessarily work any more if you're using something like angularjs.
:) Something got quoted wrong there.
This article mentions increased use of OSS libs as a rising source of XSS. I'm really not sure what's worse - OSS that can be fixed and audited easily or proprietary software that's closed and lacking visibility.
Just recently I was reading a library and stumbled upon this interesting crypto tidbit [0] ("XXX get some random bytes instead"). Maybe a paid engineer would've designed it better but history is full of counter-examples (see CVE-2017-5689 [1]).
[0]: https://github.com/nitram509/macaroons.js/blob/master/src/ma...
[1]: https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5689
I would also say that generally speaking you also get more eyes on your source code so you increase the likelihood that someone will find the flaw more quickly (although you could also say it's easier for bad actors to locate flaws to exploit too).
Also, a single company provides limitations - you've got blinders on, and your project isn't open for those with a different perspective to come in and take a look and notice something. I honestly think that fresh, open, and global perspective is truly key the success of OSS.
A large community of devs who are focused on security would indeed be good for a projects security, but that's not always their number one priority.
> your project isn't open for those with a different perspective to come in and take a look and notice something.
Yes, but consider the fact that a malicious party can also do this kind of analysis. For the record I'm not advocating for closed software, on the contrary, but merely pointing that the matter is more complex than it looks like on the surface.
What I'd say is that given an equal amount of security effort an open source lib is more likely to have higher security, however by far and away the most important factor here is the amount of security effort employed and that is not generally correlated with the software being open source.
Of course as a consumer of software that doesn't help too much 'cause you don't know which companies do a good job and which ones just say they do a good job...
Open source is better in that you can audit it easily. However lets be honest, how many users of open source software actually are able to audit the libraries they use...
So neither option is particularly great at the moment(IMO)
Developers getting into React don't always realize that all the code is executed in the client and any input validation and authentication they come up with has to also exist on the server storing that data.
> Single Page Apps increase the amount of client side logic and user input processing. This makes them more likely to be vulnerable to DOM-based XSS, which, as previously mentioned, is very difficult for website owners to detect.
The more significant work we do on the client, the more interesting it becomes as an attack vector.
I think it's a common misconception, heavy-weight software usually does pretty well with common problems. If you think of frameworks like Rails which make input validation easy, writing manual SQL almost obsolete (SQL injection) and even CSRF protection happens mostly transparently.
It used to be very easy for even experienced developers to accidentally forget to escape a variable somewhere. It took framework developers a while to realize that "escape" should be the default, and now we're at "escape by default and make the developer sign forms in triplicate to override". Which is healthy, I think.