| Details | |
|---|---|
| Alert ID | 40013-1 |
| Alert Type | Active |
| Status | beta |
| Risk | Medium |
| CWE | 384 |
| WASC | 37 |
| Technologies Targeted | All |
| Tags |
CWE-384 OWASP_2017_A05 OWASP_2021_A01 OWASP_2025_A01 POLICY_PENTEST WSTG-V42-SESS-03 |
| More Info |
Scan Rule Help |
Summary
A session id may be sent via an insecure mechanism. In the case of a cookie sent in the request, this occurs when HTTP, rather than HTTPS, is used. In the case of a cookie sent by the server in response (when the URL is modified by setting the named parameter field to NULL), the ‘secure’ flag is not set, allowing the cookie to be sent later via HTTP rather than via HTTPS. This may allow a passive eavesdropper on the network path to gain full access to the victim’s session.
Solution
1) Use the latest available version of SSL/TLS (for HTTPS) for all pages where a session id is communicated between the browser and the web server. 2) Do not allow the communication to be forced down to the unencrypted HTTP protocol. 3) Use the 'secure' flag when setting a cookie containing a session id, to prevent its subsequent transmission by an insecure mechanism. 4) Forward non-secure HTTP page requests to the secure HTTPS equivalent page.Other Info
session identifier cookie field [JSESSIONID], value [valueA] may be sent via an insecure mechanism. The 'secure' flag was not set on the session cookie supplied by the server. The url on which the issue was discovered was flagged as a logon page.References
- https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A2-Broken_Authentication
- https://owasp.org/www-community/attacks/Session_fixation
- https://acrossecurity.com/papers/session_fixation.pdf
- https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html