Agenda

Web Application n
n
Web Application basics
Web Network Security
Security n Web Host Security
n Web Application Security
n Best Practices
Prof. Sukumar Nandi
Indian Institute of Technology Guwahati n Questions ?

Web Application Basics How are they connected ?

n Web Server
Request
Web Server
n Web Client Web Transport
Client
n Web Applications Response

n Application Databases
Web Apps
“n-tiers”

Databases

1

Examples
n Web Client – Internet Explorer, Mozilla
n Web Server – Apache, IIS
n Database – MySQL, Oracle
n Firewall – PIX, CheckPoint
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.
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 ;-)
2
Network Security elements Router Security
n Router Security n Use ssh as opposed to Telnet for
n DDoS Security accessing the router.
n Firewalls n Close all unwanted services like http, ntp
etc
n Network Intrusion Detection System
n Host Intrusion Detection System n Add infrastructure ACLs to protect the
routers themselves from malicious attacks.

DDoS Security DoS and DDoS Attacks

n DDoS is a major problem and can take n TCP SYN
down incredibly large infrastructures. n TCP ACK
n A DDoS attack consists of Zombie n UDP, ICMP, TCP floods
computers controlled by an attacker who n Fragmented Packets
conducts a distributed attack on a victim. n IGMP flood
n Spoofed and un-spoofed
n DDoS attacks have know to take down
large corporation like Yahoo and E-Bay.

3
Basics of a DDoS Attack Automated DDoS Attack
Vulnerable hosts
1 Initiate scan 2 are compromised
DDoS client
Attack tool installed on
3 each compromised host

DDoS DDoS DDoS Attacker 4

handler handler handler Further scanning 4
for compromises 4

DDoS
agents
5
5
5
Massive DDoS
attack launched

affic
S Tr
DDo
Victim Network

DoS Filtering Firewall

n Firewalls are an essential requirement in today's networks.
Description Network
n It makes it very easy to filter attacks based on IP, port, service etc
default 0.0.0.0 /8
n Firewalls like Cisco PIX allow a huge level of low level customi zation to
loopback 127.0.0.0 /8 be able to fine tune it to even bits in the packet headers and even have
RFC 1918 10.0.0.0 /8 capability to peer into the application layer.
RFC 1918 172.16.0.0 /12
RFC 1918 192.168.0.0 /16
Net Test 192.0.2.0 /24
Testing devices 192.18.0.0 /15
IPv6 to IPv4 relay 192.88.99.0 /24
RFC 1918 nameservers 192.175.48.0 /24
End-node auto configuration 169.254.0.0 /16

4
Internet Router Policy
Ingress filtering:
• 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
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.
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 (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.
5
Host based IDS
n Protecting individual hosts is necessary.
n Sometimes internal computers might be the
first point of attack of email based worms Web Host Security
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.

Host Security ? Host Security (contd.)

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

6

Web Application
Security
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.
What is so unique about web App. Sec
N-BIOS
HTTP(S)
FTP
Firewall Web Server Data Base
Server
RPC
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
n Using SSL is an airtight solution
7
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 (contd.)
n Insecure Use of Cryptography
n Remote Administration Flaws
n Web and Application Server
Misconfiguration
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
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
n Type, min/max length, character set, regex, min/max value…
8
1. Unvalidated Parameters (contd.) 1. Unvalidated Parameters (contd.)
n Unvalidated input: n Unvalidated input: “SQL Injection”
n Never trust input from a user n A little more difficult
n Malicious user can tamper with anything and try to: n Insert SQL statement where they do not sufficiently
n Cause errors to occur and give up info validate input
n Buffer overflow
n Modify parameters n Vulnerable CGI-code will forward the malicious
n Common attacks: statement to database
n Modifying URL n Database is indifferent, executes the statement and
n SQL Injection sends the results back to the user
n Cross Site Scripting
n Session hijacking with cookie modification

1. Unvalidated Parameters (contd.) 1. Unvalidated Input (contd.)

n Unvalidated input: “SQL Injection”
example
www.test.com/ cgi-bin/productdesc.asp?category=10;
Unvalidated input: “SQL Injection” example
n
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!):
n CGI code will look like (don’t worry about this part!): v_cat = request("category") # v_cat= 10’ UNION SELECT name, pwd FROM
v_cat = request("category") #v_cat=10; admins;--
sqlstr ="SELECT description FROM product WHERE category='" & v_cat & "'" sqlstr ="SELECT description FROM product WHERE category='" & v_cat & "'"
set rs=conn.execute( sqlstr ) set rs=conn.execute( sqlstr )
n Database will execute:
n Database will execute: SELECT description FROM product WHERE category=’10’
n SELECT description FROM product WHERE category=10; UNION SELECT name, pwd FROM admin;--
(-- is comment out the rest of syntax.)

