Pourquoi quelqu'un devrait-il bloquer toutes les méthodes autres que GET et POST dans une application RESTful?
TL; DR:
Existe-t-il une raison valable d'exiger d'un fournisseur de logiciels qu'il cesse d'utiliser les méthodes HTTP PUT et DELETE dans une application Web et n'utilise que GET et POST? L'application utilise des cadres pour mettre sur liste blanche les chemins et méthodes de demande autorisés.
En d'autres termes, existe-t-il une différence du point de vue de la sécurité pour permettre la suppression d'un enregistrement via les méthodes DELETE ou POST sans changer le code et les contrôles de sécurité qu'il contient?
Question complète
Notre client a configuré son instance Tomcat avec les éléments suivants, conformément à sa norme d'entreprise:
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>CONNECT</http-method>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
<auth-constraint />
</security-constraint>
Ceci, parmi les Http Header Security Filter configuration, a fait briser notre application.
Notre application offre les mêmes fonctionnalités HTTP Header security dans Spring Security. De plus, notre application est RESTful, nous utilisons donc largement les méthodes PUT et DELETE pour le téléchargement de fichiers. Dans les versions futures, nous prévoyons également d'utiliser des Websockets (mais à partir d'une recherche, ils n'utilisent pas CONNECT, qui est pour le proxy).
Notre client a déclaré qu'il devra lever une exception de politique en production afin de supprimer les lignes incriminées de la configuration de Tomcat et de faire fonctionner l'application.
La politique d'exception de sécurité est déclenchée lorsque les applications du fournisseur ne respectent pas les exigences de sécurité de manière à ce que 1) la résolution du problème ne puisse pas être effectuée dans les délais et 2) aucune vulnérabilité évidente ne soit trouvée. Les politiques d'exception nécessitent l'approbation de la haute direction.
Cependant, les exceptions à la politique de sécurité exigent que notre client engage le fournisseur dans les 6 mois à "résoudre le problème de sécurité". Dans les 6 mois, le fournisseur doit fournir les coûts et les délais pour respecter la politique de sécurité.
Cela signifie qu'ils me reviendront me demander un devis pour que l'application fonctionne avec le filtrage de méthode HTTP activé et le filtre de sécurité d'en-tête HTTP.
Je ne veux pas leur faire une faveur et changer tous les appels Ajax des modèles RESTful en GET/POST uniquement, pas même pour de l'argent si possible. Je voudrais plutôt prouver que leur implémentation de sécurité est non seulement incompatible, mais redondante, en ce qui concerne les implémentations de sécurité au sein de l'application.
Si nous établissons un précédent en rendant service à ce client avec les demandes PUT et DELETE, nous devrons faire face à des demandes telles que "être compatible avec mon cadre/politique/environnement" d'une large base de clients (toutes les banques et institutions financières). À l'avenir, cela pourrait se retourner contre notre gestion des coûts.
La question est, comme dans le TLDR, l'utilisation de méthodes PUT et DELETE seules, quelles que soient les fonctionnalités de sécurité de l'application, peut-elle poser un risque pour la sécurité?
S'il est prouvé que le seul verbe HTTP ne pose pas de risque pour la sécurité, je pourrai lever une politique d'exception permanente et confronter le personnel informatique avec une argumentation solide.
Éditer
Je travaille dans une usine de logiciels qui déploie la même instance de produit auprès d'un grand nombre de clients et de notre cloud. Nous utilisons pleinement tous les outils que nous avons à bord, y compris le modèle REST. Nous prévoyons d'utiliser HATEOAS, WebSockets, des téléchargements de fichiers pouvant être repris et tout ce que la technologie Web peut nous offrir pour offrir de meilleurs résultats. expérience. Oui, cela ressemble à une ligne de marketing. Quoi qu'il en soit, la sécurité est toujours une préoccupation dans nos produits.
Je soupçonne qu'il s'agit d'un cas où quelqu'un applique avec zèle des "meilleures pratiques" qu'il ne comprend pas.
Attaque de sabotage de verbe HTTP
La raison pour laquelle cette meilleure pratique existe est à cause de l'attaque de sabotage de verbe HTTP. De cet article :
De nombreux mécanismes d'authentification de serveur Web utilisent l'authentification verbale et les contrôles d'accès. Par exemple, un administrateur peut configurer un serveur Web pour autoriser un accès illimité à une page Web à l'aide de requêtes HTTP GET, mais restreindre les POST aux administrateurs uniquement. Cependant, de nombreuses implémentations de mécanismes de sécurité verbaux appliquent les règles de sécurité de manière non sécurisée, permettant l'accès à des ressources restreintes en utilisant des méthodes HTTP alternatives (telles que HEAD) ou même des chaînes de caractères arbitraires.
Donc, quelqu'un a décidé que parce que certaines applications sont mal écrites, toutes les applications devraient être interdites d'accepter les verbes HTTP autres que GET ou POST, parce que ... vous savez ... marmonner marmonner SÉCURITÉ !!
Mon avis (éventuellement incomplet/incorrect, veuillez poster des commentaires) :
- Le contenu HTML/CSS/js pur doit être limité à GET et POST car ce sont les seuls verbes autorisés dans la spécification HTML .
- Les API (AJAX, REST) doivent être autorisées à utiliser tout verbe de la spécification HTTP , qui dit:
- Sachez que même si votre couche d'application applique correctement les contrôles d'accès basés sur les verbes, il se peut que votre serveur Web frontal ne le fasse pas.Vous devez donc à vos clients de faire des tests de sécurité et assurez-vous que votre application applique une authentification appropriée et des contrôles d'accès sur tous les verbes que vous supportez. Je recommande de suivre le guide de test OWASP .
Il semble que votre application fonctionne correctement et que votre client ait une politique de sécurité trop zélée.
En passant, HEAD est un exemple intéressant; certains scanners de sécurité semblent se plaindre si votre application répond aux demandes HEAD, car certaines applications renverront des en-têtes valides sans en invoquant les vérifications d’authentification appropriées. Cependant, la plupart des applications correctement conçues traiteront un GET complet, puis ne renverront que les en-têtes, y compris le bon content-length:. Donc, pour les applications utilisant des frameworks modernes, il n'y a probablement aucun moyen de contourner la logique d'authentification sur votre contrôleur GET. Faites quelques tests rapides! (Merci @ usr-local-ΕΨΗΕΛΩΝ de l'avoir signalé dans les commentaires. Voir ce post Stack Overflow pour plus de détails sur la façon dont Spring MVC gère cela.)
On peut dire que DELETE et PUT sont plus sûrs que GET/POST car ils ne peuvent pas être utilisés dans les attaques CSRF. On peut également soutenir que DELETE et PUT devraient être protégés contre CSRF de toute façon, car il est mauvais de baser la sécurité de votre application sur l'hypothèse que chaque implémentation de navigateur respecte les normes. Mais il n'est pas rare que les applications n'aient pas cette protection, c'est peut-être la pensée derrière l'interdiction, bien que j'atteigne un peu ici.
Ou peut-être ont-ils simplement désactivé toutes les méthodes dont ils n'avaient pas besoin (ce qui est une bonne pratique) et qui, au fil du temps, sont passées d'une règle par défaut à une règle non violable.
L'API distante peut être conçue de cette façon, donc aucune autre méthode http sauf GET ou POST ne sont pas utilisées, par exemple:
DELETE /item/123
peut être:
GET /delete/item/123
Quoi qu'il en soit, vous devrez lire une spécification d'API et comprendre comment ajouter ou supprimer des éléments, il est donc 50/50 que l'un est meilleur qu'un autre. Je préfère n'avoir que GET et POST.
OWASP recommande de verrouiller les routes inutilisées de la manière décrite dans la question.
Restreindre les méthodes HTTP
- Appliquer une liste blanche des méthodes HTTP autorisées, par exemple GET, POST, PUT.
- Rejeter toutes les demandes ne correspondant pas à la liste blanche avec le code de réponse HTTP 405 Méthode non autorisée.
- Assurez-vous que l'appelant est autorisé à utiliser la méthode HTTP entrante sur la collection de ressources, l'action et l'enregistrement
Je recommande d'engager rapidement votre équipe juridique d'entreprise afin d'avoir quelqu'un qui se concentre sur les aspects commerciaux des discussions à venir.
Dans le cadre de la politique d'exception de sécurité, le personnel de notre client est obligé d'engager le vendeur à "résoudre le problème de sécurité" dans les 6 mois.
Cela signifie qu'ils me reviendront me demandant de faire fonctionner l'application avec le filtrage de méthode HTTP activé et le filtre de sécurité d'en-tête HTTP.
Je ne veux pas leur rendre service et changer tous les appels Ajax des modèles RESTful en GET/POST uniquement, pas même pour de l'argent.
Votre client gère évidemment sa propre bureaucratie, appliquant une politique rigide. Vous croyez avoir trois voies possibles:
- Les convaincre de changer de politique.
- Effectuez le changement indésirable.
- Risque de les perdre en tant que client.
Même si cela vous semble être une décision logique et technique, la modification des politiques nécessite une bonne dose de querelles politiques. La personne avec qui vous traitez de l'autre côté de la discussion peut ou non avoir la qualité requise dans son entreprise pour réussir à faire une telle demande. Il ne voudra peut-être pas perdre son temps à combattre sa propre bureaucratie pour le changement. Sa vie pourrait être considérablement plus facile s'il change de fournisseur et utilise le produit de quelqu'un d'autre qui respecte déjà ses politiques. Pire pour vous, la vie de son patron sera certainement plus facile s'il change de fournisseur.
Il serait irresponsable de votre part de penser que vous pouvez réussir à les amener à modifier leur politique sans planifier sérieusement les autres résultats.
Les bons clients sont assez difficiles à trouver. Vous devez à votre entreprise d'évaluer soigneusement le risque d'en perdre un.