Thackamura

Thackamura

Auditeur Pentesteur

Web Checklist

Avant de commencer à vous présenter ma checklist, j’utilise pour prendre des notes mind42.com.
Un moyen simple et surtout visuel de gérer correctement votre pentest 😄
Bonne chance à vous 😋

Sommaire

  1. Phase de reconnaissance
  2. Scanners automatiques
  3. SSL/TLS vulnerabilités
  4. Bypass 403 / 401
  5. Failles applicatives
    1. SQL INJECTIONS
    2. SSRF (Server Side Request Forgery)
    3. XSS (Cross Site Scripting)
    4. File Inclusion/Path traversal
    5. File Upload
  6. Contrôle d’accès & Authentification



Phase de reconnaissance


Scanners automatiques

Quelques scanners standards


Si un CMS est utilisé, n’oubliez pas de lancer un scanner en début de pentest 😉


SSL/TLS vulnerabilités

Si le HTTP est uniquement utilisé et sert pour de l’envoi de données sensibles alors check ici.
Scanner utile :


Bypass 403 / 401


Failles applicatives

SQL INJECTIONS

L’injection SQL est une vulnérabilité de sécurité web qui permet à un attaquant d’interférer avec les requêtes qu’une application effectue dans sa base de données.
Elle permet généralement à un attaquant de visualiser des données qu’il n’est normalement pas en mesure de récupérer.
Il peut s’agir de données appartenant à d’autres utilisateurs, ou de toute autre donnée à laquelle l’application elle-même peut accéder.
Dans de nombreux cas, un attaquant peut modifier ou supprimer ces données, ce qui entraîne des changements persistants dans le contenu ou le comportement de l’application.


Tests classiques

SQLMap - Cheatsheet

Sources utiles


SSRF (Server Side Request Forgery)

Server-side request forgery (également connue sous le nom de SSRF) est une vulnérabilité Web qui permet à un attaquant d’inciter l’application côté serveur à effectuer des requêtes HTTP vers un domaine arbitraire choisi par l’attaquant.


Choses à tester

Outil

Bypass localhost


XSS (Cross Site Scripting)

Le cross-site scripting (également connu sous le nom de XSS) est une vulnérabilité web qui consiste à manipuler un site web vulnérable de manière à ce qu’il renvoie du JavaScript malveillant aux utilisateurs.
Lorsque le code malveillant s’exécute dans le navigateur d’une victime, l’attaquant peut compromettre totalement son interaction avec l’application.

Quels sont les types d’attaques XSS ?
Il existe trois principaux types d’attaques XSS. Il s’agit de :


Outils:


File Inclusion/Path traversal

Remote File Inclusion (RFI) : Le fichier est chargé à partir d’un serveur distant.
Local File Inclusion (LFI) : Le serveur charge un fichier local.
La vulnérabilité se produit lorsque l’utilisateur peut contrôler d’une manière ou d’une autre le fichier qui va être chargé par le serveur.
Fonctions PHP vulnérables : require, require_once, include, include_once.

LFI classique

RFI classique

LFI bypass

Les 25 paramètres les plus vulnérables à une LFI

paramlfi

Outils


File Upload

La faille d’upload de fichier est une faille permettant d’uploader des fichiers avec une extension non autorisée, cette faille est due à la mauvaise configuration du script d’upload ou à l’absence complète de sécurité. Celle ci est généralement présente dans les scripts d’upload d’images.

Extensions classiques

Bypass


Contrôle d’accès & Authentification

A l’aide de mécanismes d’authentification, le contrôle d’accès vise à s’assurer que les ressources hébergées sur un serveur ne sont accessibles qu’aux personnes autorisées.
Ces mécanismes d’authentification font appel à des fonctionnalités variées : cookies de session, mire d’authentification, .htaccess, etc.
Cette étape vise à examiner les moyens de contournement de ces mécanismes afin de s’affranchir du contrôle d’accès ou d’élever son niveau de privilèges.

Vérifier les messages d’erreurs d’authentification

