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.

1. Session Management Security
Introduction to OWASP
TAO Dev Forum
September 12, 2013

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. ~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. OWASP KnowledgeBase
• Projects
• Articles
• Presentations
• Mailing lists
• Cheat Sheets
• Documentation projects
• Code projects
•Videos

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. • 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. Questions?
Questions?
Thanks!

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. 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. 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. TAO Podium 2.pdf