Add ability to specify the version of used CSP

# Taras Ivashchenko (2 months ago)

Hello!

It is awkward to maintain backward compatible CSP policy, e.g. keep in it unsafe-inline with nonce for CSPv1 or frame- src/child-src. It looks like in the future versions of CSP such problem will be more obvious. In some cases in web application it is easer to have support of only the last one standard. What do you think about adding ability to specify the version of used CSP? It can be done in header name like:

Content-Security-Policy-v3: ...

If browser meets more the one CSP header it should use header with the latest support version.

I had also reported the issue on GitHub but there is no activity in it during 8 days w3c/webappsec-csp#189

Contact us to advertise here
# Bil Corry (2 months ago)

Back in 2008, I provided feedback on a newly proposed CSP specification. My very first item addressed a shortcoming regarding CSP versioning.

I suggested the client send a header with the version of CSP it supports (if any), and the server could then respond with the CSP header for that version (or make other security choices).

I even called out that it would be better than having multiple CSP headers expressed by the server, e.g.

    X-Content-Security-Policy: ...
    X-Content-Security-Policy2: ...
    X-Content-Security-Policy3: ...
    X-Content-Security-Policy4: ...
    X-Content-Security-Policy5: ...

Instead, the spec omitted a versioning scheme, perhaps because some believed that there would never be a version 2 of CSP.

The entire thread is here and makes for interesting reading, given what we know today:

groups.google.com/forum/m/#!msg/mozilla.dev.security/slJarIvaMM0/discussion

# Taras Ivashchenko (2 months ago)

+mkwst@google.com

9 years ago...and nice thread. I like the idea about some handshake between browser and server. The only thing that I'm worried about is additional logic on webserver site like "if we receive CSP version N from the browser then send relevant header with policy".

Mike, what do you think about CSP built-in versioning?

В Чт, 09/03/2017 в 07:43 -0700, Bil Corry пишет:

# Taras Ivashchenko (2 months ago)

Mike?

В Пт, 10/03/2017 в 12:26 +0300, Taras Ivashchenko пишет:

# Mike West (2 months ago)

Sorry, I missed this thread. Thanks for the ping.

In short, I think the ship has sailed on versioning. Whether or not it was a good decision, it's the decision we've run with until now, and it's not clear to me that it's worth a ton of investment at this point. Practically, developers already do user-agent sniffing to deal with differences in behavior between browsers, and I don't think versioning would actually change that (especially given browsers like Chrome and Firefox which are shipping pieces of CSP3, but don't yet support all of it).

We've established a pattern by which we introduce new bits and pieces that implicitly deprecate old bits and pieces. I agree that it's not always elegant, but it has the advantage that a policy always has the same meaning based on the features a browser supports. Moreover, it has the real advantage of not requiring us to support multiple incompatible versions of CSP in browsers at once. That's something I'd really like to avoid.

Personally, I'm not very interested in making fundamental changes to CSP at this point. I don't intend to write a CSP4, for instance. I'm more likely to be interested in stepping back from CSP, trying to learn what we can from the few years of experience we've gathered, and trying again with something more targeted. mikewest.github.io/artur-yes is a strawman sketch we talked about at TPAC last year, and I'm sure we could come up with something similar for confinement.

All that said, it would be good to listen to developers about whether a versioning system would have helped them. If it would have been amazingly useful, then it's something we should think about for features we introduce in the future.

-mike

On Mon, Mar 20, 2017 at 11:45 AM, Taras Ivashchenko oxdef@yandex-team.ru

wrote:

# Taras Ivashchenko (2 months ago)

Thanks for reply. В Пн, 20/03/2017 в 15:00 +0100, Mike West пишет:

Sorry, I missed this thread. Thanks for the ping. In short, I think the ship has sailed on versioning.

It is only 2 standard versions right now and significant next one. Also we are in the begging of CSP world wide spreading. May be it is not so late to include versioning into the 3rd version?

