Application Security: What Does it Take to Build and Test a “Trusted” App?

1. Application Security: What Does it Take to Build and Test a “Trusted” App? John Dickson, CISSP Denim Group

2. Overview • What is Application Security? • Examples of Potential Vulnerabilities • Potential Strategies to Build Secure Apps • Questions and Answers

3. Denim Group Background • Enterprise application development company with security expertise • Custom software development • Application-level integration • Application security assessments and secure application development

4. What is Application Security • Security associated with custom application code • Focus is on web application security • Versus non-Internet facing applications • Complements existing infrastructure security assets such as firewalls, IDS, and secured operating systems

5. Nature of HTTP and the Web • Connectionless protocol – no state • Anonymity of attacks • Assumption: web servers expect request to come from browser, therefore implicitly trust input

6. Why Application Security • 70% of applications reviewed by security firm had significant security design flaws • @Stake Security Briefing • Interaction between server, 3rd party code, and custom business logic creates vulnerabilities • Patching or rebuilding app expensive • Perception exists that locking down OS and web server = web security

7. Why Application Security • Web-facing, business critical applications • HTTP & SLL open to the world • Much investment focused on infrastructure • Well understood threats, mature products • Firewalls, authentication, intrusion detection • Security many times an overlooked facet of web development projects

8. Examples of Potential Vulnerabilities

9. Parameter Tampering • Price information is stored in hidden HTML field with assigned $ value • Assumption: hidden field won’t be edited • Attacker edits $ value of product in HTML • Attacker submits altered web page with new “price” • Still widespread in many web stores

10. Price Changes via Hidden HTML tags

11. Price Changes via Hidden HTML tags

12. Cookie Poisoning • Attacker impersonates another user • Identifies cookie values that ID’s the customer to the site • Attacker notices patterns in cookie values • Edits pattern to mimic another user

13. Cookie Poisoning

14. Cookie Poisoning

15. Cookie Poisoning

16. Cookie Poisoning

17. Unvalidated Input Attack • Exploitation of implied trust relations • Instead of: • john@doe.com • Attacker inputs: • ////////////////////////////////////////////////// • Exploits lack of boundary checkers on back-end application

18. Unvalidated Input Attack

19. Unvalidated Input Attack

20. Unvalidated Input Attack

21. Unvalidated Input Attack

22. Open Web Application Security Project Top Ten Most Critical Web Application Security Vulnerabilities • Unvalidated Input • Broken Access Control • Broken Authentication and Access Control • Cross-Site Scripting Flaws • Buffer Overflows • Injection Flaws • Improper Error Handling • Insecure Storage • Denial of Service • Insecure Configuration Management Source: www.owasp.org

23. Client–side authentication • Web apps many times use client-side code to present and manage data • Storage of usernames or ID numbers in cookie make them ripe for forgery • Sites rely on cookie expiration to terminate sessions • You can modify cookies to extend time • Bottom line: Never trust anything from an http request

24. Potential Strategies to Build Secure Apps

25. Key Issue: Build vs. Measure Cultures • Application Development groups are building technical capabilities based upon evolving business requirements • Corporate IS Security dept. in charge of ongoing security operations

26. Additional Challenges • Most organizations do not have sufficiently skilled resources to cope with application security assessments • Development teams typically under deadlines I love deadlines. I especially love the whooshing sound they make as they fly by. --Douglas Adams, Author, Hitchhiker's Guide to the Galaxy.

27. Emerging Best Practices • Security must become a key aspect of the development process • Security requirements reflected in design plan • Ensure the security is part of the iterative development process • Changes to web sites are ongoing and are not static • QA Group should not be last line of defense

28. Code Evaluation Paths • Code review – auditing source code • Expensive, time consuming, and takes expertise • Application assessments – reviews functionality and interactions of compiled applications in real-life environments • Potentially superficial and only capture a % of actual vulnerabilities in custom code

29. Application Security Reviews • Internal or 3rd party process to assess internally developed applications • Assessment reviews major web app vulnerabilities • Use best-of-breed tools and custom scripts • Integrated with client development schedule • Reviews designed to coincide with key development milestones of client project

30. Application Security Reviews • Commercial security scanners are becoming more widespread • Automated tools are great first-round way to assess potential vulnerabilities • However, in-depth assessments use custom scripts and code reviews (sometimes) • Analogy of network scanners • Consider Augmenting security team with internal or external .Net and Java security experts

31. Assessment Benefits • 3rd-party assessment of applications by noted experts; Increase confidence & reliability in application • Compliance with government regulations • Sarbanes Oxley, GLB, HIPAA • Satisfies potential SEC audit objectives • Knowledge transfer to clients on development techniques for secure applications

32. Wrap up • Application Security is emerging as a critical aspect of enterprise security • Emerging best practices include iterative assessments and defense in depth • Cultural, organizational, and technical challenges all may hinder an effective strategy

33. Wrap Up • Questions and Answers