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

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

09905cce02942fb076f958f4b69fd8f6?s=128

OWASP Montréal

February 25, 2014
Tweet

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?