Web Application Security

|| The White & Black of Security ||

Overview

Understanding the Web

Different Web Technologies

Attackers view on the Web

Different kinds of attacks on Web Application

Countermeasures

Understanding the Web

Internet
WWW
Web application
Website
Webpage
Web browser

In the old days...

Black hats exploited

Holes in the Underlying OS

Bugs in the web server

Weaknesses in the TCP/IP Protocol

...and we built defences

We strengthened the perimeter

Firewalls

Intrusion Detection Systems

Virtual Private Networks

We fixed the OS and the Web Servers

(well,almost)

The playing ground shifted

Attackers began looking for holes in the web

applications

New exploits were discovered

And, this fuelled greater black hat activity

Advantages !! Attackers

Lack of awareness Ignorance in Security

More focus on functionality

Time-of-Market

Complexity is Growing

Increasing Business Demand

Moreinclinationongettingthejobdone

How do we respond ?

Understand how attackers work

Their modus operandi

Their exploit techniques

Understand the vulnerabilities

The root cause of the problem

Understand how to detect

Tools

Techniques

Myths - Developers

The users will behave themselves

The users will only send required inputs

The users cannot manipulate drop down lists

The user cannot manipulate hidden fields

Myths - Developers

The Application has all enforcements

Javascripts will take care of validation

Username and password is encrypted on login page

We are on Secure Channel

Our data is transmitted over SSL

Fact...

Validation is not enough

It needs to be secure

SSL only guarantees communication security

It even guaranteed that our attackers are delivered

securely

Administrator - Myths

Technology takes care of security

My Firewall thwarts all attacks

My IDS/IPS can detect any attacks

There are very few transactions happening on

this application

Penetration Testing Methodology

Understanding the application

Creating a threat profile

Creating the test plan

Executing the test cases

Reporting

Penetration Testing Methodology

Understanding the application

Study the business purpose
Study the application features

Study the traffic between client and server

Creating a threat profile

Creating the test plan

Executing the test cases

Reporting

Penetration Testing Methodology

Understanding the application

Creating a threat profile

Identify all possible threats to the application

Prepare a threat profile or business risk document

Creating the test plan

Executing the test cases

Reporting

Penetration Testing Methodology

Understanding the application

Creating a threat profile

Creating the test plan

Map the threats and the technical risks
List down all possible attacks for a particular threat
Prepare test plan on how to attack and what to attack.

Executing the test cases

Reporting

Penetration Testing Methodology

Understanding the application

Creating a threat profile

Creating the test plan

Executing the test cases

Manual / Tool based execution

Interpret the results

Observe all expected/unexpected results
Execute again

Reporting

Penetration Testing Methodology

Understanding the application

Creating a threat profile

Creating the test plan

Executing the test cases

Reporting
Executive Summary
Findings Summary

Baseline findings with standards

Detailed description of findings with solutions
Appendix

Information Gathering

Through IP/domain

Through Web Server & its error messages

Through Database & its error/warning messages

Programming Language warnings/error messages etc

Information Gathering

Through IP/domain

dig

nslookup

whois

Through Web Server & its error messages

Through Database & its error/warning messages

Programming Language warnings/error messages etc

Information Gathering

Through IP/domain

Through Web Server & its error messages

Viewing Directory Indexing and Signatures

Accessing files which are not available etc

Through Database & its error/warning messages

Programming Language warnings/error messages etc

Information Gathering

Through IP/domain

Through Web Server & its error messages

Through Database & its error/warning messages

Inserting invalid data in the input boxes, check the

messages displayed
We'll discuss more in coming slides

Programming Language warnings/error messages etc

Information Gathering

Through IP/domain

Through Web Server & its error messages

Through Database & its error/warning messages

Programming Language warnings/error messages etc

Default messages displayed by programming

languages could reveal much information.

Application Database Communication

Application connects to database using

username and password

Queries the DB for specific information

DB replies with matching row(s)

Query

Web Server

Recordset

Database
Server

The familiar HTTP

HTTP is anonymous and stateless

No persistent connection between user and
server

Each request is discrete

For a new request, the server has no way of

knowing if its related to the previous request.

HTTP Requests 2 main types

GET , when you click on a link

GET /AccountSummary?account=34325543&type=credit_Card HTTP/1.0

