Bien sûr que non, je conseille de se concentrer sur l'ensemble du produit:
- fonctionnalité
- utilisabilité
- sécurité
- etc...
Et si ça salit le code, ton design est à revoir period.
Je préconise de se poser des questions de fond sur les bugs, plutôt qu'un rush sur une faille potentielle de sécurité: Un parseur correct ne doit pas produire ce genre de chose, les corriger à la va vite sans tenir compte de ton design posera des problèmes de régression (toute corrections de bug pose des problèmes de régression entre, dans les meilleurs cas, autour de 5%, autrement dit sur 20 correction 1 introduit un nouveau bug).
En fait, je pense qu'on est d'ailleurs, ce que j'aime pas en fait, c'est l'attitude: on tape le mot "sécurité" et ça devient hyper critique... c'est idiot: c'est un point important, qui n'est pas à négliger, mais ce n'est pas tout... pour l'utilisateur final, qu'il perde son doc à cause d'un virus ou d'un plantage ne change rien: il a perdu son doc, perdu du temps, de l'argent, etc... (y'a un américain pour le moment qui parle pas mal de sécurité nationale :p)
Enfin si tu regardes la pratique, 99% des attaques réussies, réussissent "grâce" (à cause...) à une erreur humaine... et non a une faille du produit utilisé (mes chiffres date un peu, et ça ne tient compte que du monde de l'entreprise). Le social engineering reste la méthode la plus efficace (et crois moi ça fonctionne bien...). Si tu suis ce raisonnement, il serait ptêt plus rentable (niveau taux d'attaque réussies) de coder une fonctionnalité d'assistance à l'utilisateur et de formation que colmater un bug. (ce qui ne veut pas dire qu'il ne faut pas les corriger, au contraire, mais ne pas se faire d'illusion sur le fait que ça empêchera toute attaque).
[^] # Re: Sécurité?
Posté par tene . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 1.
- fonctionnalité
- utilisabilité
- sécurité
- etc...
Et si ça salit le code, ton design est à revoir period.
Je préconise de se poser des questions de fond sur les bugs, plutôt qu'un rush sur une faille potentielle de sécurité: Un parseur correct ne doit pas produire ce genre de chose, les corriger à la va vite sans tenir compte de ton design posera des problèmes de régression (toute corrections de bug pose des problèmes de régression entre, dans les meilleurs cas, autour de 5%, autrement dit sur 20 correction 1 introduit un nouveau bug).
En fait, je pense qu'on est d'ailleurs, ce que j'aime pas en fait, c'est l'attitude: on tape le mot "sécurité" et ça devient hyper critique... c'est idiot: c'est un point important, qui n'est pas à négliger, mais ce n'est pas tout... pour l'utilisateur final, qu'il perde son doc à cause d'un virus ou d'un plantage ne change rien: il a perdu son doc, perdu du temps, de l'argent, etc... (y'a un américain pour le moment qui parle pas mal de sécurité nationale :p)
Enfin si tu regardes la pratique, 99% des attaques réussies, réussissent "grâce" (à cause...) à une erreur humaine... et non a une faille du produit utilisé (mes chiffres date un peu, et ça ne tient compte que du monde de l'entreprise). Le social engineering reste la méthode la plus efficace (et crois moi ça fonctionne bien...). Si tu suis ce raisonnement, il serait ptêt plus rentable (niveau taux d'attaque réussies) de coder une fonctionnalité d'assistance à l'utilisateur et de formation que colmater un bug. (ce qui ne veut pas dire qu'il ne faut pas les corriger, au contraire, mais ne pas se faire d'illusion sur le fait que ça empêchera toute attaque).
Enfin bref...