Manish Dusad (dusad@avaya.com)Sumita Uday (suday@avaya.com)

All you wanted to know about OWASP WEB TOP 10 !

Covering the first FIVE vulnerabilities

OWASP Web Top 5• Injection

• Broken Authentication/Session Management

• Cross-Site scripting – XSS

• Insecure Direct Object Reference

• Security Misconfiguration

Injection

OWASP Definition:Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.

Injection

Injection

What happens when the Login button is clicked?User name & Password is sent to the server

Server does a lookup of the username/password against some database

Server checks if the Password matches against the result of the query

QueryCan be SQL like statements (mostly are)Or, could be against an external system

LDAPSSO

Fire

wal

l

Hardened OS

Web Server

App Server

Fire

wal

l

Data

base

sLe

gacy

Sys

tem

sW

eb S

ervi

ces

Dire

ctor

ies

Hum

an R

esrc

sBi

lling

Custom Code

APPLICATIONATTACK

Net

wor

k La

yer

Appl

icatio

n La

yer

Acco

unts

Fina

nce

Adm

inist

ratio

nTr

ansa

ction

sCo

mm

unic

ation

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Func

tions

HTTP request

SQL

queryDB Table

HTTP response

"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"

1. Application presents a form to the attacker2. Attacker sends an attack in the form data3. Application forwards attack to the database in a SQL query

Account Summary

Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-0293

4. Database runs query containing attack and sends encrypted results back to application

5. Application decrypts data as normal and sends results to the user

Account:

SKU:

Account:

SKU:

SQL Injection

• Untrusted Data is sent to an interpreter as part of a command or query.

• Other Database specific constructs can also be passed to determine the DBMS used.

• Very prevalent, especially in Legacy Code.• Easier to detect using Code Inspection, than

testing.• Can result in Data Stealing/Loss/Corruption

Recommendations• Use an interface that supports ‘bind variables’ – they allow the

interpreter to distinguish between ‘code’ and ‘data’– Prepared StatementsString query = "SELECT * FROM accounts WHERE account = ?";PreparedStatement pstmt = connection.prepareStatement(query , … );pstmt.setString( 1, request.getParameter("acct"));ResultSet results = pstmt.executeQuery( );

– Stored Procedures

Recommendations• Encode user input before passing to the interpreter• Perform white list/black list input validation on all user

supplied input– create, alter, drop, rename, select, insert, update, delete, grant, revoke, @@version, exec, union, waitfor, order by, case when, utl_, winhttp

• Minimize Database privileges to reduce impact of a flaw• Use a vetted library or framework

Broken Authentication/Session Management

OWASP Definition:Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.

Custom Code

Acco

unts

Fina

nce

Adm

inist

ratio

nTr

ansa

ction

sCo

mm

unica

tion

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Fun

ction

s1 User sends credentials

2Site 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...

4Hacker checks referrer logs on www.hacker.com

and finds user’s JSESSIONID

5 Hacker uses JSESSIONID and takes over victim’s account

• HTTP is a stateless protocol– Credentials are have to go with every request– Should use SSL for everything requiring authentication

• Session Management Flaws– Session ID is used to track state, as HTTP doesn’t – just as good as

credentials to an attacker– Session ID is typically exposed on the network, in browser logs, etc.

• Typical Impact– User account compromised– User session Hijacked

Recommendations• Authentication should be simple, centralized and standardized• Use the standard session ID provided by the container

– Change the name to avoid ‘obviousness’• Make sure that SSL protects both, credentials as well as session ID• Verify that logoff actually destroys the session

Session session = request.getSession();session.invalidate();

Implement Session Time-outs Change Session ID after successful login Set cookies as HTTP-Only and secure (on SSL)

AIC_SESSIONID=728CA9E50D86BA91384191F3793B064C; Path=/website; HttpOnly

• Predictable Login Credential• Credentials are not protected when stored

using hashing or encryption• Password Strength• Password Expiry

Broken Account and Session Management

Broken Account and Session Management: Protection

Password Storage - never store passwords in plain text. Passwords should always be stored in either hashed (preferred) or encrypted form.

Protecting Credentials in Transit - to prevent "man-in-the-middle" attacks the entire authenticated session / transaction should be encrypted SSLv3 or TLSv1

Man-in-the-middle attacks - are still possible with SSL if users disable or ignore warnings about invalid SSL certificates.

Replay attacks - Transformations such as hashing on the client side provide little protection as the hashed version can simply be intercepted and retransmitted so that the actual plain text password is not needed.

15

Cross-Site Scripting (XSS)

• A quick View

Cross-Site Scripting (XSS)

• OWASP definition

Types of XSS• Server XSS

– Server XSS occurs when untrusted user supplied data is included in an HTML response generated by the server. – The source of this data could be from the request, or from a stored location. – The entire vulnerability is in server- side code, and the browser is simply rendering the response and executing any valid

script embedded in it.

• Client XSS– Client XSS occurs when untrusted user supplied data is used to update the DOM with an unsafe JavaScript call. – The ultimate source of the data could have been from a request, or from a stored location on the client or the server.

• Stored XSS Attacks– Stored attacks are those where the injected script is permanently storedon the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

• Reflected XSS Attacks– Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request

Reflected Vs Stored

Recommendations

• All input must be validated against a positive or “whitelist” of acceptable value ranges.

• You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into.

• consider auto-sanitization libraries like OWASP’s AntiSamy

• Consider Content Security Policy (CSP) to defend against XSS across your entire site.

Insecure Direct Object Reference

• OWASP definition

Insecure direct object references

After clicking the button, the customer details are returned and written to the page

Hitting the button exposes the following information in Firebug:

If we jump over to the response tab, we start to see some really interesting info:

{"d":{"__type":"Customer:#Web","Address":"3 NIBM Road","CustomerID":3,"Email":“suday@avaya.com","FirstName":“Sumita","Postcode":“411048","State":“MH",“City":“Pune"}}

Re-issue the same request

but with a different

customer ID

What made this possible?

• The fact that the customer’s ID was an integer; auto-incrementing it is both logical and straight forward.

• Obviously the problem here was unauthorized access and the solution is to add some controls around who can access the service– Establish an identity, validate access rights then run the

service otherwise bail them out.– validating the user’s right access the customer

data before anything is returned by the service

Recommendations• Using an indirect reference map

– An indirect reference map is simply a substitution of the internal reference with an alternate ID which can be safely exposed externally.

• Check Access– Each use of a direct object reference from an untrusted source must include an access

control check to ensure the user is authorized for the requested object.

Security Misconfiguration• OWASP definition

RecommendationsPositive step forward for this vulnerability :

– Develop a repeatable process to reduce the surface of vulnerability– Disable default accounts and change passwords– Keep your frameworks up to date– Develop a strong application architecture that effectively isolates components

and encrypts data which is especially important with sensitive data.– Disable any unnecessary files or features– Ensure security settings in development frameworks and libraries are set to

secure values– Run tools (i.e. automated scanners) and perform regular audits to identify

holes in the security configuration– Customize your error messages– Get those traces under control– Disable debugging– Encrypt sensitive configuration data– Apply the principle of least privilege to your database/others user accounts