Les messages d’échec de connexion ne doivent pas indiquer l’origine de l’erreur (identifiant inconnu ou mot de passe invalide par exemple), car cela fournit des informations précieuses à un attaquant.

En effet, lors d’une attaque par force brute par exemple, un message d’échec de connexion tel que « mot de passe invalide » permet à un attaquant de se concentrer sur l’identifiant renseigné, ce qui lui fait gagner beaucoup de temps.

De plus, cela facilite l’énumération d’utilisateurs et donc des fuites de données lorsque l’identifiant est l’adresse email de l’utilisateur (ce qui est par ailleurs assez fréquent). Ces données peuvent être utilisées dans des attaques d’ingénierie sociale et notamment de spear phishing.

Vérifier si la politique de mot de passe est assez robuste

La sécurité de l’authentification passe naturellement par la mise en place d’une politique de mot de passe efficace. En premier lieu, la complexité du mot passe qui doit être imposée lors de la création d’un compte : il doit être suffisamment long (10 à 12 caractères) et intégrer des caractères spéciaux, minuscules et majuscules.

Vérifier que tous les contrôles d’authentification sont réalisés côté serveur et non côté client.

Vérifier que le mot de passe de l’utilisateur soit demandé avant toute opération sensible (modification d’informations sensibles : mot de passe, comptes de messagerie, informations de paiement, etc.).

Vérifier si le système de réinitialisation de mots de passe est sécurisé.

La fonction « mot de passe oublié » et les autres chemins de récupération ne doivent pas révèler le mot de passe actuel ; et le nouveau mot de passe ne doit jamais être envoyé en clair à l’utilisateur.

Un token unique, composé d’une chaine de caractères aléatoire, doit être généré à chaque demande de réinitialisation puis invalidé une fois la réinitialisation effectuée.

Vérifier que des mesures techniques anti « brute force » soient présentes

Vérifier que les attributs sécurisés pour les cookies de session, notamment HTTPOnly, secure et samesite soient présents.

HTTPOnly permet d’éviter que l’identifiant de session soit accessible aux scripts Javascript, ce qui permet de contrer certaines méthodes de vol de session.

L’attribut « Secure » quant à lui, informe les navigateurs que l’identifiant de session ne doit transiter que via des canaux HTTPS, ce qui permet de contrer certaines attaques basées sur l’écoute du réseau.

Enfin, l’attribut « samesite » qui permet de se protéger contre des attaques de type CSRF.

Vérifier que les identifiants de session ne soient pas exposé dans les URLs

Vérifier que la session soit détruite lorsqu’un utilisateur se déconnecte de l’application.

Vérifier que les fonctionnalités sensibles soient protégées

Dans sa forme la plus élémentaire, l’élévation verticale des privilèges survient lorsqu’une application n’applique aucune protection sur les fonctionnalités sensibles. Par exemple, les fonctions administratives peuvent être liées à partir de la page d’accueil d’un administrateur mais pas à partir de la page d’accueil d’un utilisateur. Cependant, un utilisateur peut simplement accéder aux fonctions d’administration en accédant directement à l’URL d’administration appropriée.

Cela peut en fait être accessible par n’importe quel utilisateur, pas seulement les utilisateurs administratifs qui ont un lien vers la fonctionnalité dans leur interface utilisateur. Dans certains cas, l’URL d’administration peut être divulguée à d’autres emplacements, tels que le fichier robots.txt

Vérifier la modification de l’id de session dans l’URL

Les attaques d’élévation horizontale des privilèges peuvent utiliser des types de méthodes d’exploitation similaires à l’élévation verticale des privilèges. Par exemple, un utilisateur peut généralement accéder à la page de son propre compte à l’aide d’une URL comme celle-ci :

https://localhost/myaccount?id=123

Désormais, si un attaquant modifie la valeur “id” du paramètre pour celle d’un autre utilisateur, il peut alors accéder à la page de compte d’un autre utilisateur, avec les données et les fonctions associées.