Le Guide API ReST | Marmicode
  • Le Guide API ReST par Marmicode
  • API ReST
    • L'Ecosystème Moderne
    • Le Besoin
    • Re.S.T. : REpresentational State Transfer
    • Les 5 règles et ½ de l’API ReST
    • Le Modèle de Maturité de Richardson
    • H.A.T.E.O.A.S. & Resource Linking
    • Avis Subjectif sur H.A.T.E.O.A.S. et le Semantic Web
    • ReST over HTTP
    • HTTP & CRUD
    • ReSTful donc Stateless
    • Pragmatisme, Idéologie et ReSTafarians
  • Conventions & Bonnes Pratiques
    • Nommage
    • Base URL
    • Media Type
    • Versioning
    • Propriété “id”
    • Polymorphisme
    • Datetime
    • Ressource d'Association
    • Pourquoi Appliquer ces Bonnes Pratiques
    • Zalando ReSTful API Guidelines
  • Les Outils
    • Swagger
    • OpenAPI Visual Editors
    • IDE Plugins
    • Postman
    • Insomnia
    • Fake & Sandbox
    • JSON Generator
    • Pact
  • Sécurité des APIs ReST
    • OWASP Top 10
    • Authentification et Session Management
    • Autorisation et Gestion des Permissions
    • Validation, Canonicalization, Escaping & Sanitization
    • Cookies are EVIL
    • C.O.R.S.
    • C.S.R.F.
    • C.S.R.F. & Media Type
    • C.S.R.F. Mitigation
    • C.S.R.F. & "Resource Linking"
    • J.O.S.E.
      • J.W.K.
      • J.W.S.
      • J.W.E.
    • J.W.T.
      • Description et Fonctionnement de JWT
      • Usages et Avantages
      • Utilisation de JWT pour l’Authentification
      • JWT, Authentification, Sessions et Risques Sécurité
      • Recommandations JWT
    • OAuth 2
      • OAuth 2 Roles
      • OAuth 2 Abstract Flow
      • OAuth 2 Authorization Code Flow
      • OAuth 2 Implicit Flow
      • OAuth 2 Resource Owner Password Credentials Flow
      • OAuth 2 Client Credentials
      • OAuth 2 Registration
      • OAuth 2 Risques & Recommandations
      • OAuth 2 Substitution Attack
    • OpenID Connect
      • Terminologie
      • Quoi de Neuf ?
      • OpenID Connect Flows
      • Que Faire ?
  • Autres Spécifications
    • JSON API
    • H.A.L.
    • JSON LD
    • Les Autres Initiatives
    • So What?
  • Quelques Liens & Ressources
  • Stay Tuned
    • 📝Blog
    • 🐦Twitter
    • 📬Newsletter
Propulsé par GitBook
Sur cette page
  1. Sécurité des APIs ReST

C.S.R.F.

Cross-Site Request Forgery (ou X.S.R.F.)

PrécédentC.O.R.S.SuivantC.S.R.F. & Media Type

Dernière mise à jour il y a 6 ans

Cross-Site Request Forgery est une attaque in-the-browser dont le scénario est le suivant :

  1. Un utilisateur (victime) doit être authentifié sur l’application vulnérable.

  2. L'attaquant doit réussir à faire visiter une application qu’il contrôle (entièrement ou partiellement) par la victime.

  3. Lors de la visite de la victime, l'attaquant déclenche une opération sur l’application vulnérable en utilisant implicitement les credentials de la victime. On suppose qu’une requête de type GET ne peut pas déclencher d’opération sensible car autrement il suffirait de rediriger l’utilisateur vers l’URL en question.

  4. Si les règles C.O.R.S. sont désactivées par l’un des moyens décrits dans le chapitre C.O.R.S., l'attaquant peut simplement déclencher une requête POST de son choix à destination de l’application vulnérable en utilisant les credentials de la victime.

Si la whitelist d'origins n’effectue pas une vérification rigoureuse, l'attaquant pourrait éventuellement contrôler le domaine http de l’application vulnérable en ciblant le domaine https de l’application vulnérable.

Cross-Site Request Forgery