Contourner une erreur 403 Forbidden : en-têtes, méthodes, chemins

Introduction

Et si contourner les erreurs 403 permettait de découvrir des vulnérabilités cachées ? Cet article explore des techniques avancées pour contourner ces erreurs et mettre au jour d'éventuelles failles de sécurité. Nous examinons des méthodes telles que le fuzzing des en-têtes de requête, qui peut révéler des erreurs de configuration du serveur, la modification des méthodes HTTP pour tester différents types de requêtes, la manipulation des paramètres de requête pour contourner les restrictions, l'utilisation de la Wayback Machine pour retrouver des fichiers autrefois accessibles, et bien d'autres. Ces techniques peuvent apporter des informations essentielles pour les tests d'intrusion et les évaluations de sécurité.

Techniques mises en œuvre pour contourner les erreurs 403

Pour y parvenir, de nombreuses techniques peuvent être employées. Elles comprennent la modification des en-têtes d'hôte pour détecter des erreurs de configuration, la création de requêtes avec différents user agents pour découvrir d'autres points d'accès, l'ajustement des paramètres de requête pour trouver des vulnérabilités, la génération de chemins de requête fuzzés pour contourner les contrôles d'accès et l'utilisation de la Wayback Machine pour retrouver du contenu autrefois accessible. Chacune de ces méthodes, et bien d'autres, joue un rôle déterminant pour déjouer les erreurs 403 et révéler des failles de sécurité cachées.

Modifier l'en-tête Host

La manipulation des en-têtes HTTP peut souvent révéler des vulnérabilités ou contourner des restrictions.

Requête/réponse d'origine :

GET /admin HTTP/1.1  
Host: redacted.com

HTTP/1.1 403 Forbidden  
Access Denied

Requête/réponse modifiée (contournement) :

GET /admin HTTP/1.1  
Host: google.com

HTTP/1.1 200 Ok  
Admin Panel Login Page(Source Code)

Supprimer l'en-tête Host

Excluez l'en-tête Host pour tester les réponses du serveur lorsque l'hôte n'est pas spécifié, ce qui peut parfois conduire à des comportements par défaut ou à des erreurs de configuration.

Requête/réponse d'origine :

