XSS Attacks: The Next Wave • Hacker News Board

Re: XSS Attacks: The Next Wave

#11

Post by hdhzy » Thu, Jun 08, 2017, 6:01 PM UTC

bnb wrote: post #8

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…

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

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

Re: XSS Attacks: The Next Wave

#12

Post by _xgw » Thu, Jun 08, 2017, 6:05 PM UTC

dansingerman wrote: post #10

"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) tha…

Reflected XSS attacks

Re: XSS Attacks: The Next Wave

#13

Post by fryguy » Thu, Jun 08, 2017, 6:24 PM UTC

bsears wrote: post #2

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.

It seems to me to be the exact opposite of this. If all of the data going from server to client comes through JSON to javascript, which usually means a JSON serializer and should correctly escape the data since you're not generating the JSON by hand, then there is no chance for traditional XSS attacks since the only remaining vector would be doing manual DOM building by concatenating strings, which you generally don't do in React. Now CSRF attacks I would believe you, but not XSS with React.

Re: XSS Attacks: The Next Wave

#14

Post by coderzach » Thu, Jun 08, 2017, 6:31 PM UTC

dansingerman wrote: post #10

"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) tha…

Imagine a link like this:

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.

Re: XSS Attacks: The Next Wave

#15

Post by airza » Thu, Jun 08, 2017, 6:39 PM UTC

dansingerman wrote: post #10

"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) tha…

Yes, a very common dom-based XSS vector is against document.hash, which is never passed to the server. Versions of Adobe Robohelp keep getting pwned by this. The article is kind of wrong that attacks against the URL won't be detected by the server since a decent WAF will detect this.

Re: XSS Attacks: The Next Wave

#16

Post by airza » Thu, Jun 08, 2017, 6:42 PM UTC

coderzach wrote: post #14

dansingerman wrote: post #10

"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) tha…

Imagine a link like this: 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.

Yes, but that gets passed to the server.

Re: XSS Attacks: The Next Wave

#17

Post by sbarre » Thu, Jun 08, 2017, 7:06 PM UTC

airza wrote: post #16

coderzach wrote: post #14

Earlier quoted context omitted.

Imagine a link like this: 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.

Yes, but that gets passed to the server.

It may get logged by the server but if it's designed to be parsed client-side, there may not be any server-side code examining or sanitizing that value before the SPA gets to it.

Re: XSS Attacks: The Next Wave

#18

Post by tptacek » Thu, Jun 08, 2017, 7:08 PM UTC

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.

Re: XSS Attacks: The Next Wave

#19

Post by sbarre » Thu, Jun 08, 2017, 7:08 PM UTC

hdhzy wrote: post #11

bnb wrote: post #8

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…

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/m…

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

Re: XSS Attacks: The Next Wave

#20

Post by hdhzy » Thu, Jun 08, 2017, 7:14 PM UTC

sbarre wrote: post #19

hdhzy wrote: post #11

Earlier quoted context omitted.

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/m…

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

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.