Est-il correct d'avoir une couche de validation avant la couche de contrôle d'accès

24

Je crée une application Web structurée API et dans cette application, nous avons différentes couches qui font leur propre travail.

La première couche est la couche de validation qui valide les entrées de l'utilisateur et si elle passe la validation, nous la déplaçons vers la deuxième couche (qui est la couche de contrôle d'accès ) sinon, retournons le message d'erreur

La deuxième couche est le contrôle d'accès qui vérifie si l'utilisateur est autorisé à effectuer la tâche qu'il souhaite effectuer.Si l'utilisateur a la permission, il déplace la demande vers la couche suivante, sinon renvoie un message d'erreur

La troisième couche est la couche contrôleur où nous avons la logique d'application

Ma question est la suivante: est-ce correct d'avoir une couche de validation avant le contrôle d'accès? Que se passe-t-il si l'utilisateur essaie d'effectuer une tâche à laquelle l'utilisateur n'a pas l'autorisation et que nous renvoyons un message d'erreur de validation? L'utilisateur enverrait des demandes à un point de terminaison et parlerait avec la couche de validation et une fois la validation réussie, il verrait le messageYou can't access this!

Cela me semble étrange, est-ce que c'est bien comme ça ou quelles pourraient être mes autres options dans l'infrastructure?

validation web-api access-control

— Muhammad
source

10

Il convient également de mentionner que les validations doivent souvent atteindre la base de données pour faire leur travail, ou un magasin de fichiers. Si vous faites cela avant de rechercher des violations de contrôle d'accès, vous autorisez essentiellement les attaquants à DDoS votre base de données ou système de fichiers en lançant des quantités massives de trafic à cette URL particulière.

— Greg Burghardt

Dans mon cas, il en va de même pour le middleware de contrôle d'accès, il vérifie une ressource et voit si le type de ressource est accessible par l'utilisateur, s'il est accessible, j'autorise l'accès sinon

— Muhammad

C'est vrai. Pendant un DDoS, cette couche atteindra toujours votre magasin de données. En exécutant cette couche en premier, vous n'atteindrez pas votre magasin de données pour les validations ET le contrôle d'accès - vous le frapperez simplement pour le contrôle d'accès. Il réduit la taille du tsunami, mais ne l'empêche pas de toucher la plage. Cela vous donne, à vous ou à votre équipe de serveurs, une chance de vous battre pour répondre à une attaque avant que l'ensemble du système ne s'embourbe.

— Greg Burghardt

5

D'un point de vue pratique, le contrôle d'accès devrait de toute façon précéder la validation - comment allez-vous valider l'exactitude de la demande d'un utilisateur s'il ne peut pas accéder à la demande en premier lieu?

— Zibbobz

La validation @Zibbobz est simple comme vérifier si l'utilisateur envoie un schéma correct, comme le paramètre qui devrait être entier est entier ou autre

— Muhammad

57

Cela dépend si la connaissance de la validité d'une entrée pour une tâche que vous n'êtes pas autorisé à faire est une fuite de sécurité. Si c'est le cas, vous devriez vraiment le faire dans l'autre sens.

La seule réponse sûre à un utilisateur non autorisé est "accès refusé". Si parfois la réponse est «mauvaise demande» et parfois «accès refusé», vous envoyez des informations à un utilisateur non autorisé.

Par exemple, vous pouvez vérifier la validation de la tâche "supprimer le document" que le document nommé existe. Quelqu'un sans autorisation serait en mesure de discerner si quelque chose existe en tentant de le supprimer et en comparant l'erreur qu'il reçoit en retour. Un attaquant particulièrement déterminé pourrait énumérer tous les noms de documents (sous une certaine longueur), pour voir lesquels existent.

— Caleth
source

7

+1, absolument. Si vos données sont personnellement identifiables ou sensibles de toute autre manière, les implications en matière de sécurité sont beaucoup, beaucoup plus graves que les implications d'utilisabilité.

