Web Application Security

Web Application

Security

Prof. Sukumar Nandi Indian Institute of Technology Guwahati

Agenda

n

Web Application basics

n

Web Network Security

n

Web Host Security

n

Web Application Security

n

Best Practices

n

Questions ?

Web Application Basics

n

Web Server

n

Web Client

n

Web Applications

n

Application Databases

How are they connected ?

Web Server Web Apps Databases Transport

Web

Client

“n-tiers”

How are they connected ? (contd.)

n

Web Client (normally a browser) issues a

request to the Web Server using

HTTP/HTTPS.

n

Web server processes the request and

builds a web page using resources such as

databases.

n

This web page is returned to the Web

Client, which it displays to the user.

Examples

n

Web Client – Internet Explorer, Mozilla

n

Web Server – Apache, IIS

n

Database – MySQL, Oracle

n

Firewall – PIX, CheckPoint

Network Security

n

For Web application its host network is of

prime importance.

n

Web Application security will work only if its

surrounding network infrastructure is safe.

n

If an attacker is successful in taking down

the Web application host network, then the

rest is history ;-)

Network Security elements

n

Router Security

n

DDoS Security

n

Firewalls

n

Network Intrusion Detection System

n

Host Intrusion Detection System

Router Security

n

Use ssh as opposed to Telnet for

accessing the router.

n

Close all unwanted services like http, ntp

etc

n

Add infrastructure ACLs to protect the

routers themselves from malicious attacks.

DDoS Security

n

DDoS is a major problem and can take

down incredibly large infrastructures.

n

A DDoS attack consists of Zombie

computers controlled by an attacker who

conducts a distributed attack on a victim.

n

DDoS attacks have know to take down

large corporation like Yahoo and E-Bay.

DoS and DDoS Attacks

n

TCP SYN

n

TCP ACK

n

UDP, ICMP, TCP floods

n

Fragmented Packets

n

IGMP flood

Basics of a DDoS Attack

Automated DDoS Attack

1 2 3 4 4 4 5 5 5

Initiate scan Vulnerable hosts are compromised

Attack tool installed on each compromised host Further scanning for compromises Massive DDoS attack launched Victim Network Attacker

DoS Filtering

192.175.48.0 /24 RFC 1918 nameservers

192.88.99.0 /24 IPv6 to IPv4 relay

192.18.0.0 /15 Testing devices 192.0.2.0 /24 Net Test 192.168.0.0 /16 RFC 1918 172.16.0.0 /12 RFC 1918 10.0.0.0 /8 RFC 1918 127.0.0.0 /8 loopback 0.0.0.0 /8 default Network Description

Firewall

n Firewalls are an essential requirement in today's networks.

n It makes it very easy to filter attacks based on IP, port, servi ce etc

n Firewalls like Cisco PIX allow a huge level of low level customi zation to be able to fine tune it to even bits in the packet headers and even have capability to peer into the application layer.

Internet Router Policy

• deny all rfc 1918 and special use addresses from entering the corporate network

• deny all traffic with an IP source address of the corporate network or branch networks

• permit all other traffic

Egress filtering:

• permit only traffic with an IP source address of the corporate network and branch networks

• deny all other traffic

Internet Router Configuration

access-list 133 deny ip host 0.0.0.0 any access-list 133 deny ip 127.0.0.0 0.255.255.255 any access-list 133 deny ip 10.0.0.0 0.255.255.255 any access-list 133 deny ip 172.16.0.0 0.15.255.255 any access-list 133 deny ip 192.168.0.0 0.0.255.255 any access-list 133 deny ip 192.0.2.0 0.0.0.255 any access-list 133 deny ip 169.254.0.0 0.0.255.255 any access-list 133 deny ip 240.0.0.0 15.255.255.255 any access-list 133 deny ip 144.254.0.0 0.0.255.255 any access-list 133 deny ip 171.71.32.0 0.0.0.31 any access-list 133 deny ip 192.150.42.0 0.0.0.31 any access-list 133 permit ip any any

access-list 144 permit ip 144.254.0.0 0.0.255.255 any access-list 144 permit ip 171.71.32.0 0.0.0.31 any access-list 144 permit ip 192.150.42.0 0.0.0.31 any access-list 144 deny ip any any

interface Serial 0/0 description To Internet ip access -group 133 in ip access -group 144 out

Network IDS

n

Network based Intrusion Detection

Systems are used to detect various attacks

at the network level itself.

