Difference between revisions of "Reviewing Code for Session Integrity issues"

From OWASP
Jump to: navigation, search
(Leading Practice Patterns for Session Management/Integrity)
Line 33: Line 33:
 
HTTPOnly Cookie:
 
HTTPOnly Cookie:
 
Prevents cookie access via client side script. Not all browsers support such a directive.
 
Prevents cookie access via client side script. Not all browsers support such a directive.
 +
 +
Valid Session checking:
 +
 +
Upon any HTTP request the framework should check if the user pertaining to the HTTP request (vis session ID) is valid.
 +
 +
Successful Authentication:
 +
Upon a successful login the user should be issued a new session identifier. The old session Id should be invalidated. This prevents session fixation attacks and the same browser also sharing the same session ID in a multi user environment. SOme times the session Id is per browser and the session remains valid while the browser is alive.
 +
 +
Logout:
 +
This also leads to the idea of why a logout button is so important. The logout button should invalidate the users session Id when it is selected.
 +
 
==Related Articles==
 
==Related Articles==
  

Revision as of 09:37, 12 September 2007

OWASP Code Review Guide Table of Contents

Contents

Introduction

How to locate the potentially vulnerable code

Session Tracking/Management Techniques

HTML Hidden Field

The HTML Hidden field could be used to perform session tracking. Upon each HTTP POST request the hidden field is passed to the server identifying the user. It would be in the form of

<INPUT TYPE="hidden" NAME="user"VALUE="User001928394857738000094857hfduekjkksowie039848jej393"> 


Server-side code is used to perfrom validation on the VALUE in order to ensure the used is valid. This approach can only be used for POST/Form requests.

URL Rewriting

URL rewriting approaches session tracking by appending a unique id pertaining to the user at the end of the URL.

<A HREF="/smackmenow.htm?user=User001928394857738000094857hfduekjkksowie039848jej393">Click Here</A> 


Cookies

Cookies were invented by netscape as a way of keeping state when using the stateless protocol HTTP. Commonly used for maintaining state but must be careful not to store any sensitive information in a cookie.


Persistant Cookies

State information and cookies

Leading Practice Patterns for Session Management/Integrity

HTTPOnly Cookie: Prevents cookie access via client side script. Not all browsers support such a directive.

Valid Session checking:

Upon any HTTP request the framework should check if the user pertaining to the HTTP request (vis session ID) is valid.

Successful Authentication: Upon a successful login the user should be issued a new session identifier. The old session Id should be invalidated. This prevents session fixation attacks and the same browser also sharing the same session ID in a multi user environment. SOme times the session Id is per browser and the session remains valid while the browser is alive.

Logout: This also leads to the idea of why a logout button is so important. The logout button should invalidate the users session Id when it is selected.

Related Articles

http://www.owasp.org/index.php/Category:OWASP_Cookies_Database http://msdn2.microsoft.com/en-us/library/ms533046.aspx http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/Cookie.html