I'm trying to lock down my pages with a content security policy (CSP). The default CSP is too restrictive (and I cannot change the code to make it compliant, as it comes from a 3rd party), so I'm trying to define the minimal set of permissions in the CSP. To that end, I'd like to use style-src-attr and script-src-attr. And I'd like to use these with a nonce. I can see how to specify the nonce for both of these in the CSP. What I'm not sure about is how to specify the nonce for the html element (in the case of style-src-attr) and the javascript object (in the case of script-src-attr). I looked for an example, but couldn't find anything. Please give an example of how this could be done.
I stumbled over this question in actually preparing a lecture on the topic. The answer to the question is: you cannot.
Looking at the CSP Spec (https://www.w3.org/TR/CSP3/#match-element-to-source-list), only script or style tags can be nonced. The -attr variants do not apply to stand-alone elements (script tags, style tags, or links to CSS files), as per the spec (https://w3c.github.io/webappsec-csp/#directive-script-src-attr)
The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.
Bottom line, in the current specificiation, it should not be possible to allow event handlers through nonces. It is possible to rely on unsafe-hashes and put the hashes of known event handlers in there, but even that is not fully supported in browser (FF and Safari lack support, see https://caniuse.com/mdn-http_headers_csp_content-security-policy_unsafe-hashes)
Related
I'd like to specify a hash to my CSP of an allowed font.
Currently my default-src is none, then for font-src I have 'self'.
My font is currently included as data, like so: "data:font/ttf;base64,AAEAAAARAQ..."
Instead of just adding data: to my font-src, I'd like add the hash. I'm not sure if this is possible, or how to properly do it. I've taken the sha256 hash of "data:font/ttf;base64,AAEAAAARAQ..." and included it as 'sha256-asldfkj' in my font-src, but that did not work.
Any insight would be greatly appreciated!
1). 'hash-value' kind of 'sha256-he03geRc75f', 'sha384-nd78ro9==' etc. are applied to the inline scripts and inline styles only, see the second "Note" to para 5 of CSP3 spec.
2). CSP3 spec did extend hashes usage to external scripts (but Firefox still have a bug with this). Note in this case you have to use integrity= attribute in the tag.
Therefore hashes are not applicable to fonts because of para 1) above (plus, you probably forgot to use the integrity= attribute).
The data:-URL is considered as URL to external resource, not as inline. Therefore hashes are not applicable because of para 2) above too.
Note: The 'hash-value' is supported to allow external scripts with data:-urls in Chrome.
If script-src: hash-source is used in a browser that does not understand hash-source, will the browser ignore all of script-src:, or even all of the CSP? Or will it only ignore the hash-source part?
More generally, do browsers implement CSP in forward compatible manner?
What oreoshake stated about backward compatibility is accurate. The process of determining an element match is described in section 6.6.2.2 of the CSP draft standard: In the presence of hash-source or nonce-source, unsafe-inline is ignored by conforming user agents:
A source list allows all inline behavior of a given type if it contains the keyword-source expression 'unsafe-inline', and does not override that expression as described in the following algorithm:
[...]
If expression matches the nonce-source or hash-source grammar, return "Does Not Allow".
Furthermore, CSP 2 specifies the process of parsing a source list with unknown tokens as follows:
For each token returned by splitting source list on spaces, if the token matches the grammar for source-expression, add the token to the set of source expressions.
Otherwise, it should be ignored. So clearly the authors intended at least a certain level of forward compatibility.
Browsers that do not understand hash source elements may emit a warning in the console, but they may not as well. The recommended approach is to use user agent sniffing to detect support or send both 'unsafe-inline' with your hash source values.
User agents that understand hash sources will ignore the 'unsafe-inline' and those that do not will fallback to the 'unsafe-inline'. So it's backwards compatible.
I wonder what is the name of the left section of header in atlassian fisheye.
For example, the right section of the header is system.header.item
I've already searched through source code of fisheye, but I still can't find an answer.
And so called "documentation" of FishEye Web Item Locations is uncomplete.
Unfortunately that section isn't pluggable at the moment (FishEye/Crucible 3.5.1 and older).
You can plug items on the right-hand side using the system.header.item section. You could also possibly use some non-api way to add items to the main header (one solution would be having a javascript resource in the atl.general (and possibly atl.admin) context that modifies the DOM appropriately).
If you'd like the plugin point added to the main header, make sure to add a feature request.
The good people of OWASP emphasize that you MUST use the escape syntax for the part of the HTML document you’re putting untrusted data into (body, attribute, JavaScript, CSS, or URL). See OWASP - XSS. Their API (developed by the ESAPI team) subsequently caters for this having encoders for each context:
ESAPI.encoder().encodeForHTML("input");
ESAPI.encoder().encodeForHTMLAttribute("input");
ESAPI.encoder().encodeForJavaScript("input");
ESAPI.encoder().encodeForCSS("input");
ESAPI.encoder().encodeForURL("input");
Subsequently this allows the developer to cater for DOM-based XSS .
So my question is how does GWT's safehtml package cater for this or does it merely focus on HTML encoding?
SafeHtmlTemplates will do it (client-side only though, as it relies on a GWT generator). It'll parse the HTML fragment using a "tag soup" parser, that will infer the context and either log a warning or throw if the argument cannot be used in this context (for instance, it prevents all use of placeholders in script context). This is still in flux though (SafeUri is still in review and SafeStyles is still severely limited) but it'll be there in due time (should be in GWT 2.4 I think).
Otherwise:
SafeHtmlUtils's will escape all of <, >, &, ' and " so the result is safe for "HTML" and "HTML attribute" contexts
SafeHtmlBuilder's various append methods will just call SafeHtmlUtils under the hood
UriUtils provides tools to scrub unsafe URIs (you'll still need a SafeHtmlUtils pass or equivalent afterwards if you're building an HTML string –vs. using the value directly for an image's source or anchor's href–).
SafeStyles doesn't provide anything specific in itself, but SafeHtmlTemplates will only allow it at the beginning of a CSS context, and will log a warning if you try to put anything else in a CSS context. SafeStylesBuilder is expected to be extended with type-safe methods, to help build well-formed CSS.
I've been working on a SafeUri interface, similar to SafeStyles but in a URL context. In due time, SafeHtmlTemplates will only allow a SafeUri or a String as the full value of a URL attribute, passing the String through UriUtils to make sure it's safe.
In brief, I think the answer to your question is: yes, GWT's safehtml package cater for this; but you'll probably have to always use the latest version of GWT (at least for the coming year) to be safe.
I once read a page a few years ago about the various browsers' differing implementations of behaviour when a link with an empty href is clicked.
some of them linked to the directory (/path/to/file?query → /path/to/)
some of them linked to the exact same URI (/path/to/file?query → /path/to/file?query)
some of them linked to the same page (/path/to/file?query → /path/to/file)
...and various other behaviours.
Is the behaviour defined in a specification?
If so, what is the correct behaviour?
If so, have the latest versions of the big five browsers today fixed their implementations?
Since there's no "specification" for contents of HREF (at least in HTML 4), the browsers can do whatever they damn well please.
UPDATE However, aside from HTML, there's an RFC3986: Uniform Resource Identifier (URI): Generic Syntax. It has section 4.4. Same-Document Reference which says:
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are empty ...
I do not necessarily read the above as "an empty URI MUST cause the client to reload the same socument's URI", but it does sound like a "best practice" type of wording; so if I was implementing my own browser I'd almost certainly follow such a behavior.
On a related note, here's a good recent 3/2010) roundup of how browsers treat empty src attribute of <img> tag: http://www.nczonline.net/blog/2010/03/16/empty-string-urls-in-html-a-followup/ and http://www.nczonline.net/blog/2010/07/13/empty-string-urls-browser-update/ . Please note that it is a big deal, since having and empty img src would cause the page to endlessly re-load itself in the worst case scenario.