n Got the admin username and password!

9
 3. Broken Account and Session
2. Broken Access Control Management
n Access control is how you keep one user away from other users’ n Account Management
information n Handling credentials across client-server gap
n The problem is that many environments provide authentication, but n Backend authentication credentials too
don’t handle access control well n Session Management
n Many sites have a complex access control policy
n HTTP is a “stateless” protocol. Web apps need to keep track of
n Insidiously difficult to implement correctly which request came from which user
n Key Points n “Brand” sessions with an id using cookie, hidden field, URL tag,
n Write down your access control policy etc…
n Don’t use any “id’s” that an attacker can manipulate n Key Points
n Implement access control in a centralized module n Keep credentials secret at all times

n Use only the random sessionid provided by your environment

4. Cross-Site Scripting (XSS)

Flaws 4. XSS (Contd.)
n Web browsers execute code sent from websites n Unvalidated input: “Cross site scripting”
n Javascript n Hidden Html code/ Java script code injection
n Similar to SQL Injection
n Flash and many others haven’t really been explored
n Cross-Site-Scripting may not be directly against your website but
n But what if an attacker could get a website to forward an attack! against your clients
n Stored – web application stores content from user, then sends it n 4 easy steps!
to other users
1. Locate Web page with unchecked input
n Reflected – web application doesn’t store attack, just sends it
2. Embed “poisoned link” or scripts to Web page
back to whoever sent the request 3. Send the pages to client to collect information using spam or putting in forum
n Key Points 4. Collect the Web users client information or further for session hijacking

n Don’t try to strip out active content – too many variations. Use a
n Few people check html/javascript codes, sometime the links are
“positive” specification. unicoded, hard to read

10
5. Buffer Overflows 6. Command Injection Flaws
n Web applications involve many interpreters
n Web applications read all types of input from users
n OS calls, SQL databases, templating systems
n Libraries, DLL’s, Server code, Custom code, Exec
n Malicious code
n C and C++ code is vulnerable to buffer overflows
n Sent in HTTP request
n Input overflows end of buffer and overwrites the stack
n Extracted by web application
n Can be used to execute arbitrary code
n Passed to interpreter, executed on behalf of web app
n Key Points
n Key Points
n Don’t use C or C++
n Use extreme care when invoking an interpreter
n Be careful about reading into buffers
n Use limited interfaces where possible (PreparedStatement)
n Use safe string libraries correctly
n Check return values

11
 Application Hacking

7. Error Handling Problems

n Errors occur in web applications all the time
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

What do these variables do?

Application Hacking

Variable IB&F22 -> IB&F112

Variable IB -> IC
Different variable, different error

12
 l Full path names
revealed

l Table Name

l Field Name

l Database Name

13
8. Insecure Use of Cryptography 9. Remote Administration Flaws
n Use cryptography to store sensitive information n Many sites allow remote administration
n Algorithms are simple to use, integrating them is hard n Very powerful, often hidden interfaces

n Key Points n Difficult to protect

n Do not even think about inventing a new algorithm n Key Points

n Be extremely careful storing keys, certs, and passwords n Eliminate all administration over the Internet

n Rethink whether you need to store the information n Separate the admin application from the main app

n Don’t store user passwords – use a hash like SHA-256 n Limit the scope of remote administration

n The “master secret” can be split into two locations and assembled n Consider strong authentication
n Configuration files, external servers, within the code n Smart card or token

10. Web and Application Server

Mis-configuration E-Commerce
n All web and application servers have many security-relevant
configuration options
n Default accounts and passwords
Security – Best
n Unnecessary default, backup, sample apps, libraries

n Overly informative error messages

Practices
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!

14
How to protect Web Apps ?
n How to stop Web application attacks
n Error message customization
n Restricted access to sensitive information Questions ?
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

15