This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Testing for cookies attributes (OTG-SESS-002)"
(→Path attribute: new section) |
|||
| (5 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
__TOC__ | __TOC__ | ||
| + | |||
| + | == Reviewer Note == | ||
| + | https://www.owasp.org/index.php/User:Rick.mitchell#.22and.2For.22_Explanation [[User:Rick.mitchell|Rick.mitchell]] 10:33, 22 July 2008 (EDT) | ||
== Re: Section Title == | == Re: Section Title == | ||
| Line 11: | Line 14: | ||
Testing for cookie's attributes<br> | Testing for cookie's attributes<br> | ||
(Multiple attributes belonging to a cookie) [[User:Rick.mitchell|Rick.mitchell]] 10:05, 22 July 2008 (EDT) | (Multiple attributes belonging to a cookie) [[User:Rick.mitchell|Rick.mitchell]] 10:05, 22 July 2008 (EDT) | ||
| + | |||
| + | == Domain attribute == | ||
| + | There's an error in the Domain attribute explanation: | ||
| + | "For example, if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com)" | ||
| + | |||
| + | That's not correct. If the cookie set by an application at app.mydomain.com has no domain attribute set, then the cookie will be -only- submitted to app.mydomain.com and NOT to subdomains such as hacker.app.mydomain.com. Also, if you set the attribute to ".app.domain.com" the cookie WILL be submitted to subdomains. | ||
| + | |||
| + | In conclusion, it's more restrictive/secure if you leave the domain attribute unset. | ||
| + | |||
| + | [[User:Guillermo Caminer|Guillermo Caminer]] | ||
| + | |||
| + | == Path attribute == | ||
| + | |||
| + | The page seems to contain an error in the section about the cookie path attribute. I've highlighted the error in the quote below: | ||
| + | |||
| + | <blockquote> | ||
| + | Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/"''' or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used, the browser will send the cookie to any path that matches "myapp" such as "myapp-exploited".''' | ||
| + | </blockquote> | ||
| + | |||
| + | The current text says the trailing slash in the cookie path is important because, when omitted, a cookie for www.example.com/foo would also be sent to www.example.com/foo-bar. However, the relevant [http://tools.ietf.org/html/rfc6265#section-5.1.4 RFC 6265] contains the following path matching rules for browsers: | ||
| + | |||
| + | <blockquote> | ||
| + | A request-path path-matches a given cookie-path if at least one of | ||
| + | the following conditions holds: | ||
| + | |||
| + | o The cookie-path and the request-path are identical. | ||
| + | |||
| + | o The cookie-path is a prefix of the request-path, and the last | ||
| + | character of the cookie-path is %x2F ("/"). | ||
| + | |||
| + | o The cookie-path is a prefix of the request-path, and the first | ||
| + | character of the request-path that is not included in the cookie- | ||
| + | path is a %x2F ("/") character. | ||
| + | </blockquote> | ||
| + | |||
| + | This would mean a cookie for /foo would never be sent to /foo-bar because | ||
| + | * /foo is not identical to /foo-bar | ||
| + | * /foo is a prefix of /foo-bar, but /foo does not end with a / | ||
| + | * /foo is a prefix of /foo-bar, but -bar (the part of the request-path that is not included in the cookie-path) does not start with a / | ||
| + | |||
| + | If a browser adheres to the rules from the RFC the advice on the page is unnecessarily cautious. ";path=/foo" will have the same effect as ";path=/foo/". | ||
| + | |||
| + | PS I've tested this behaviour in Firefox 44.0.2 and Chrome 48.0.2564.109 m and those browsers both adhere to the RFC rules. | ||
Latest revision as of 08:28, 25 February 2016
Reviewer Note
https://www.owasp.org/index.php/User:Rick.mitchell#.22and.2For.22_Explanation Rick.mitchell 10:33, 22 July 2008 (EDT)
Re: Section Title
"Testing for cookies attributes"
Something is wrong with this title. One of the following should be used:
Testing for cookies' attributes
(Multiple attributes belonging to multiple cookies)
Testing for cookie attributes
(Multiple attributes per cookie)
Testing for cookie's attributes
(Multiple attributes belonging to a cookie) Rick.mitchell 10:05, 22 July 2008 (EDT)
Domain attribute
There's an error in the Domain attribute explanation: "For example, if a cookie is set by an application at app.mydomain.com with no domain attribute set, then the cookie would be resubmitted for all subsequent requests for app.mydomain.com and its subdomains (such as hacker.app.mydomain.com)"
That's not correct. If the cookie set by an application at app.mydomain.com has no domain attribute set, then the cookie will be -only- submitted to app.mydomain.com and NOT to subdomains such as hacker.app.mydomain.com. Also, if you set the attribute to ".app.domain.com" the cookie WILL be submitted to subdomains.
In conclusion, it's more restrictive/secure if you leave the domain attribute unset.
Path attribute
The page seems to contain an error in the section about the cookie path attribute. I've highlighted the error in the quote below:
Path Attribute - Verify that the path attribute, just as the Domain attribute, has not been set too loosely. Even if the Domain attribute has been configured as tight as possible, if the path is set to the root directory "/" then it can be vulnerable to less secure applications on the same server. For example, if the application resides at /myapp/, then verify that the cookies path is set to "; path=/myapp/" and NOT "; path=/" or "; path=/myapp". Notice here that the trailing "/" must be used after myapp. If it is not used, the browser will send the cookie to any path that matches "myapp" such as "myapp-exploited".
The current text says the trailing slash in the cookie path is important because, when omitted, a cookie for www.example.com/foo would also be sent to www.example.com/foo-bar. However, the relevant RFC 6265 contains the following path matching rules for browsers:
A request-path path-matches a given cookie-path if at least one of the following conditions holds:
o The cookie-path and the request-path are identical.
o The cookie-path is a prefix of the request-path, and the last character of the cookie-path is %x2F ("/").
o The cookie-path is a prefix of the request-path, and the first character of the request-path that is not included in the cookie- path is a %x2F ("/") character.
This would mean a cookie for /foo would never be sent to /foo-bar because
- /foo is not identical to /foo-bar
- /foo is a prefix of /foo-bar, but /foo does not end with a /
- /foo is a prefix of /foo-bar, but -bar (the part of the request-path that is not included in the cookie-path) does not start with a /
If a browser adheres to the rules from the RFC the advice on the page is unnecessarily cautious. ";path=/foo" will have the same effect as ";path=/foo/".
PS I've tested this behaviour in Firefox 44.0.2 and Chrome 48.0.2564.109 m and those browsers both adhere to the RFC rules.
