OWASP Khartoum - CSRF Session - Abdullah Ulber - January 2013


Published on

Abdullah Ulber works at Banan IT as a senior software architect, web developer and education manager. He looks back to more than ten years of professional software development, specialising in web applications based on ASP.NET MVC, HTML5 and Silverlight. He is a keen follower of all trends in the web world and enjoys passing on his knowledge in captivating presentations and courses.

Outside his work, he is an organising member of the OWASP local chapter in Khartoum.

Before his move to Sudan, Abdullah was the co-organiser of the Swiss Olympiad in Informatics and the team leader of the Swiss delegation to the International Olympiads in Informatics from 1998 to 2005.

He holds a master’s degree in computer science from ETH Zurich.

This session was held on Saturday 12/01/2013. Check our best shots from the event on our Facebook group: http://fb.com/groups/OWASP.Khartoum

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Use official flyer to connect with the invitation, start with something familiar.
  • Graduated at ETH Zurich in 1996.SOI team leader and co-organiser from 1998 to 2005.Moved to Sudan in 2005.Since 2012 working as a volunteer at OWASP Khartoum.
  • Explain how this session is aligned with OWASP’s mission.Highlight “visible” -> demos, diagrams“decisions” -> requires knowledge and understanding
  • OWASP is not “Hogwarts School of Witchcraft And Wizardry” (from Harry Potter), or in security terms, it is not a workshop for wanna-be hackers. We are not teaching how to break into websites, but how to protect yourself and your web sites. We are “the good guys” rather than “the bad guys”.And there is a second reason why OWASP is not “Hogwarts School of Witchcraft And Wizardry”: whatever we teach is not witchcraft or magic at all. In this session, I will go to great lengths to explain exactly how everything works.Image: http://en.wikipedia.org/wiki/File:Hog2warts.jpg
  • There is on final point to clarify before we jump into the real subject.Explain that “OWASP does not endorse or recommend commercial products or services” (from https://www.owasp.org/index.php/Main_Page).I am using FireFox and ASP.NET simply because I am familiar with both and because they serve my purpose, that’s all. It does not mean that either product is superior to other products. Everything that I demonstrate works equally well with any other browser and any other server-side technology.
  • Introduce a break before Protections or before Effective Protections
  • Here I could connect CSRF to myself, how I learnt about it and how it impressed me at that time. This also connects the audience to the speaker and adds a personal touch.Intro slide: tell how I came to meet CSRF and how shocking it was. All my previous web apps were vulnerable of course. Kind of fell in love with CSRF. Simple yet dangerous and profound. There is so much more to it than what meets the eye. Everybody knows XSS but hardly anyone knows CSRF. Time to change this!
  • CSRF, XCRF,Session Surfing, Sea SurfCSRF coined in 2001 by Peter WatkinsImage: Surfer: http://freerangestock.com/details.php?gid=&sgid=&pid=21894
  • The easiest way to introduce CSRF is with a demo.
  • Image: http://www.morguefile.com/archive/display/623253
  • The MITRE Corporation: http://en.wikipedia.org/wiki/MITRECVE = Common Vulnerabilities and Exposures: http://cve.mitre.org/Image: http://freerangestock.com/details.php?gid=&sgid=&pid=18985
  • “Numbers represent search volume”Contrast with XSS and SQL Injection.
  • “Let’s be clear here. Just because interest is falling does not mean the threat is gone. Both attacks are as dangerous as always and you have to protect against them.”
  • “It is terribly easy to manipulate with statistics. Therefore, to be fair, let’s compare CSRF directly with XSS and SQL Injection”http://www.google.com/trends/explore#q=xss%2C%20csrf%2C%20sql%20injection&cmpt=q
  • http://www.marketwatch.com/story/q3-2012-firehost-web-application-attack-report-shows-marked-increase-in-cross-site-attacks-2012-10-22http://www.securityweek.com/cross-site-attacks-rise-top-q3-says-firehost“Analysis of 15 million cyber attacks by FireHost users found XSS, directory traversals, SQL injections, and cross-site request forgery (CSRF) attacks to be the most serious and frequent and are part of FireHost's 'Superfecta' group. In Q3 of 2012, XSS and CSRF represented 64 per cent of attacks in this group.The report claimed that XSS is now the most common attack type, with more than one million XSS attacks blocked during this period alone, a rise from 603,016 separate attacks in Q2 to 1,018,817 in Q3. There were 843,517 CSRF attacks reported.”
  • Image: http://www.morguefile.com/archive/display/79942
  • http://www.darkreading.com/security/perimeter-security/211201111/Ransom = فديةFocus in oneThe size of the stolen data: 18 millionLargest online shopping siteDemand for ransom
  • http://www.darkreading.com/security/perimeter-security/211201111/ING: global financial institution ( http://en.wikipedia.org/wiki/ING_Group )“the CSRF bug […] found on INGDirect.com represents one of the first publicly disclosed CSRF flaws on a bank site. ”“The CSRF bug they found on ING’s site would have let an attacker move funds from the victim’s account to another account ”
  • http://news.softpedia.com/news/Researchers-Find-Wormable-CSRF-and-XSS-Flaws-on-Facebook-159342.shtmlIn certain cases, the LIKE and become a friend function could be executed via CSRF.Bridge: All the previous news reports are pretty old. Does that mean web sites have become more secure now? Well, think again, here are brand new article, again from facebook.
  • http://www.zdnet.com/researcher-reports-a-csrf-vulnerability-in-facebooks-app-center-earns-5000-7000003245/
  • Amazon: manipulate recently bought books
  • Image: http://digital-ink-stock.deviantart.com/art/Wooden-Doll-005-5225041
  • Image: http://freerangestock.com/details.php?gid=&sgid=&pid=894
  • Image: http://freerangestock.com/details.php?gid=47&sgid=&pid=1491
  • No popups, no alerts, no unusual behaviours, totally silentImage: http://www.dreamstime.com/spider-fly-stock-photos-imagefree238003Alternative image: http://www.morguefile.com/archive/download/223273
  • No special tools or deep knowledge necessary.No need for sniffing, no need for access to traffic in the middle.Image: http://freerangestock.com/details.php?gid=&sgid=&pid=11170
  • CSRF penetrates areas that are considered secure: Intranet and admin areasTell story about cat ladders that are sometimes hard to believe that a cat can actually use it.
  • A video to diversify the media.
  • Image: http://www.morguefile.com/archive/display/15667
  • Counterintuitive: admin areas feel safe, so they are many times not appropriately secured.
  • Reason for underestimation: hard to detect attacks taking place. They look like legitimate accesses.Compare this for example to XSS and SQLi: both leave identifiable traces in the request and in the server.Underestimated in two senses of the word:Not taking the risk seriouslyNot accurately reflected in statistics (due to being hard to detect)Image: http://www.morguefile.com/archive/display/791662
  • All of the characteristics described so far are bad enough, it gets worse: here is the reason why CSRF is truly evil and so powerful.Compare with XSS, SQL injection: protection by default (out of the box)Compare with HIV/AIDS prevention: three elements are necessary:Awareness of the threatKnowledge about the protectionActual use of protectionAdd that with HIV prevention, an even better protection is of course a monogamous relationship. However, the web world is by its nature completely promiscuous.Image: http://openwalls.com/down/image/20303/durex_condoms_2560x1024.jpg
  • Bridge: to be able to protect yourself or your web site from CSRF, we need to learn first how CSRF actually works.Image: http://freerangestock.com/details.php?gid=&sgid=&pid=15833
  • Build up the diagram piece by piece. Mention that the beginning might be terribly simple but no worries, it will get more involved later on Image: http://freerangestock.com/details.php?gid=36&sgid=&pid=18719
  • Mention: less interesting in the context of CSRF since GET is (should be) idempotent (= no changes on the server)
  • For POST, image of a form and arrows from the fields to the internet
  • Show first diagram.This is the state of the Internet at its very beginning => very simple.Point out something strange: how does facebook know who I am? How does it know on which wall to post? => need for identity.
  • A user identity is just a random number.Mention that session id is the technical term.
  • Overlay: domains (keep it simple: no need to mention subdomains, etc)Images: http://freerangestock.com/details.php?gid=&sgid=&pid=2380
  • This slide introduces the baseline diagram that is used in several of the following slides. Make sure that the audience understands its components.
  • Give a demo with traffic inspector here => audience can see real traffic for the first time, including GET, POST and cookies
  • Explain the problem and mention the confused deputy
  • “poor man’s CSRF”: but many times succeeds!Via image, iframe, script (GET)Nearly same diagram as with POSTIMG SRC  <imgsrc="http://host/?command">  SCRIPT SRC  <script src="http://host/?command">  IFRAME SRC  <iframesrc="http://host/?command">
  • Demo: carry out the initial attack and this time show the traffic. Show real headers
  • Image: http://www.bloggingawaydebt.com/2011/11/false-security/
  • Point out spelling mistake?On the face of it, thereferer header would be the best and most natural protection that would do away with all CSRF attacks immediately. The number onereason why CSRF works is because the server has no way to know from which page a request came. It only sees the identifying cookie and is happy with it. Explain, demo: show in network inspectorDiscuss privacy issue with refererImage: letter with sender’s address http://3.bp.blogspot.com/-IDt_3nLxbaI/TfIu1nezSzI/AAAAAAAADec/-xubUokKUEM/s1600/cl_0001+%25282%2529.jpg
  • Mention how much info can be inside a typical SharePoint URL.Image: http://www.morguefile.com/archive/display/15667
  • Diagram to explain tracking sites and how they gain their information.
  • Then demonstrate with Collusionhttp://edition.cnn.com/2012/12/17/showbiz/movies/hobbit-december-record-ew/index.htmlhttp://www.imdb.com/title/tt0903624www.amazon.com/The-Hobbit-An-Unexpected-Journey/dp/B009O07NDYCareful: Collusion does NOT yet work with FF 18 (as of 12.1.2013).Make sure you run the demo on https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0.1/win32/en-US/
  • http://www.mozilla.org/en-US/collusion/
  • “Unless you actively protect yourself, your privacy is seriously violated in the internet.”Bridge: fortunately, there are any number of add-ons that block the Referer header. I am only showcasing one of them: HeaderControlRevived.
  • However, HTTPS + Referer is quite practical. The Referer is usually sent with same-domain HTTPS requests, and is NEVER sent with cross-domain HTTPS.Prop: bring isolated cable and connect with a listener in the first row. A neat way to showcase the effect of HTTPS.Image: http://www.audiophilia.com/wp/wp-content/uploads/2011/11/a_komako_sc_master_1.jpg
  • “This time, all transmission between the server and the client are protected. So what? The green cookie is still delivered to the server.”
  • “So protecting the transmission channel does not work. How about protecting the cookies, then?”
  • “The point here is that the malicious JavaScript code does not have to read the cookie at all, because the browser sends the httpOnly cookie by itself to the green server.As a side note, the browser itself prevents code from the red page to read the cookies for the green site anyways.”
  • “This time, all transmission between the server and the client are protected. So what? The green cookie is till delivered to the server.”
  • “None of the built-in features of HTTP protocol provide sufficient protection against CSRF.”
  • Image: http://www.morguefile.com/archive/display/782103Image 2: http://hoo-peninsula.blogspot.com/2011/02/isle-of-grain-ww2-anti-tank-obstacles.html
  • Diagram: user, browser, server, application protectionsDraw roadmap with a detour to application and then back to server. Explain the reason for the detour: “never use a tool that you don’t understand what it does”Also, allows to end with OWASP which is really cool.Mention that CSRF is interesting because there are any number of ways to protect against it (unlike, e.g. XSS or SQLi).Connect the user and developer side to the audience.Image: http://www.thestarphoenix.com/health/Laptop+said+nuke+sperm+caveats+abound/5783206/story.html
  • “For each of the following protections, I will show you the CSRF diagram and pinpoint exactly why the protection works and how it works.And we will discuss how friendly and how strong the protection is.”Image: http://cdn-s3-2.wanelo.com/product/image/1509176/original.jpgAlternatives: http://www.glidergloves.com/wp-content/uploads/2010/11/glide14.jpg, http://the-gadgeteer.com/wp-content/uploads/2012/02/nutouch-gloves-4.jpg
  • “In my country/in Europe, we are big fans of separate our waste into separate bins. For example, we have separate bins for plastic bottles, glass and metal.” Image: http://freerangestock.com/details.php?gid=&sgid=&pid=10805http://www.morguefile.com/archive/display/141227
  • But is this practical? Is it even safer? Only marginally, because most likely, the CSRF attack will happen inside the “everything else” browser.Extreme measure.Seriously, who does that? Very user unfriendly, dumps all the responsibility on the user. Almost paranoid. Besides, there are only so many browsers out there. If you have used up IE, FireFox, Chrome and Opera, then your busted anyway  => stay humorous.But: very secure
  • A CSRF attack from browser B will not succeed because no cookie is sent to the web server.Assessment: very secure but also very inconvenient.
  • Lessextreme than different browsers, but still not very user friendly. Most people use their personal machines, so why sign out and sign in all the time?
  • When a user signs out, the cookie with the user identity is destroyed. Once signed out, a CSRF attack will not succeed any more.
  • Really in between client and server side. The cookie lifetime is determined by the web application.Signs out the user automatically, kind of an extension of the previous slide.Image: http://dayofglory.deviantart.com/art/Time-Expired-56977194
  • Assessment
  • “Manually signing out or even more so using multiple browsers is a bit tedious. It would be a lot more convenient if the browser could protect us from CSRF. And there is good news: this is really possible! There are multiple browser add-ons out there that do exactly this.”CsFireNoScript Application Boundaries Enforcer (ABE)Request PolicyDemo CsFire (does not seem to work properly with subdomains) or Request Policy (works great, always blocks)Mention that all of these add-ons try to distinguish between legitimate and illegitimate cross-site calls.Image: http://www.morguefile.com/archive/display/117415
  • Here is one place where it looks a bit like magic By default, CsFire will prevent cookies from being sent across domains. You can also go and change the settings to suppress the entire request altogether.Need to mention that sometimes, cross-site cookies or cross-site requests are legitimate and even essential for transactions to work. Examples are single-sign on or eBanking sites.
  • Here is one place where it looks a bit like magic By default, CsFire will prevent cookies from being sent across domains. You can also go and change the settings to suppress the entire request altogether.Need to mention that sometimes, cross-site cookies or cross-site requests are legitimate and even essential for transactions to work. Examples are single-sign on or eBanking sites.
  • Showcase the alert andthe request suppression.
  • School of thought: The application must defend itselfYou cannot rely on the client to be protected.Fundamentally, all server-side protections increase the claims coming from the client side.Image: http://s1.aecdn.com/images/news/history-of-the-batmobile-51373_1.jpeg
  • Sending the correct cookie and a form is not enough. The client must send some kind of proof along with the request.Bridge: There is a large number of ways this proof can be sent.
  • Used for high impact or security related settings. Would be too annoying for everyday operations.
  • Not very user friendly, in fact, annoyingAlso pretty weak: only proofs that you’re human, not the actual identity.There are services dedicated to CAPTCHA solving.human assisted:http://www.zdnet.com/blog/security/inside-indias-captcha-solving-economy/1835http://www.troyhunt.com/2012/01/breaking-captcha-with-automated-humans.htmlhttp://www.deathbycaptcha.com/user/loginfully automated:http://www.captchasniper.com/
  • http://en.wikipedia.org/wiki/Dual_factor_authenticationExamples: online + email, online + mobile(ATM: presence + PIN + card)Image: http://upload.wikimedia.org/wikipedia/commons/e/ef/CryptoCard_two_factor.jpg
  • Assessment: Very secure, but costly for the issuer (SMS, letters, special devices)
  • AKA Dynamic Authorization Token (DAT)“Instead of requiring the client to provide proof, why not let the server generate and send the proof itself? The client then returns the same proof and we’re done.”Explain the idea with the sealed letter.Image: http://suptg.thisisnotatrueending.com/archive/21086394/images/1350022280196.jpg
  • The server keeps the master copy of the snowflake for later comparison.Explain that the red JavaScript cannot read the token from inside the green form: same-origin policy.Explain drawback of the simple request validation token approach: state on the server
  • AKA Synchroniser Token Pattern (OWASP terminology)Benefit:Avoidsstate on the server.Similarity to dual-factor authentication (previous slide): proof arrives to the server via cookie and form.
  • “This time, the snowflake is sent both inside a cookie and inside the form. Both are sent back to the server, where they are checked for identity. We end up with so many snowflakes, it almost feels like winter.  “Explain double submit and the benefit. Equality check on the server.The red JavaScript cannot read the green snowflake (because of they originate from different servers).Let the audience guess the weakness: Snowflakes could be stolen and reused for any other sessions or users. They can even be stored for later. Heck, you can simply produce your own values (if you find a way to set green cookies, which is possible in some circumstances).
  • The problem with the double submit token from the previous slide is that the entire protection is in the hands of the clients.
  • Tell the story of the thief in the souq al-araby who replaced the padlocks in the shops with his own and then broke into the shops later in the night with his own key.Bring two identical padlocks and keys.
  • http://en.wikipedia.org/wiki/HMACWe literally have to find a way to protect the protection. However, there is a small problem: we cannot simply keep the padlock inside (on the server) – we need to round-trip the token to the client and back. Hmmm…Fortunately, mathematics and cryptography can help up out.Image: www.dreamstime.com/lock-and-key-stock-photo-imagefree187880
  • To protect the token, we can merge it mathematically with the session identity. Keep in mind that all these icons are in reality just numbers.A crucial feature is that neither session identity nor the (original) token can be regenerated from the protected token (hash). We can however verify that a given protected token belongs to a session identity (yes/no). That’s the question that the server asks whenever a protected token arrives.
  • This is the recommended best practice to prevent CSRF attacks.By now things have become pretty involved. Would be challenging to implement this yourselves.“You might be asking yourselves: am I supposed to implement all of this myself? The good news is that the answer is: no.”Mention ASP.NET MVC’s AntiRequestForgeryToken
  • Showcase the ASP.NET MVC version.
  • “But it gets even better: you do not even have to go over each form separately, you can apply the protection on the application and server level. The friendly people from OWASP did all the hard work already.”Don’t go into too much detail here. Leave a teaser for the audience to investigate on their own.
  • Time to draw strings together.Diagram showing user friendliness against effectiveness of the protection. CsFire is outside the scale: sometimes it is too effective! => humorous element.Discuss the appropriate location with the audience. Mention that the exact location is certainly negotiable.
  • No-one says you can only use a single protection in your site. Let’s see which protectionsfacebook uses.Image: http://www.gluckstein.com/blog/2011/04/15/its-cool-to-bucket-your-brain-tell-your-kids-and-everyone-you-know/
  • Ask the audience which one to show first. Hopefully – and predictably – they will choose the bad news first.The first four questioners receive a roll of cookies.
  • OWASP Khartoum - CSRF Session - Abdullah Ulber - January 2013

    1. 1. About the Speaker Abdullah Ulber MSc in Computer Science Swiss Olympiad in Informatics Senior Software Architect Web Developer Volunteer at OWASP Khartoum
    2. 2. OWASP Mission Lots of demos Lots of diagrams "to make application security visible so that people and organisations can make informed decisions about application security risks" Lots of stuff covered“Everything you ever wanted to know about CSRF ”
    3. 3. What OWASP is NOT Hogwarts School of Witchcraft And Wizardry
    4. 4. Product Neutrality“OWASP does not endorse or recommend commercial products orservices, allowing our community to remain vendor neutral with thecollective wisdom of the best minds in software security worldwide.”
    5. 5. Character How CSRFIntroduction Motivation Protections Study Works
    7. 7. CSRF, pronounced "sea surf"First mention in 2001 by Peter Watkins.The attack withthe coolest name.“Im afraid CSRF is going to be a mess to deal with inmany cases. Like trying to tame the seas.”
    8. 8. A Magic Trick
    9. 9. MOTIVATION
    10. 10. Predictions 2007OWASP 2007: “CSRF is more prevalentthan its current ranking wouldindicate, and it can be highlydangerous.” MITRE CVE Trends, May 2007: “… there will likely be a significant increase in CSRF reports.” WhiteHat Security, July 2007: “The Sleeping Giant”
    11. 11. Interest over Time 2005 2006 2007 2008 2009 2010 2011 2012
    12. 12. Unlike XSS and SQL Injection SQL Injection XSS 2005 2006 2007 2008 2009 2010 2011 2012
    13. 13. Let’s Be Fair SQL Injection XSS CSRF 2005 2006 2007 2008 2009 2010 2011 2012
    14. 14. CSRF and XSS: The Evil Twins 12 9 32 29 CSRF 27 40 30 35 XSS 43 24 38 Directory 24 Traversal 14 21 10 12 SQL Injection Total 2011 Q1 2012 Q2 2012 Q3 2012 Statistics by Firehost
    15. 15. In the News
    16. 16. Strike #1 Feb 2008
    17. 17. Strike #2 Sept 2008
    18. 18. Strike #3 May 2010
    19. 19. A Career Alternative? Aug 2012
    20. 20. More Victims cPanel osCommerce Amazon Ebay Gmail … and countless more
    22. 22. Remote Control
    23. 23. No Damage Ceiling Purchase of unwanted/unexpected items Change the “Ship To:” address Password Reset / User Account modification Add contact or “friend”
    24. 24. Silent but DeadlyNo browser warningsNo popups No unusual behaviour whatsoever
    25. 25. Easily Mountable No DNS manipulations No wire-tapping “Even a monkey can do it.”
    26. 26. Sneaky
    27. 27. Sneaky
    28. 28. Intranet Penetration
    29. 29. Administration Areas
    30. 30. Underestimated Hard to detect CSRF attacks fly under radar Under-reported
    31. 31. Unprotected by Default Unlike XSS and SQL Injection 1. Awareness of the threat 2. Knowledge of the protection 3. Use of protection
    32. 32. A Toxic Mix Remote control without damage ceiling Silent But deadly Sneaky Underestimated Unprotected by default
    33. 33. HOW CSRF WORKS
    34. 34. Internet 101
    35. 35. GET
    36. 36. POST
    37. 37. Regular Browsing GET Browser Web Server GET link POST form link form
    38. 38. User Identity
    39. 39. On the Server: Session State3059750700 012299210
    40. 40. On the Client: Cookies owasp.sd 3059750700 012299210cnn.com
    41. 41. Regular Browsing With Identity Browser Web Server GET link POST form
    42. 42. Prepare For Attack
    43. 43. POST-Based CSRF Browser Web Server POST form POST Evil Web Server JavaScript
    44. 44. From the Server’s Perspective Web Server Confused deputy problem
    45. 45. GET-Based CSRF (Poor Man’sVersion) Browser Web Server POST form GET Evil Web Server image
    46. 46. PROTECTIONS
    47. 47. Ineffective Protections
    48. 48. Referer Header
    49. 49. The Server’s Perspective withReferer Web Server referer
    50. 50. Corporate Information Leaks link referer
    51. 51. Behaviour Tracking Tracking site Tracking cookie
    52. 52. Real-Life Behaviour Tracking
    53. 53. A Helpful Venn Diagram
    54. 54. HTTPS
    55. 55. HTTPS Browser Web Server protected POST form POST Evil Web Server JavaScript
    56. 56. Protected Cookies httpOnly “secure” invisible to JavaScript sent only via HTTPS
    57. 57. Protected Cookies: httpOnly Browser Web Server can’t read POST form can’t read POST Evil Web Server JavaScript
    58. 58. Protected Cookies: secure Browser Web Server protected POST form POST Evil Web Server JavaScript
    59. 59. Ineffective Protections: SummaryReferer Header HTTPS Secure CookiesWould be the perfect Good in their own respects, butsolution but suffers unfortunately do not help with CSRF.from privacy issues.
    60. 60. Effective Protections
    61. 61. Protections by Location Client-side Server-side ServerUser Browser App
    62. 62. Client-Side Protections
    63. 63. Separation of Concerns
    64. 64. Use of Separate Browsers facebook email everything else
    65. 65. Use of Separate Browsers Browser A Web Server POST form POST Browser B Evil Web Server JavaScript
    66. 66. Sign Out
    67. 67. Sign Out Browser Web Server POST form POST Evil Web Server JavaScript
    68. 68. Cookie Expiry
    69. 69. Cookie Expiry Browser Web Server POST form POST Evil Web Server JavaScript
    70. 70. Anti-CSRF Browser Add-Ons CsFire NoScript: Application Boundaries Enforcer (ABE) Request Policy
    71. 71. Anti-CSRF Browser Add-Ons(CsFire) Browser Web Server POST form POST Evil Web Server JavaScript
    72. 72. Anti-CSRF Browser Add-Ons (RequestPolicy) Browser Web Server POST form Evil Web Server JavaScript
    73. 73. Server-Side Protections The server has to defend itself. Don’t rely on the client. Let the client prove its legitimate origin.
    74. 74. The Burden of Proof Web Server + proof
    75. 75. Re-Authentication
    76. 76. Re-Authentication Browser Web Server form POST password ? Evil Web Server JavaScript
    77. 77. CAPTCHA Very unfriendly. Only proves that you are human.
    78. 78. CAPTCHA Browser Web Server form POST solution ? Evil Web Server JavaScript
    79. 79. Dual-Factor Authentication
    80. 80. Dual-Factor AuthenticationBrowser Web Server POST form POST Evil Web Server JavaScript
    81. 81. Request Validation Token
    82. 82. Request Validation Token Browser Web Server form POST can’t read ? POST Evil Web Server JavaScript
    83. 83. Double Submit Token aka “Synchroniser Token Pattern” (OWASP terminology) via cookie via form
    84. 84. Double Submit Token Browser Web Server form POST ? POST Evil Web Server JavaScript
    85. 85. Good and Evil on the Web Client Server
    86. 86. The Padlock Thief
    87. 87. Protect the Protection
    88. 88. HMAC (Hash-based message authenticationcode) Session identity ? Protected token Token
    89. 89. Protected Double Submit Token Browser Web Server form POST ? POST Evil Web Server JavaScript
    90. 90. Pluggable Protection Web Server CSRFGuard Library Apache IIS Web ModSecurity CRS Project Application Java PHP .NET
    91. 91. Take Your Pick browser add-onshigh separate browsers sign out double submit token Effectiveness re-authenticate dual factor auth. CAPTCHA cookie expiry low low User Friendliness high
    92. 92. Multiple Protections double submit token re-authentication dual-factor authentication CAPTCHA cookie expiry All !
    93. 93. Take-Aways Questions? The bad news The good newsCSRF is a clear and present There are many protectionsdanger. available.CSRF is on the rise. Tools are your friends.
    94. 94. Planned Upcoming Presentations Hijacking Bonanza (SSL/TSL, NTLM, JSON) Web Server Hardening (Apache/IIS) Secure Development Practices (PHP/ASP.NET) Application Defense in Depth HTML5 Content Security Policy - The End of XSS ?