Proven Strategies for Web Application Security by Justin C. Klein Keane

OWASP Montreal - February 25th - Proven Strategies for Web Application Security

MAIN PRESENTER: Justin C. Klein Keane

ABSTRACT: The rising dominance of the web as an application delivery platform has focused attacker attention squarely on the security of dynamic web applications. Application security is a complex, and shifting, field. Learn about tested and successful techniques to build safer applications, find flaws before they become vulnerabilities, and deploy applications that can detect, and resist attack.

BIO: Justin C. Klein Keane is a security engineer and chapter leaders of OWASP in Philadelphia. For over a decade Justin has worked as a trainer, coder, and exploit developer. Justin is currently writing a book for NoStarch Press on hacking, speaks regularly at conferences, holds a masters degree in information technology from the University of Pennsylvania and is credited with hundreds of application vulnerability discoveries.

WHEN: February 25th 2014

Transcript

1. Copyright Justin C. Klein Keane <justin@madirish.net> Proven Strategies for Web Application Security Justin C. Klein Keane University of Pennsylvania Web App Security
2. Copyright Justin C. Klein Keane <justin@madirish.net> About Me • Security Engineer for the University of Pennsylvania • Chapter leader of Philadelphia OWASP • Professional career as a web developer
3. Copyright Justin C. Klein Keane <justin@madirish.net> Proven Strategies • Sadly, I can't prove a negative • Discussion followed by concrete examples from Penn • Ideal solution may not meet all practical needs
4. Copyright Justin C. Klein Keane <justin@madirish.net> Why are Web Apps Targets? • Globally available • Always on (esp when you're not watching) • Client application available on most every platform • Victims of the success of firewalls • Browsers becoming nearly as valuable as OS targets
5. Copyright Justin C. Klein Keane <justin@madirish.net> Choose a Standard • Best advice for a secure environment • It doesn't matter what you choose • Base your choice on an evaluation – Best choice is the best match to your environment
6. Copyright Justin C. Klein Keane <justin@madirish.net> Standardize on a Framework • Choose one framework and invest in – Security – Support • Develop expertise • Enable all security features
7. Copyright Justin C. Klein Keane <justin@madirish.net> Framework Security • Each language has challenges • No language is “insecure” • Understand the business reasons for your platform • Recognize, and use, safe libraries • Keep your platform up to date • Do security testing prior to deployment
8. Copyright Justin C. Klein Keane <justin@madirish.net> Choosing a Framework that Fits • Technology match • Robust security team and lifecycle • Long term support • Availability of local talent • Published material • Lifespan • Etc.
9. Copyright Justin C. Klein Keane <justin@madirish.net> Benefit of Framework
10. Copyright Justin C. Klein Keane <justin@madirish.net> Our Choice • School of Arts & Sciences chose Drupal and Symfony • Our environment is largely PHP, MySQL and Linux based • Lots of local Drupal developers • Prior to choice we had no Drupal sites
11. Copyright Justin C. Klein Keane <justin@madirish.net> Harden the App Layer • Enable all the language security features • Disable dangerous features altogether • Customize your build to remove tools only useful to attackers
12. Copyright Justin C. Klein Keane <justin@madirish.net> Our Solutions • Customized PHP to limit unsafe functions • Required Drupal modules to: – Audit logins for brute force – Audit configuration for security issues – Enforce password strength – Allow for the use of CAPTCHA – Logging to syslog • Enforce safe database libraries (MySQLi, Doctrine, Drupal db) • Security testing is a published component of the app deployment process
13. Copyright Justin C. Klein Keane <justin@madirish.net> Harden the Full Stack • Every stack has multiple layers • Utilize the security of each layer to the fullest
14. Copyright Justin C. Klein Keane <justin@madirish.net> OS Hardening • Limit file system privileges • Isolate your web or application server • Install a host based intrusion detection system • Limit shell access and require secure connections
15. Copyright Justin C. Klein Keane <justin@madirish.net> Our Solution • Key based SSH for developers to access hosted environments • Centralized, active response enabled, OSSEC HIDS (ossec.net) • Web server has very limited write capabilities
16. Copyright Justin C. Klein Keane <justin@madirish.net> Isolate your Server • Application compromise often leads to application server compromise • Limit the privileges of the server process • If possible isolate applications from one another • Ensure uniform data sensitivity across each server install
17. Copyright Justin C. Klein Keane <justin@madirish.net> Our Solution • When possible one codebase runs all applications • Developers cannot change that code base • Application server privileges limited (php.ini customization) • Diverse applications get dedicated servers
18. Copyright Justin C. Klein Keane <justin@madirish.net> Database Security • Limit application privileges to least necessary • Isolate data in separate databases • If possible make use of: – stored procedures – Parameterized queries • Use safe interaction libraries (like an ORM) • Eliminate remote DB connections
19. Copyright Justin C. Klein Keane <justin@madirish.net> Our DB Practice • When developers start an app: – New app specific database provisioned – Two accounts • one for developers most privileges • one for the application with least privilege – App password obfuscated in code – Stored procedures for sensitive functions – DB is accessed over SSH
20. Copyright Justin C. Klein Keane <justin@madirish.net> People Standards • Train your developers • Establish secure coding baselines • Publish approved libraries and tools • Insist that applications meet the baseline – Then provide support! • Training helps, but try to make vulnerabilities deliberate
21. Copyright Justin C. Klein Keane <justin@madirish.net> Our Solution • Constant push to refine security of our platforms • Published coding standards • Trained developers perform code level reviews prior to deployment • All changes are vetted before deployment
22. Copyright Justin C. Klein Keane <justin@madirish.net> Automated Tools • You should run them! • You should realize they mostly suck! • Best testing tool: a person – Penultimate – a person with tools and source code
23. Copyright Justin C. Klein Keane <justin@madirish.net> Layer 8 Security • Personnel charged with security should be developers • One of these statements is dangerous: crsr.execute(“SELECT * FROM table where id = %s” % id) crsr.execute(“SELECT * FROM table where id = %s” , id)
24. Copyright Justin C. Klein Keane <justin@madirish.net> Tools We Use • W3af • OWASP ZAP • Firefox Tamper Data Plugin • Eclipse • Custom Python scripts
25. Copyright Justin C. Klein Keane <justin@madirish.net> Detect Compromises • Audit filesystem changes – Automated integrity checking • Scan uploads for malware • Build logging into your applications • Perform automated log analysis
26. Copyright Justin C. Klein Keane <justin@madirish.net> Detection We Use • OSSEC – File integrity and log monitoring – Custom decoders and rules – Alerts sent via e-mail to security staff • Clam AV
27. Copyright Justin C. Klein Keane <justin@madirish.net> Respond Quickly • Have backups • Using version control is an excellent way to be able to recover from a compromise
28. Copyright Justin C. Klein Keane <justin@madirish.net> Tools We Use • Regular backups (nightly) • CVS and Git for version control • Separate development, staging and production environments • Automated deployments
29. Copyright Justin C. Klein Keane <justin@madirish.net> Conclusion • Choose a tool and make it work • Understand security options and enable them • Secure each layer of the app stack • Use isolation and monitoring to your advantage • Enforce use of safe libraries • Make security testing a requirement for deployment • Have intrusion detection and incident response plans in place
30. Copyright Justin C. Klein Keane <justin@madirish.net> Thank You Questions?