Lora Vaughn McIntoshSecurity EngineeringBlue Cross Blue Shield of AlabamaLora.McIntosh@bcbsal.org(205)220-2181

APPLICATION SECURITY IN THE REAL WORLDWHAT THE OWASP TOP 10 MEANS TO EVERYONE

About Me• BS Computer Science from Birmingham-Southern College• Formerly employed at Accenture, National Security Agency, Regions Bank • Certifications:• Certified Information Systems Security Professional (CISSP)• EnCase Certified Examiner (EnCE)

Agenda•What’s an OWASP?•Why should I care?• Security myths• Hacks in the news• OWASP Top 10 in 10 minutes or less• Legacy and third party applications• Defense in depth•Where do you start?

OWASP Who???• Open Web Application Security Project• 501c3 not-for-profit • Focused on improving the security of application software• Release Top 10 List periodically• 2010• 2007• 2004

APPLICATION SECURITY:

WHY SHOULD I CARE?

6

Progress—You can’t have it all• Business demands more

bells and whistles• Internal applications get

‘web-enabled’ and are exposed to Intranet or Internet• Increasing complexity of

software• Rush software out without

adequate testing• Poor security training and

awareness

7

Things Have Changed• Threats have evolved as the Internet and our world have evolved

• Any website you visit could infect your browser—even a Google search

• An infected browser can do anything you can do

• An infected browser can scan, infect, spread

Source: owasp.org

8

Regulations • If you’re lucky enough to

NOT need to meet• PCI• SOX• HIPAA• GLBA• Etc….

That’s nice, BUT what about• Your proprietary data?• Customer confidence?• Impact to operations?• Data integrity?

You still need to consider security. Period.

After all, you may just be one congressional session way from a new regulation.

9

So What???• Defacement• Phishing• Denial of Service• Data Loss• Bot Infection• Loss of <fill in the blank>• Legal action• ...

See the Web Hacking Incidents Database onhttp://www.webappsec.org/projects/whid/

How about I throw some money at the problem? Buy some tools!

10

OK, YOU’VE GOT ME THERE…

11

Well…. Tools Can’t Fix Everything• MITRE found that all application

security tool vendors’ claims put together cover only 45% of the known vulnerability types (over 600 in CWE)

• They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true)

Source: owasp.org

12

Great…

BUT I HAVE OTHER CONTROLS!

SECURITY MYTHS

The Trouble with Firewalls

Joe User says: “But we have a firewall”!

75% of Internet Vulnerabilities are at the application layer, not the network layer

- Gartner

Firewalls have to allow some things through, and attackers have adapted.

Source: Jeremiah Grossman, BlackHat 2001

The Trouble with Firewalls Illustrated

Source: owasp.org

But… But… We use SSL!• SSL only secures data in transit• Does not solve vulnerabilities on:• Applications• Web server• Browser• If you exploit the application, any data at rest encryption is

useless too.

16Source: Jeremiah Grossman, BlackHat 2001

SSL Illustrated

Source: owasp.org

17

Myth – my perimeter will save me

Firewall

Hardened OSWeb ServerApp Server

Firewall

Dat

abas

esLe

gacy

Sys

tem

sW

eb S

ervi

ces

Dire

ctor

ies

Hum

an R

esrc

sB

illin

gCustom Developed Application Code

APPLICATIONATTACK

You can’t use network layer protection (firewall, SSL, IDS, hardening) to stop or detect application layer attacks

Net

wor

k La

yer

App

licat

ion

Laye

r

Your security “perimeter” has huge holes at the application layer

Source: owasp.org

Real Life Application (?) Hacks• CitiGroup• May 2011 • Approximately 210,000 credit card holders• “Basically after you logged into your account as a Citi customer, the URL

contained a code identifying your account. All you had to do was change around the numbers and boom, you were in someone else's account”

• StuxNet• Targeted Siemens SCADA systems of Iranian nuclear facilities• Stolen encryption keys used to sign infected drivers• Zappos • January 2012• 24+ Million customer accounts• Name, e-mail, billing and shipping addresses, phone numbers, last 4 of credit

card, encrypted passwords• TJ Maxx• 2007• 45.7 million credit/debit cards

OWASP TOP 10 IN 10 MINUTES OR LESS

OWASP Top 10 Risk Rating Methodology

ThreatAgent

AttackVector

Weakness Prevalence

Weakness Detectability Technical Impact Business

Impact

?Easy Widespread Easy Severe

?Average Common Average ModerateDifficult Uncommon Difficult Minor

1 2 2 1

1.66 * 1

1.66 weighted risk ratingInjection Example

123

Source: owasp.org

OWASP Top Ten (2010 Edition)A1: Injection

A2: Cross-Site Scripting

(XSS)

A3: Broken Authentication and Session Management

