Je pense utiliser Jouer pour un projet à grande échelle, alors, quelqu'un a-t-il testé le cadre de Play pour le Top 10 de l'OWASP ? Y a-t-il des problèmes de sécurité que vous connaissez dans le cadre de Play ?
Réponses
Trop de publicités?
Sur le Top 10 de l'OWASP et Play (quelques infos) aquí ):
-
A1 : Injection
Utilise JPA et échappe les chaînes de caractères par défaut.
-
A2 : Cross-Site Scripting (XSS)
Depuis la version 1.0.1, le moteur de modèles de Play échappe automatiquement les chaînes de caractères.
-
A3 : Authentification et gestion de session cassées
Le jeu est sans statut, aucune session n'est impliquée. Les cookies sont protégés par cryptographie. Le stockage sécurisé des données dans la base de données (mots de passe) via le hachage dépend de l'utilisateur, pas du framework.
-
A4 : Références directes à un objet non sécurisées
Encore une fois, cela dépend du développeur qui vérifie l'accès aux ressources autorisées, pas tellement du cadre.
-
A5 : Falsification de requête intersite (CSRF)
Les demandes POST permettent d'utiliser des jetons d'authenticité pour éviter cela. Bien sûr, cela dépend de l'utilisation correcte de GET/POST par le développeur.
-
A6 : Mauvaise configuration de la sécurité
Le processus de signalement des erreurs par défaut semble sûr en production (aucune fuite de trace de pile). Le seul problème serait l'entrée "catch all" dans les routes, mais elle devrait être commentée en mode production.
-
A7 : Stockage cryptographique non sécurisé
Le développeur est responsable du cryptage des informations sensibles dans la base de données.
-
A8 : Absence de restriction de l'accès aux URLs
Le développeur doit mettre en place une restriction de sécurité (via @Before, comme dans le tutoriel) pour interdire l'accès aux pages interdites.
-
A9 : Protection insuffisante de la couche de transport
Play prend en charge SSL
-
A10 : Redirections et transferts non validés
La redirection du jeu se fait par 302, et non par des chaînes codées en dur, ce qui devrait empêcher cela.
TL;DR : Dans les parties où le framework peut faire tout le travail, Play le fait. Dans les parties où le développeur doit faire tout le travail, eh bien, le développeur doit faire tout le travail. Les parties qui nécessitent 50% de chaque, Play donne ses 50%.
Disons-le ainsi : il n'y a aucune raison pour que vous considériez Play comme moins sûr que n'importe quel autre framework Java. Dans de nombreux cas, vous pouvez le considérer comme plus sûr. Et comme Play est un framework facile à développer, sans état et REST, vous avez moins de chances de vous tromper.
kravietz
Points
908
A propos de l'A3, vous devez être prudent. Play a deux types de variables de session. L'une est session() que est signé numériquement, et l'autre est flash() qui est no signé. Voir aussi les deux d'entre eux sont stockés dans des cookies côté client ce qui peut poser des problèmes de confidentialité si vous décidez d'y stocker des données sensibles.
En ce qui concerne le point A7 (cryptographie), notez que Play propose une fonction pratique Crypto mais son chiffrement utilise le mode ECB, ce qui ouvre à nouveau une un tout nouveau groupe de problèmes potentiels .
