web applications

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



Study the business purpose

Study the application features

Study the traffic between client and server




Reporting




Identify all possible threats to the application

Prepare a threat profile or business risk document



Reporting





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.


Reporting






Manual / Tool based execution

Interpret the results

Observe all expected/unexpected results

Execute again

Reporting






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


Through IP/domain

dig

nslookup

whois





Through IP/domain


Viewing Directory Indexing and Signatures

Accessing files which are not available etc




Through IP/domain



Inserting invalid data in the input boxes, check the messages displayed

We'll discuss more in coming slides



Through IP/domain




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)

Web Server

Database

Server

Query

Recordset

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

Web Proxy Editor

Intercept the traffic between browser and the web server

Web Browser

Web Server

Proxy 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

http://www.infosecawareness.in/

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

Select, update, insert, delete

SQL Data Definitional language

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'andpassword='$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 on .* to

user@localhost identified by 'password';

mailto:root@localhostmailto:user@localhost

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 , , and .

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

Malicious link on webpage

or email with malicious link

Bank.com

Reflected Code

Send cookie to attacker

Malicouse Code

http://bank.com/account.jsp?Send cookie to attacker.com

http://bank.com/login/ Executed

User

Internet

Banking

Cookie

1

2 3

4

http://bank.com/account.jsp

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 HTML tag

Is tag necessary to execute Javascript ??

javascript:codejavascript:alert

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

http://hackers.org/xss.htmlhttp://hackers.org/xss.html

Few Observations

We din't click on anything to get the script executed

There was no 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,;,>,

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

Whats your choice while coding?

Would you prefer to check your fields with white list or black list

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

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

web applications

Documents

test plan

web application security

application study

threat profile

application features

web servers

web server weaknesses

web different kinds