Session Management Security using OWASP

4,387 views

Published on

Technology Association of Oregon's Develop Forum produced Application Security using OWASP with speakers James Bohem and Tim Morgan. This is their presentation for the event held in September 2013.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
4,387
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Open Web Application Security Project (OWASP) is a not-for-profit worldwide organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way.Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.
  • Portland chapter stats, events
  • The reason of OWASP’s existance are our projects.OWASP is the home of more than 140 projects: split eenly between code/tools and docsUnlike a lot of hacker resources, that focus on breaking software and web sites, OWASP projects focus on buildling secure software.OWASP tools and documents are used to protect software, to detect security-related design and implementation flaws.A lot of effort is made to provide tools and documents that can be used in all the stages of the Software Development Life Cycle.Evolve https://www.owasp.org/index.php/Defenders
  • Clean up
  • Clean up
  • Session Management Security using OWASP

    1. 1. Session Management Security Introduction to OWASP TAO Dev Forum September 12, 2013
    2. 2. About Tim • Timothy D. Morgan – Application security consultant for VSR – PDX OWASP chapter leader – Popular labels: "ethical hacker", penetration tester, "breaker", software critic(?), ...
    3. 3. Cookies and Sessions ▪ HTTP cookies are a simple mechanism to track state ▫ Web server sets name/value pair ▫ Client sends name/value pair with each future request ▪ Cookies have many uses, but primarily: ▫ Organize sets of requests/responses as a "session" (think: shopping cart) ▫ Track users as they view/click on ads ▫ Authenticate future requests after users log in
    4. 4. A Short History of Cookies ▪ Great summary by lcamtuf (Michal Zalewski) in [1] ▪ Cookies first introduced circa 1994 based on a Netscape proposal ▪ Two initial RFCs (2109 and 2965) attempted, but these were never fully implemented and are very inaccurate ▪ Until RFC 6265 (April 2011), there was NO cookie standard that reflected reality
    5. 5. Problems With Cookies ▪ Domain scoping ▫ login.example.com can set cookies for example.com ▫ Should example.co.uk be able to set them for co.uk? ▪ Third-party cookies? Why not?!? ▫ Great for invading privacy advertising ▫ Some browsers block by default, others prompt, many allow while giving users options ▪ Cookie origin != JavaScript origin ▫ Cookies don't care about port/protocol/subdomain ▫ Cookies can be restricted to a URL path
    6. 6. More Problems With Cookies (I'm just getting started...) ▪ Mandated cookie minimums - can easily set enough cookies to grow beyond HTTP header limits ▪ Upper limits on cookie jar is undefined ▪ Cookies set over HTTPS will also be sent over HTTP ▫ Need extra hack (secure flag) to prevent this ▫ What if secure flag is set over HTTP? ▪ HttpOnly is a mess-- designed to make cookie theft hard in event of XSS: ▫ Can JavaScript set HttpOnly cookies? ▫ What about Flash/Java/other plugins? ▫ What about XmlHttpRequest responses? ▪ ...
    7. 7. How do I MitM thee? Let me count the ways... ▪ Wireless ▫ Open networks (even with web auth) ▫ WEP ▫ WPA-PSK ▫ Cell networks ▪ ARP poisoning ▪ DNS cache poisoning ▪ NetBIOS name poisoning ▪ Compromised router ▪ Routing protocol trickery (RIP, ICMP, etc)
    8. 8. Assumptions ▪ While underlying networking protocols have many MitM issues, SSL/TLS is designed to prevent them ▪ Let us, for the sake of argument pretend that SSL/TLS itself is secure ▫ No protocol flaws ▫ No implementation flaws ▫ Certificates properly validated ▫ We actually trust our certificate authorities ▪ I know, it's a stretch, but bear with me...
    9. 9. HTTP and HTTPS: Downgrade Attacks ▪ Whenever we try to upgrade protocol security: ▪ Same goes for the web. If an HTTP page includes an https://.../ link, what's the problem? ▫ sslstrip-style attacks ▪ This issue goes deeper still. More on that later. Backward Compatibility Protocol Negotiation Downgrade Attacks Demands Leads to
    10. 10. SSL/TLS Downgrade Attack hapless victim clever haxor search engine https://secure.bank ... Where's my bank? https://secure.bankhttp://secure.bank Request to http://secure.bank Request to https://secure.bank All additional https links replaced with http
    11. 11. Session Fixation ▪ Cookies have multiple uses, including tracking unauthenticated users ▪ Most sites issue new visitors a session on first page access ▪ Later, if the user logs in, that session is updated to an authenticated state ▪ A site is vulnerable to session fixation if they do not refresh the session cookie upon login ▪ To exploit this: ▫ Set the session cookie to a known value before login ▫ Wait for victim to log in
    12. 12. Session Fixation + Third Party Cookies hapless victim clever haxor https://example.com Got a cookie? Set-Cookie: 1234 Visit Me! Okay… Set-Cookie: 1234; domain=example.com Let me in! user=hapless&pass=victim Cookie: 1234 OK Cookie: 1234 (snicker)
    13. 13. Session Fixation + MitM hapless victim clever haxor https://example.com Got a cookie? Set-Cookie: 1234 What’s new? Same old... <img src= http://example.com/x.png> Let me in! Cookie: 1234 OK Cookie: 1234 (snicker) news.example.com Same old... Need: x.png Set-Cookie: 1234
    14. 14. Lack of Secure Flag ▪ Clearly exploitable if: ▫ Site has mixed HTTP/HTTPS content ▫ Any third-party sites link to the HTTP version ▫ Users previously bookmarked HTTP version ▪ Suppose a site only supports HTTPS, but fails to set the secure flag. Is it vulnerable?
    15. 15. No Secure Flag: Forcing a Cookie Leak hapless victim clever haxor https://example.com Set-Cookie: 1234 What’s new? Same old... <img src= http://example.com/x.png> Huh? 404 Not Found Cookie: 1234 (snicker) news.example.com Same old... Let me in! Cookie: 1234 Need: x.png Cookie: 1234
    16. 16. A Reasonable Mitigation: HTTP Strict Transport Security (HSTS) ▪ HSTS [2] tells browsers: ▫ For all future connections use HTTPS instead of HTTP ▫ Can be limited to a time period ▪ Doesn't help on a user's first visit ▪ RFC finalized in November 2012. Chrome, Firefox, and Opera support it.
    17. 17. Where HSTS Helps ▪ Mitigates: ▫ HTTPS link downgrades (sslstrip attacks) ▫ Session fixation MitM ▫ All secure flag attacks ▪ Doesn't help with: ▫ Session fixation + third-party cookies, other session fixation attacks ▫ Browsers that don't support it (yet)
    18. 18. Castles Built on Sand: Cookies Still Suck ▪ Cookies could be fixed, but they won't be: too many non-security applications depend on them ▪ Why not use an authentication protocol that is designed with security in mind? ▪ There's no good solution right now, but a promising approach is HTTP Mutual Authentication [3] ▫ Password-based auth, verifies server identity ▫ Doesn't leak a usable hash for cracking ▫ Binds authentication to underlying SSL/TLS session ▫ Mitigates phishing attacks
    19. 19. About James • James Bohem – Operates security program at WebMD Health Services – Previously spent 15 years as a security consultant – PDX OWASP community outreach coordinator
    20. 20. OWASP: Core Mission • The Open Web Application Security Project (OWASP) is a not-for-profit worldwide organization focused on improving the security of application software. • Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. • Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.
    21. 21. Core Values • OPEN Everything at OWASP is radically transparent from our finances to our code • INNOVATION OWASP encourages and supports innovation / experiments for solutions to software security challenges • GLOBAL Anyone around the world is encouraged to participate in the OWASP community • INTEGRITY OWASP is an honest and truthful, vendor agnostic, global community
    22. 22. By the numbers • OWASP tools and documentation: – Over 15,000 downloads (per month) – Over 50,000 unique visitors (per month) – Over 2 million website hits (per month) • OWASP community is blossoming worldwide – 1900+ OWASP Members in active chapters worldwide – 200+ Chapters – 36,000+ participants • Global Events – 5+ global annual conferences – Regional and local events: 20+ annually
    23. 23. About Us Portland chapter: • Founded: 2009 • 3-5 events/year • All chapter meetings are free to attend • Working on: – FLOSSHack events – Outreach to PDX development communities (You!) • Join our email list for updates
    24. 24. ~140 Active Projects • PROTECT - These are tools and documents that can be used to guard against security- related design and implementation flaws. • DETECT - These are tools and documents that can be used to find security-related design and implementation flaws. • LIFE CYCLE - These are tools and documents that can be used to add security-related activities into the Software Development Life Cycle (SDLC).
    25. 25. OWASP KnowledgeBase • Projects • Articles • Presentations • Mailing lists • Cheat Sheets • Documentation projects • Code projects •Videos
    26. 26. A few of the available resources pertinent to today’s topic: OWASP Resources Cheat Sheets: Session Management Transport Layer Protection User Privacy Protection Testing Guides: Testing cookie attributes Testing session strength Testing for Credentials Transported over an Encrypted Channel Dev Guides: Session Management Guide to Authentication Phishing Controls: HSTS page Session Fixation Attacks: Main-in-the-Middle Man-in-the-Browser Session Fixation
    27. 27. • Quick how-to-use resources & examples – Where/How to get started: • https://www.owasp.org • Cheat Sheets • Top 10 lists • Tutorials • Development Guides – In-depth articles – Code & tools – Past presentations – Events Where to look for more info
    28. 28. Questions? Questions? Thanks!
    29. 29. References 1.HTTP cookies, or how not to design protocols http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how- not-to-design.html 2.RFC 6797: HTTP Strict Transport Security (HSTS) http://tools.ietf.org/html/rfc6797 3.HTTP mutual authentication protocol proposal http://tools.ietf.org/agenda/74/slides/httpbis-3.pdf
    30. 30. Simple Steps to fight Big Brother • As fragile as it is, we need HTTPS everywhere – No downgrade if there’s nothing to downgrade to • Demand support for TLS 1.2 – Diffie-Hellman and GCM ciphersuites • Increase RSA key sizes to 2048 or greater • NIST/FIPS approved products? Don’t bother
    31. 31. Simple Steps to fight Big Brother (continued) • Stop using weak VPNs – IPSEC with pre-shared keys – PPTP • Assume the following are always monitored: – All telco traffic, including MPLS – Cloud services
    32. 32. TAO Podium 2.pdf

    ×