Transcript CHAPTER 7 Unexpected Input

CHAPTER 7
UNEXPECTED INPUT
1
Why Unexpected Data is
Dangerous

Three classes of attack can result from unexpected
data:
– Buffer overflow
» An attacker sent more data than the application expects
» May not gracefully handle the surplus data
» Example of language (do not properly handle surplus), C and
C++
» Example of language (do properly handle surplus):



Perl (Practical Extraction &Reporting Language)
PHP (PHP: Hypertext Preprocessor)
By increasing the size for variable storage
2
Why Unexpected Data is
Dangerous

Three classes of attack can result from
unexpected data:
– System Function
» Data use in some form to interact with a resources
that is not contained within the application
» It’s including running other application, accessing or
working with files
3
Why Unexpected Data is
Dangerous

Three classes of attack can result from unexpected
data:
– Logic alteration
» Data is crafted as a way to modify how the application’s logic
handles it
» It’s include diverting mechanism, altering Structured Query
Language (SQL) queries and gaining access to parts of the
application the attacker wouldn’t normally have access to

Unexpected data do not have any specific format,
can be as simple as supplying normal value that
modifies the application’s intended logical
execution
4
Situations Involving Unexpected
Data

HTTP / HTML
– Cause: lack of understanding of how they work
– The biggest mistake applications rely on the HTTP
referrer header
– Referrer header contains the address of the referring
page
– The client supplies the referrer header, so any altering
with the client, it’s trivial to spoof
– Dependency on HTML form limitations
– Client-side filtering, validation on the form
– Cookies, method give data to client & return back
5
Situations Involving Unexpected
Data

Unexpected Data in SQL queries
– Cause: the attacker is to modify the command that is
sending to your database server
– The biggest threat within SQL is that it’s possible to
include extra command to be executed
– Example:
SELECT * FROM table WHERE x=$data
» The value ($data) will be fill by the user. But, imagine an
attacker sending the
10; SELECT * FROM table WHERE y=5
» So, the result string sent
SELECT* FROM table WHERE x=10; SELECT* FROM table
WHERE y=5;
6
Situations Involving Unexpected
Data

Disguising the Obvious
– Nowadays, there are few of application rely on
signature matching. Signature matching is one of the
unexpected data attack
– Basic signature-matching network IDS has a list of
various values and situations to look for on a network.
So, the IDS processes will alert when a particular scene
is matches
– IDS (Intrusion Detection System)
– Web request, using various tactics and inventions
– Encoded
– Self-referenced directory notation
7
Finding Vulnerabilities


Same techniques to determine if an application is
vulnerable
Black-boxing tactics:
– Use intuition on what the application is doing
– Run through the full interactive process from start to
finish at least once. Look for hidden elements. Have
opportunity to undo the filtering
– Try to intentionally cause an error. Goal to see if
application alerts to an error
– Methodically work through each parameter, inserting
first a single quote(‘) and then a double quote(“).
Checking for possibility of breaking-out of a data string
in a SQL query
8
Finding Vulnerabilities

Black-boxing tactics:
– Try to determine the need and usefulness of
each parameter. Looking for strings or members
tend to be session keys
– Take into account the overall posture presented
by the web site and the application and use that
to hypothesize possible application aspects. If
not custom coded find the source
– Keep an eye out of anything that looks like a
filename
9
Finding Vulnerabilities

Black-boxing tactics:
– Research and understand the technological
limitations of the different types of web servers
/ scripting applications languages and database
servers
– Look for anything that seems to look like
equation, formula or actual snippets of
programming code
– Put yourself in the coder’s position
10
Finding Vulnerabilities

Use the source (Luke):
– Application auditing on source code available
– calls the system function and trace back where
the data being given to the system function
comes from
– Use techniques such as diffing to find
vulnerabilities / changes between function
11
Finding Vulnerabilities

Application Authentication:
– method to give a range random session or
authentication key (popular method bruteforcing)
– There are two serious concerns with this approach:
» The key must prove to be truly random; any predictability will
result in increased chances of an attacker guessing a valid
session key
» The size of the key space in comparison to the more extreme
number of keys needed at any time
– common method to use a SQL query against a database
of usernames and password
12
Protection: Filtering Bad Data


To combat unexpected data is to filter the data to
what is expected
Escaping characters is not always enough
– Remove offending data

Perl
– Perl’s translation command with delete modifier (tr///d)
works very well for removing characters
– Perl’s substitution operator (s///) is more flexible

Cold Fusion/Cold Fusion Markup Language
(CFML)
» To remove unwanted characters from data
» Has a regular replace function
13
Protection: Filtering Bad Data

ASP
– Introduced a regex object into their newest scripting
engine
– Use the new engine to perform a regex replacement

PHP
– Quotemeta-escape a small set of metacharacters
– Addslashes-sanitize at used in SQL queries

Protecting Your SQL Queries
– method->quoting-to make sure that submitted data is
properly contained within a set of quotes and that there
are no renegades quotes contained within the data itself
14
Protection: Filtering Bad Data

Silently Removing vs. Alerting on Bad Data
– Deal with incoming user data, two choices
» Remove bad characters, save good & continue process
» Stop immediately & alert to invalid input
– Alerts can determine which characters by attacker
– Silently filtering the data to any include safe characters
yields some different problems
» Integrity of data will be disturbed
» Still can determine if apps prints the submitted data after
changed
– Better combine both approaches based on type and
integrity of data
15
Protection: Filtering Bad Data

Invalid Input Function
– Function to report invalid data, especially can
report when & how an attacker is trying to
subvert your application logic
– Suitable use for reporting unexpected data
violations
– Analysis, tuning filters with greater accuracy
– Log character violations for above purpose
– Can deal by alert & abort once hit
16
Protection: Filtering Bad Data

Token Substitution
– The trick where you substitute a token
(typically a large, random session key)
– To correlate sensitive database, reference to the
data
– Token values must be huge & random if not
attacker possibly can guess
17
Available Safety Features

Some features to reduce or minimize the
risks of vulnerabilities:
– Perl
» has a ‘taint’, enables with the-T command-line
switch. It will warn when a user data pass into
command( bind, chdir, chmod etc)
» by passing tainted data, it will refusing to execute
your script and appear a message
» to ‘untaint’, use Perl’s matching regex (m///)
18
Available Safety Features

Some features to reduce or minimize the risks of
vulnerabilities:
– PHP
» includes a ‘safe-mode’, that limit the uses of PHP’s system
function
» when safe mode is enables: PHP limits-only to access file
owned by the UID or files in directory owned by PHP UID
» he use of exec, system, passthru and popen only be able to run
application contained in PHP_SAFE_MODE_EXEC_DIR
directory
» Mysql-Connect limits – only allow database connections(UID
of the Web server / UID of the current running script)
19
Available Safety Features

Some features to reduce or minimize the risks of
vulnerabilities:
– Cold Fusion/Cold Fusion Markup Language
» used to limits the scope of system functions
– ASP (VBScript and JScript)
» contain a configuration switch, disallows”../” notation. So, the
attacker are possible to gain access to the file not found under
the root Web directory
– MySQL
» contains the ability to read data in from or out to files during
queries using this syntax:
SELECT * INTO FILE ”/file/to/save.db” FROM table
» limit this by not granting ‘file’ permission to any users(in
MySQL)
20
End Of Chapter 7
21