Login   Search
Skip Navigation Links
Home
Application Security Tips
Oracle , PL/SQL
IT Product Reviews
Project Management
Forum
Contact Us
Links & References
Avoid SQL Injection attack
Threats and Countermeasures: S.T.R.I.D.E
Input Validation
Session Management
Authentication Mechanism
Cross Site Scripting Vulnerabilities
Configuration Management
Scroll up
Scroll down
Oracle 9i - Programming basics PL/SQL
PL/SQL - Conditional Statements – IF
PL/SQL -Nested Block
LOOPS in PL/SQL
PL/SQL Records
Cursors in PL/SQL
PL/SQL Tables
PL/SQL Exceptions
PL/SQL Procedures
PL/SQL Functions
Oracle supplied packages
Packages
PL/SQL Ref Cursors
Types in Oracle PL/SQL
Varrays
Nested Table
Bfile and LOBs
Bulk Binding
Know Depandencies
PL/SQL Wrapper
Triggers
Scroll up
Scroll down
DBMS_SQL package
DBMS_DDL Package
DBMS_JOB Package
UTL_FILE Package
DBMS_METADATA Package
DBMS_PIPE Package
DBMS_SESSION Package
Scroll up
Scroll down

 

Blog

  • Imperativeness of agile methodology in software development
  • Get list of installed softwares on machines in your network
  • VMWare - Error - the vmware authorization service is not running
  • Add chart / graphs in ASP.net application / website
  • Microsoft Ramp Up

Blog

  • Review: uCertify.com: PrepKit for: 70-529 (C#)
  • Bird eye Review: uCertify.com: PrepKit for: 70-529 (C#)
Skip Navigation Links>Application Security Tips>Session Management

Session Management

Web applications are built on the stateless HTTP protocol, so session management is an application-level responsibility. Session security is critical to the overall security of an application.

Top session management threats include:


Session Hijacking

A session hijacking attack occurs when an attacker uses network monitoring software to capture the authentication token (often a cookie) used to represent a user’s session with an application. With the captured cookie, the attacker can spoof the user’s session and gain access to the application. The attacker has the same level of privileges as the legitimate user.

Countermeasures to prevent session hijacking include:

● Use SSL to create a secure communication channel and only pass the authentication cookie over an HTTPS connection.

● Implement logout functionality to allow a user to end a session that forces authentication if another session is started.

● Make sure you limit the expiration period on the session cookie if you do not use SSL. Although this does not prevent session hijacking, it reduces the time window available to the attacker.


Session Replay

Session replay occurs when a user’s session token is intercepted and submitted by an attacker to bypass the authentication mechanism. For example, if the session token is in plaintext in a cookie or URL, an attacker can sniff it. The attacker then posts a request using the hijacked session token.

Countermeasures to help address the threat of session replay include:

● Re-authenticate when performing critical functions. For example, prior to performing a monetary transfer in a banking application, make the user supply the account password again.

● Expire sessions appropriately, including all cookies and session tokens.

● Create a “do not remember me” option to allow no session data to be stored on the client.


Man in the Middle Attacks

A man in the middle attack occurs when the attacker intercepts messages sent between you and your intended recipient. The attacker then changes your message and sends it to the original recipient. The recipient receives the message, sees that it came from you, and acts on it. When the recipient sends a message back to you, the attacker intercepts it, alters it, and returns it to you. You and your recipient never know that you have been attacked.

Any network request involving client-server communication, including Web requests, Distributed Component Object Model (DCOM) requests, and calls to remote components and Web services, are subject to man in the middle attacks.

Countermeasures to prevent man in the middle attacks include:

● Use cryptography. If you encrypt the data before transmitting it, the attacker can still intercept it but cannot read it or alter it. If the attacker cannot read it, he or she cannot know which parts to alter. If the attacker blindly modifies your encrypted message, then the original recipient is unable to successfully decrypt it and, as a result, knows that it has been tampered with.

● Use Hashed Message Authentication Codes (HMACs). If an attacker alters the message, the recalculation of the HMAC at the recipient fails and the data can be rejected as invalid.


 

Discussion about Session Management

AuthorBody
Rahul
7/10/2009 11:11 PM
Please provide feedback about this article here.

To participate in this discussion Sign up for free membership of 24x7code.

To Signup click on Login , Use create user link & the follow the instructions.

Thank you.



Designed & Developed by Rahul Bagal