— Kilian Foth

4

@caleth en fait, il ne vous permettrait pas de savoir si un certain document est dans le système ou non, ce type d'informations ne sera donné que lorsque vous atteindrez la couche contrôleur. La validation vérifie simplement le schéma, il n'accède pas à la base de données - seul le contrôle d'accès et des couches plus profondes font l'accès à la base de données. De plus, la couche de contrôle d'accès ne vous montre que les mêmes choses lorsqu'une ressource existe ou non. La seule chose compromettante est le schéma que je pense si ça va ou pas

— Muhammad

@Caleth Pourriez-vous développer votre dernier commentaire? Je ne vois pas comment c'est le cas compte tenu des commentaires des PO. Il semble en tout cas que les seules informations renvoyées soient des informations non privilégiées si le schéma est publiquement documenté.

— Rotem

11

@Rotem Il est essentiellement impossible de déterminer à l'avance les informations dont un attaquant pourrait bénéficier. Ce n'est pas parce que vous n'avez pas trouvé un moyen d'apprendre quelque chose que vous ne devriez pas savoir qu'il n'y en a pas. A titre d'exemple extrême, il n'y aurait pas une vulnérabilité maintenant , mais dans le futur que quelqu'un pourrait ajouter un chèque à la couche de validation qui fait l' information fuite parce qu'ils ne savaient pas qu'il n'a pas été protégé.

— Kamil Drakari

4

@KamilDrakari ce n'est pas un exemple extrême, c'est un exemple parfaitement raisonnable. Autrement dit - si vous effectuez une validation avant le contrôle d'accès, chaque fois qu'un développeur souhaite ajouter une étape de validation, il doit décider si cette validation expose quelque chose de sensible. La chance que chaque développeur reçoive cet appel semble minuscule.

— mfrankli

24

Eh bien, il existe plusieurs types de validation:

Vérification de la santé de base bon marché, qui vérifie que la demande n'est pas manifestement malformée.

Ceci est généralement au moins partiellement dupliqué côté client, pour éviter les allers-retours inutiles.

Quoi qu'il en soit, cela devrait être fait avant le contrôle d'accès pour rendre les choses plus faciles et moins sujettes aux erreurs, car cela ne risque pas de fuite d'informations.
Validation plus coûteuse qui ne dépend toujours d'aucune donnée d'application protégée.

S'il y a une telle validation supplémentaire, cela peut être après le contrôle d'accès non pas pour éviter les fuites de données, mais pour empêcher les attaques DOS.
Parfois, la simple exécution de la demande effectue une partie de cette validation implicitement à un coût réduit ou nul, elle peut donc être omise ici.

Si toute la validation de la première étape est dupliquée, il peut également être judicieux de dupliquer des parties de ce côté client.
Validation supplémentaire en fonction des données d'application protégées.

Le faire avant le contrôle d'accès risque évidemment de provoquer des fuites d'informations. Ainsi, faites d'abord le contrôle d'accès.

— Déduplicateur
source

3

Il serait idéal d'effectuer un contrôle d'accès à un point d'application des stratégies dans votre infrastructure avant même d'atteindre votre API. Un ensemble de validation statique de base (Ex: OpenAPI) serait le premier, suivi d'une validation métier plus approfondie. Même une validation statique pourrait avoir un impact sur la disponibilité de vos ex app- ODER attaques.

— felickz

@felickz: Oui, les attaques DOS sont une raison valable de reporter la validation jusqu'à après l'autorisation. C'est un acte d'équilibre. Quoi qu'il en soit, je partage mon premier point pour bien en tenir compte.

— Déduplicateur

Une validation coûteuse avant le contrôle d'accès risque également de fuir des informations en raison d'attaques temporelles. Si votre système prend plus ou moins de temps en fonction de la ressource, l'attaquant peut déduire des aspects de la ressource demandée.

— Lie Ryan

