3. Data Validation
Scenarios :
Preventing SQL Injection Attacks
Table of Content
Web Application Firewall
o possible security measures of WAF
Data Validation Strategies
o Varieties Of Input
o Reject Known Bad
o Accept Known Good
o Sanitization Safe Data Handling
o Semantic Checks
4. Data Validation
Scenarios :
Preventing SQL Injection Attacks
Table of Content
Introducing SQL Injection
Countermeasures Of SQL Injection
o PHP Functions
o Using Principle Of Least Privilege
o Prepared Statement
o Review of ORM Injection
5. Data Validation
Web Application Firewall
Data Validation Strategies
Introducing SQL Injection
Countermeasures Of SQL Injection
7. Data Validation
Web Application Firewall
a WAF is defined as a security solution on the web application level which
- from a technical point of view - does not depend on the application
itself. Good WAF
Main Goal
This applies to vulnerabilities in particular which have been revealed via a
penetration test or even via analysis of the source code, , and - especially
in the short term - cannot be fixed within the application
8. Data Validation
Why You Need A Web Application Firewall
Threats are evolving
Web applications are the low-hanging fruitHandlig user input
Web applications are growing
Good WAF
block access to certain ports or filter by IP address
look at every request and response within web service layers such as
HTTP, HTTPS, SOAP, and XML-RPC.
The meticulous inspection of web traffic
10. Data Validation
possible security measures of WAF
The table below gives possible security measures in the WAF :
o + very well covered by a WAF
o - cannot be covered (or only to a small degree) by a WAF
o ! dependent on the WAF/application/requirements
o = can partially be covered by a WAF
11. Data Validation
possible security measures of WAF
The table below gives possible security measures in the WAF :
o + very well covered by a WAF
o - cannot be covered (or only to a small degree) by a WAF
o ! dependent on the WAF/application/requirements
o = can partially be covered by a WAF
14. Data Validation
Web Application Firewall
Data Validation Strategies
Introducing SQL Injection
Countermeasures Of SQL Injection
15. Data Validation
Applications Defense Mechanisms
The defense mechanisms employed by web applications comprise the
following core elements:
Handling user access
Handlig user input
Handling attackers
Managing the application itself
16. Data Validation
Applications Defense Mechanisms
The defense mechanisms employed by web applications comprise the following
core elements:
Handling user access to the application’s data and functionality, to prevent users from
gaining unauthorized access.
Handlig user input to the application’s functions, to prevent malformed
input from causing undesirable behavior.
Handling attackers, to ensure that the application behaves appropriately
when being directly targeted, taking suitable defensive and offensive measures to
frustrate the attacker.
Managing the application itself, by enabling administrators to monitor its activities
and configure its functionality.
17. Handling User Input
Input validation
A huge variety of different attacks against web applications involve
submitting unexpected input, crafted to cause behavior that was not
intended by the application’s designers. Correspondingly:
a key requirement for an application’s security defenses
is that it must handle user input in a safe manner.
18. Handling User Input
Varieties of Input
A typical web application processes user-supplied data in a range of
different Forms.
19. Handling User Input
Varieties of Input
A typical web application processes user-supplied data in a range of different Forms.
very stringent validation checks
o username field
• 3<length<8
• charactersand contain only alphabetical letters
the application must tolerate a wider range of possible input.
o Address field
• Charactersand contain letters, numbers, spaces, hyphens, apostrophes, ...
• Restrict : should not contain any HTML mark-up
a blogging application may create a blog whose subject is web application hacking.
o Comment field
21. Handling User Input
Varieties of Input
In addition to the various kinds of input that is entered by users via the
browser interface, a typical application also receives numerous items of data
that began their life on the server and that are sent to the client so that the
client an transmit them back to the server on subsequent requests. This
includes
o Cookies
• Cookies are packages of data your servers hand out that are stored by a
browser so that they can be remembered next time they return.
o hidden form fields
o Some Http Header (refer)
o Some input that again retrive from db
22. Handling User Input
Approaches to Input Handling
Different approaches are often preferable for different situations and
different types of input, and a ombination of approaches may sometimes
be desirable.
o Reject Known Bad
o Accept Known Good
o Sanitization
o Safe Data Handling
o Semantic Checks
23. Approaches to Input Handling
Reject Known Bad
This approach typically employs a blacklist containing a set of literal
strings or patterns that are known to be used in attacks. The validation
mechanism blocks any data that matches the blacklist and allows
everything else.
o exploite using a wide variety of different input
o techniques for exploitation are constantly evolving
24. Approaches to Input Handling
Accept Known Good
This This approach employs a white list containing a set of literal strings
or patterns,or a set of criteria, that is known to match only benign input.
The validation mechanism allows data that matches the white list, and
blockseverything else.
while it is often extremely effective, the white-list-based approach does
not represent an all-purpose solution to the problem of handling user
input.
25. Approaches to Input Handling
Sanitization
Sometimes accept data that cannot be guaranteed as safe. Instead of
rejecting this input, the application sanitizes it in various ways to prevent
it from having any adverse effects.
Potentially malicious characters may be:
o removed from the data altogether
o leaving only what is known to be safe
o suitably encoded or “escaped” before further processing is performed
26. Approaches to Input Handling
Sanitization
Example
o For example, the usual defense against cross-site scripting attacks is
to HTML-encode dangerous characters before these are embedded
into pages of the application
code char
&apos ; “
& ; ‘
< ; <
& gt ; >
27. Approaches to Input Handling
Safe Data Handling
It is often the case that vulnerabilities can be avoided, not by validating
the input itself but by ensuring that the processing that is performed on it
is inherently safe. In some situations, there are safe programming
methods available that avoid common problems.
For example, SQL injection attacks can be prevented through the correct
use of parameterized queries for database access, as described later.
28. Approaches to Input Handling
Semantic Checks
Some vulnerabilities the input supplied by the attacker is identical to the
input that an ordinary, non-malicious user may submit. What makes it
malicious is the different circumstances in which it is submitted. For
example, an attacker might seek to gain access to another user’s bank
account by changing an account number transmitted in a hidden form
field.
29. Approaches to Input Handling
Boundary Validation
The core security problem with web applications arises because data received
from users is untrusted.
The point at which user data is first received by the server-side application
represents a huge trust boundary, at which the application needs to take
measures to defend itself against malicious input.
30. Approaches to Input Handling
Boundary Validation
disadvntages
o It would be very difficult to devise a single mechanism at the external boundary to defend
against all attacks.
o A single piece of user-supplied input might result in a number of operations in different App
components, with the output of each being used as the input for the next.
o Defending against different categories of input-based attack may entail performing different
validation checks
31. Approaches to Input Handling
Boundary Validation
solution
o An application function using boundary validation at multiple stages of
processing
32. Data Validation
Web Application Firewall
Data Validation Strategies
Introducing SQL Injection
Countermeasures Of SQL Injection
33. SQL Injection
Introduction SQL Injection
A SQL injection attack consists of insertion or "injection" of a SQL query via
the input data from the client to the application
o SQL Injection
o Blind SQL Injection
34. SQL Injection
Introduction SQL Injection
SQL query:
SELECT * FROM Users WHERE Username='$username' AND Password='$password'
values:
$username = 1' or '1' = '1
$password = 1' or '1' = '1
The query will be :
SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
SELECT * FROM Users WHERE username = '' OR 1=1 -- -' AND password = '';
SELECT * FROM Users WHERE id = '' UNION SELECT 1, 2, 3`';
35. SQL Injection
Some SQL Injection query
1' ORDER BY 1--+ True
1' ORDER BY 2--+ True
1' ORDER BY 3--+ False
- Query is only using 2 columns -1' UNION SELECT 1,2--+ True
Get version :
SELECT * FROM Users WHERE Username=‘admin' union select 1,@@version – AND
Password='$password'
Get table name:
SELECT * FROM Users WHERE Username=‘admin' union select table_name,2 from
INFORMATION_SCHEMA .tables – AND Password='$password'
Get tables of current db:
SELECT * FROM Users WHERE Username=‘admin' union select table_name,2 from
INFORMATION_SCHEMA.tables where table_schema = database() – AND Password='$password'
37. SQL Injection
How to Avoid SQL Injection Vulnerabilities
Using register_globals(depricated)
Using PHP function
Use of Prepared Statements (Parameterized Queries)
Use of Stored Procedures
Escaping all User Supplied Input
Also Enforce: Least Privilege
Also Perform: White List Input Validation
38. SQL Injection
How to Avoid SQL Injection Vulnerabilities
Using register_globals
• When you have register_globals=on, anything passed via GET or POST or
COOKIE automatically appears to be global variable in code, this might
have security consequences.
• I.e. you click on url test.php?access_level=100 and you'll have
$access_level = 100 in PHP.
• This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as
of PHP 5.4.0.
39. SQL Injection
How to Avoid SQL Injection Vulnerabilities
Using PHP function
• is_int()
• gettype()
• intval()
• settype()
• stripslashes(); ( /n -> n)
• mysql_real_escape_string();
40. SQL Injection
How to Avoid SQL Injection Vulnerabilities
Use of Prepared Statements gettype()
• use PDO with strongly typed parameterized queries (using bindParam())
Use of Stored Procedures
• Stored procedures have the same effect as the use of prepared
statements when implemented safely*. They require the developer to
define the SQL code first, and then pass in the parameters after.
$a=new PDO("mysql:host=localhost;dbname=library;",“leastprivilageduser","");
$b=$a->prepare("SELECT first_name, last_name FROM users WHERE user ==:user");
$b->bindParam(":user",$id , PDO::PARAM_INT);
$b->execute();
41. SQL Injection
How to Avoid SQL Injection Vulnerabilities
Use of Prepared Statements gettype()
43. SQL Injection
Information schema
In relational databases, the information schema is an ANSI standard set of read-only views
which provide information about all of the tables, views, columns, and procedures in a
database.
QUICK SQL COMMANDS OVERVIEW:
UNION ALL – Combine multiple columns
ORDER BY – Orders columns by alphabetical or numerical order
LIMIT – The number of the selected field to be displayed
CONCAT – Short for concatenate which means to combine two strings into a one.
GROUP_CONCAT – Grouping all values from a concatenated string
INTO_DUMPFILE() to dump the contents of a column into a text file
LOAD_FILE() to read the contents of any file contained within the webserver
back