n

Positioning the NIDS is very important so it

can see all the traffic on the network.

n

NIDS like Snort are Signature based and

those like PHAD are anomaly based.

Network IDS (contd.)

n

Anomaly based IDS have the ability to

learn what is “normal” for the network in

question and then tries to detect

aberrations from this “normality”.

n

Signature based IDS detect attacks try to

detect signature patterns in the network

traffic.

Host based IDS

n

Protecting individual hosts is necessary.

n

Sometimes internal computers might be the

first point of attack of email based worms

and viruses.

n

A good patching system is also required.

n

Security updates for software packages

installed on the computer should be

installed from time to time.

Web Host Security

Host Security ?

n

Host security refers to the security

measures used to secure the computer

hosting the web applications.

n

Shut down unnecessary services which are

not used e.g. RPC ports

n

Have a good patch management system in

place.

Host Security (contd.)

n

Host based IDS is a program which sits on

the computer and probes for suspicious

events at a process and sometimes even a

system call level.

n

Host based IDS provide an access edge

level security by protecting the end hosts

on the network.

Web Application

Security

What is so unique about web App. Sec

Web Server

Data Base

Server

Firewall

Uniqueness lies in the fact that …

n

Almost all E-Commerce applications are

web application based – banking, shopping

n

Web application uses port 80 i.e. the HTTP

port.

n

Port 80 is almost NEVER blocked on the

firewalls.

n

Thus applications accessible via port 80

are the starting point for a web hacker.

Are Web Applications Vulnerable?

n HTTP is a stateless protocol and inherently insecure

n Each HTTP request is discrete

n Application has to keep track of user session

n Trusting Browser input is a myth and so are these:

n The user will only send required input n The user cannot manipulate drop-down lists n The user cannot manipulate hidden fields n Java scripts will take care of validation

Are Web Apps vulnerable ?

n

Attractive targets yielding high value results

n Credit Card Numbers

n Bank account information

n Confidential information

n Personal Email

n

Conventional security solutions (SSL and

Firewalls) not adequate

n

Often developed in house - poor code and

frequent updates

n

Gartner: most of the cyber attacks were at the

application level

Web App vulnerability list

n

Unvalidated parameters

n

Broken Access Control

n

Broken Account and Session Management

n

XSS Flaws

n

Buffer Overflows

n

Command Injection Flaws

n

Error handling Problems

Web App Vulnerability list (contd.)

n

Insecure Use of Cryptography

n

Remote Administration Flaws

n

Web and Application Server

Misconfiguration

1. Un-validated Parameters

n HTTP requests from browsers to web apps

n URL, Querystring, Form Fields, Hidden Fields, Cookies, Headers

n Web apps use this information to generate web pages n Attackers can modify anything in request

n WebScarab n Key Points:

n Check before you use anything in HTTP request

n Canonicalize before you check

n Client -side validation is irrelevant

n Reject anything not specifically allowed

1. Unvalidated Parameters (contd.)

n

Unvalidated input:

n Never trust input from a user

n Malicious user can tamper with anything and try to: nCause errors to occur and give up info

nBuffer overflow

nModify parameters

n Common attacks:

nModifying URL

nSQL Injection

nCross Site Scripting

nSession hijacking with cookie modification

1. Unvalidated Parameters (contd.)

n

Unvalidated input: “SQL Injection”

n

A little more difficult

n

Insert SQL statement where they do not sufficiently

validate input

n

Vulnerable CGI-code will forward the malicious

statement to database

n

Database is indifferent, executes the statement and

sends the results back to the user

1. Unvalidated Parameters (contd.)

n

Unvalidated input: “SQL Injection”

example

www.test.com/ cgi-bin/productdesc.asp?category=10;

n

CGI code will look like (don’t worry about this part!):

v_cat = request("category") #v_cat=10;

sqlstr ="SELECT description FROM product WHERE category='" & v_cat & "'" set rs=conn.execute( sqlstr )

n

Database will execute:

n SELECT description FROM product WHERE category=10;

1. Unvalidated Input (contd.)

n If we give the category another value instead of the normal one:

www.test.com/cgi-bin/productdesc .asp?category=10’ UNION SELECT name,pwd FROM

admins;--n CGI code will look like (don’t worry about this part!):

v_cat = request("category") # v_cat= 10’ UNION SELECT name, pwd FROM

admins;--sqlstr ="SELECT description FROM product WHERE category='" & v_cat & "'" set rs=conn.execute( sqlstr )

