M\u00e9thode utilis\u00e9e par les serveurs<\/h2>\n\n\n\n\n- GET<\/li>\n\n\n\n
- POST<\/li>\n\n\n\n
- PUT<\/li>\n\n\n\n
- PATCH<\/li>\n\n\n\n
- DELETE<\/li>\n<\/ul>\n\n\n\n
Implication possible d’un changement de m\u00e9thode HTTP<\/h2>\n\n\n\n
Lorsqu’une application PHP utilise une API REST pour communiquer avec d’autres services, le choix de la m\u00e9thode HTTP peut avoir une incidence sur la s\u00e9curit\u00e9 de l’application. Par exemple, l’utilisation de la m\u00e9thode GET pour les op\u00e9rations de modification de donn\u00e9es expose l’application \u00e0 des attaques telles que l’injection de commande SQL ou le vol de donn\u00e9es.<\/p>\n\n\n\n
Voici un exemple de code pour illustrer cela. Supposons que nous avons une application PHP qui communique avec une API REST pour obtenir les informations de profil d’un utilisateur \u00e0 partir de son identifiant:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.searchevolution.com\/security\/wp-content\/uploads\/2023\/04\/get_code.png\")
<\/figure>\n\n\n\nDans cet exemple, nous utilisons la m\u00e9thode GET pour r\u00e9cup\u00e9rer les informations de profil de l’utilisateur \u00e0 partir de l’API REST. Cependant, cette m\u00e9thode est vuln\u00e9rable aux attaques de type injection de commande SQL ou cross-site scripting (XSS), car l’identifiant de l’utilisateur est r\u00e9cup\u00e9r\u00e9 directement \u00e0 partir de la requ\u00eate GET et peut \u00eatre modifi\u00e9 par un attaquant malveillant.<\/p>\n\n\n\n
Pour rendre cette requ\u00eate plus s\u00fbre, nous pourrions utiliser la m\u00e9thode POST ou PUT pour envoyer l’identifiant de l’utilisateur dans le corps de la requ\u00eate plut\u00f4t que dans l’URL:<\/p>\n\n\n\n![\"\"](\"https:\/\/www.searchevolution.com\/security\/wp-content\/uploads\/2023\/04\/post_code.png\")
<\/figure>\n\n\n\nDans cet exemple, nous utilisons la m\u00e9thode POST pour envoyer l’identifiant de l’utilisateur dans le corps de la requ\u00eate, ce qui permet de valider et de filtrer les donn\u00e9es avant de les envoyer \u00e0 l’API REST, ce qui renforce la s\u00e9curit\u00e9 de l’application.<\/p>\n\n\n\n
Vous pouvez donc essayer de modifier comment la requ\u00eate est envoy\u00e9e au serveur. Possiblement qu’un code diff\u00e9rent sera ex\u00e9cut\u00e9 (possibilit\u00e9 d’une faille)<\/strong><\/p>\n\n\n\nTypes de m\u00e9dias<\/h2>\n\n\n\n
Les diff\u00e9rents types de m\u00e9dias. Les requ\u00eates ou les r\u00e9sultats sont form\u00e9s de cette fa\u00e7on. JSON<\/a> et XML<\/a> sont les plus utilis\u00e9s<\/p>\n\n\n\n\n- Application\/json<\/li>\n\n\n\n
- Application\/xml<\/li>\n<\/ul>\n\n\n\n
Vous pouvez essayer de modifier le fromat des donn\u00e9es envoy\u00e9 au serveur. (param\u00e8tre format dans une requ\u00eate get, ent\u00eate http Content-Type)<\/p>\n\n\n\n
Les codes de r\u00e9sultat retourn\u00e9s par un serveur.<\/h2>\n\n\n\n
Vous pouvez avoir la liste compl\u00e8te des codes HTTP<\/a> ici<\/p>\n\n\n\n\n- 2XX<\/li>\n\n\n\n
- 3XX<\/li>\n\n\n\n
- 4XX<\/li>\n\n\n\n
- 5XX<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
M\u00e9thode par vuln\u00e9rabilit\u00e9 XXE (Application\/xml)<\/h2>\n\n\n\n
voir mon article XXE – Si XML est utilis\u00e9 par le serveur. D\u00e9ficience dans le traitement du XML<\/a> <\/p>\n\n\n\nInsecure Direct Object References (IDOR) dans un API rest.<\/h2>\n\n\n\n
La vuln\u00e9rabilit\u00e9 IDOR (Insecure Direct Object Reference) est une faille de s\u00e9curit\u00e9 courante qui se produit lorsque les identifiants d’objet, tels que les identifiants de base de donn\u00e9es, sont expos\u00e9s dans les entr\u00e9es utilisateur et ne sont pas correctement v\u00e9rifi\u00e9s ou filtr\u00e9s par l’application Web.<\/p>\n\n\n\n
L’exploitation de cette vuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant de contourner les contr\u00f4les d’acc\u00e8s et d’acc\u00e9der \u00e0 des ressources ou des informations qui ne lui sont pas autoris\u00e9es. Par exemple, si un identifiant de compte utilisateur est expos\u00e9 dans une URL et qu’il n’est pas v\u00e9rifi\u00e9, un attaquant peut acc\u00e9der aux informations du compte de l’utilisateur sans autorisation.<\/p>\n\n\n\n
Pour pr\u00e9venir l’exploitation de cette vuln\u00e9rabilit\u00e9, il est recommand\u00e9 de limiter l’acc\u00e8s direct aux objets de donn\u00e9es, en utilisant des contr\u00f4les d’acc\u00e8s stricts et en utilisant des m\u00e9thodes d’authentification et d’autorisation solides. Les entr\u00e9es utilisateur doivent \u00e9galement \u00eatre valid\u00e9es et filtr\u00e9es correctement pour \u00e9viter toute injection de code malveillant.<\/p>\n\n\n\n
Les d\u00e9veloppeurs peuvent \u00e9galement utiliser des techniques telles que l’obscurcissement des identifiants d’objet et l’utilisation de jetons d’autorisation pour renforcer la s\u00e9curit\u00e9 de leur application Web.<\/p>\n\n\n\n
En conclusion, la vuln\u00e9rabilit\u00e9 IDOR est une faille de s\u00e9curit\u00e9 courante qui peut permettre \u00e0 un attaquant d’acc\u00e9der \u00e0 des ressources ou des informations non autoris\u00e9es. Pour se prot\u00e9ger contre cette vuln\u00e9rabilit\u00e9, il est recommand\u00e9 de limiter l’acc\u00e8s direct aux objets de donn\u00e9es, de mettre en place des contr\u00f4les d’acc\u00e8s solides et de valider correctement les entr\u00e9es utilisateur.<\/p>\n\n\n\n
Exemple de vuln\u00e9rabilit\u00e9 IDOR dans un API rest<\/h2>\n\n\n\n
Supposons qu’une application Web permet aux utilisateurs d’acc\u00e9der \u00e0 des informations confidentielles en saisissant un identifiant de compte utilisateur. Le lien pour acc\u00e9der \u00e0 ces informations est de la forme suivante :<\/p>\n\n\n\n
Implication possible d’un changement de m\u00e9thode HTTP<\/h2>\n\n\n\n
Lorsqu’une application PHP utilise une API REST pour communiquer avec d’autres services, le choix de la m\u00e9thode HTTP peut avoir une incidence sur la s\u00e9curit\u00e9 de l’application. Par exemple, l’utilisation de la m\u00e9thode GET pour les op\u00e9rations de modification de donn\u00e9es expose l’application \u00e0 des attaques telles que l’injection de commande SQL ou le vol de donn\u00e9es.<\/p>\n\n\n\n
Voici un exemple de code pour illustrer cela. Supposons que nous avons une application PHP qui communique avec une API REST pour obtenir les informations de profil d’un utilisateur \u00e0 partir de son identifiant:<\/p>\n\n\n\n Dans cet exemple, nous utilisons la m\u00e9thode GET pour r\u00e9cup\u00e9rer les informations de profil de l’utilisateur \u00e0 partir de l’API REST. Cependant, cette m\u00e9thode est vuln\u00e9rable aux attaques de type injection de commande SQL ou cross-site scripting (XSS), car l’identifiant de l’utilisateur est r\u00e9cup\u00e9r\u00e9 directement \u00e0 partir de la requ\u00eate GET et peut \u00eatre modifi\u00e9 par un attaquant malveillant.<\/p>\n\n\n\n Pour rendre cette requ\u00eate plus s\u00fbre, nous pourrions utiliser la m\u00e9thode POST ou PUT pour envoyer l’identifiant de l’utilisateur dans le corps de la requ\u00eate plut\u00f4t que dans l’URL:<\/p>\n\n\n\n Dans cet exemple, nous utilisons la m\u00e9thode POST pour envoyer l’identifiant de l’utilisateur dans le corps de la requ\u00eate, ce qui permet de valider et de filtrer les donn\u00e9es avant de les envoyer \u00e0 l’API REST, ce qui renforce la s\u00e9curit\u00e9 de l’application.<\/p>\n\n\n\n Vous pouvez donc essayer de modifier comment la requ\u00eate est envoy\u00e9e au serveur. Possiblement qu’un code diff\u00e9rent sera ex\u00e9cut\u00e9 (possibilit\u00e9 d’une faille)<\/strong><\/p>\n\n\n\n Les diff\u00e9rents types de m\u00e9dias. Les requ\u00eates ou les r\u00e9sultats sont form\u00e9s de cette fa\u00e7on. JSON<\/a> et XML<\/a> sont les plus utilis\u00e9s<\/p>\n\n\n\n Vous pouvez essayer de modifier le fromat des donn\u00e9es envoy\u00e9 au serveur. (param\u00e8tre format dans une requ\u00eate get, ent\u00eate http Content-Type)<\/p>\n\n\n\n Vous pouvez avoir la liste compl\u00e8te des codes HTTP<\/a> ici<\/p>\n\n\n\n <\/p>\n\n\n\n voir mon article XXE – Si XML est utilis\u00e9 par le serveur. D\u00e9ficience dans le traitement du XML<\/a> <\/p>\n\n\n\n La vuln\u00e9rabilit\u00e9 IDOR (Insecure Direct Object Reference) est une faille de s\u00e9curit\u00e9 courante qui se produit lorsque les identifiants d’objet, tels que les identifiants de base de donn\u00e9es, sont expos\u00e9s dans les entr\u00e9es utilisateur et ne sont pas correctement v\u00e9rifi\u00e9s ou filtr\u00e9s par l’application Web.<\/p>\n\n\n\n L’exploitation de cette vuln\u00e9rabilit\u00e9 permet \u00e0 un attaquant de contourner les contr\u00f4les d’acc\u00e8s et d’acc\u00e9der \u00e0 des ressources ou des informations qui ne lui sont pas autoris\u00e9es. Par exemple, si un identifiant de compte utilisateur est expos\u00e9 dans une URL et qu’il n’est pas v\u00e9rifi\u00e9, un attaquant peut acc\u00e9der aux informations du compte de l’utilisateur sans autorisation.<\/p>\n\n\n\n Pour pr\u00e9venir l’exploitation de cette vuln\u00e9rabilit\u00e9, il est recommand\u00e9 de limiter l’acc\u00e8s direct aux objets de donn\u00e9es, en utilisant des contr\u00f4les d’acc\u00e8s stricts et en utilisant des m\u00e9thodes d’authentification et d’autorisation solides. Les entr\u00e9es utilisateur doivent \u00e9galement \u00eatre valid\u00e9es et filtr\u00e9es correctement pour \u00e9viter toute injection de code malveillant.<\/p>\n\n\n\n Les d\u00e9veloppeurs peuvent \u00e9galement utiliser des techniques telles que l’obscurcissement des identifiants d’objet et l’utilisation de jetons d’autorisation pour renforcer la s\u00e9curit\u00e9 de leur application Web.<\/p>\n\n\n\n En conclusion, la vuln\u00e9rabilit\u00e9 IDOR est une faille de s\u00e9curit\u00e9 courante qui peut permettre \u00e0 un attaquant d’acc\u00e9der \u00e0 des ressources ou des informations non autoris\u00e9es. Pour se prot\u00e9ger contre cette vuln\u00e9rabilit\u00e9, il est recommand\u00e9 de limiter l’acc\u00e8s direct aux objets de donn\u00e9es, de mettre en place des contr\u00f4les d’acc\u00e8s solides et de valider correctement les entr\u00e9es utilisateur.<\/p>\n\n\n\n Supposons qu’une application Web permet aux utilisateurs d’acc\u00e9der \u00e0 des informations confidentielles en saisissant un identifiant de compte utilisateur. Le lien pour acc\u00e9der \u00e0 ces informations est de la forme suivante :<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\nTypes de m\u00e9dias<\/h2>\n\n\n\n
\n
Les codes de r\u00e9sultat retourn\u00e9s par un serveur.<\/h2>\n\n\n\n
\n
M\u00e9thode par vuln\u00e9rabilit\u00e9 XXE (Application\/xml)<\/h2>\n\n\n\n
Insecure Direct Object References (IDOR) dans un API rest.<\/h2>\n\n\n\n
Exemple de vuln\u00e9rabilit\u00e9 IDOR dans un API rest<\/h2>\n\n\n\n