A4: Insecure Direct Object References

A5: Cross Site Request Forgery (CSRF)

A6: Security Misconfigurat

ion

A7: Failure to Restrict URL

Access

A8: Insecure Cryptographi

c Storage

A9: Insufficient Transport

Layer Protection

A10: Unvalidated

Redirects and Forwards

http://www.owasp.org/index.php/Top_10

Source: owasp.org

A1 – Injection• Tricking an application into including unintended commands in

the data sent to an interpreter

Injection means…

• Take strings and interpret them as commands• SQL, OS Shell, LDAP, XPath, Hibernate, etc…

Interpreters…

• Many applications still susceptible (really don’t know why)• Even though it’s usually very simple to avoid

SQL injection is still quite common

• Usually severe. Entire database can usually be read or modified• May also allow full database schema, or account access, or even

OS level access

Typical Impact

Source: owasp.org

23

SQL Injection• A common issue in most applications• Can only occur when the application is building dynamic SQL that contains a string that is tainted with user supplied data

http://xkcd.com/327/

24

SQL Injection in the Wild

A2 – Cross-Site Scripting (XSS)

• Raw data from attacker is sent to an innocent user’s browser

Occurs any time…

• Stored in database• Reflected from web input (form field, hidden field, URL, etc…)• Sent directly into rich JavaScript client

Raw data…

• Try this in your browser – javascript:alert(document.cookie)

Virtually every web application has this problem

• Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or malware site

• Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on vulnerable site and force user to other sites

Typical Impact

Source: owasp.org

26

XSS In The Real World

A4 – Insecure Direct Object References

• This is part of enforcing proper “Authorization”, along with A8 – Failure to Restrict URL Access

How do you protect access to your data?

• Only listing the ‘authorized’ objects for the current user, or

• Hiding the object references in hidden fields• … and then not enforcing these restrictions on the

server side• This is called presentation layer access control, and

doesn’t work• Attacker simply tampers with parameter value

A common mistake …

• Users are able to access unauthorized files or data

Typical Impact

Source: owasp.org

Insecure Direct Object References Illustrated

• Attacker notices his acct parameter is 6065

?acct=6065

• He modifies it to a nearby number

?acct=6066

• Attacker views the victim’s account information

• Look familiar???

https://www.onlinebank.com/user?acct=6065

Source: owasp.org

A5 – Cross Site Request Forgery (CSRF)

• An attack where the victim’s browser is tricked into issuing a command to a vulnerable web application

• Vulnerability is caused by browsers automatically including user authentication data (session ID, IP address, Windows domain credentials, …) with each request

Cross Site Request Forgery

• What if a hacker could steer your mouse and get you to click on links in your online banking application?

• What could they make you do?

Imagine…

• Initiate transactions (transfer funds, logout user, close account)• Access sensitive data• Change account details

Typical Impact

Source: owasp.org

A6 – Security Misconfiguration• Everywhere from the OS up through the App Server• Don’t forget all the libraries you are using!!

Web applications rely on a secure foundation

• Think of all the places your source code goes• Security should not require secret source code

Is your source code a secret?

• All credentials should change in production

CM must extend to all parts of the application

• Install backdoor through missing OS or server patch• XSS flaw exploits due to missing application framework patches• Unauthorized access to default accounts, application functionality

or data, or unused but accessible functionality due to poor server configuration

Typical Impact

Source: owasp.org

A7 – Insecure Cryptographic Storage

• Failure to identify all sensitive data• Failure to identify all the places that this sensitive data

gets stored• Databases, files, directories, log files, backups, etc.

• Failure to properly protect this data in every location

Storing sensitive data insecurely

• Attackers access or modify confidential or private information• e.g, credit cards, health care records, financial data (yours or

your customers)• Attackers extract secrets to use in additional attacks• Company embarrassment, customer dissatisfaction, and loss

of trust• Expense of cleaning up the incident, such as forensics,

sending apology letters, reissuing thousands of credit cards, providing identity theft insurance

• Business gets sued and/or fined

Typical Impact

Source: owasp.org

A8 – Failure to Restrict URL Access

• This is part of enforcing proper “authorization”, along with A4 – Insecure Direct Object References

How do you protect access to URLs (pages)?

• Displaying only authorized links and menu choices• This is called presentation layer access control, and

doesn’t work• Attacker simply forges direct access to ‘unauthorized’

pages

A common mistake …

• Attackers invoke functions and services they’re not authorized for

• Access other user’s accounts and data• Perform privileged actions

Typical Impact

Source: owasp.org

A9 – Insufficient Transport Layer Protection

• Failure to identify all sensitive data• Failure to identify all the places that this sensitive data is

sent• On the web, to backend databases, to business partners, internal

communications• Failure to properly protect this data in every location

Transmitting sensitive data insecurely

