1 / 21

Ch. 7 -Attacking Session Management

Ch. 7 -Attacking Session Management. Adapted from The Web Application Hacker’s Handbook 2 nd Edition by Dafydd Stuttard and Marcus Pinto. Latasha A. Gibbs CSCE 813 – Internet Security, Fall 2012 College of Engineering and Computing University of South Carolina. OVERVIEW . The Need

chendon
Download Presentation

Ch. 7 -Attacking Session Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ch. 7 -Attacking Session Management Adapted from The Web Application Hacker’s Handbook 2nd Edition by Dafydd Stuttard and Marcus Pinto Latasha A. Gibbs CSCE 813 – Internet Security, Fall 2012 College of Engineering and Computing University of South Carolina

  2. OVERVIEW • The Need • Weaknesses of Token Generation • Weaknesses of Session Token Handling • Securing Session Management • Summary

  3. THE NEED • Reminder: HTTP Protocol is stateless • Majority of web “sites” are actually web applications • The session management mechanism is a fundamental security component in most web applications

  4. TRUE OR FALSE? If we use smartcards for authentication, a user’s session cannot be compromised without them?

  5. SESSION MANAGEMENT VULNERABILITIES • HTTPOnly Flag Not Set • Secure Flag Not Set • Session Porting Permitted • Persistent Cookie • Cookieless Sessions in Use • Session Token Content Weaknesses • Session Token Not Regenerated on Login • Cookie Domain and Path not Restricted JUST A FEW VULNERABILITIES!

  6. WHAT HAPPENS IF THE ATTACKER SUCCEEDS? • Attacker can bypass authentication • Attacker can masquerade as a legitimate user • Attacker can compromise an administrative user or own the entire application The list goes on…

  7. OVERVIEW • The Need • Weaknesses of Token Generation • Weaknesses of Session Token Handling • Securing Session Management • Summary

  8. WEAKNESSES IN TOKEN GENERATION • Meaningful Tokens • Predictable Tokens • Concealed Sequences • Weak Random Number Generation

  9. MEANINGFUL TOKENS 757365723d6461663b6170703d61646d696e3b646174653d30312f31322f3131 • Tokens containing account username, first or last names, date/time stamp, client IP, etc. • Attackers can use a hexadecimal decoder to reveal the session token easily • Examples of online decoders include: www.string-functions.comor www.converstring.com User=daf;app=admin;date=10/09/11

  10. WEAK RANDOM NUMBER GENERATION • Predictable pseudorandom generator used • After a visual inspection, a more rigorous approach to test the quality of randomness is necessary • Burp Sequencer is a tool that will test randomness of web application tokens • Obtaining a sample size of 20,000 tokens, will achieve compliance with FIPS test for randomness

  11. OVERVIEW • The Need • Weaknesses of Token Generation • Weaknesses of Session Token Handling • Securing Session Management • Summary

  12. WEAKNESSES IN TOKEN HANDLING Disclosure of tokens on network Disclosure of Tokens in System Logs An application may use the URL query string as a mechanism for transmitting tokens For example, google search inurl:jsessionid will produce a list of applications that transmit the Java platform session token • Occurs when tokens are transmitted in an unencrypted form • For example, a site that uses HTTPS to protect login, but reverts to HTTP for the remainder of the user session

  13. DO’S & DON’TS • Tokens should only be transmitted over HTTPS • Tokens should never be transmitted in the URL • Visibility of session token for administrative or diagnostic purposes should be limited • Logout functionality should be implemented • Session expiration should be implemented • Concurrent logins should be prevented • Restrict domain and path scope of application should be restricted as much as possible

  14. COMMON MYTHS • “Our token is secure from disclosure to 3rd-parties because we use SSL.” • “Our token is generated by the platform using cryptographically sound technologies.”

  15. OVERVIEW • The Need • Weaknesses of Token Generation • Weaknesses of Session Token Handling • Securing Session Management • Summary

  16. HOW CAN WE ENSURE SECURE SESSIONS?

  17. SECURING SESSION MANAGEMENT • Appears simple...as generating strong tokens and providing token protection throughout life cycle • But…requires developers to have an in-depth understanding of protocols, algorithms, and black-hat community attacks

  18. OVERVIEW • The Need • Weaknesses of Token Generation • Weaknesses of Session Token Handling • Securing Session Management • Summary

  19. SUMMARY • Web Applications with Broken Session Management = Keys to the Kingdom • Possible avenues of attack are endless • Secure session management is necessary to protect web applications

  20. FURTHER READING • OWASP-Session Management Cheat Sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet • Paper on Secure Session Management with Cookies http://www.isecpartners.com/files/web-session-management.pdf • Paper on Web Session Management http://www.technicalinfo.net/papers/WebBasedSessionManagement.html • Session Management for Clustered Applications http://www.oracle.com/technetwork/articles/entarch/session-management-092739.html

  21. Thanks and have a lovely evening… QUESTIONS?

More Related