Insecure Authorization Restriction
Restriction d'Autorisation Non Sécurisée
Description
La restriction d'autorisation non sécurisée (Insecure Authorization Restriction) fait référence aux faiblesses des restrictions côté serveur qui peuvent être exploitées par des techniques de manipulation des requêtes HTTP. Cette vulnérabilité permet aux attaquants de contourner les contrôles d'accès, conduisant à un accès non autorisé aux ressources, à une élévation des privilèges et permettant aux utilisateurs non autorisés de récupérer, créer, mettre à jour ou supprimer des données sensibles.
Cibler les restrictions d'autorisation non sécurisées sur un serveur web, par exemple, impliquerait ces techniques :
- Fuzzing de la méthode de requête HTTP : Tester des méthodes HTTP invalides, malformées ou inattendues sur le serveur.
- Fuzzing du chemin de la requête HTTP : Manipuler le chemin de la requête HTTP en le déformant, en y ajoutant ou en y soustrayant des éléments.
- Fuzzing des paramètres de requête HTTP : Ajouter, supprimer ou modifier les paramètres de requête d'origine.
- Fuzzing des en-têtes de requête HTTP : Ajouter des en-têtes connus, supprimer des en-têtes ou ajouter des en-têtes de proxy.
Toutes ces techniques ciblent des défauts, des vulnérabilités ou des erreurs dans la logique d'un serveur.
import requests
response = requests.get("http://www.some-url.com/unauthorized_path")
'''if we have some unauthorized path that gets us a 403 code,
we can try something like adding a query parameter like "debug=true" to see if we can
trick the server by exploiting some mistake.'''
response = requests.get("http://www.some-url.com/unauthorized_path?debug=true")
'''Might get us the resource we want''
Recommandation
Les organisations doivent implémenter des contrôles d'accès appropriés et appliquer une validation stricte des requêtes HTTP pour atténuer le risque de vulnérabilités HTTP liées à la restriction d'autorisation non sécurisée. Cela implique de disposer d'une logique côté serveur robuste pour gérer les règles sur les méthodes, les en-têtes, les paramètres de requête et les chemins HTTP reçus.
Voici quelques recommandations :
- Limiter les méthodes HTTP : Restreindre les méthodes HTTP pouvant accéder à chacune de vos vues/ressources.
- Nettoyer les paramètres de requête : Nettoyer les paramètres de requête de chaque requête et s'assurer que seul un ensemble limité de paramètres peut affecter la logique du serveur.
- Limiter les en-têtes : Restreindre les en-têtes pouvant affecter votre code. Utilisez des règles strictes sur les combinaisons d'en-têtes/méthodes qui peuvent apporter des modifications côté serveur, et assurez-vous que votre logique ne repose pas sur des valeurs d'en-tête qui peuvent être facilement trouvées sur Internet (comme le User-Agent de Google).
- Analyse de chemin robuste : Implémenter une analyse de chemin robuste avec des règles strictes et rejeter les requêtes qui ne sont pas conformes à vos standards.
python
# n'autoriser que les méthodes GET et POST pour cette route
@app.route('/limiting_method_usage', methods=['GET', 'POST'])
def limiting_method_usage():
if request.method == 'GET':
return jsonify({"message": "This is a GET request"})
elif request.method == 'POST':
data = request.json
return jsonify({"message": "This is a POST request", "data": data})
# utiliser uniquement les en-têtes attendus
@app.route('/limiting_header_values')
def limiting_header_values():
expected_header = request.headers.get('Expected-Header')
### logique en fonction de l'en-tête attendu
Liens
Normes
- OWASP_ASVS_L1:
- V4_1_1
- V4_1_2
- V4_1_3
- V4_1_5
- V5_1_1
- V5_1_2
- V5_1_3
- V5_1_4
- V5_2_2
- OWASP_ASVS_L2:
- V4_1_1
- V4_1_2
- V4_1_3
- V4_1_5
- V5_1_1
- V5_1_2
- V5_1_3
- V5_1_4
- V5_2_2
- OWASP_ASVS_L3:
- V4_1_1
- V4_1_2
- V4_1_3
- V4_1_5
- V5_1_1
- V5_1_2
- V5_1_3
- V5_1_4
- V5_2_2
- PCI_STANDARDS:
- REQ_2_2
- HIPAA_CONTROLS:
- SECURITY221
- SECURITY212
- SECURITY213