Host : www.accountsample.com

POST , when you submit a form

POST/Login/Login.action HTTP/1.0
username=test&pwd=test123&app=sample
Host : www.sample.com

And we can see those requests

Web Proxy Editors

Tool to intercept traffic between browser and server

We can modify the data before sending to the

server

<Lets see a small Demo>

Web Proxy Editor

Intercept the traffic between browser and the

web server

Web Browser

Proxy

Server

Web Server

HTTP Request & Response Formats

Request

GET http://www.infosecawareness.in HTTP/1.0 (request-line)

Headers (0 or more)

body

Response

HTTP/1.0 404 Not Found (Status-line)

Headers (0 or more)
body

Cookies

Cookies

Piece of info stored on the client by the server

Persistent -

Text file written to the client's harddisk

Valid for as long as the expiry date

Expiry set by the server

Non-persistent

Stored in the browser's memory RAM

Lost when browser is closed

Cookies details

Set using two main methods

HTTP headers and javascript

Enable a server and browser to pass

information among themselves
Cannot be shared (read or written) across DNS
domains

Cookie Manipulation
Real world example
Cookie: Location=India; ADMIN=N; time=10:30;
SessionID=BasedRteR234553636336

The attacker can simply modify cookie to:

Cookie: Location=India; ADMIN=Y; time=10:30;
SessionID=BsedRteRt12345535353453

Session Management

Process of keeping track of user's activity

Happens across period of interaction between the client &
server

Basic aim is to avoid repeated authentication (userid/pwd)

for every request.
Cookies or Session Ids are like passports or gate passes

Needtobeshowneachtimetheyareaskedfor else
you'llbethrownout.

Session Management Best Practices

Strongly bind the token to

specific user data.
Use SSL or IPSec when
possible

Use a strong random-number

generator for session tokens
Never accept new tokens
submitted by a client
Never include sensitive
information in the token
Use secure cookies

Set short cookie timeouts as

appropriate for your application

Use relative and absolute

timeouts

Delete session token both from

client and server after logout
Allow users to manually
terminate a session
Always issue a new token with
each login
Use cookie based tokens and
page tokens whenever possible
Use non-persistent cookies
wherever possible

Terminating Sessions

Invalidate session ID both from client and server side

Set the session ID to null on client side either using

Set-Cookie or using Javascript

Explicitly delete all user session objects on server

side

Direct URL access a.k.a Forceful Browsing

Forceful browsing Its is an attempt to access

a Resource that was not intended to be.
Causes

This happens when there is inadequate authorization checks

in the application
There may be strong authentication but what about
authorization?
Its like having a huge Iron Gate with big locks but with
broken wall.

Solutions

Authentication and authorization must take

place at every page.
Don't assume that authorized users, once
logged in, are going to behave as expected !

All of you know SQL.....

SQL Structured Query Language

Allows us to access and manipulate a database

SQL can :

Execute queries against a database

Retrieve data from database
Insert new records in a database
delete records form database
Update records in a database
Create new db, tables in db, stored procedures, views
Set permissions on tables, procedures and views

Points to know and understand

SQL Data Manipulation Language

SQL Data Definitional language

Select, update, insert, delete

Create , alter, drop

Aggregate functions

Sum(), count()...etc

Group By

Metadata

Stores in DB just as regular data is

What is SQL Injection ?

Trick to inject Structured Query Language

(SQL) query/command as an input via web
browser
Any parameter that the web application passes
through to a database
An attacker can go to extent of dropping tables
from database.
Lets See a Demo

How does SQL Injection Work ?

Common SQL Query
Select * from users where login='star' and password='kitkat';
In code:

varsql=Select*fromuserswherelogin='$username'and
password='$pwd';
when injected something its replaced like this...
Select * from users where login='' OR 1=1 ;-where -- is comment in most sql like Oracle, PostgreSQL, Mysql, HSQl,
/* comment*/ - for some, ({}) - Informix, DB2
OR 1=1 makes the condition true what ever is the username
Demo

SQL Injection - Contd..

Thus, the Magic Quotes, 'OR' and '=' are mostly used to
test the SQL injection.
When an application is vulnerable for SQL injection, Blind
SQL Injection can also be used. Blind SQL injection can be
done using logical stmts injected into the SQL statement
like OR 1=1
Usually usage of GROUP, HAVING in the query
statements throws error messages with clear cut field
types which helps SQLInjection

