Il n'y a aucune différence entre un site web dont on contrôle le contenu et un site web dont on laisse les visiteurs poser des contenus. Considérer des données comme sur et n'y appliquer aucun traitement (ne serait-ce que pour éviter les bogues liés au parasitage du format de sortie) est une erreur grave.
Le fournisseur de flux est une donnée externe qui doit être filtrée. Si tu affiches les contenus provenant de sources externes que tu ne contrôle pas, tu t'exposes aux joies du javascript qui va venir prendre le contrôle du navigateur.
Je n'ai pas besoin de donner d'exemple. L'ensemble des appels à header, l'ensemble des formulaires sont des portes ouvertes pour les attaques.
Pour être plus concret, ce genre de construction est problématique :
Dans ce cas, urlencode devrait suffire. Tu as 50 appels à header pour des redirections diverses. Plutôt que de toujours construire manuellement, tu devrais faire quelques fonctions utilitaires. Par exemple :
<?phpfunctionhttp_redirect($url){header(sprintf('Location: %s',$url));}functionhttp_url($base,$path,$params,$secure=false){$base=urlencode($base);$path=urlencode($path);$searchpart=array();// Je ne prends pas en compte les paramètres à valeur multipleforeach($paramsas$name=>$value)$searchpart[]=sprintf('%s=%s',urlencode($name),urlencode($value));$searchpart=implode('&',$searchpart);returnsprintf('%s://%s%s%s',$secure?'https':'http',$base,$path,'?'.$searchpart);}http_redirect(http_url('example.com','/search',array('q'=>'Ceci est fou!'));
Ce n'est pas parce qu'il y a de moins en moins de personnes qui ne mettent plus de capotes que tu en fais autant. Du moins j'espère pour toi. Pour la sécurité c'est pareil. Quand je travaillais en support technique pour un hébergeur, mon plaisir quotidien était d'envoyer au client le message qui lui disait qu'il avait été détourné à cause d'un script mal fagoté, que les admin sys avaient dû suspendre.
Les requêtes POST ne protègent absolument pas d'une attaque par CSRF. Il est possible de faire exécuter une requête POST par une requête AJAX sur un autre site visité dans le même navigateur, ou encore depuis un script que tu auras toi-même inclus via un flux RSS compromis.
D'ailleurs, la protection contre les CSRF permet également de supprimer le bogue du double-post.
[^] # Re: De la sécurité
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche zenCancan, un lecteur web de flux RSS. Évalué à 3.
Il n'y a aucune différence entre un site web dont on contrôle le contenu et un site web dont on laisse les visiteurs poser des contenus. Considérer des données comme sur et n'y appliquer aucun traitement (ne serait-ce que pour éviter les bogues liés au parasitage du format de sortie) est une erreur grave.
Le fournisseur de flux est une donnée externe qui doit être filtrée. Si tu affiches les contenus provenant de sources externes que tu ne contrôle pas, tu t'exposes aux joies du javascript qui va venir prendre le contrôle du navigateur.
Je n'ai pas besoin de donner d'exemple. L'ensemble des appels à header, l'ensemble des formulaires sont des portes ouvertes pour les attaques.
Pour être plus concret, ce genre de construction est problématique :
Dans ce cas, urlencode devrait suffire. Tu as 50 appels à header pour des redirections diverses. Plutôt que de toujours construire manuellement, tu devrais faire quelques fonctions utilitaires. Par exemple :Ce n'est pas parce qu'il y a de moins en moins de personnes qui ne mettent plus de capotes que tu en fais autant. Du moins j'espère pour toi. Pour la sécurité c'est pareil. Quand je travaillais en support technique pour un hébergeur, mon plaisir quotidien était d'envoyer au client le message qui lui disait qu'il avait été détourné à cause d'un script mal fagoté, que les admin sys avaient dû suspendre. Les requêtes POST ne protègent absolument pas d'une attaque par CSRF. Il est possible de faire exécuter une requête POST par une requête AJAX sur un autre site visité dans le même navigateur, ou encore depuis un script que tu auras toi-même inclus via un flux RSS compromis. D'ailleurs, la protection contre les CSRF permet également de supprimer le bogue du double-post.