Content Security policy setting in iframe [duplicate] - html

Say I have this header set on mywebsite.com:
Content-Security-Policy: script-src self https://*.example.com
I know it will allow https://foo.example.com and https://bar.example.com, but will it allow https://example.com alone?
Looking at the spec....
Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host or any of its subdomains (and any of its subdomains' subdomains, and so on))
...it seems as it should allow plain https://example.com. However, I've found several different sites (site 1, site 2, site 3, site 4) that all say that https://example.com isn't included. Which is it?

*.example.com for a CSP header doesn’t also match example.com, per the current CSP spec.
That text cited from the (old) CSP spec is wrong (now fixed). The other sources cited are right.
But that https://www.w3.org/TR/CSP/#source-expression section cited, which defines what a CSP source expression is, isn’t actually stating the relevant normative requirements.
Instead the section of the CSP spec that does actually normatively define the relevant requirements is the Does url match expression in origin with redirect count algorithm, in a substep at https://www.w3.org/TR/CSP/#ref-for-grammardef-host-part-2 which reads:
If the first character of expression’s host-part is an U+002A ASTERISK character (*):
Let remaining be the result of removing the leading "*" from expression.
If remaining (including the leading U+002E FULL STOP character (.)) is not an ASCII case-insensitive match for the rightmost
characters of url’s host, then return "Does Not Match".
The including the leading U+002E FULL STOP character (.) part of the requirement indicates the remaining part after the asterisk is removed includes the leading full stop, and so the rightmost characters of url’s host must also start with a dot in order to match that.
In other words, if you start with *.example.com and walk through that part of the algorithm, you start by removing the * to get .example.com as the remaining part, and then you match the rightmost characters of url's host against that, including the leading full stop.
So https://foo.example.com matches, because the rightmost characters of its host part match .example.com, but https://example.com doesn’t match, because the rightmost characters of its host part don’t match .example.com (because it lacks the included full stop).
2017-10-13 update
A while back I reported the problem with the CSP spec and it’s now been fixed.
The relevant part of the CSP spec now reads:
Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host’s subdomains (and any of its subdomains' subdomains, and so on))
Notice that the part which had read “matches any resource on the host or any of its subdomains” now just reads “matches any resource on the host’s subdomains”.

According to Mozilla's docs you should include 'self' as well as *.example.com in the CSP header if you want to include the base domain.

Related

Marking message as spam or important

I have a Django email client powered by IMAPClient library. I successfully control read/unread status, as well as deleted. As descriped here.
My code for declaring a message as readlooks like this:
from imapclient.imapclient import SEEN
server.add_flags(msg_uids, SEEN)
Now I am stuck trying to add flag 'Junk' to the message.
I mean, doing something like:
server.add_flags(msg_uids, '\Junk')
There are a few things at play here. Firstly, flags that start with "" are system flags and \Junk isn't a standard system flag (as defined here).
Are you sure the server you're talking to supports the \Junk flag? You can check what flags the server lets the client set by checking for a PERMANENTFLAGS response in the return from IMAPClient's select_folder() call. This lists the flags the client is allowed to change. Is \Junk included?
If PERMANENTFLAGS includes \* then the client is allowed to define new keywords (flags that don't start with \) just by using them. See the spec for further details. If \* isn't included then the client may only set the listed flags.

Mac OS X - Accept self-signed multi domain SSL Certificate

I've got a self-signed certificate for multiple domains (let's say my.foo.bar.com & yours.foo.bar.com) that I've imported using Keychain Access but Chrome will still not accept it, prompting me for verification at the beginning of each browsing session per domain.
The Certificate was generated using the x509v3 subject alternative name extension to validate multiple domains. If I navigate to the site before I import the certificate, I get a different warning message than after importing. Attached below is an image of the two errors (with the top being the error before imported)
Is there any way to accept a self-signed multi-domain certificate? I only get warnings in Chrome, btw. FF and Safari work great (except those browsers suck ;) )
UPDATE: I tried generating the cert both with the openssl cli and the xca GUI
The problem is that you're trying to use too broad a wildcard (* or *.com).
The specifications (RFC 6125 and RFC 2818 Section 3.1) talk about "left-most" labels, which implies there should be more than one label:
1. The client SHOULD NOT attempt to match a presented identifier in
which the wildcard character comprises a label other than the
left-most label (e.g., do not match bar.*.example.net).
2. If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
I'm not sure whether there's a specification to say how many minimum labels there should be, but the Chromium code indicates that there must be at least 2 dots:
We required at least 3 components (i.e. 2 dots) as a basic protection
against too-broad wild-carding.
This is indeed to prevent too broad cases like *.com. This may seem inconvenient, but CAs make mistakes once in a while, and having a measure to prevent a potential rogue cert issued to *.com to work isn't necessarily a bad thing.
If I remember correctly, some implementations go further than this and have a list domains that would be too broad for second-level domains too (e.g. .co.uk).
Regarding your second example: "CN:bar.com, SANs: DNS:my.foo.bar.com, DNS:yours.foo.bar.com". This certificate should be valid for my.foo.bar.com and yours.foo.bar.com but not bar.com. The CN is only a fallback solution when no SANs are present. If there are any SANs, the CN should be ignored (although some implementations will be more tolerant).

HTML5 Application Cache Manifest - index fallback without catchall

I'm delivering a manifest for my app that looks something like this
CACHE MANIFEST
#1359542586541
NETWORK:
*
FALLBACK:
/ /index.offline
When offline, it works correctly by returning index.offline on the index path, however it has the side-effect of returning index.offline for every other resource as well. i.e. The / pattern is acting as a catchall.
Is there any way of matching the index page without everything else so only the homepage uses the fallback?
One irritation this causes is that it seems to return index.offline whenever a request returns a 500 status
No, the first URL in a FALLBACK is a prefix match. The only way is to always use the explicit index page rather than rely on default documents:
FALLBACK:
/index.html /index.offline
There was a discussion of the behaviour for 500 errors on HTML5 Help mailing list last February including several responses by the spec editor, this message specifically talks about FALLBACK sections.

What kind of example url I can use that will immediately cause a request to fail?

What is the "official" url I should use if I want to indicate just a resource that fails as soon as possible?
I don't want to use www.example.com since its an actual site that accepts and responds requests and I don't want something that takes forever and fails from a timeout (like typing using a random, private IP address can lead to).
I thought about writing an invalid address or just some random text but I figured it wouldn't look as nice and clear as "www.example.com" is.
If you want an invalid IP, trying using 0.0.0.0.
The first octet of an IP cannot be 0, so 0.0.0.0 to 0.255.255.255 will be invalid.
For more info, see this question: what is a good invalid IP address to use for unit tests?
https://www.rfc-editor.org/rfc/rfc5735:
192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. See[RFC1166].
Use .invalid, as per RFC 6761:
The domain "invalid." and any names falling within ".invalid." are special [...] Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.
So a request for https://foo.invalid/bar will always fail, assuming well-behaved DNS.
Related question: What is a guaranteed-unresolvable (but valid) URL?
if it's in a browser then about: is fairly useless - but it would be better if your service returned the correct HTTP status code - e.g. 200 = good, 404 = not found, etc.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

is link / href with just parameters (starting with question mark) valid?

Is this link valid?
eng
I know the browsers treat it as expected and I know the empty link would be ok too - but is it ok to specify just the parameters?
I am curious because question mark ("?") is only a convention by most HTTP servers (AFAIK), though I admit it is a prevailing one.
So, to recap:
will all browsers interpret this correctly?
is this in RFC?
can I expect some trouble using this?
UPDATE: the intended action on click is to redirect to the same page, but with different GET parameters ("lang=en" in above example).
Yes, it is.
You can find it in RFC 1808 - Relative Uniform Resource Locators:
Within an object with a well-defined base URL of
Base: <URL:http://a/b/c/d;p?q#f>
the relative URLs would be resolved as follows:
5.1. Normal Examples
?y = <URL:http://a/b/c/d;p?y>
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax restates the same, and adds more details, including the grammar:
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty #; zero characters
Now, that is not to say all browsers implement it according to the standard, but it looks like this should be safe.
Yes - and it will hit the current url with parameters what you are passing.
It is very convenient to use in situations where you want to make sure you do not cross current page/form boundary and keep on hitting same ActionMethod or whatever is listening with different parameters.