Re: [CSP2] Large CSP headers

On Fri, 6 Dec 2019 at 16:31, Devin Lundberg <devinlundberg@pinterest.com>
wrote:

> What is the value of setting a CSP for non-html pages in the first place
> (assuming "X-Content-Type-Options=nosniff" is set)?



It's there as a backup.

nosniff might not be set, or the content-type might be wrong (the API might
respond with "text/html")... personally I just like having all the
restrictions in place, just in case.

All of my web pages return a custom CSP header for each page (only allowing
what that page needs), but I'm experimenting with the equivalent of
the Apache `Header setifempty` rule to set a default CSP of "default-src
'none'; etc" for any response that hasn't specified it's own.

Unfortunately `setifempty` doesn't work with fcgi, so I'm currently using
the following on my development server:

Header set "Content-Security-Policy" "default-src 'none'; base-uri 'none';
> form-action 'none'; frame-ancestors 'none'; block-all-mixed-content" "*expr=-z
> %{resp:Content-Security-Policy}*"


Assuming it goes well, it will be used on the Live servers in the new year.

Craig



On Fri, 6 Dec 2019 at 16:31, Devin Lundberg <devinlundberg@pinterest.com>
wrote:

> What is the value of setting a CSP for non-html pages in the first place
> (assuming "X-Content-Type-Options=nosniff" is set)?
>
> On Fri, Dec 6, 2019 at 9:13 AM Craig Francis <craig.francis@gmail.com>
> wrote:
>
>> Hi Ben,
>>
>> I agree with Frederik,
>>
>> But I would take it a bit further, as it's an API, and presumably not
>> going to be loaded as a web-page (it's returning "application/json"), then
>> the CSP header could be replaced with one that's considerably more
>> restrictive/useful, something like:
>>
>> Content-Security-Policy: default-src 'none'; base-uri 'none'; form-action
>>> 'none'; frame-ancestors 'none'; block-all-mixed-content
>>
>>
>> Although I do appreciate it's fairly easy to add a site-wide CSP, rather
>> than tailor it to every page (this is where I think our tools for building
>> websites fail us).
>>
>> Craig
>>
>>
>>
>> On Fri, 6 Dec 2019 at 13:21, Frederik Braun <fbraun@mozilla.com> wrote:
>>
>>> Hi Ben,
>>>
>>> You will have to talk to the site operators and they will have to agree
>>> that it's a good idea from a security perspective.
>>>
>>> That all being said, this CSP is not going to protect against XSS with
>>> 'unsave-inline' and data: in the script-src directive. (There's more and
>>> https://csp-evaluator.withgoogle.com/ will tell you.)
>>>
>>> If they think their CSP is a great idea anyway, you might be able to
>>> convince them to do User-Agent sniffing and not send browser-specific
>>> headers for known client libraries (curl, python-request, whatever).
>>> Might not be fun to maintain, but potentially worth the bandwidth
>>> savings on their end as well as yours.
>>>
>>>
>>> Hope this helps,
>>> Frederik
>>>
>>>
>>>
>>>
>>> Am 03.12.19 um 22:48 schrieb Ben:
>>> > Good afternoon,
>>> >
>>> > I'm trying to make a number of API requests to an endpoint that has
>>> > excessively large CSP headers in the replies, and this seems like the
>>> > best place to ask about what to do.
>>> >
>>> > In practice I'm going to be making a lot of API calls, and CSP headers
>>> > have become a bandwidth issue.
>>> >
>>> > For example:
>>> > $ curl --http1.1 -Lis https://api.itbit.com/v1/markets/XBTUSD/ticker |
>>> wc -c
>>> > 4474
>>> >
>>> > That reply only has a body-length of 428, and the vast majority of the
>>> > rest are CSP headers.
>>> >
>>> > HTTP2 doesn't help much, because api.itbit.com <http://api.itbit.com>
>>> > marks all header fields as sensitive, so they skip the hpack table:
>>> > $ nghttp  -v --multiply=2
>>> https://api.itbit.com/v1/markets/XBTUSD/ticker
>>> > | grep "recv HEADERS frame"
>>> > [  0.436] recv HEADERS frame <length=2925, flags=0x04, stream_id=13>
>>> > [  0.437] recv HEADERS frame <length=2842, flags=0x04, stream_id=15>
>>> >
>>> > Is there a way to signal that the request is not coming from a browser
>>> > so these headers may be suppressed or at least reduced?
>>> >
>>> > Thanks a lot,
>>> >
>>> > --Ben
>>>
>>>