Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/csp #3

Merged
merged 2 commits into from
Aug 7, 2014
Merged

Feature/csp #3

merged 2 commits into from
Aug 7, 2014

Conversation

Avaq
Copy link
Contributor

@Avaq Avaq commented May 15, 2014

CSP

Cross Site Scripting (XSS) attacks are easier and easier to perform as new features are introduced to the web stack. As a result they are becoming harder and harder to detect and filter out on the server-side. One thing all XSS has in common is that information needs to be exfiltrated in order for the attack to be successful. One way to fight XSS is therefore to only send data to trusted sources.

Browsers now allow us to give them a whitelist of trusted domains, and they simply do not load any data from any other source: This is implemented under a standard called Content Security Policy (CSP). The simplicity of this system makes it very strong. It cuts off a single feature which XSS relies upon. It does however have some cons and is therefore up for discussion.

Pros

  • Hackers can hack what they want. Their external source code will not be loaded, and even if they manage to execute code, they won't be able to exfiltrate the data they gather.
  • Easily detectable when there's a leak because the browser sends a JSON report to the server when trying to load from an untrusted source. (Not implemented in my pull request)

Cons

  • Browser plug-ins which add scripts to the page will not work.
  • Bookmarklets will not work unless they have their sources explicitly white-listed.
  • Whenever one of the above occurs, a "false" report will be sent to our server. (Not implemented in my pull request)

@@ -3,6 +3,7 @@ module.exports =
clientPort: 3000
serverPort: 3001
httpPort: null
debug: false
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This option has been added to the develop branch in the mean time. Just ignore it.

@bartwr
Copy link
Member

bartwr commented May 15, 2014

Browser plug-ins which add scripts to the page will not work.
Bookmarklets will not work unless they have their sources explicitly white-listed.

This is only true if the bookmarklet uses scripts from https://webistor.net, right? If that's the case, we can save the bookmarklet scripts locally.

@Avaq
Copy link
Contributor Author

Avaq commented May 15, 2014

I'm talking about third party bookmarklets which use is attempted on a webisor.net page. For example, if someone would want to read their entry using a Readability bookmarklet, they'd attempt to load source from https://www.readability.com/ and since our site does not have it listed as a trusted source the browser will block the script and send a "false" report of a potential XSS leak to our server.

"default-src 'none'"
"style-src 'self' http://fonts.googleapis.com/ http://netdna.bootstrapcdn.com/"
"font-src 'self' http://themes.googleusercontent.com/ http://netdna.bootstrapcdn.com/"
"script-src 'self' 'unsafe-eval'"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should implement configurable sources for styles, fonts and scripts.

@Beanow Beanow merged commit 7752045 into develop Aug 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants