Testing for Exposed Session Variables (OTG-SESS-004) - Revision history

Andrew Muller at 14:18, 31 July 2014

2014-07-31T14:18:28Z

Andrew Muller: Andrew Muller moved page Testing for Exposed Session Variables (OWASP-SM-004) to Testing for Exposed Session Variables (OTG-SESS-004): Align with Common Numbering

2014-07-31T14:16:18Z

Andrew Muller moved page Testing for Exposed Session Variables (OWASP-SM-004) to Testing for Exposed Session Variables (OTG-SESS-004): Align with Common Numbering

Jane O'Connor: Final edit

2014-05-17T16:31:24Z

Final edit

Mmeucci at 14:49, 9 October 2012

2012-10-09T14:49:30Z

Laurence Casey: Reverted edits by RoldrOncos (Talk) to last version by KirstenS

2009-05-26T19:59:06Z

Reverted edits by RoldrOncos (Talk) to last version by KirstenS

Deleted user at 12:10, 26 May 2009

2009-05-26T12:10:28Z

Deleted user at 20:41, 22 May 2009

2009-05-22T20:41:20Z

KirstenS: /* References */

2009-02-06T14:53:54Z

‎References

KirstenS: /* Black Box testing and example */

2009-02-06T14:53:19Z

‎Black Box testing and example

KirstenS: /* Black Box testing and example */

2009-02-06T14:51:14Z

‎Black Box testing and example

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers.
 <br>
 The information here relates to how transport security applies to the transfer of sensitive Session ID data rather than data in general, and may be stricter than the caching and transport policies applied to the data served by the site.
@@ Line 21: / Line 19: @@
-== Black Box Testing ==
+==How to Test==
 '''Testing for Encryption & Reuse of Session Tokens vulnerabilities:''' <br>

@@ Line 3: / Line 3: @@
 == Brief Summary ==
-The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  As such, it is important that they are protected from eavesdropping at all times – particularly whilst in transit between the Client browser and the application servers.
+The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers.
 <br>
-== Short Description of the Issue==
 The information here relates to how transport security applies to the transfer of sensitive Session ID data rather than data in general, and may be stricter than the caching and transport policies applied to the data served by the site.
 Using a personal proxy, it is possible to ascertain the following about each request and response:
 * Protocol used (e.g., HTTP vs. HTTPS)
 * HTTP Headers
 * Message Body (e.g., POST or page content)
-== Black Box testing and example ==
 '''Testing for Encryption & Reuse of Session Tokens vulnerabilities:''' <br>
-Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption.
+Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption. It should be noted that encryption or cryptographic hashing of the Session ID should be considered separately from transport encryption, as it is the Session ID itself being protected, not the data that may be represented by it.
 It should be noted that encryption or cryptographic hashing of the Session ID should be considered separately from transport encryption, as it is the Session ID itself being protected, not the data that may be represented by it.
 If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk.
-It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used (e.g., a hidden form field).
+If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk. It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used (e.g., a hidden form field). Simple checks such as replacing https:// with http:// during interaction with the application should be performed, together with modification of form posts to determine if adequate segregation between the secure and non-secure sites is implemented.<br>
 Simple checks such as replacing https:// with http:// during interaction with the application should be performed, together with modification of form posts to determine if adequate segregation between the secure and non-secure sites is implemented.<br>
-Note: if there is also an element to the site where the user is tracked with Session IDs but security is not present (e.g., noting which public documents a registered user downloads) it is essential that a different Session ID is used.  The Session ID should therefore be monitored as the client switches from the secure to non-secure elements to ensure a different one is used.<br>
 '''Result Expected:'''<br>
 Every time the authentication is successful, the user should expect to receive:
 * A different session token
 * A token sent via encrypted channel every time they make an HTTP Request
-<br>
 '''Testing for Proxies & Caching vulnerabilities:''' <br>
-Proxies must also be considered when reviewing application security.  In many cases, clients will access the application through corporate, ISP, or other proxies or protocol aware gateways (e.g., Firewalls).
+Proxies must also be considered when reviewing application security.  In many cases, clients will access the application through corporate, ISP, or other proxies or protocol aware gateways (e.g., Firewalls). The HTTP protocol provides directives to control the behavior of downstream proxies, and the correct implementation of these directives should also be assessed.
-The HTTP protocol provides directives to control the behaviour of downstream proxies, and the correct implementation of these directives should also be assessed.
-In general, the Session ID should never be sent over unencrypted transport and should never be cached.  The application should therefore be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs.  Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.<br>
-The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP.
+In general, the Session ID should never be sent over unencrypted transport and should never be cached.  The application should be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs.  Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.<br>
 HTTP/1.1 provides a number of cache control mechanisms.  Cache-Control: no-cache indicates that a proxy must not re-use any data.  Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data.  In the case of web-cafes or other shared systems, this presents a clear risk.  Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used.  HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.
 '''Result Expected:'''<br>
@@ Line 41: / Line 53: @@
 Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.
 <br>
 '''Testing for GET & POST vulnerabilities:''' <br>
-In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs.  They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools.
+In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs.  They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools. Furthermore, [[Cross-site Scripting (XSS)]] attacks are most easily exploited by sending a specially constructed link to the victim.  This is far less likely if data is sent from the client as POSTs.
 <br>
 '''Result Expected:'''<br>
-All server side code receiving data from POST requests should be tested to ensure it doesn’t accept the data if sent as a GET.
+All server side code receiving data from POST requests should be tested to ensure it does not accept the data if sent as a GET.
-For example, consider the following POST request generated by a login page.
+For example, consider the following POST request generated by a log in page.
 <pre>
 POST http://owaspapp.com/login.asp HTTP/1.1
@@ Line 63: / Line 78: @@
 Login=Username&password=Password&SessionID=12345678
 </pre>
 If login.asp is badly implemented, it may be possible to log in using the following URL:
 http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678
 Potentially insecure server-side scripts may be identified by checking each POST in this way.
-<br>
+Potentially insecure server-side scripts may be identified by checking each POST in this way.<br>
 '''Testing for Transport vulnerabilities:''' <br>
 All interaction between the Client and Application should be tested at least against the following criteria.
@@ Line 77: / Line 96: @@
 * Are GET requests incorporating the Session ID used?
 * If POST is used, can it be interchanged with GET?
 == References ==

← Older revision		Revision as of 14:49, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	== Brief Summary ==		== Brief Summary ==

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v3}}
 == Brief Summary ==
-The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  As such, it is important that they are protected from eavesdropping at all times Ã¢ÂÂ particularly whilst in transit between the Client browser and the application servers.
+The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  As such, it is important that they are protected from eavesdropping at all times – particularly whilst in transit between the Client browser and the application servers.
 <br>
@@ Line 79: / Line 34: @@
 The HTTP protocol provides directives to control the behaviour of downstream proxies, and the correct implementation of these directives should also be assessed.
 In general, the Session ID should never be sent over unencrypted transport and should never be cached.  The application should therefore be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs.  Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.<br>
-The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 Ã¢ÂÂ RFC 2616 discusses the appropriate controls with reference to HTTP.
+The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP.
 HTTP/1.1 provides a number of cache control mechanisms.  Cache-Control: no-cache indicates that a proxy must not re-use any data.  Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data.  In the case of web-cafes or other shared systems, this presents a clear risk.  Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used.  HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.
 '''Result Expected:'''<br>
-The Ã¢ÂÂExpires: 0Ã¢ÂÂ and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
+The “Expires: 0” and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
 Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.
 <br>
@@ Line 91: / Line 46: @@
 <br>
 '''Result Expected:'''<br>
-All server side code receiving data from POST requests should be tested to ensure it doesnÃ¢ÂÂt accept the data if sent as a GET.
+All server side code receiving data from POST requests should be tested to ensure it doesn’t accept the data if sent as a GET.
 For example, consider the following POST request generated by a login page.
 <pre>
@@ Line 125: / Line 80: @@
 == References ==
 '''Whitepapers'''<br>
-* RFCs 2109 & 2965 Ã¢ÂÂ HTTP State Management Mechanism [D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
+* RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
-* RFC 2616 Ã¢ÂÂ Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt
+* RFC 2616 – Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt

@@ Line 1: / Line 1: @@
 http://www.textdelorvichi.com
 {{Template:OWASP Testing Guide v3}}
@@ Line 4: / Line 48: @@
 == Brief Summary ==
-The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  As such, it is important that they are protected from eavesdropping at all times â particularly whilst in transit between the Client browser and the application servers.
+The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately.  As such, it is important that they are protected from eavesdropping at all times Ã¢ÂÂ particularly whilst in transit between the Client browser and the application servers.
 <br>
@@ Line 35: / Line 79: @@
 The HTTP protocol provides directives to control the behaviour of downstream proxies, and the correct implementation of these directives should also be assessed.
 In general, the Session ID should never be sent over unencrypted transport and should never be cached.  The application should therefore be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs.  Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.<br>
-The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 â RFC 2616 discusses the appropriate controls with reference to HTTP.
+The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 Ã¢ÂÂ RFC 2616 discusses the appropriate controls with reference to HTTP.
 HTTP/1.1 provides a number of cache control mechanisms.  Cache-Control: no-cache indicates that a proxy must not re-use any data.  Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data.  In the case of web-cafes or other shared systems, this presents a clear risk.  Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used.  HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.
 '''Result Expected:'''<br>
-The âExpires: 0â and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
+The Ã¢ÂÂExpires: 0Ã¢ÂÂ and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
 Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.
 <br>
@@ Line 47: / Line 91: @@
 <br>
 '''Result Expected:'''<br>
-All server side code receiving data from POST requests should be tested to ensure it doesnât accept the data if sent as a GET.
+All server side code receiving data from POST requests should be tested to ensure it doesnÃ¢ÂÂt accept the data if sent as a GET.
 For example, consider the following POST request generated by a login page.
 <pre>
@@ Line 81: / Line 125: @@
 == References ==
 '''Whitepapers'''<br>
-* RFCs 2109 & 2965 â HTTP State Management Mechanism [D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
+* RFCs 2109 & 2965 Ã¢ÂÂ HTTP State Management Mechanism [D. Kristol, L. Montulli] - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
-* RFC 2616 â Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt
+* RFC 2616 Ã¢ÂÂ Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt

← Older revision	Revision as of 14:16, 31 July 2014
(No difference)

@@ Line 70: / Line 70: @@
 '''Testing for Transport vulnerabilities:''' <br>
 All interaction between the Client and Application should be tested at least against the following criteria.
-* How are Session IDs transferred? E.g., GET, POST, Form Field (including hidden fields)
+* How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields)
 * Are Session IDs always sent over encrypted transport by default?
-* Is it possible to manipulate the application to send Session IDs unencrypted? E.g., by changing HTTP to HTTPS?
+* Is it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTP to HTTPS?
 * What cache-control directives are applied to requests/responses passing Session IDs?
 * Are these directives always present?  If not, where are the exceptions?