The Hacker's Guide to Session Hijacking
2 likes903 views
The document discusses session hijacking in Java EE applications. It begins with an introduction to the speaker and agenda. It then covers the basics of HTTP sessions and the OWASP top 10 risk of session hijacking. The bulk of the document demonstrates through code examples four ways to hijack sessions: exposing the session ID in the URL, sniffing network traffic to obtain the session cookie, using cross-site scripting to steal the cookie, and cross-site request forgery. It discusses best practices for secure session management in Java EE, such as using HTTPS, changing session IDs after login, and using anti-CSRF tokens. The conclusion emphasizes that complete security is not possible and the importance of continuous learning.
The Hacker's Guide to Session Hijacking
- 2. About Me • 15+ professional experience • SoRware engineer, architect, head of soRware R&D • Author and speaker • JavaOne, Devoxx, JavaZone, TheServerSide Java Symposium, Jazoon, OOPSLA, ASE, others • Top 10 Women in Tech 2016 in Poland • Founder and CTO of Yon Labs and Yonita • Automated detecZon and refactoring of soRware defects • Trainings and code reviews • Security, performance, concurrency, databases • Twi[er @yonlabs
- 3. About Me • 15+ professional experience • SoRware engineer, architect, head of soRware R&D • Author and speaker • JavaOne, Devoxx, JavaZone, TheServerSide Java Symposium, Jazoon, OOPSLA, ASE, others • Top 10 Women in Tech 2016 in Poland • Founder and CTO of Yon Labs and Yonita • Bridge the gap between the industry and the academia • Automated detecZon and refactoring of soRware defects • Trainings and code reviews • Security, performance, concurrency, databases • Twi[er @yonlabs
- 4. Agenda • HTTP, session, OWASP • 4 demos to hijack a session • Best pracZces in Java EE
- 7. HTTP
- 8. HTTP
- 9. What is Web Session? • Session idenZfies interacZons with one user • Unique idenZfier associated with every request • Cookie • Header • Parameter • Hidden field
- 13. Session Hijacking • Session theR • URL, sniffing, logs, XSS • Session fixaZon
- 14. Session Hijacking • Session theR • URL, sniffing, logs, XSS • Session fixaZon • Session predicZon
- 15. Demo: Session Exposed in URL • I will log into the sample applicaZon • I will post a link with my session id on Twi[er • @yonlabs • Hijack my session :)
- 16. How to Avoid Session Id in URL? • Default: allows cookies and URL rewriZng • Default cookie, fall back on URL rewriZng • To embrace all users • Disabled cookies in a browser • Disable URL rewriZng in an app server • App server specific • Tracking mode • Java EE 6, web.xml
- 18. Session Sniffing • How to find out a cookie? • e.g., network monitoring and packet sniffing • How to use a cookie? • Browsers’ plugins and add-ons (e.g., Cookie Manager for Firefox) • IntercepZng proxy (e.g., OWASP ZAP) • DIY: write your own code
- 19. Demo: Session Sniffing • You will log into the sample applicaZon • Any non empty user name • Please, use meaningful names! • I will monitor network traffic • tcpdump • I will hijack one of your sessions • Cookie Manager
- 24. Session Exposure • Transport • Unencrypted transport • Client-side • XSS • A[acks on browsers/OS • Server-side • Logs • Session replicaZon • Memory dump
- 27. Demo: Session Grabbed by XSS • JavaScript code to steal a cookie • Servlet to log down stolen cookies • Vulnerable applicaZon to be exploited via injected JavaScript code (XSS)
- 28. Demo: Session Grabbed by XSS • I will store malicious JavaScript code in the app • Through wriZng an “opinion” • Log into the vulnerable applicaZon • h[ps://demo.yonita.com:8181/session-xss/ • Any non empty user name • Please, use meaningful names! • Click ‚View others opinions’ page • Wait unZl I will hijack your session :)
- 32. When Session is Created? A. On storing an a[ribute in a session for the first Zme B. On calling request.getSession(true) /() for the first Zme C. On a successful login D. None of the above
- 33. When Session is Created? A. On storing an a[ribute in a session for the first Zme B. On calling request.getSession(true)/() for the first Zme C. On a successful login D. None of the above
- 34. When Session is Created? A. On storing an a[ribute in a session for the first Zme B. On calling request.getSession(true)/() for the first Zme • H[pServletRequest::getSession(true) • H[pServletRequest::getSession() • an implicit session object on JSP pages • unless <%@ page session="false" %> C. On a successful login D. None of the above
- 35. Session FixaZon: Scenario 1 • Hacker opens a web page of a system in a browser • JSP page: a new session iniZalized! • Hacker writes down the session id • Hacker leaves the browser open • User comes and logs into the app • Uses the session iniZalized by the hacker • Hacker uses the wri[en down session id to hijack the user’s session
- 36. Session FixaZon: Scenario 2 • Hacker opens a web page of a system in a browser • JSP page: a new session iniZalized! • Hacker prepares a link with the session id in URL • Hacker tricks a user to click the link • e.g. sends an email with the link • User clicks the link • Uses the session iniZalized by the hacker • Hacker uses the wri[en down session id to hijack the user’s session
- 39. Session FixaZon: SoluZon in Java EE • Change the session ID aRer a successful login • more generally: escalaZon of privileges • Java EE 7 (Servlet 3.1), Java EE 8 (Servlet 4.0) • H[pServletRequest.changeSessionId() • Java EE 6 • H[pSession.invalidate() • H[pServletRequest.getSession(true)
- 40. Secure Session Management Best PracZces • Random, unpredictable session id • At least 16 characters • Secure transport and storage of session id • Cookie preferred over URL rewriZng • Cookie flags: secure, h[pOnly • Don’t use too broad cookie paths • Consistent use of HTTPS • Don’t mix HTTP and HTTPS under the same domain/cookie path
- 41. Consistent Use of HTTPS Typical Errors • StaZc content served as HTTP from the same domain name • Pre-authenZcated pages as HTTP, post-authenZcated pages as HTTPS from the same domain name • Login form as HTTPS, the rest as HTTP • GMail for a few years aRer its launch!
- 42. Secure AuthenZcaZon Best PracZces • Session creaZon and destrucZon • New session id aRer login • Logout bu[on • Session Zmeouts: 2”-5” for criZcal apps, 15”-30” for typical apps • DetecZng session anomalies • Basic heurisZc: a session associated with the headers of the first request • The fingerprint of a first reques: IP, User-Agent,… • If they don’t match, something’s going on (invalidate!) • OWASP ModSecurity Web ApplicaZon Firewall • Rules for detecZng common security a[acks
- 43. Secure AuthenZcaZon Best PracZces cont. • Servlet 3.0 vs 3.1 vs. 4.0 • the session visible to developer code a=er login must be the same session object that was created prior to login • Session fixaZon problem • 3.0: no way to change a session id! (invalidate/getSession) • 3.1, 4.0: changeSessionId • Check out the container implementaZons • Java EE 6 vs. Java EE 7 vs. Java EE 8
- 46. Demo: CSRF to Use a Cookie • I will log into the applicaZon • Log into the applicaZon • h[ps://demo.yonita.com:8181/session-csrf/ • Any non empty user name • Please, use meaningful names! • Click the link and the bu[on ‘Click me’ • h[ps://demo.yonita.com:8181/a[ack-csrf/ • I will check my account balance :)
- 47. CSRF: SoluZon • AnZ-CSRF Token • unique token • server-side session • web framework dependent • Double Submit Cookie • no server-side session • e.g. Play framework • Encrypted Token Pa[ern • User ID + Zmestamp + nonce • Extra: • SameSite cookie flag • no support in Java EE yet, addiZonal filter needed
- 48. SameSite Cookie A[ribute: lax, strict Request Type Example Code Cookie Sent Link <a href=“…”> Normal, lax Prerender <link rel=“prerender” href=“…”> Normal, lax Form GET <form method=“GET” action=“…”> Normal, lax Form POST <form method=“POST” action=“…”> Normal iframe <iframe src=“…”> Normal AJAX $.get(“...") Normal Image <img src=“…”> Normal
- 52. Please, vote! :)