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 "Secure Session Management Cheat Sheet"
Raul Siles (talk | contribs) |
Raul Siles (talk | contribs) |
||
| Line 16: | Line 16: | ||
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. On a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user, while in generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. | The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. On a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user, while in generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application. | ||
| + | |||
= Session ID Properties = | = Session ID Properties = | ||
| Line 43: | Line 44: | ||
If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. | If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2]. | ||
| − | |||
== Session ID Content (or Value) == | == Session ID Content (or Value) == | ||
| Line 51: | Line 51: | ||
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). | It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits). | ||
| + | |||
= Session Management Implementation = | = Session Management Implementation = | ||
| Line 61: | Line 62: | ||
== Built-in Session Management Implementations == | == Built-in Session Management Implementations == | ||
| − | |||
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. | Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time. | ||
| Line 69: | Line 69: | ||
== Used vs. Accepted Session ID Exchange Mechanisms == | == Used vs. Accepted Session ID Exchange Mechanisms == | ||
| − | |||
A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or if cookies are not accepted due to user privacy concerns). | A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or if cookies are not accepted due to user privacy concerns). | ||
| Line 75: | Line 74: | ||
== Transport Layer Security == | == Transport Layer Security == | ||
| − | |||
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the whole web session, not only for the authentication process where the user credentials are exchanged. | In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the whole web session, not only for the authentication process where the user credentials are exchanged. | ||
| Line 89: | Line 87: | ||
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation, but session ID disclosure and capture from the network traffic, one of the most prevalent attack vectors still today. | It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation, but session ID disclosure and capture from the network traffic, one of the most prevalent attack vectors still today. | ||
| + | |||
| + | |||
| + | = Cookies = | ||
| + | |||
| + | The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID: | ||
| + | |||
| + | == Secure Attribute == | ||
| + | The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. An attacker can simply capture the web browser traffic that contains the session ID. | ||
| + | |||
| + | Even the fact that the web application is only using HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against the session ID disclosure if the “Secure” cookie has not been set, as the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear. | ||
| + | |||
| + | == HttpOnly Attribute == | ||
| + | The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. Javascript or VBscript) to be able to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. | ||
| + | |||
| + | See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet]. | ||
| + | |||
| + | == Domain and Path Attributes == | ||
| + | The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie. | ||
| + | |||
| + | It is recommended to use a narrow or restricted scope for these two attributes, therefore, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID. | ||
| + | |||
| + | Setting the “Domain” attribute to a too permisive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com. | ||
| + | |||
| + | Additionally, it is recommended not to mix web applications of different security levels on the same domain, as vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permisive “Domain” attribute, such as “example.com”, a technique that can be used in session fixation attacks [4]. | ||
| + | |||
| + | Although the “Path” attribute allows to isolate session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host, as other methods can be used by these applications to access the session IDs, such as the “document.cookie” object, plus the fact that any web application can set cookies for any path on that host. | ||
| + | |||
| + | Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain. | ||
| + | |||
| + | == Expire and Max-Age Attributes == | ||
| + | Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based on the expiration time. Tipically, session management capabilities to track users after authentication make use of non-persistent cookies, forcing the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it. | ||
| + | |||
| + | |||
| + | = Implications of Cookies in Other Web-Based Vulnerabilities = | ||
| + | |||
| + | == CSRF == | ||
| + | The usage of cookies as the session ID exchange mechanim makes web applications vulnerable to Cross-Site Request Forgery (CSRF) attacks, as the existence of an automatic session management mechanism (aka “ambient authority”) allows to get a continuous and transparent authorized access to the web application (aka “session ridding”). | ||
| + | |||
| + | Other session ID exchange mechanisms do not present this behaviour, such as session IDs exchanged through the URL, where the secret URL (containing the session ID) is not automatically send and thus acts as the authorization mechanism (although these mechanisms present other issues, such as information disclosure). See the OWASP CSRF Prevention Cheat Sheet: [https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet]. | ||
| + | |||
| + | == Cross-Site Tracing (XST) == | ||
| + | The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of Cross-Site Tracing (XST) vulnerabilities, where an attacker tries to get access to the cookies from the response of the HTTP TRACE method. The HTTP TRACE method response includes the full client request as the web server received it, including all HTTP headers and therefore, the session ID in the cookie header. It is highly recommended to disable the HTTP TRACE method in the web server. | ||
| + | |||
| + | Most modern web browsers do not allow neither the usage of the TRACE method through the Javascript XMLHTTPRequest (XHR) object (to avoid effective XST attacks), nor direct access to the cookie headers (“Set-Cookie”) from the XMLHTTPRequest object responses. | ||
| + | |||
| + | == HTTP Response Splitting == | ||
| + | The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of HTTP response splitting (or CRLF injection) vulnerabilities, where an attacker can inject end of line characters (CR or LF or CRLF) in specific web application input fields to add his own cookie headers, an effective technique for session fixation attacks [4]. | ||
| + | |||
| + | == HTTP Cookie META Tags == | ||
| + | An attacker can take advantage of HTTP META tags within URLs to set cookies, an effective technique for session fixation attacks [4]: | ||
| + | |||
Revision as of 22:15, 18 July 2011
Introduction
Web Authentication, Session Management, and Access Control
A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require to retain information or status about each user for the duration of multiple requests, therefore, sessions provide the ability to establish variables, such as access rights and localization settings, which will apply to every and each interaction a user has with the web application for the duration of the session.
Web applications can create sessions to keep track of anonymous users since the very first user request, for example, to maintain the user language preference. Additionally, web applications will make use of sessions once the user has authenticated in order to identify the user on any subsequent requests and be able to apply security access controls, grant access to the user private data, and increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.
Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: http://www.owasp.org/index.php/Authentication_Cheat_Sheet.
HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions, therefore, in order to introduce the concept of a session it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:
XXX
The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.
The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. On a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user, while in generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.
Session ID Properties
In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.
With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:
Session ID Name Fingerprinting
The name used by the session ID shouldn’t be extremely descriptive and offer unnecessary details about the purpose and meaning of the ID.
The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.
It is recommended to change the default session ID name of the web development framework by a generic name, such as “id”.
Session ID Length
The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.
The session ID length must be at least 128 bits (16 bytes).
Session ID Entropy
The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.
The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).
NOTE: The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2].
If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].
Session ID Content (or Value)
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
Session Management Implementation
The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewritting – RFC 2396), URL arguments on GET requests, body arguments on POST request, such as hidden form fields (HTML forms), or proprietary HTTP headers.
The preferred session ID exchange mechanism should allow to define advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.
The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].
Built-in Session Management Implementations
Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.
However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.
The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.
Used vs. Accepted Session ID Exchange Mechanisms
A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or if cookies are not accepted due to user privacy concerns).
For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.
Transport Layer Security
In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the whole web session, not only for the authentication process where the user credentials are exchanged.
Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victim web browser [4].
The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:
- Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
- Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
- Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to use two different hosts instead, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
- Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.
See the OWASP Transport Layer Protection Cheat Sheet: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet.
It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation, but session ID disclosure and capture from the network traffic, one of the most prevalent attack vectors still today.
Cookies
The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:
Secure Attribute
The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. An attacker can simply capture the web browser traffic that contains the session ID.
Even the fact that the web application is only using HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against the session ID disclosure if the “Secure” cookie has not been set, as the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.
HttpOnly Attribute
The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. Javascript or VBscript) to be able to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.
See the OWASP XSS Prevention Cheat Sheet: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet.
Domain and Path Attributes
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.
It is recommended to use a narrow or restricted scope for these two attributes, therefore, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
Setting the “Domain” attribute to a too permisive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.
Additionally, it is recommended not to mix web applications of different security levels on the same domain, as vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permisive “Domain” attribute, such as “example.com”, a technique that can be used in session fixation attacks [4].
Although the “Path” attribute allows to isolate session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host, as other methods can be used by these applications to access the session IDs, such as the “document.cookie” object, plus the fact that any web application can set cookies for any path on that host.
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.
Expire and Max-Age Attributes
Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based on the expiration time. Tipically, session management capabilities to track users after authentication make use of non-persistent cookies, forcing the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
Implications of Cookies in Other Web-Based Vulnerabilities
CSRF
The usage of cookies as the session ID exchange mechanim makes web applications vulnerable to Cross-Site Request Forgery (CSRF) attacks, as the existence of an automatic session management mechanism (aka “ambient authority”) allows to get a continuous and transparent authorized access to the web application (aka “session ridding”).
Other session ID exchange mechanisms do not present this behaviour, such as session IDs exchanged through the URL, where the secret URL (containing the session ID) is not automatically send and thus acts as the authorization mechanism (although these mechanisms present other issues, such as information disclosure). See the OWASP CSRF Prevention Cheat Sheet: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet.
Cross-Site Tracing (XST)
The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of Cross-Site Tracing (XST) vulnerabilities, where an attacker tries to get access to the cookies from the response of the HTTP TRACE method. The HTTP TRACE method response includes the full client request as the web server received it, including all HTTP headers and therefore, the session ID in the cookie header. It is highly recommended to disable the HTTP TRACE method in the web server.
Most modern web browsers do not allow neither the usage of the TRACE method through the Javascript XMLHTTPRequest (XHR) object (to avoid effective XST attacks), nor direct access to the cookie headers (“Set-Cookie”) from the XMLHTTPRequest object responses.
HTTP Response Splitting
The usage of cookies as the session ID exchange mechanim makes web applications the target for the exploitation of HTTP response splitting (or CRLF injection) vulnerabilities, where an attacker can inject end of line characters (CR or LF or CRLF) in specific web application input fields to add his own cookie headers, an effective technique for session fixation attacks [4].
HTTP Cookie META Tags
An attacker can take advantage of HTTP META tags within URLs to set cookies, an effective technique for session fixation attacks [4]:
COMING SOON
Text
Relevant
More text
Title 2
Title 2.1
Text. Numbered List:
- 1
- 2
Title 2.2
Related Articles
One'
For more information on XXX please see the OWASP Cross-Site Request Forgery (CSRF) page.
OWASP Cheat Sheets Project Homepage
Authors and Primary Editors
Raul Siles - raul[at]taddong.com
