1. Web Application Security (PHP)
Zakieh Alizadeh
zakiehalizadeh@gmail.com
APA Laboratory – Ferdowsi University of Mashhad

2. Session 3
Data Validation

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

6. Data Validation
Web Application Architecture

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

9. Data Validation
Web Application Firewall

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

12. Data Validation
possible security measures of WAF

13. Data Validation
possible security measures of 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

20. Handling User Input
Varieties of Input
 Application Inputs :
users input via the browser
interface
?

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 ; “
&amp ; ‘
&lt ; <
& 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'

36. SQL Injection
 SQL injection threats

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()

42. SQL Injection
How to Avoid SQL Injection Vulnerabilities
 Least Privilege

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

44. Handling User Input