2 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

This may be helpful for security in certain situations, basically if your internet connection was tampered due to lack of HTTPS encryption. However in most relevant cases cookie injection is low on the list of concerns compared to the other compromised features.

The HTTP protocol does not currently offer a way for the client to provide metadata about the cookie.

For example, if a cookie is set with path=/, and later a cookie is set with path=/narrow-scope Then if you visit the site, visiting a /narrow-scope URL, both cookies are sent: Cookie: name=valueA, name=valueB.

The server cannot tell what specific path was used for each cookie. Only that the metadata between them is different otherwise they would be considered the same cookie (having the same name)

Similarly, there is no way for Cookies to be marked as whether it the Secure flag is set or HttpOnly. No metadata is passed from the client to the server.

In order to prevent an HTTP page from setting a secure cookie would result in two possibilities:

  • All HTTP-provided cookies are not accessible when visiting the HTTPS page. This would be a significant break in compatibility.

  • Or Metadata is added to the Client-provided Cookie value so that the server can know some things about it. For example, the server may wish to distinguish cookies set via JavaScript. Or as you say, whether it was set within HTTPS or HTTP.

    This would be a big change, and there is not that much demand for it. Also in most cases it does not equal a security feature.

Ultimately the correct solution is to force users to use HTTPS connectionsforce users to use HTTPS connections.

This may be helpful for security in certain situations, basically if your internet connection was tampered due to lack of HTTPS encryption. However in most relevant cases cookie injection is low on the list of concerns compared to the other compromised features.

The HTTP protocol does not currently offer a way for the client to provide metadata about the cookie.

For example, if a cookie is set with path=/, and later a cookie is set with path=/narrow-scope Then if you visit the site, visiting a /narrow-scope URL, both cookies are sent: Cookie: name=valueA, name=valueB.

The server cannot tell what specific path was used for each cookie. Only that the metadata between them is different otherwise they would be considered the same cookie (having the same name)

Similarly, there is no way for Cookies to be marked as whether it the Secure flag is set or HttpOnly. No metadata is passed from the client to the server.

In order to prevent an HTTP page from setting a secure cookie would result in two possibilities:

  • All HTTP-provided cookies are not accessible when visiting the HTTPS page. This would be a significant break in compatibility.

  • Or Metadata is added to the Client-provided Cookie value so that the server can know some things about it. For example, the server may wish to distinguish cookies set via JavaScript. Or as you say, whether it was set within HTTPS or HTTP.

    This would be a big change, and there is not that much demand for it. Also in most cases it does not equal a security feature.

Ultimately the correct solution is to force users to use HTTPS connections.

This may be helpful for security in certain situations, basically if your internet connection was tampered due to lack of HTTPS encryption. However in most relevant cases cookie injection is low on the list of concerns compared to the other compromised features.

The HTTP protocol does not currently offer a way for the client to provide metadata about the cookie.

For example, if a cookie is set with path=/, and later a cookie is set with path=/narrow-scope Then if you visit the site, visiting a /narrow-scope URL, both cookies are sent: Cookie: name=valueA, name=valueB.

The server cannot tell what specific path was used for each cookie. Only that the metadata between them is different otherwise they would be considered the same cookie (having the same name)

Similarly, there is no way for Cookies to be marked as whether it the Secure flag is set or HttpOnly. No metadata is passed from the client to the server.

In order to prevent an HTTP page from setting a secure cookie would result in two possibilities:

  • All HTTP-provided cookies are not accessible when visiting the HTTPS page. This would be a significant break in compatibility.

  • Or Metadata is added to the Client-provided Cookie value so that the server can know some things about it. For example, the server may wish to distinguish cookies set via JavaScript. Or as you say, whether it was set within HTTPS or HTTP.

    This would be a big change, and there is not that much demand for it. Also in most cases it does not equal a security feature.

Ultimately the correct solution is to force users to use HTTPS connections.

1
source | link

This may be helpful for security in certain situations, basically if your internet connection was tampered due to lack of HTTPS encryption. However in most relevant cases cookie injection is low on the list of concerns compared to the other compromised features.

The HTTP protocol does not currently offer a way for the client to provide metadata about the cookie.

For example, if a cookie is set with path=/, and later a cookie is set with path=/narrow-scope Then if you visit the site, visiting a /narrow-scope URL, both cookies are sent: Cookie: name=valueA, name=valueB.

The server cannot tell what specific path was used for each cookie. Only that the metadata between them is different otherwise they would be considered the same cookie (having the same name)

Similarly, there is no way for Cookies to be marked as whether it the Secure flag is set or HttpOnly. No metadata is passed from the client to the server.

In order to prevent an HTTP page from setting a secure cookie would result in two possibilities:

  • All HTTP-provided cookies are not accessible when visiting the HTTPS page. This would be a significant break in compatibility.

  • Or Metadata is added to the Client-provided Cookie value so that the server can know some things about it. For example, the server may wish to distinguish cookies set via JavaScript. Or as you say, whether it was set within HTTPS or HTTP.

    This would be a big change, and there is not that much demand for it. Also in most cases it does not equal a security feature.

Ultimately the correct solution is to force users to use HTTPS connections.