Session3 data-validation

Web Application Security (PHP)

Zakieh Alizadeh

[email protected]

APA Laboratory – Ferdowsi University of Mashhad

Session 3

Data Validation

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

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

Data Validation

Web Application Firewall




Data Validation

Web Application Architecture

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

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

Data Validation


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

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

Data Validation

possible security measures of WAF

Data Validation

possible security measures of WAF

Data Validation





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

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.

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.

Handling User Input

Varieties of Input A typical web application processes user-supplied data in a range of

different Forms.

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

Handling User Input

Varieties of Input

Application Inputs :

users input via the browser interface

?

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

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

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


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

blocks everything 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.


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


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 ; >


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.


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.


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.


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


Boundary Validation

solution

o An application function using boundary validation at multiple

stages of processing

Data Validation





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

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`';

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'

SQL Injection

SQL injection threats

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

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.

SQL Injection

How to Avoid SQL Injection Vulnerabilities Using PHP function

• is_int()

• gettype()

• intval()

• settype()

• stripslashes(); ( /n -> n)

• mysql_real_escape_string();

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

SQL Injection

How to Avoid SQL Injection Vulnerabilities Use of Prepared Statements gettype()

SQL Injection

How to Avoid SQL Injection Vulnerabilities Least Privilege

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

Handling User Input

Technology

Session3 data-validation