~ read.

Astuces de sécurité avec Symfony[FR]

Hello, World!
Ahh, la sécurité, enfin nous allons parler d’un truc que tout le monde déteste !

Les patrons d’abord, car la sécurité coûte cher mais ne rapporte rien. En plus, se faire péter sa base en 2017 c’est tendance.
Les équipes marketing ensuite, car on rajoute des contraintes qui peuvent abaisser le taux de conversion des utilisateurs.
Les équipes tout court, car elles passent leur temps à passer de Facebook à 2FA sur leur mobile, c’est long et fatigant.
Les utilisateurs aussi, car ils ne peuvent pas librement mettre le nom de leur chien ou leur date de naissance comme mot de passe.
Les ops, qui doivent mettre à l'échelle les performances d’une belle infrastructure microservice avec du handshake X.509 de partout.
Les développeurs, nous, bien entendu, car de toute façon nous n'avons pas le temps ! Notre framework fait le boulot pour nous ! Et puis, qui oserait donc s’attaquer à une application que même le marketing n’arrive pas à afficher en 10ième page de Google ?
Alors voilà, nous sommes à 10 jours de Noël, tes projets sont bouclés, tu n’as plus envie de bosser avant les vacances, et tu es quand même là. Pourquoi ne pas faire une petite revue sur les tendances et les erreurs classiques de sécurité dans tes applications Web, histoire de passer le temps de manière constructive ?

C’est parti ! ✌️

Du nouveau dans l’OWASP Top 10 !
Et oui, l’OWASP Top 10 a été mis à jour cette année, quoi de neuf ?

TOP 10 OWASP 2013 TOP 10 OWASP 2017
A1-Injection A1-Injection
A2-Broken Authentication and Session Management A2-Broken Authentication and Session Management
A3-Cross-Site Scripting (XSS) A3-Cross-Site Scripting (XSS)
A4-Insecure Direct Object References A4-Broken Access Control
A5-Security Misconfiguration A5-Security Misconfiguration
A6-Sensitive Data Exposure A6-Sensitive Data Exposure
A7-Missing Function Level Access Control A7-Insufficient Attack Protection
A8-Cross-Site Request Forgery (CSRF) A8-Cross-Site Request Forgery (CSRF)
A9-Using Components with Known Vulnerabilities A9-Using Components with Known Vulnerabilities
A10-Unvalidated Redirects and Forwards A10-Underprotected APIs
A4 et A7 de 2013 deviennent A4 de 2017

Tout d’abord, dans les risques de 2013, A4 (j’accède à /resource/{id} sans que {id} m’appartienne) et A7 (je valide mon formulaire en JavaScript mais je le revalide pas côté serveur) ont été fusionnés dans A4 de 2017.

A7 de 2017 est désormais « Insufficient Attack Protection »

L’OWASP pointe du doigt notre laxisme au niveau du traitement automatique des attaques. Afin d’être complètement efficace, il nous faut automatiquement détecter, surveiller, enregistrer et répondre.

Un exemple classique est une attaque sur le formulaire de connexion : on peut détecter une attaque par le nombre de soumissions par adresse IP et par minute, surveiller facilement sur un graphique les connexions réussies vs échouées, et bloquer une IP si elle dépasse une certaine limite. Cela éviterait les attarques par force brute, dictionnaire, réutilisation de mot de passe, et j’en passe. Sauf si le hacker est très motivé, auquel cas il viendra avec un grand nombre d’IPs et il faudra trouver d’autres solutions.

A10 de 2017 devient « Underprotected APIs »

Nos applications utilisent de plus en plus des APIs pour accéder au backend, cela permet aux interfaces Web et mobile de récupérer les informations en un même point qui centralise le code métier. L’OWASP attire notre attention sur le manque de protections sur celles-ci.

C’est assez simple à comprendre, nous avons moins l’occasion d’auditer nos APIs :

On utilise un SDK bien adapté pour y accéder, mais quel comportement ont ces dernières quand on les utilise mal ou directement ?
On ne voit pas facilement les données qui transitent entre l’application et l’API. Sont-elles toutes nécessaires et sont-elles toutes exposables ?
Pour déboguer plus facilement, vous pouvez mettre votre client derrière un proxy tel que Charles. Cet outil permet de consulter les requêtes qui transitent, de les modifier et de les rejouer en restant déconnecté. C'est très instructif !

A10 de 2013 disparait

Les failles « open redirects », c'est-à-dire le fait de rediriger l’utilisateur vers une URL arbitraire sans la valider, ne sont plus dans le top 10 des risques. Ce n'est cependant pas une raison pour renvoyer une RedirectResponse sur le referrer ♥️.

Astuces de sécurité par le code
Maintenant, faisons un petit tour dans vos applications, à grands coups de grep, afin de vérifier si elles contiennent quelques erreurs de base ou au moins des choses suspectes. Je vous préviens, il s’agit souvent de cas issus d’un besoin bien tordu… Par conséquent, la solution proposée peut-être aussi alambiquée. Soyons pragmatique, et faisons quelque chose de sécurisé.

XSS
Le principe de l’attaque consiste à injecter du code dans les pages afin de le rendre exécutable par le navigateur. Par exemple, si l'on parvient à placer un tag comme celui ci-dessous dans la page :

❌ Utiliser {{ myVariable }} vous protège car Twig échappe automatiquement le contenu de la variable.
Twig choisit la stratégie d’échappement sur la base de l’extension du fichier. Par exemple, l'extension de fichier .html.twig utilisera la stratégie html. Par conséquent, l'instruction Twig {{ myVariable }} est identique aux instructions {{ myVariable | e }} et {{ myVariable | e('html') }}.
Dans un fichier .html.twig, si vous devez afficher le contenu d'une variable Twig à l'intérieur d'un tag