GET /reach%2fsip.svc HTTP/1.1
Host: lyncdiscover.microsoft.com
User-Agent: curl/7.79.1
Accept: */*
Connection: close


HTTP/1.1 403 Forbidden
Cache-Control: no-cache
Content-Type: text/html
X-MS-Correlation-Id: fd2fe958-0683-4bb6-8ac6-36637ce86b81
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:25:58 GMT
Connection: close
Content-Length: 1233

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
            <title> 
                403 - Forbidden: Access is denied. 
            </title>
            <style type="text/css">
...

Requête/réponse modifiée (contournement) :

GET /reach%2fsip.svc HTTP/1.0
<deleted_host_header>


HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-MS-Correlation-Id: c989aa79-e7d7-4855-9937-67a51a548435
x-ms-client-request-id: c30a03fa-dce8-4a8c-b34f-c5f6a11d47d0
X-Content-Type-Options: nosniff
Date: Thu, 08 Sep 2022 07:45:40 GMT
Connection: close
Content-Length: 3058

Créer des requêtes avec différents user agents

Utilisez différents blocages propres à un user agent pour modifier les caractéristiques de la requête et contourner les blocages spécifiques à un user agent.

• Par exemple, utiliser les user agents de différents navigateurs ou appareils peut produire des réponses différentes.
• Une longue liste de User-Agents est disponible à ce lien.

Créer des requêtes avec différents en-têtes de proxy

Ajoutez des en-têtes de proxy pour voir si le comportement du serveur change selon l'adresse IP perçue du client.

• Par exemple, utilisez des en-têtes comme :

X-Originating-IP,
X-Forwarded-For,
X-Forwarded,
Forwarded-For,
X-Remote-IP,
X-Remote-Addr,
X-ProxyUser-Ip,
X-Original-URL,
Client-IP,
True-Client-IP,
Cluster-Client-IP

• Avec des valeurs telles que :

10.0.0.0 
10.0.0.1
127.0.0.1
127.0.0.1:443
127.0.0.1:80
172.16.0.0
localhost

Ajouter un en-tête de port

Ajoutez des numéros de port à l'en-tête X-Forwarded-Port pour tester si le serveur applique des règles propres à un port. - Exemple : - X-Forwarded-Port: 443 - X-Forwarded-Port: 80

Ajouter des en-têtes de schéma

Incluez des en-têtes propres au schéma pour modifier la requête, par exemple pour indiquer que la requête est en HTTP ou en HTTPS. - Exemple : - X-Forwarded-Proto: http - X-Forwarded-Proto: https

Changer la méthode HTTP

Passez d'une méthode à l'autre (GET, POST, PUT, DELETE, etc.) pour voir si les différentes méthodes sont traitées de façon incohérente.

Changer la casse de la méthode HTTP

Testez des variations comme GET et get pour voir si le serveur est sensible à la casse. - Par exemple, en utilisant get /admin HTTP/1.1.

Changer la méthode HTTP à l'aide d'un en-tête

Utilisez des en-têtes tels que X-HTTP-Method-Override pour contourner les restrictions de méthode. - Par exemple, en définissant X-HTTP-Method-Override: PUT dans une requête POST. - Autres méthodes : - X-Original-Method - X-Method-Override

Créer des requêtes avec des paramètres modifiés

Modifiez les paramètres existants de la requête pour tester différents scénarios d'entrée.

Requête/réponse d'origine :

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=9999&access=restricted

HTTP/1.1 403 Forbidden 
Content-Type: application/json 

{ 
    "error": "Access denied" 
}

Requête/réponse modifiée (contournement) :

POST /api/admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

id=1&access=granted

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Access granted",
    "data": {
        "id": 1,
        "role": "admin"
    }
}

Mise en garde :

Cette technique peut produire des faux positifs si la réponse du serveur dépend du contexte ou si les paramètres modifiés ne sont pas traités comme prévu. Assurez-vous que les modifications que vous effectuez sont pertinentes pour les contrôles d'accès ou les conditions précis que vous testez. Une mauvaise interprétation des réponses due à un comportement non standard du serveur peut conduire à des conclusions erronées sur la présence de vulnérabilités.

Incrémenter les valeurs des paramètres

Augmentez progressivement les valeurs des paramètres pour tester les erreurs de décalage d'une unité (off-by-one) ou les conditions aux limites. - Par exemple, id=1, id=2, id=3, etc.

Mise en garde :

Incrémenter les paramètres pour tester les conditions aux limites peut produire des faux positifs, surtout si l'application traite les paramètres de façon non standard ou comporte une logique de validation étendue. Assurez-vous que les résultats sont analysés au regard du comportement attendu et envisagez de tester une série de valeurs pour identifier avec précision les problèmes potentiels. Une mauvaise interprétation des réponses due à la conception de l'application ou à des contraintes de données peut conduire à des conclusions trompeuses.

Ajouter des paramètres

Introduisez des paramètres supplémentaires dans la requête pour voir si le serveur les traite de manière incorrecte.

• Par exemple, en ajoutant isAdmin=true.
• Autres exemples :

- ("isAdmin", "true")
- ("order", "desc")
- ("sort_by", "date")
- ("limit", "100")
- ("debug", "true")
- ("admin", "true")
- ("verbose", "true")
- ("user_id", "10")
- ("mode", "admin")
- ("user", "admin")
- ("role", "admin")

Supprimer des paramètres

Supprimez des paramètres pour tester le comportement par défaut ou vérifier si les paramètres obligatoires sont imposés. Par exemple, retirer un jeton de la requête.

Inverser l'ordre des paramètres

Modifier l'ordre des paramètres dans une requête peut parfois aider à contourner les erreurs 403 Forbidden si le serveur traite les paramètres dans un ordre précis ou applique une logique dépendante de l'ordre. Par exemple, si un serveur vérifie les paramètres selon une certaine séquence pour le contrôle d'accès ou la validation, inverser l'ordre des paramètres peut le tromper et lui faire accorder l'accès. Cette technique est particulièrement utile lorsque la logique backend du serveur suppose un ordre fixe des paramètres : modifier cet ordre peut révéler des vulnérabilités cachées.

Par exemple, en remplaçant id=1&name=John par name=John&id=1.

Ajouter des paramètres limites

Ajouter des paramètres aux cas limites peut aider à identifier des vulnérabilités en poussant la gestion des entrées du serveur dans ses retranchements. Des valeurs extrêmement grandes, des caractères spéciaux ou des formats d'entrée inattendus peuvent déclencher des comportements imprévus ou révéler des faiblesses. Cette technique permet de tester si le serveur valide ou assainit correctement les entrées, et s'il est sensible à des cas limites pouvant conduire au contournement de restrictions de sécurité, y compris les erreurs 403.

Par exemple, id=0 ou name=-99999999999999999999999999999.

Injection SQL sur les paramètres

Tentez des attaques par injection SQL pour rechercher des vulnérabilités.

Requête/réponse d'origine :

Requête/réponse modifiée (contournement) :

Paramètres vides

Utilisez des valeurs de paramètre vides pour voir comment le serveur gère les données manquantes.

• Par exemple, id=.

Inverser les valeurs

Inverser les valeurs des paramètres consiste à permuter ces valeurs pour tester si le serveur les traite différemment selon leur contenu. Cette technique permet de découvrir des vulnérabilités ou des incohérences dans le traitement des données.

Comment ça fonctionne

Certaines applications peuvent traiter les valeurs de paramètre d'une manière précise ou s'attendre à ce qu'elles respectent un format particulier. En inversant ou en altérant ces valeurs, vous pouvez tester si la validation des entrées ou les mécanismes de traitement de l'application sont robustes.

Exemples

• Valeurs numériques : remplacer « 1 » par « 0 » ou « 0 » par « 1 ».
• Valeurs booléennes : passer de « true » à « false » et de « false » à « true ».
• Valeurs de chaîne : remplacer « yes » par « no » et « no » par « yes », ou « Yes » par « No » et « No » par « Yes ».

Pollution de paramètres

La pollution de paramètres désigne la technique qui consiste à introduire des paramètres en double ou contradictoires dans des requêtes HTTP afin de perturber ou de manipuler la façon dont un serveur traite les entrées. Cela peut dérouter le serveur et conduire à un comportement imprévu ou exposer des vulnérabilités.

Voici comment cela fonctionne :

1. Paramètres en double : en incluant plusieurs fois le même paramètre avec des valeurs différentes, par exemple id=1&id=2, vous pouvez tester la façon dont le serveur gère une telle entrée. Les serveurs peuvent traiter ces doublons de plusieurs manières :
   • Première occurrence : certains serveurs ne considèrent que la première instance du paramètre et ignorent les suivantes.
   • Dernière occurrence : d'autres utilisent la dernière valeur fournie et écartent les précédentes.
   • Fusion : dans certains cas, les serveurs peuvent tenter de combiner ou de fusionner les paramètres en double, ce qui peut produire des résultats inattendus.
2. Gestion des conflits : les serveurs peuvent gérer différemment les paramètres contradictoires. Par exemple, si une requête contient sort=asc&sort=desc, la façon dont le serveur résout ce conflit peut révéler des incohérences ou des faiblesses.
3. Contournement des restrictions : la pollution de paramètres peut parfois contourner des restrictions de sécurité ou des contrôles de validation. Par exemple, un serveur peut appliquer des règles de validation strictes à un paramètre, qui sont contournées si plusieurs instances de ce paramètre sont introduites.

Changer la casse du chemin

Modifiez la casse des caractères dans le chemin pour tester la sensibilité à la casse. - Par exemple, en remplaçant /admin par /Admin.

Ajouter une extension au chemin

Ajoutez des extensions au chemin pour voir si différents types de fichiers sont traités différemment. - Par exemple, en remplaçant /admin par /admin.php.

Variations de chemin

Essayez différents encodages et variations de chemin : - /path(bloqué) → /%2e/path, /%252e/path. - Contournement Unicode : /%ef%bc%8fpath. - Variations de casse et barres obliques finales : /secret, /SECRET, /secret/, /secret/., //secret//, /./secret/.. - Caractères supplémentaires : ;/secret, /.;/secret, //;//secret.

Requête/réponse d'origine :

Requête/réponse modifiée (contournement) :

Changement de version d'API

Passez d'une version d'API à une autre pour tester des vulnérabilités propres à une version. - Par exemple, en remplaçant /v1/users par /v2/users.

Encoder en URL la première lettre

Encodez en URL le premier caractère du chemin pour tester une mauvaise gestion des caractères encodés. - Par exemple, en remplaçant /admin par /%61dmin.

Consulter la Wayback Machine

Utiliser la Wayback Machine peut être une approche stratégique dans les évaluations de sécurité pour retrouver des ressources autrefois accessibles et désormais restreintes. En interrogeant les instantanés historiques d'une URL cible, vous voyez à quoi ressemblait une page ou un point d'accès à différents moments. Cela peut être particulièrement utile pour :

1. Identifier d'anciennes URL : les archives historiques peuvent révéler des URL ou des chemins de ressources autrefois accessibles publiquement mais aujourd'hui restreints ou supprimés. Cela peut aider à découvrir des points d'accès obsolètes qui pourraient encore être vulnérables.
2. Découvrir des ressources cachées : des ressources telles que des répertoires, des fichiers ou des API qui étaient exposés dans des versions antérieures du site peuvent être dissimulées aujourd'hui. La Wayback Machine peut aider à identifier ces ressources, ce qui permet d'effectuer d'autres tests pour déterminer si elles restent accessibles dans certaines conditions.
3. Analyser les changements de contenu : examiner d'anciennes versions d'une page peut mettre en évidence des changements dans les contrôles d'accès ou la logique applicative. Cela peut donner des indications sur l'évolution de la posture de sécurité de l'application et sur l'introduction éventuelle de nouvelles vulnérabilités.

Par exemple, si une page qui renvoie aujourd'hui une erreur 403 Forbidden était accessible dans des instantanés antérieurs, la Wayback Machine peut montrer sa structure et son contenu passés. Ce contexte historique peut révéler des chemins d'accès ou des vulnérabilités potentiels qui ne sont plus évidents dans la version actuelle.

Changer de version de protocole

Lorsque vous testez différentes versions du protocole HTTP, comme HTTP/1.1, HTTP/1.0, HTTP/2.0 et HTTP/3.0, il est important de noter que tous les serveurs et toutes les piles ne prennent pas en charge toutes les versions. Certains serveurs peuvent avoir une prise en charge limitée ou incohérente des protocoles plus récents, ce qui peut affecter le traitement des requêtes. Par exemple, un serveur peut traiter les requêtes HTTP/2.0 différemment de celles en HTTP/1.1, ou ne pas prendre en charge HTTP/3.0 du tout. Cette incohérence peut parfois conduire à un comportement inattendu, permettant potentiellement à certaines requêtes de contourner des restrictions ou de révéler des vulnérabilités qui ne seraient pas apparentes avec la version de protocole par défaut. Tester plusieurs versions peut donc être utile, mais gardez à l'esprit les limites de prise en charge de la pile, qui peuvent influencer les résultats.

Exemple : passer de HTTP/1.1 à HTTP/1.0

Requête/réponse d'origine :

Requête/réponse modifiée (contournement) :

Conclusion

En recourant à des techniques telles que le fuzzing des en-têtes de requête, l'expérimentation des méthodes HTTP, la modification des paramètres de requête et l'altération des chemins de requête, nous pouvons découvrir des vulnérabilités potentielles cachées derrière des erreurs 403. De plus, consulter la Wayback Machine pour retrouver du contenu archivé et tester différentes versions du protocole HTTP peut révéler des failles de sécurité négligées. Ensemble, ces méthodes aident à contourner les erreurs 403 et à identifier des faiblesses critiques dans les applications web.