OWASP Khartoum - CSRF Session - Abdullah Ulber - January 2013
•Descargar como PPTX, PDF•
6 recomendaciones•4,676 vistas
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
Recomendados
Recomendados
Más contenido relacionado
Destacado
Más de OWASP Khartoum
Más de OWASP Khartoum (12)
Último
Último (20)
OWASP Khartoum - CSRF Session - Abdullah Ulber - January 2013
- 2. About the Speaker Abdullah Ulber MSc in Computer Science Swiss Olympiad in Informatics Senior Software Architect Web Developer Volunteer at OWASP Khartoum
- 3. 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 ”
- 4. What OWASP is NOT Hogwarts School of Witchcraft And Wizardry
- 5. Product Neutrality “OWASP does not endorse or recommend commercial products or services, allowing our community to remain vendor neutral with the collective wisdom of the best minds in software security worldwide.”
- 6. Character How CSRF Introduction Motivation Protections Study Works
- 7. INTRODUCTION
- 8. CSRF, pronounced "sea surf" First mention in 2001 by Peter Watkins. The attack with the coolest name. “I'm afraid CSRF is going to be a mess to deal with in many cases. Like trying to tame the seas.”
- 10. MOTIVATION
- 11. Predictions 2007 OWASP 2007: “CSRF is more prevalent than its current ranking would indicate, and it can be highly dangerous.” MITRE CVE Trends, May 2007: “… there will likely be a significant increase in CSRF reports.” WhiteHat Security, July 2007: “The Sleeping Giant”
- 12. Interest over Time 2005 2006 2007 2008 2009 2010 2011 2012
- 13. Unlike XSS and SQL Injection SQL Injection XSS 2005 2006 2007 2008 2009 2010 2011 2012
- 14. Let’s Be Fair SQL Injection XSS CSRF 2005 2006 2007 2008 2009 2010 2011 2012
- 15. 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
- 16. In the News
- 17. Strike #1 Feb 2008
- 18. Strike #2 Sept 2008
- 19. Strike #3 May 2010
- 20. A Career Alternative? Aug 2012
- 21. More Victims cPanel osCommerce Amazon Ebay Gmail … and countless more
- 23. Remote Control
- 24. No Damage Ceiling Purchase of unwanted/unexpected items Change the “Ship To:” address Password Reset / User Account modification Add contact or “friend”
- 25. Silent but Deadly No browser warnings No popups No unusual behaviour whatsoever
- 26. Easily Mountable No DNS manipulations No wire-tapping “Even a monkey can do it.”
- 27. Sneaky
- 28. Sneaky
- 31. Underestimated Hard to detect CSRF attacks fly under radar Under-reported
- 32. Unprotected by Default Unlike XSS and SQL Injection 1. Awareness of the threat 2. Knowledge of the protection 3. Use of protection
- 33. A Toxic Mix Remote control without damage ceiling Silent But deadly Sneaky Underestimated Unprotected by default
- 34. HOW CSRF WORKS
- 35. Internet 101
- 36. GET
- 37. POST
- 38. Regular Browsing GET Browser Web Server GET link POST form link form
- 39. User Identity
- 40. On the Server: Session State 3059750700 012299210
- 41. On the Client: Cookies owasp.sd 3059750700 012299210 cnn.com
- 42. Regular Browsing With Identity Browser Web Server GET link POST form
- 44. POST-Based CSRF Browser Web Server POST form POST Evil Web Server JavaScript
- 45. From the Server’s Perspective Web Server Confused deputy problem
- 46. GET-Based CSRF (Poor Man’s Version) Browser Web Server POST form GET Evil Web Server image
- 47. PROTECTIONS
- 49. Referer Header
- 50. The Server’s Perspective with Referer Web Server referer
- 51. Corporate Information Leaks link referer
- 52. Behaviour Tracking Tracking site Tracking cookie
- 54. A Helpful Venn Diagram
- 55. HTTPS
- 56. HTTPS Browser Web Server protected POST form POST Evil Web Server JavaScript
- 57. Protected Cookies httpOnly “secure” invisible to JavaScript sent only via HTTPS
- 58. Protected Cookies: httpOnly Browser Web Server can’t read POST form can’t read POST Evil Web Server JavaScript
- 59. Protected Cookies: secure Browser Web Server protected POST form POST Evil Web Server JavaScript
- 60. Ineffective Protections: Summary Referer Header HTTPS Secure Cookies Would be the perfect Good in their own respects, but solution but suffers unfortunately do not help with CSRF. from privacy issues.
- 62. Protections by Location Client-side Server-side Server User Browser App
- 65. Use of Separate Browsers facebook email everything else
- 66. Use of Separate Browsers Browser A Web Server POST form POST Browser B Evil Web Server JavaScript
- 67. Sign Out
- 68. Sign Out Browser Web Server POST form POST Evil Web Server JavaScript
- 69. Cookie Expiry
- 70. Cookie Expiry Browser Web Server POST form POST Evil Web Server JavaScript
- 71. Anti-CSRF Browser Add-Ons CsFire NoScript: Application Boundaries Enforcer (ABE) Request Policy
- 72. Anti-CSRF Browser Add-Ons (CsFire) Browser Web Server POST form POST Evil Web Server JavaScript
- 73. Anti-CSRF Browser Add-Ons (Request Policy) Browser Web Server POST form Evil Web Server JavaScript
- 74. Server-Side Protections The server has to defend itself. Don’t rely on the client. Let the client prove its legitimate origin.
- 75. The Burden of Proof Web Server + proof
- 77. Re-Authentication Browser Web Server form POST password ? Evil Web Server JavaScript
- 78. CAPTCHA Very unfriendly. Only proves that you are human.
- 79. CAPTCHA Browser Web Server form POST solution ? Evil Web Server JavaScript
- 81. Dual-Factor Authentication Browser Web Server POST form POST Evil Web Server JavaScript
- 83. Request Validation Token Browser Web Server form POST can’t read ? POST Evil Web Server JavaScript
- 84. Double Submit Token aka “Synchroniser Token Pattern” (OWASP terminology) via cookie via form
- 85. Double Submit Token Browser Web Server form POST ? POST Evil Web Server JavaScript
- 86. Good and Evil on the Web Client Server
- 89. HMAC (Hash-based message authentication code) Session identity ? Protected token Token
- 90. Protected Double Submit Token Browser Web Server form POST ? POST Evil Web Server JavaScript
- 91. Pluggable Protection Web Server CSRFGuard Library Apache IIS Web ModSecurity CRS Project Application Java PHP .NET
- 92. Take Your Pick browser add-ons high separate browsers sign out double submit token Effectiveness re-authenticate dual factor auth. CAPTCHA cookie expiry low low User Friendliness high
- 93. Multiple Protections double submit token re-authentication dual-factor authentication CAPTCHA cookie expiry All !
- 94. Take-Aways Questions? The bad news The good news CSRF is a clear and present There are many protections danger. available. CSRF is on the rise. Tools are your friends.
- 95. 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 ?
Notas del editor
- 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.