n Database will execute:

SELECT description FROM product WHERE category=’10’ UNION SELECT name, pwd FROM

admin;--2. Broken Access Control

n Access control is how you keep one user away from other users’ information

n The problem is that many environments provide authentication, but don’t handle access control well

n Many sites have a complex access control policy n Insidiously difficult to implement correctly

n Key Points

n Write down your access control policy

n Don’t use any “id’s” that an attacker can manipulate n Implement access control in a centralized module

3. Broken Account and Session

Management

n Account Management

n Handling credentials across client-server gap n Backend authentication credentials too

n Session Management

n HTTP is a “stateless” protocol. Web apps need to keep track of which request came from which user

n “Brand” sessions with an id using cookie, hidden field, URL tag, etc…

n Key Points

n Keep credentials secret at all times

n Use only the random sessionid provided by your environment

4. Cross-Site Scripting (XSS)

Flaws

n Web browsers execute code sent from websites n Javascript

n Flash and many others haven’t really been explored

n But what if an attacker could get a website to forward an attack! n Stored – web application stores content from user, then sends it

to other users

n Reflected – web application doesn’t store attack, just sends it back to whoever sent the request

n Key Points

n Don’t try to strip out active content – too many variations. Use a “positive” specification.

4. XSS (Contd.)

n

Unvalidated input: “Cross site scripting”

n Hidden Html code/ Java script code injection

n Similar to SQL Injection

n Cross-Site-Scripting may not be directly against your website but against your clients

n 4 easy steps!

1. Locate Web page with unchecked input 2. Embed “poisoned link” or scripts to Web page

3. Send the pages to client to collect information using spam or putting in forum 4. Collect the Web users client information or further for session hijacking

n Few people check html/javascript codes, sometime the links are unicoded, hard to read

5. Buffer Overflows

n Web applications read all types of input from users n Libraries, DLL’s, Server code, Custom code, Exec

n C and C++ code is vulnerable to buffer overflows n Input overflows end of buffer and overwrites the stack n Can be used to execute arbitrary code

n Key Points

n Don’t use C or C++

n Be careful about reading into buffers n Use safe string libraries correctly

6. Command Injection Flaws

n OS calls, SQL databases, templating systems

n Malicious code n Sent in HTTP request n Extracted by web application

n Passed to interpreter, executed on behalf of web app

n Key Points

n Use extreme care when invoking an interpreter

n Use limited interfaces where possible (PreparedStatement) n Check return values

7. Error Handling Problems

n Out of memory, too many users, timeout, db failure n Authentication failure, access control failure, bad input

n How do you respond?

n Need to tell user what happened (no hacking clues) n Need to log an appropriate (different) message n Logout, email, pager, clear credit card, etc…

n Key Points:

n Make sure error screens don’t print stack traces n Design your error handling scheme

n Configure your server

Application Hacking

What do these variables do?

Application Hacking

Variable IB -> IC

Variable IB&F22 -> IB&F112

Different variable, different error

l

Full path names

revealed

l

Field Name

l

Table Name

8. Insecure Use of Cryptography

n Algorithms are simple to use, integrating them is hard

n Key Points

n Do not even think about inventing a new algorithm n Be extremely careful storing keys, certs, and passwords n Rethink whether you need to store the information n Don’t store user passwords – use a hash like SHA -256

n The “master secret” can be split into two locations and assembled n Configuration files, external servers, within the code

9. Remote Administration Flaws

n Very powerful, often hidden interfaces n Difficult to protect

n Key Points

n Eliminate all administration over the Internet n Separate the admin application from the main app n Limit the scope of remote administration

n Consider strong authentication n Smart card or token

10. Web and Application Server

Mis-configuration

n All web and application servers have many security-relevant configuration options

n Default accounts and passwords

n Unnecessary default, backup, sample apps, libraries n Overly informative error messages

n Misconfigured SSL, default certificates, self-signed certs n Unused administrative services

n Key Points:

n Keep up with patches (Code Red, Slammer) n Use Scanning Tools (Nikto, Nessus) n Harden your servers!

E-Commerce

Security – Best

How to protect Web Apps ?

n

How to stop Web application attacks

n

Error message customization

n

Restricted access to sensitive information

n

Patch Web servers

n

Remove the sensitive page from Google

n

Regularly perform application test

n

Deploy a web application firewall

n

Deploy IPS that will analyze application level