Bypassing Client-

Side Controls
By: M. Swain
Client-side
refers to operations that are performed by the
client in a clientserver environment
Typically, web browser, that runs on a user's
local computer
The user has complete control over the client
Client Side Control
An application may rely on client-side
controls to restrict user input in two broad
ways.
Transmitting data via the client component
Implementing measures on the client side
Capturing User Data: HTML Forms
Simplest and most common mechanism for
capturing input from the user and submitting
it to the server
Example: Consider this HTML form
<form action=order.asp method=post>
<p>Product: Sony VAIO A217S</p>
<p>Quantity: <input size=2 maxlength=3
name=quantity>
Hack Steps for Length
Limit
Look for form elements containing a max-
length attribute.
Submit data that is longer than this length
If the application accepts the overlong data,
you may infer that the client-side validation is
not replicated on the server.
The above security flaws if exists, can lead to
possibilities of other vulnerabilities such as
SQL injection, cross-site scripting, or buffer
overflows.
Script-Based Validation
Input validation mechanisms built into HTML
forms are simple and fine-grained to perform
relevant validation for many kinds of input
Therefore, common to see customized client-
side input validation implemented within
scripts
<script>
function ValidateForm(theForm)
{
var isInteger = /^\d+$/
if(!isInteger.test(theForm.quantity.value))
{
alert(Please enter a valid quantity);
return false;
}
return true;
}
</script>
<form action=order.asp method=post onsubmit=return
ValidateForm(this)>
<p>Product: Sony VAIO A217S</p>
<p>Quantity: <input size=2 name=quantity>
<input name=price type=hidden value=1224.95>
<input type=submit name=buy value=Buy!></p>
</form>
Hack Steps
Identify any cases where client-side JavaScript
is used
Submit data to the server by blocking the
validation steps
Determine whether the client-side controls
are replicated on the server
And if not, whether this can be exploited for
any malicious purpose.
Disabled Elements
Element on an HTML form is flagged as
disabled, it appears on-screen but is grayed
out and is not editable or usable
Consider the following form:
Disabled Elements
<form action=order.asp method=post>
<p>Product: <input disabled=true name=product
value=Sony VAIO
A217S></p>
<p>Quantity: <input size=2 name=quantity>
<input name=price type=hidden value=1224.95>
<input type=submit value=Buy!></p>
</form>
Capturing User Data: Thick-Client
Components
Besides HTML forms, the other main method
for capturing, validating, and submitting user
data
Technology: Java Applet, ActiveX Control, Shock
Wave Flash Objects
Internal workings are less transparently
visible than HTML forms and JavaScript
Java Applets
Popular for implementing thick-client
components
cross-platform and run in a sandboxed environment
Main use: to capture user input or other in-
browser information
 Java game example
<script>
function play()
{
alert(you scored + TheApplet.getScore());
document.location = submitScore.jsp?score= +
TheApplet.getObsScore() + &name= +
document.playForm.yourName.value;
}
</script>
<form name=playForm>
<p>Enter name: <input type=text name=yourName
value=></p>
<input type=button value=Play onclick=JavaScript:play()>
</form>
<applet code=https://wahh-game.com/JavaGame.class
id=TheApplet></applet>
Java example
URL entry that is returned after playing game:
https://wahh-game.com/submitScore.jsp?score=

c1cc3139323c3e4544464d51515352585a61606a6b&name=d
af
Want to cheat the game, one way is to
harvest a large number of scores and attempt
to reverse engineer the algorithm
Decompiling Java
Bytecode
Better approach to hack Java
To decompile: first save a copy of file/URL to
disk
Use browser to request the URL specified in the
code attribute of the applet tag
Jad
Tool for decompiling Java bytecode
Once Jad has decompiled the applet back to
its source code, you can start to bypass the
client-side controls
For example, you could change the
getObsScore method to:
return obfuscate(99999|0.123456789);
Coping with Bytecode Obfuscation
Various techniques have been developed to
obfuscate bytecode because of the ease Java
can decompile it
These techniques result in bytecode that is
harder to decompile or that leads to
misleading or invalid source code
Obfuscation techniques
Meaningful class, method, and member variable
names are replaced with meaningless expressions
like a, b, c.
Redundant code may be added for Obscurity
ActiveX Controls
Heavyweight technology compared to Java
ActiveX controls are written in C and C++
Cant be decompiled back to source code easily
Its possible for a user to hack ActiveX, but
too complicated
Fixing Inputs Processed by Controls
ActiveX controls are sometimes put as a
client-side control to verify that the client
computer compiles with specific security
standards before access is granted to certain
server-side functionality
Filemon and Regmon (now Process Monitor)
Enable you to monitor all of a processs
interaction with the computers file system and
registry
Decompiling Managed
Code
.NET Reflector by Lutz Roeder
Useful tool for decompiling a thick-client
component written in C# & Visual Basic
Shockwave Flash Objects
Most common use of Flash is for an
application context for online games
Flash objects are contained within a compiled
file that the browser downloads from the
server and executes in a virtual machine
(Flash player)
SWF file contains bytecode that can be
decompiled to recover the original source
Flasm
Dissembler and assembler for SWF bytecode
and can be used to extract human-readable
representation of the bytecode from an SWF
file then reassemble modified bytecode into a
new SWF file
Handling Client-Side Data Securely
Security problems with web applications arise
because client-side components and user
input are outside of the servers direct control
Transmitting Data via the
Client
Encryption techniques can be used to prevent
tampering by the user
If the above is used, then there are two
important pitfalls to avoid:
Replay Attack
Cryptographic Attack
Validating Client-Generated Data
Data generated on the client and transmitted
to the server cannot be validated securely on
the client:
Lightweight client-side controls like HTML form
fields and JavaScript provide zero assurance
about the input received by the server
Use of thick-client components are sometimes
more difficult to circumvent, but this may
merely slow down an attacker for a short
period.
Logging and Alerting
Integration of server-side intrusion detection
defenses
Anomalies should be logged and
administrators should be alerted in real time
to take action
Summary
Almost all client-server applications must
accept the fact that the client component, and
all processing that occurs on it, cannot be
trusted to behave as expected

Questions?