Uncle Sam's Guide to Grails Security

  • Published on

  • View

  • Download


Speaker: Joe Rinehart Grails makes it easy to dive right in and build an application, but that's the tip of a very large iceberg. Joe Rinehart's spent years working in highly secured environments and been the subject of many top-to-bottom, OS-to-Web audits. Join him as he introduces publicly available security guidelines for Java/Grails applications made available by some of the strictest clients in the world, showing how Grails can often make life much easier. "STIGing." It's a phrase that makes even seasoned secured application developers wince. What's a STIG? It's a "Security Technical Implementation Guide" - a grammar fail only the U.S. Government could manage. It's usually a product-specific, hundred-plus page PDF or XML document describing applicable security controls. These are not thrilling reads. Their content, however, is fantastic: from obvious XSS issues to nuances of running Tomcat within an application security manager, they present a holistic approach to technical application security. Join Joe as he walks through the essential security topics for Grails (and Java) Web applications, showing how Grails can often lighten your load and the pitfalls of attempting to secure highly dynamic code.


1.UNCLE SAMS GUIDE TO GRAILS SECURITY JOE RINEHART BOOZ | ALLEN | HAMILTONPhoto: AJ Cann2. WHAT ARE WE TALKING ABOUT? Photo: milos milosevic 3. WHO AM I? 4. WHO AM I? 5. AND?Photo: eli duke 6. STIGS.Photo: lemonradPhoto: Automotiveart.nl 7. STIGS.Photo: lemonrad 8. IN A NUTSHELL A STIG is a list of security/assurance controls for a given technology. There are many available: operating system, database, and application development. Well concern ourselves with the Application Development STIG. 9. PROPER PLANNING AND PREPARATION PREVENTS PISS POOR PERFORMACE 10. MEA CULPA These are things Ive rarely done, or seen done, in the commercial space. Theyre not fun. Theyre good ideas. Left to my own, Id take a common sense, good-enough documentation approach. 11. SYSTEM SECURITY PLAN Who can get to what. What you think can go wrong. What to do about it. 12. CONFIGURATION GUIDE Hosting requirements Deployment instructions 13. CLASSIFICATION GUIDE How critical is data youre collecting? Is it PII? Are there legal ramifications if data is leaked? 14. 3RD PARTY USE What are you using that you didnt invent? Where did it come from? What support does it have? 15. KNOW THYSELF Whos responsible for management? Design? Testing? What are their strengths? What are their weaknesses? 16. WHEN THINGS GO WRONG What do you do when a vulnerability is identified? Exploited? When a natural disaster occurs? 17. SYSTEM DESIGN AN OUNCE OF PREVENTION 18. IM NOT TALKING RATIONALPlease dont confuse encouraging some degree of system design with a push for anti-agile bits like RUP 19. KNOWING WHAT YOU DONT KNOW YOU DONT KNOWDevelop a threat model Assumptions Interactions Entries Risk Mitigations 20. BROAD GUIDANCE How should an exception be handled, and what should end users see? What kinds of encryption should be used? Avoided? What should never be stored? Basically, document choices developers dont like to have to make. 21. SIGH. THIS COULD BE A LOT OF WORK. 22. DEVELOPMENT == GREAT TRAIL.Photo: lemonrad 23. SECURITY == RICHARD SIMMONSPhoto: lemonrad Photo: heraldpost 24. THIS 25. STUFF 26. IS 27. BORING 28. IT MAKES ME GRUMPY.Photo: Joint Base Lewis McChord 29. SECURITY, AGILE, AND YOU. ITS NOT THE END OF THE WORLD. 30. INEFFECTIVE SECURITY Most of the time Ive seen STIGing, its a tacked-on waterfall a sidecar. a box to check to get on with life. I dont deal well with getting my ticket punched. 31. A JOB WORTH DOING Whats worse than security work? Doing it poorly. 32. PROBLEMS? 1. Copied / pasted paperwork, designs, and plans 2. Documentation for documentations sake 3. Ineffective process 33. BE ORIGINAL Write from scratch. You need to think about these things. If nothing else, it makes auditors do their job. 34. SERVE YOURSELF Too often, people do these things just to get accredited. Instead, cover your Make it known that these things are important and should take place. Word processors are evil: use a wiki-style solution! 35. PART OF EVERYDAY LIFE Dont STIG and walk off. Its a task like any other: prioritize, backlog, and attack. Ingrain security into your normal workflow. 36. GRAILS, FINALLY. HOW WEVE STIGD IN RECORD TIME 37. TWO WEEKS. Largely thanks to Grails and its community, we took a very basic JEE application and reached a secured state in two weeks. 38. MANY BIRDS, ONE STONE. HUGE THANKS TO BURT BECKWITH 39. SPRING-SECURITY Half of you have probably used it. The other half will tell you why they havent. We have, and we like it, and heres why. 40. WHY SPRINGSECURITY? 1. Open source and well examined 2. Out-of-the-box good practices 3. Native x509 integration 4. LDAP, AD, and many other authentication providers are supported 5. Simple API! 41. SPRING-SECURITY: CONTROLS SATISFIED Role-based security Passwords must be stored in an encrypted format Passwords cannot be displayed in clear text Many PKI controls Session logout Token rotation Logon limitations 42. MANY BIRDS, MANY PEBBLES. A BRIEF TOUR OF SOLVING SOME CONTROLS WITH GRAILS 43. CSRF VULNERABILITIES 44. CODE COVERAGE Weve used the code-coverage plugin. Big thanks to Mike Hugo and Jeff Beck.> grails test-app -coverage 45. TRANSACTIONS Does data change? Does a controller perform two data access operations? Service time.> grails create-service com.acme.Book 46. DATABASE CREDENTIALS Please dont let anyone find this. Externalize! environments { production{ dataSource { username = "sa" password = "password" } } } 47. LAST TIME/DATE OF CHANGE package com.acme class Book { Date dateCreated Date lastUpdated } 48. LAST TIME/DATE OF CHANGE EXTRA CREDIT class DataAccessAuditingListener implements ApplicationListener { void onApplicationEvent( ApplicationEvent e ) { if ( e instanceof AbstractPersistenceEvent ) { // do stuff } } } 49. XSS 1. Filter posts to check referers! 2. grails.views.default.codec = html 50. SQL INJECTION Its hard to really screw this up with Grails/GORM, but if youre using straight SQL, please: 1. Use bound parameters instead of GStrings 2. Understand the ramifications of toString()ing a GString and then using it as a statement! 51. ACCOUNT LOCKOUT class UserLoginAuditingListener implements ApplicationListener { void onApplicationEvent( ApplicationEvent e ) { if ( e instanceof AbstractAuthenticationEvent ) { // do stuff } } } 52. VALIDATION This ones hard to enforce programatically, but we try to cover it by: 1. Using commands 2. Testing domain validation 53. CONCLUSIONS? 54. THE STIG IS YOUR FRIEND.Photo: lemonradPhoto: Automotiveart.nl