juillet
2011
Un article de Philippe Vialatte
Une question qui se pose régulièrement dans des revues de code en web est celle de savoir a partir de quand il faut taper, ou au moins se fâcher tout rouge.
Après pas mal d’itérations, voici la liste de ce qui, de mon avis, ne devrait pas se trouver dans le code d’un développeur Web en 2011 (pas que cela aurait du s’y trouver en 2010):
Les entrées utilisateur non encodées
Les dernières versions du framework ont rendu beaucoup plus simple (comprendre un seul caractère: http://philippe.developpez.com/articles/nouveautes-asp-net-4/#LVIII-H) l’encodage du text, et la bibliothèque anti-xss peut maintenant être facilement utilisée dans un projet
Des paramètres de requête non parsés/non contraints
Utiliser TryParse sur tous les composants de la query string ne coute rien, mais permets d’éviter pas mal de mauvaises surprises en prod.
De la même façon, vérifier la longueur de ces valeurs, dans le cas d’une chaine, ne mange pas de pain
Du SQL construit a la main sans paramètres
Vu le cout de l’utilisation des paramètres, laisser la porte ouverte a une injection SQL, ca mérite un coup de pied quelque part. A noter, l’article suivant date de 2008: http://johannblais.developpez.com/tutoriel/dotnet/bonnes-pratiques-acces-donnees/
A noter, c’est évidemment non exhaustif, mais c’est juste le petit quelque chose qui va faire sonner les oreilles de quelqu’un si je tombe dessus dans une revue 
Et vous, y a t’il une erreur grossière qui vous fait bondir ?
4 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
Les personnes qui laissent trainer des user/mdp dans leurs programmes.
Et tout autre truc en « dur » (nom de fichier, machine, …).
[…] title= »Le minimum absolu de la sécurité (vu du coté du web) » href= »http://blog.developpez.com/philippe/p10136/net/asp-net/le-minimum-absolu-de-la-securite-vu-du-c/ » target= »_blank »>Le minimum absolu de la sé […]
> Reste plus qu’à faire un DROP DATABASE…
Pas mal, pas mal.
)
Ceci dit, la, on a une défaillance en chaine, pas juste du code :
– le dev qui a laissé un trou pour permettre le drop database (a moins que tu ne parles d’autre chose, je pense que tu parles de l’exploitation d’une injection SQL)
– l’archi qui n’a pas vérifié le niveau de droits nécessaires (parce que c’est aussi son boulot, la sécurité et la gouvernance)
– la prod qui n’a pas donné son veto (biscotte le DBA qui laisse créer en prod un compte qui a les droits d’admins, je le connais pas
On va arriver sur la seconde passe de verifs, toutes les bêtises qui peuvent se retrouver dans la conf
« Et vous, y a t’il une erreur grossière qui vous fait bondir ? »
Donner les droits administrateur au processus ASP .NET pour l’accès complet au SGBD… Reste plus qu’à faire un DROP DATABASE…