Slides from Paul Mooney's talk at the OWASP Ireland June Chapter meeting offering an overview of the Encrypted Token Pattern, and ARMOR, its .NET implementation.

1. Protecting Applications Against CSRF Attacks

2. Who am I?
• Host of insidethecpu.com
• Software Architect at Ryanair
• Specialise in performance optimisation
• Creator of the Encrypted Token Pattern
• Builder of A.R.M.O.R

3. Who I am NOT
• A security expert
• Certified Ethical Hacker or otherwise
• Affiliated with other security initiatives
• Here to preach

4. Why am I here?
• A nuts-and-bolts programmer
• C#
• Java
• Google Go
• JavaScript
• Etc.
• Stumbled (and then dived) into security
• Asked to implement OWASP Top 10

5. Why am I here?
• Talking about the Encrypted Token Pattern
• My Blog (insidethecpu.com)
• Visual Studio Magazine article
• .NET Rocks
• Very kindly extended an invitation

6. Cross Site Request Forgery
(CSRF)

7. Anatomy of a CSRF Attack
• User logs in to mybank.com
• Clicks on a malicious link
• Link executes a HTTP request
• Request damages the user’s data
• HTTP request leverages user’s authenticated
status

8. De facto Defence Mechanisms
• Synchroniser Token
• Double Submit Cookie

9. Synchroniser Token Pattern
• Uses 2 tokens and compares both on the
server
• 1 token in session
• 1 token on the UI
• Dissimilar token pairs are rejected
• User must be validated

10. Double Submit Cookie
• Compares 2 tokens
• Both tokens held on the UI
• 1 token in a cookie
• 1 token in the HTTP AUTH Header
• Dissimilar token pairs are rejected
• User must be validated

11. Why roll your own?
• Existing patterns have shortcomings
• Didn’t like the idea of multiple tokens
• Full disclosure – I wanted to take the problem
apart to understand it more thoroughly
• So what’s wrong with existing defences?

12. Synchroniser Token Pattern
• Requires session state
• Promotes session affinity
• Session is volatile
• Session requires memory
• Not a good fit for the cloud

13. Why this didn’t suit us
• Large cloud-based infrastructure
• 25 – 50 million customers
• Needs to be evenly balanced
• Didn’t want security mechanism to direct
traffic

14. Double Submit Cookie
• Reliant on cookies
• Cookies are a hacker’s first port of call
• Susceptible to MITM attacks
• Cookies can be overwritten
• XSS vulnerabilities in sub-domains
circumnavigate CSRF defence

15. Double Submit Cookie
• mydomain.com
• sub.mydomain.com has an XSS fault
• Supercookies can be altered
• BANG.

16. Where does that leave us?
• Didn’t want session
• Cookies to exposed
• What to do next…

17. What is the Encrypted Token Pattern?
• An alternative to existing CSRF defences
• Leverages a single security token only
• Reduces the scope of attack

18. Encrypted Token Pattern
1 token only
No Session
No Cookies

19. Implementations
• .NET – A.R.M.O.R written in C#
• Major Java version in development
• Upcoming Google Go
• Accepted by Visual Studio Magazine
• Under scrutiny by MSDN

20. Don’t take my word for it
• Used by a major bank in Quebec
• Used by a major Irish bank (based here)
• Used by a major US education provider

21. How does it work?
• Single token encryption
• Stored anywhere on the UI
• Persisted through AJAX or form-submit
• Validated on the server
• Refreshed on each request

23. What kind of encryption?
• Rijndael 256bit (AES) by default
• SHA256 hashing by default
• ARMOR abstracts encryption and hashing
• Easily implement other standards

24. Summary
• ARMOR is an alternative to existing defences
• In circulation > 2 years
• Well established

25. Further Discussions
• Happy to talk about this afterwards
• Ongoing discussions on insidethecpu.com,
reddit, hackernews, stackoverflow
• https://ie.linkedin.com/in/daishisystems
• Questions?