Bug #7573
closed
Cookies in default configuration are not marked Secure
Added by Pavel Kácha over 2 years ago.
Updated about 2 years ago.
Category:
Development - Tools
Description
Nessus info¶
Synopsis¶
HTTP session cookies might be transmitted in cleartext.
Description¶
The remote web application sets various cookies throughout a user's unauthenticated and authenticated session. However, there are instances where the application is running over unencrypted HTTP or the cookies are not marked 'secure', meaning the browser could send them back over an unencrypted link under certain circumstances. As a result, it may be possible for a remote attacker to intercept these cookies.
Note that this plugin detects all general cookies missing the 'secure' cookie flag, whereas plugin 49218 (Web Application Session Cookies Not Marked Secure) will only detect session cookies from an authenticated session missing the secure cookie flag.
Links and related¶
FLAB Pentest 2022-03 no. 38
- Status changed from New to In Progress
- Assignee set to Rajmund Hruška
- To be discussed changed from No to Yes
- % Done changed from 0 to 50
Rajmund Hruska wrote in #note-4:
Pavel Kácha wrote in #note-3:
Rajmund Hruska wrote in #note-2:
I see a couple of options here:
1. Only set session cookie as secure using Flask configuration (https://stackoverflow.com/questions/45218195/set-secure-attribute-for-flask-cookies)
2. Set all cookies as secure in the code (https://stackoverflow.com/questions/45218195/set-secure-attribute-for-flask-cookies)
3. Set all cookies as secure by using apache2 configuration (https://geekflare.com/httponly-secure-cookie-apache/)
I guess the best option is the third one (maybe together with the first one, just to be sure). What do you think Pavel Kácha?
I think (1) or (2) are not simply combinable with (3). (3) is simple string replacement, which in combination with (1) or (2) might end up as Cookie: name=value; Secure; Secure
. Or would need some more elaborate regex love. I'd go for (1), which is still overridable for debugging purposes, like running Mentat under internal Flask webserver (if we ever alow this).
(1) will only mark session cookies as Secure. Is that OK? I didn't find any other not secure cookies on mentat-hub, but on mentat-alt there is a fldt
cookie, which I guess is the Flask Development Toolbar cookie.
I overlooked, that (1) only concerns session cookie - however we in fact have ONLY session cookie. So I'd go for (1), as config value is easily changeable for developer if he wants to run some fancy environment.
- Status changed from In Progress to In Review
- % Done changed from 50 to 100
- To be discussed deleted (
Yes)
- Status changed from In Review to Closed
- Related to Bug #7574: Non-compliant Strict Transport Security (STS) added
- Related to Config #7786: Multiple issues with web configuration added
Also available in: Atom
PDF