Remember

All these attacks are successful only when the

application or end user is given access to the
administrator of the database.

Countermeasures
Restrict users through web applications
grant all on *.* to root@localhost identified by '';
grant <INSERT,DELETE,SELECT> on <test>.* to
user@localhost identified by 'password';

HTML Injection

HTML Injection happens due to the functionality of the

client browser.

The browsers are coded to identify some special

characters and act accordgingly when request received.

Scripting tags that are most often used to embed malicious

content include <SCRIPT>, <OBJECT>, <APPLET> and
<EMBED>.

Cross Site Scripting ( XSS)

A cross-site scripting vulnerability is caused by the failure of
an web based application to validate user supplied input
before returning it to the client system.
Insert html code that is parsed by browser.
e.g. javascript, fake login form
Javascript can capture form data, key strokes and send it to
a remote IP address
The most popular CSS/XSS attack (and devastating) is the
harvesting of authentication cookies and session
management tokens.

Demo

Types of XSS
Reflective (non-persistent)
Injected code is reflected off the web server
Delivered to the victims via another route (email
or another web server)

Error messages, search engines etc

Stored (persistent)
Stored in database/filesystem
Delivered to the victims from the same web
server

CMS, Blogs/Forums etc

Reflective XSS
Any page that takes user input and displays it back as is:
Ex: Search results, validate user details.

Steps in Reflective XSS

The web site gathers user input
User input is displayed back to user
Attackers crafts URL with a script in it and sends to
victim
Victims click on the link
Script in the URL is send to server as user input
Userinputdisplayed;scriptreflectedbacktoclient
Script runs on client

Cross Site Scripting in Internet Banking

Attacker.com

Bank.com
1

Malicious link on webpage

or email with malicious link

Reflected Code
<SCRIPT> Send cookie to attacker</SCRIPT>

4
http://bank.com/login/
Malicouse Code
http://bank.com/account.jsp?<SCRIPT>Send cookie to attacker.com</SCIPRT>

User
Internet
Banking
Cookie

Executed

Stored XSS
The site takes user input
Attacker gives input with malicious code
Stored it in databae without validating it
Another user tries to view the input
The appliction shows the input with the script
The script executes on the victim's browser

Javascript URLs
Javascripturlshavetheformatjavascript:code
An example Javascript url
javascript:alert(HelloWorld)

Type the above in browser and check if alert pops up

Works also with <A> HTML tag
Is <script> tag necessary to execute Javascript ??
<DEMO>

How to detect XSS

Insert all possible combinations of malicious code on all
data fields on all application forms
Malicious scripts - http://hackers.org/xss.html

Remember SSL doesn't help in defending XSS

Few Observations
We din't click on anything to get the script executed
There was no <script> tag
What other events are there?
mousedown, mouseup
click
dblclick
mouseover, mouseout, mousedown
mouseenter, mouseleave

Defending XSS
Don't allow HTML in posts
Filter out dangerous characteds
',,?,&,>,<,;,etc

Replace
<

&lt

>

&gt

&#40;

&#41;

&#35;

&

&#38;

CAPTCHA
Completely Automatic Public Turing Tests to Tell
Computers and Humans Apart

Aim to introduce an entry that requires human intervention

Protection against Brute Force or Misuse
Avoiding automatic submissions

Insecure Implementation
We are not focusing weakness of CAPTCHA generation
Verifying CAPTCHA on client side
Having limited set words

CAPTCHA Implementation best practices

Generated on server side
Verified in server side
Strings must be randomly generated
Must be bound to a session
Must be regenerated after each successful or unsucessful
attempt

White and Black Listing

White Listing array of allowed characters

Listing array of special character which are not
to be allowed.

Black

Whats your choice while coding?

Would you prefer to check your fields

with white list or black list

Secure Your application

Log HTTP Requests

Use web application firewall to check requests.

Validate all fields at client and server side

Review source code for vulnerabilities

Create threat model and perform risk assessment of

application

Database Security

Passwords use hashing techniques

Web Vulnerability Scanner

Nikto

Paros Proxy

Webscarab

WebInspect

Burpsuite

Wikto

Acunetix *

Thank You