Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSS Attacks: The Next Wave

snyk.io

Post reply on HN
Print view View original

31–40 of 47 posts

Re: XSS Attacks: The Next Wave

#31

Post by raesene9 »

bnb wrote: post #23
hdhzy wrote: post #20

Earlier quoted context omitted.

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.

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 hon…

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.

Re: XSS Attacks: The Next Wave

#32

Post by hdhzy »

bnb wrote: post #23
hdhzy wrote: post #20

Earlier quoted context omitted.

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.

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 hon…

Yes, my point is that we're just throwing anecdotes here, picking examples that suit the augment. It's not proven than one model is better than the other, otherwise we'd all just use the best one and that's all.

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

Re: XSS Attacks: The Next Wave

#33

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

Re: XSS Attacks: The Next Wave

#34

Post by raesene9 »

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…

What a closed source development team provides over OSS is some control over the quality and training of the developers allowed to commit to the codebase (e.g. the company can mandate that all developers have had training in how to avoid common XSS issues), control over the processes to be followed when commiting code, and control over the security tests to be carried out.

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)

Re: XSS Attacks: The Next Wave

#36

Post by tallclair »

Why can't we tackle XSS in the browser, by preventing javascript from executing in the (or anywhere other than 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. )

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

Re: XSS Attacks: The Next Wave

#37

Post by tallclair »

Why can't we tackle XSS in the browser, by preventing javascript from executing in the (or anywhere other than 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. )

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

Re: XSS Attacks: The Next Wave

#38

Post by dfabulich »

tallclair wrote: post #36

Why can't we tackle XSS in the browser, by preventing javascript from executing in the (or anywhere other than 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…

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

Re: XSS Attacks: The Next Wave

#39

Post by [deleted] »

tallclair wrote: post #36

Why can't we tackle XSS in the browser, by preventing javascript from executing in the (or anywhere other than 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…

[deleted]
Post reply on HN