Whether or not it was a good decision, it's the decision we've run with until now, and it's not clear to me that it's worth a ton of investment at this point. Practically, developers already do user-agent sniffing to deal with differences in behavior between browsers, and I don't think versioning would actually change that (especially given browsers like Chrome and Firefox which are shipping pieces of CSP3, but don't yet support all of it).

In my opinion, user-agent sniffing is bad practice. It is better when protocol/technology provides versioning built-in so developers don't need to write code like: if ua.name == "Chrome" and ua.version > 46 ...

We've established a pattern by which we introduce new bits and pieces that implicitly deprecate old bits and pieces. I agree that it's not always elegant, but it has the advantage that a policy always has the same meaning based on the features a browser supports. Moreover, it has the real advantage of not requiring us to support multiple incompatible versions of CSP in browsers at once. That's something I'd really like to avoid.

On the another side it makes the policy more complex and harder to maintain for web resources. Furthermore it makes possible to more safely brake backward compatibility in future versions of CSP.

Personally, I'm not very interested in making fundamental changes to CSP at this point. I don't intend to write a CSP4, for instance. I'm more likely to be interested in stepping back from CSP, trying to learn what we can from the few years of experience we've gathered, and trying again with something more targeted. mikewest.github.io/artu r-yes/ is a strawman sketch we talked about at TPAC last year, and I'm sure we could come up with something similar for confinement.

All that said, it would be good to listen to developers about whether a versioning system would have helped them. If it would have been amazingly useful, then it's something we should think about for features we introduce in the future.

-mike

On Mon, Mar 20, 2017 at 11:45 AM, Taras Ivashchenko oxdef@yandex-team.ru wrote:

Mike?

В Пт, 10/03/2017 в 12:26 +0300, Taras Ivashchenko пишет:

+mkwst@google.com

>

9 years ago...and nice thread. I like the idea about some handshake between browser and server.

The only thing that I'm worried about is additional logic on webserver site like "if we receive CSP version N from the

browser then send relevant header with policy".

>

Mike, what do you think about CSP built-in versioning?

>

В Чт, 09/03/2017 в 07:43 -0700, Bil Corry пишет:

Back in 2008, I provided feedback on a newly proposed CSP specification. My very first item addressed a shortcoming

regarding CSP versioning.

>

I suggested the client send a header with the version of CSP it supports (if any), and the server could then respond

with the CSP header for that version (or make other security choices).

>

I even called out that it would be better than having multiple CSP headers expressed by the server, e.g.

>

    X-Content-Security-Policy: ...

    X-Content-Security-Policy2: ...

    X-Content-Security-Policy3: ...

    X-Content-Security-Policy4: ...

    X-Content-Security-Policy5: ...

>

Instead, the spec omitted a versioning scheme, perhaps because some believed that there would never be a version 2

of

CSP.

>

The entire thread is here and makes for interesting reading, given what we know today:

>

groups.google.com/forum/m/#!msg/mozilla.dev.security/slJarIvaMM0/discussion

>

>

  • Bil

>

On Mar 9, 2017, at 2:01 AM, Taras Ivashchenko oxdef@yandex-team.ru wrote:

>

Hello!

>

It is awkward to maintain backward compatible CSP policy, e.g. keep in it unsafe-inline with nonce for CSPv1 or

frame-

src/child-src. It looks like in the future versions of CSP such problem will be more obvious.

In some cases in web application it is easer to have support of only the last one standard.

What do you think about adding ability to specify the version of used CSP?

It can be done in header name like:

>

Content-Security-Policy-v3: ...

>

If browser meets more the one CSP header it should use header with the latest support version.

>

I had also reported the issue on GitHub but there is no activity in it during 8 days

w3c/webappsec-csp#189

>

--

Taras Ivashchenko

Information Security Officer,

Yandex

--

Taras Ivashchenko

Information Security Officer,

Yandex

Taras Ivashchenko Information Security Officer, Yandex

Want more features?

Request early access to our private beta of readable email premium.