Web Security

Johnny da Costa

André Neto Da Silva

Cours de sécurité

Prof. Ninoslav Marina

DLMB

Table des matières

Pourquoi la sécurité des applications web est importante ?

Comment attaquer une application web?

Comment se protéger?

Par où commencer?

Table des matières

Types d'attaques les plus connues

Fonctionnement de chaque attaque

Démo en live d'une attaque par injection SQL

Comment se protéger de ces attaques

50%

des applications web testées par WhiteHat restent vulnérables chaque jour de l'année

93%

des attaques sont financées et préparées par des organisations criminelles

77%

sont réalisées par des botnets

WhiteHat Security Statistics Report

$500M

Ashley Madison - Site de rencontre extra conjugal

Prix à payer pour les plaintes et poursuites

N'inclut pas le prix pour sécuriser la faille, ainsi que les pertes dues à la mauvaise réputation du site

Comprendre la sécurité des applications web

Présentation

(navigateur)

Logique

(serveur)

Données

(base de données)

Découvrir des failles de sécurité

http://hackyourselffirst.troyhunt.com/

http://www.itsecgames.com/

https://www.root-me.org

https://www.owasp.org/

Reconnaissance et Footprinting

Généralement la phase initiale d'une attaque

Cartographie de la surface d'attaque permettant de concentrer l'effort de piratage

Généralement automatisable

Spidering

Méthode de scrawling

Parcourt tous les liens depuis la racine

Exemple d'outil existant:

Forced Browsing

Méthode similaire au Spidering

Brute force des chemins à la recherche de nouvelles ressources

Exemple d'outil existant:

Banner Grabbing

Récupérer des informations concernant le serveur, framework, service, etc...

Exemple avec un simple wget

wget --server-response hackyourselffirst.troyhunt.com

Ensuite?

https://cve.mitre.org/cve/

Exemple: CVE-2014-3704

https://www.shodan.io/

Se renseigner sur les failles existantes:

Si nécessaire utiliser cet outil "magique":

Protection offerte par les navigateurs

Liste de phishing

Certificats SSL invalides

Cryptage faible

Cryptage cassé

Cryptage obsolète

Bon cryptage

Détection Cross Site Scripting

Types d'attaques les plus connues

Title Text

Injection

NoSQL

Javascript

SQL

Applications qui sont vulnérables

  • Données utilisateurs non-validées ou filtrées par l'application

 

  • Les données sont directement utilisées ou concaténées, de sorte que le SQL ou la commande contient à la fois des données de structure et des données hostiles dans les requêtes dynamiques, les commandes ou les procédures stockées.
http://newspaper.com/user.php?id=2

Exemple d'attaque : scenarios 

http://newspaper.com/user.php?id=2 or 1=1

SELECT * FROM users WHERE ID = 2
SELECT * FROM users WHERE ID = 2 or 1=1
or 1=1 -- toujours vrai

Un hacker peut avoir accès à tous les noms d'utilisateurs et mots de passe dans une base de données, en insérant simplement OR 1 = 1 dans le champ de saisie.

Repérer les sites qui comportent des failles d'injection SQL

Google is your friend

Dork query

Google dorking, également connu sous le nom de Google piratage, peut renvoyer des informations difficiles à localiser grâce à des requêtes de recherche simples. Cette description comprend des informations qui ne sont pas destinées au public mais qui n'ont pas été protégées de manière adéquate.

Fresh Google Dorks 2018 for SQLi

https://www.nextleveltricks.com/latest-google-dorks-list/

  • about.php?cartID=
  • accinfo.php?cartId=
  • acclogin.php?cartID=
  • add.php?bookid=
  • add_cart.php?num=
  • addcart.php?
  • addItem.php
  • add-to-cart.php?ID=
  • addToCart.php?idProduct=
  • addtomylist.php?ProdId=
  • adminEditProductFields.php?intProdID=
  • advSearch_h.php?idCategory=
  • ...

Démonstration

Se protéger d'une attaque par injection SQL

Utiliser des procédures stockées, à la place du SQL dynamique.

Utiliser une expression rationnelle afin de valider qu'une donnée entrée par l'utilisateur est bien de la forme souhaitée.

Utiliser des comptes utilisateurs SQL à accès limités (en lecture-seule) quand cela est possible.

Utilisation d'une White List Input Validation

CSRF

Cross-site request forgery

CSRF

!=

XSS

CSRF est une attaque qui force un utilisateur final à exécuter des actions indésirables sur une application Web dans laquelle il est actuellement authentifié

Gmail

MySpace

Windows Live Mail

Skyrock

Dynadot

...

Les victimes de ce type d'attaque

Recommandations générales pour la défense CSRF automatisée

Check standard headers to confirm that the request is of the same origin

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Check CSRF token

https://laravel.com/docs/5.6/csrf

Laravel génère automatiquement un "jeton" CSRF pour chaque session utilisateur active gérée par l'application. Ce jeton est utilisé pour vérifier que l'utilisateur authentifié est celui qui envoie les requêtes à l'application.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Check CSRF token

GET request

GET request

token session

no token session

legal user

illegal user

site web

session

xxxxxxxx

logic

CSRF token check

http://www.mcherifi.org/hacking/les-attaques-csrf-injection.html

Vérification de l’url de provenance

if (!empty($_SERVER[‘HTTP_REFERER’])) {
    if (!ereg($_SERVER[‘HTTP_HOST’], $_SERVER[‘HTTP_REFERER’])) {
        die(“Vous ne pouvez pas venir ici!”);
    }
} else {
    die(“Désolé, Vous ne venez pas d’ici”);
}

Pas une valeur sûre puisque modifiable, désactivable par l'utilisateur

Conclusion

Merci de votre attention

Johnny da Costa

André Neto Da Silva

Cours de sécurité

DLMB

Made with Slides.com