@LieRyan: C'est la raison pour laquelle toute la validation qui est potentiellement avant le contrôle d'accès ne dépend pas du tout des données d'application protégées.

— Déduplicateur

13

Il doit y avoir une validation avant le contrôle d'accès. Supposons que l'API de SO ait un point de terminaison "modifier la réponse", alors si l'utilisateur peut modifier une réponse particulière peut dépendre de la réponse (en dessous d'une certaine réputation, un utilisateur ne peut modifier que ses propres réponses). Le paramètre "ID de réponse" bien formé doit donc être vérifié avant que la couche de contrôle d'accès n'entre en jeu; peut-être aussi que la réponse existe.

OTOH, comme le mentionnent Caleth et Greg, mettre une validation plus approfondie avant le contrôle d'accès est un risque potentiel pour la sécurité.

Les règles strictes sont donc

Vous ne devez divulguer aucune information par le biais d'une validation que l'utilisateur n'est pas censé être en mesure de découvrir autrement.
Vous devez valider les données avant que le contrôle d'accès puisse les utiliser dans la mesure où le contrôle d'accès en a besoin.

Le respect de ces deux règles peut signifier que vous devez avoir une validation avant et après le contrôle d'accès.

— Sebastian Redl
source

3

Telle est la réponse réaliste. Si sa validation de structure de données d'entrée est simple et directe, il ne doit y avoir aucun scrupule à la mettre en premier. Il protège même la couche de contrôle d'accès des entrées / paquets spécialement conçus. La validation qui implique réellement une fuite d'informations sécurisées ou une supposition, doit être placée après les contrôles d'accès.

— SD

Cela suppose que les réponses sont publiques. J'ose dire que beaucoup d'API ne vous montreront même pas les données sans authentification.

— TomTom

6

En plus de la frustration possible de recevoir un «accès refusé» après avoir validé la saisie; gardez également à l'esprit que la couche Validation , à moins qu'elle ne soit très simple, peut toujours avoir besoin des informations du contrôleur . En gardant cela à l'esprit, je pense que positionner la validation derrière le contrôle d'accès , plus près du contrôleur est plus logique.

— simurg
source

2

Cela dépend de ce que vous entendez par couche de validation - si vous entendez simplement par là vérifier la syntaxe de la demande, c'est sûr et quelque chose que vous devez faire de toute façon. Si votre «validation» utilise des informations auxquelles un utilisateur non privilégié n'a pas accès, ce n'est plus sûr.

Vous devriez certainement avoir un vérificateur d'esprit avant d'essayer de contrôler l'accès, mais vous devez vous assurer de communiquer très clairement à tous les responsables (actuels et futurs) que cette partie ne doit pas utiliser d'informations privilégiées; Ces vérifications doivent être effectuées dans une étape de validation distincte après l' authentification.

En tant que contrôle d'intégrité pour le vérificateur d'intégrité, il ne devrait en fait pas avoir de dépendances de code sur une partie de votre code plus bas dans le pipeline et devrait être séparable dans son propre package qui devrait être publiquement publiable sans aucun problème (autre que les éventuels problèmes juridiques) . Si vous ne pouvez pas faire cela, votre «couche de validation» en fait trop (ou votre base de code est un gâchis).

— Cubique
source

1

Non, ce n'est pas ok.

Si vous avez un bogue dans votre couche de validation, il peut contourner la couche de sécurité.

C'est une erreur courante de considérer la sécurité comme faisant partie des exigences commerciales. "seuls les utilisateurs ayant le rôle ventes, devraient pouvoir voir les chiffres trimestriels" semble être une règle commerciale.

Mais si vous voulez être sécurisé, vous devez lire une telle règle comme "seuls les utilisateurs dans le rôle de vente, devraient pouvoir exécuter du code sur ce point de terminaison" Vous devez vous assurer que votre serveur retourne toujours "accès refusé" avant d'arriver à tout type de code que vous avez écrit ou fichiers sur le serveur.

— Ewan
source