
XSS Attacks: The Next Wave - tkadlec
https://snyk.io/blog/xss-attacks-the-next-wave/
======
tptacek
I do not believe any entity in the world has statistics strong enough to make
predictions like the expected percentage change in XSS year over year.
Everyone claiming to have those statistics has thoroughly confounded their
analyses by relying heavily on applications that have been made available to
specific tools and companies. But the modal web application deployed on the
Internet is the one that has had no security testing whatsoever.

Be very suspicious of articles like these.

------
thephyber
> Lastly, “DOM-based XSS” attacks occur purely in the browser when client-side
> JavaScript echoes back a portion of the URL onto the page.

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...](https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOkPx6t5dR3QyQo24kCVYQy7YY/edit#gid=0)

~~~
guypod
You're right, I tried to keep this section as brief as I could. DOM Based XSS
could happen from any source, but the hardest-to-detect (and very common)
variant is using the fragment (the part after the #) to inject the payload,
which is never sent to the user.

------
tallclair
Why can't we tackle XSS in the browser, by preventing javascript from
executing in the <body> (or anywhere other than <head> for that matter)? There
is an old memory protection technique of designating the stack & heap (data
portions of memory) as non-executable. It seems like a similar idea should
apply to the web, where the DOM is effectively a "data" portion, and separate
out all executable javascript into a separate section. I know this breaks
things like `onclick=` attributes, but can't those be replaced with event
listeners? Of course it would be opt-in by setting an attribute somewhere in
the DOM (e.g. <body non-executable="true">)

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 :)

~~~
dfabulich
This already exists. It's called Content Security Policy.
[https://developer.mozilla.org/en-
US/docs/Web/HTTP/CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)

~~~
simooooo
And it is an almighty pain in the arse to set up

~~~
zxcmx
Unless you can influence an organisation at a pretty high level it is often
impossible to write a useful CSP.

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.

------
dansingerman
"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."

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?

~~~
coderzach
Imagine a link like this:

[https://example.com/login?vulernable-
param=evilcredentialste...](https://example.com/login?vulernable-
param=evilcredentialstealingjavascript\(\))

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.

~~~
airza
Yes, but that gets passed to the server.

~~~
ghayes
What about httsp://example.com/login#vulnerable-fragment

~~~
airza
Yes, as i commented elsewhere in this thread that would be fine.

------
hannob
I'm interested in the topic, but found the article quite disappointing. It
doesn't really go into the technical details why we have a new wave of XSS
vulns.

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.

~~~
guypod
This article was very much about the data we've collected and our analysis of
it, as opposed to our opinions as to why - had to keep it to a reasonable
length! So we kept that section short in the end. I do plan follow up posts
that provide my theories as to why it's happening, and I think a best
practices guide that discusses template-related XSS is a good idea. In the
meantime, you can check out this related post: [https://snyk.io/blog/type-
manipulation/](https://snyk.io/blog/type-manipulation/)

------
nate
> AngularJS version 1, used at that point by approx. 30% of all websites

:) Something got quoted wrong there.

~~~
stevula
I think they misread a chart from their source, which shows 0.3% market share
for AngularJS:
[https://w3techs.com/technologies/history_overview/javascript...](https://w3techs.com/technologies/history_overview/javascript_library/all)

~~~
guypod
awkward typo there! Fixed now.

------
bnb
IIRC the GitHub Open Source Survey noted that the people surveyed were more
likely to trust OSS software in terms of security because of the transparency
with vulnerabilities and the community surrounding it.

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.

~~~
hdhzy
OSS is no silver bullet - you still have to do your due diligence to have
secure system. OSS just gives you an option to "fix it yourself".

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...](https://github.com/nitram509/macaroons.js/blob/master/src/main/ts/CryptoTools.ts#L61)

[1]: [https://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-5689](https://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-5689)

~~~
sbarre
> OSS just gives you an option to "fix it yourself".

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).

~~~
hdhzy
Well we are comparing apples and oranges here because this small open source
repo most certainly have less people looking at it than Intel have engineers
working on ME.

~~~
bnb
Who said this is a small open-source repo? Node.js has one of the most active
OSS communities on the web, with many contributors and developers looking at
the code, consuming and working on security and fixing bug reports daily.

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.

~~~
raesene9
Large communities of open source developers are no panacea, look at shellshock
or all the various OpenSSL libs. Those bugs stayed present for years in highly
used software...

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.

------
bsears
The rise in the client doing heavy lifting via libraries such as React is
driving an increase in vulnerabilities.

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.

~~~
efdee
React by default has pretty good XSS protection. That being said, "don't trust
the client" has been something developers have struggled with ever since we
started writing client/server software.

~~~
blablabla123
Not just pretty good, I mean to show code unescaped you need to write
`dangerouslySetInnerHTML`.

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.