• Attackers access or modify confidential or private information• e.g, credit cards, health care records, financial data (yours or your

customers)• Attackers extract secrets to use in additional attacks• Company embarrassment, customer dissatisfaction, and

loss of trust• Expense of cleaning up the incident• Business gets sued and/or fined

Typical Impact

Source: owasp.org

A10 – Unvalidated Redirects and Forwards

• And frequently include user supplied parameters in the destination URL

• If they aren’t validated, attacker can send victim to a site of their choice

Web application redirects are very common

• They internally send the request to a new page in the same application

• Sometimes parameters define the target page• If not validated, attacker may be able to use unvalidated

forward to bypass authentication or authorization checks

Forwards (aka Transfer in .NET) are common too

• Redirect victim to phishing or malware site• Attacker’s request is forwarded past security checks, allowing

unauthorized function or data access

Typical Impact

Source: owasp.org

35

What about…

LEGACY APPLICATIONS

36

Legacy Application ProblemsOld Frameworks + Old Code + Old Vulnerabilities

= Low hanging fruit

We didn’t even know about some of these attacks 10 years ago

How old are your apps?

37

Don’t forget 3rd Party Apps• Think • Frameworks• HR software• Data analytics tools• Cloud

38

So…

WHERE DO YOU START???

39

Defense in Depth• Multiple layers of protection reduces the likelihood that an attacker will be successful• Firewall, IDS, etc? Useful technologies, but not as your sole defense• Penetration testing• Code analysis• Security training for your developers

40

Write secure code in the first place• Build procedures into the process to mitigate risk (SDLC)• Create standards that will assist in answering FAQs• Libraries and best practices for coding• Follow the best practices in OWASP’s Guide to Building Secure Web

Applications• http://www.owasp.org/index.php/Guide• Use OWASP’s Application Security Verification Standard as a guide to

what an application needs to be secure• http://www.owasp.org/index.php/ASVS• Use standard security components that are a fit for your organization• Use OWASP’s ESAPI as a basis for your standard components• http://www.owasp.org/index.php/ESAPI

Don’t reinvent the wheel. If you try to write your own cleansing functions, you WILL miss something. Unless you’re a coding God, but even then…

41

But that ship already sailed, so…Know your data• What data do you care about?• Regulations help – PCI, GLBA, HIPAA• Proprietary data—What’s your “secret sauce”?• What types of data do you have?• Where is that data?• Is it encrypted? Should it be?• How about backups?• Are you sure it’s not sitting on Susan’s workstation because “it’s

easier if I don’t have to log on to the server”?• Who has access to that data?• Should they have access to it?• What happens when they change roles or jobs?

42

Baby Steps - Policy• State that you intend to write secure code• Policy for remediating legacy code• Get security into the overall procurement and development

cycle

43

Baby Steps - Standards• Incorporate secure development standards (Start with

OWASP?)• Require minimums• In the lifecycle, get stop points in place – QA cycle?

44

Baby Steps - Procedures• Pre-deployment checklists--a low cost approach to building

application security in• Code reviews• Formal application security testing• Remediation plans

Tools and Services• Review Your Applications• In house manual code review• Not a bad idea, but how many of your developers know the ins and outs

of every single application vulnerability and exploit?• Application assisted static code analysis• Look into products like HP Fortify, Rational, Veracode, etc.• Most of these offer cloud and local solutions• Large amounts of tuning required to make sure your environment is reflected

• Have an expert team or service review your applications• Review your applications yourselves following OWASP Guidelines• OWASP Code Review Guide:

http://www.owasp.org/index.php/Code_Review_Guide • OWASP Testing Guide:

http://www.owasp.org/index.php/Testing_Guide

46

Options: Web Application Firewalls• Can you spend the money?• Do you have the staff to manage one?• OWASP has great resources on when and where to use them

47

Code Analysis• Dynamic, static, or both?• Each type can miss things• A combination is probably best, but can be costly• On premise, hosted, or hybrid?• Do you have the staff to implement?• Plans to remediate findings?

48

Tools… again• Vendors• Accunetix • Cenzic• HP Fortify• IBM• Veracode• Open Source (free or lower

cost)• WebScarab• Nikto• Paros

• Vendors• Coverity • IBM • HP Fortify• Veracode• Open Source (free or lower

cost)• FindBugs (Java only)• Other options, but mostly

targeting specific vulnerabilities like

Dynamic Analysis Static Analysis

49

You have tools – now what???• Back to the people side• Sell it (much easier if you have regulations behind you)• Training• User• Administrator• Team to administer• Audit • Make sure developers are following procedures and using the tool• Ensure new vulnerabilities aren’t added – think “No new critical flaws”

• Reporting• Can save you in an audit• Good place for metrics• . . . • Profit!!!

Source: owasp.org

50

QUESTIONS?