Avec la situation actuelle, l'organisation des conférences a été bousculée car des rassemblements de cette ampleur ne seront pas autorisés avant un bon moment que ce soit en France ou en Allemagne. Malgré tout les sessions restent maintenues !
L’article 2020, conférences et COVID-19 est apparu en premier sur CH Studio - Stéphane Hulard / PHP, Laravel, Symfony, Sécurité, API.
Une question simple et complexe à la fois. VSCode est mon éditeur de cœur depuis quelques années maintenant, il est configuré aux petits oignons et connecté au bout de mes doigts. Le partage et la liberté ! Cependant, ma naïveté m’a fait penser, à tort, que tout était beau dans le meilleur des mondes. Microsoft […]
L’article Pourquoi migrer de VSCode à VSCodium ? est apparu en premier sur CH Studio - Stéphane Hulard / PHP, Laravel, Symfony, Sécurité, API.
dump(). Cet article est le troisième d’une série consacrée aux failles de sécurité dans le web, après un premier sur l’injection SQL et un deuxième consacré au cross-site scripting (XSS).
Les attaques de type cross-site request forgery sont un peu plus malicieuses que celles décrites dans les précédents articles.
Dans ce qu’on avait vu, qu’il s’agisse d’injection SQL ou de XSS, l’idée était globalement de faire entre des données corrompues dans un système, pour le pervertir de l’intérieur. C’est moche, mais quelque part c’est ce qu’on attend d’un hacker.
Les solutions à appliquer étaient presque simples : ne pas faire confiance, filtrer les données entrantes, et échapper les données sortantes.
Si je dis que le CSRF est plus malicieux, c’est parce que ce type d’attaque ne porte pas du tout sur le système visé. Aucune donnée pernicieuse n’est envoyée sur votre serveur, aucun code Javascript vérolé ne sera exécuté sur vos pages web.
Les attaques CSRF profitent de failles dans les systèmes d’authentification, et y ajoutent un peu de social engineering pour faire faire à vos utilisateurs des actions qu’ils ne souhaitent pas exécuter.
Prenons un exemple simple. Imaginons que vous ayez créé un site web sur lequel vous publiez des articles (pour l’exemple on imaginera que vous ayez tout développé vous-même plutôt que d’utiliser un CMS existant). Vous avez dû créer une petite interface d’administration, qui permet de créer des articles et de les effacer. Par-dessus, vous avez développé une couche d’authentification, pour restreindre l’accès aux seuls utilisateurs autorisés.
Votre système d’authentification repose peut-être sur la validation d’un couple identifiant/mot de passe. Lorsqu’un utilisateur s’est identifié correctement, vous déposez un cookie sur son navigateur. Ainsi, à chaque fois qu’il va sur une page d’administration, ou qu’il effectue une action à partir de l’interface d’administration, vous vérifiez le cookie avant d’autoriser l’affichage de la page ou l’exécution de l’action.
De cette manière, pour effacer l’article dont l’identifiant est le numéro 18, un administrateur cliquera sur le lien “Supprimer” correspondant. Son navigateur le conduira alors sur l’adresse “/admin/effacer/18”. Le serveur recevra en même temps le cookie servant à identifier l’utilisateur.
Si le cookie est valide, le serveur effacera l’article, puis redirigera l’utilisateur vers la page “/admin” pour le ramener à l’accueil de l’interface d’administration.
Si ce n’est pas déjà fait, je vous invite à lire le premier article de cette série. J’y explique le contexte dans lequel j’écris ces articles, et je parle des failles par injection SQL.
Le cross-site scripting (ou XSS pour faire court) est une faille de sécurité qui arrive assez classiquement lorsque des données saisies par un utilisateur peuvent se retrouver telles quelles dans une page web vue par une autre personne. Si la première personne est mal intentionnée, elle peut ainsi exécuter du code sur le navigateur de la seconde ; c’est la porte ouverte à la récupération d’informations personnelles.
L’usage le plus courant est la récupération des cookies du visiteur, ce qui permet ensuite de se connecter au site en se faisant passer pour cette personne. Cela peut être dramatique sur un site bancaire (détournement d’argent) ou administratif (vol d’identité) ; mais une usurpation d’identité sur un réseau social peut être tout aussi gênante.
Prenons l’exemple d’un site proposant à ses visiteurs de laisser des commentaires. Pour cela, un simple formulaire avec un champ texte fait l’affaire. Le texte saisi par un utilisateur est enregistré en base de données, et lorsqu’un autre internaute consulte la page, les commentaires sont lus depuis la base de données pour être ajoutés dans le corps de la page. Jusque-là tout va bien.
Mais si le commentaire contient du code Javascript, et qu’il se retrouve directement dans la page, il sera exécuté par les navigateurs des visiteurs.
Normalement, si vous avez fait un minimum de développement web, vous devriez vous dire « Bien sûr, mais personne ne fait ça ! ».
On est d’accord. De manière générale, tout ce qui vient de l’extérieur − saisi par un être humain dans un formulaire, ou bien reçu lors d’un appel à un webservice externe − doit être traité de manière particulière.
La fondation OWASP (Open Web Application Security Project) a écrit une “cheatsheet” sur la prévention des failles XSS, qui donne 14 règles à suivre.
Envoyez un email avec l'URL du site et du flux à planetephpfr AT afup POINT org
Gestion