"vous proposez quoi sur le terrain technique ?" C'est bien simple: on resout les bugs au cas par cas. Je sais que vu de loin, comme ca, on prefere croire a des solutions miracles qui elimineraient d'un coup toute un classe de vulnerabilites. Mais dans la realite, pour la grande majorite des bugs, il n'y a pas de telle solution miracle. Chaque bug doit etre compris et repare separement.
Je ne suis pas du tout d'accord. Je ne suis pas un expert en sécurité mais je vois de temps en temps passer des annonces de failles de sécurité, et dans l'extrême majorité des cas on peut les classer dans des "grandes familles" de bugs qui pourraient être tout à fait éliminées par une architecture plus robuste.
L'exemple typique, ce sont les failles de buffer overflow permises par l'interface de manipulation de chaînes en C. C'est un cas typique, il y a eu des milliers de failles de ce genre et il en reste encore qu'on n'a pas détectées. "Résoudre au cas par cas" c'est la moindre des choses, mais utiliser d'autres outils pour manipuler les chaînes c'est encore mieux, et d'ailleurs le logiciel écrit dans des langages de plus haut niveau qui font de la vérification des accès aux chaînes/tableaux n'ont quasiment jamais ces failles. On a donc bien un changement d'architecture qui éradique complètement un problème de sécurité.
C'est encore la même chose pour les failles d'injection SQL, qui sont liées à une interface rétrograde choisie à la frontière entre le langage serveur et la base de donnée.
Les exemples 1 ou 3 dans ton billet sont typiquement des choses qui pourraient être corrigées si l'architecture était plus solide. Ce sont des exemples du fait que sur une page web, les principaux (au sens de la littérature de sécurité, les agents ayant des intérêts différents) ne sont pas bien identifiés. Avec une architecture ou les principaux sont identifiés, et les éléments de la page sont compartimentés selon le principal auquel ils appartiennent, le DoS ne serait pas un problème (il suffit de limiter les ressources par principal, et de laisser l'utilisateur décider en cas d'abus) et les attaques cross-domaines seraient beaucoup plus difficiles. Il y a des gens qui travaillent sur ça, par exemple le projet Google Caja que j'ai déjà cité.
Je ne dis pas que c'est un problème facile à résoudre, ce n'est pas du tout le cas, surtout avec l'architecture (assez faible) actuelle (des navigateurs, mais surtout des langages de contenu et de script) et les contraintes de standardisation et de compatibilité très fortes. Mais ce sont bien des erreurs au niveau architectural que l'on pourrait régler en très grande partie avec une meilleure organisation. Il y a des gens qui travaillent sur ça et qui font des choses intéressantes, qui ont des impacts sur l'industrie.
[^] # Re: Oui, mais
Posté par gasche . En réponse à la dépêche Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing ». Évalué à 10. Dernière modification le 22 janvier 2012 à 15:54.
Je ne suis pas du tout d'accord. Je ne suis pas un expert en sécurité mais je vois de temps en temps passer des annonces de failles de sécurité, et dans l'extrême majorité des cas on peut les classer dans des "grandes familles" de bugs qui pourraient être tout à fait éliminées par une architecture plus robuste.
L'exemple typique, ce sont les failles de buffer overflow permises par l'interface de manipulation de chaînes en C. C'est un cas typique, il y a eu des milliers de failles de ce genre et il en reste encore qu'on n'a pas détectées. "Résoudre au cas par cas" c'est la moindre des choses, mais utiliser d'autres outils pour manipuler les chaînes c'est encore mieux, et d'ailleurs le logiciel écrit dans des langages de plus haut niveau qui font de la vérification des accès aux chaînes/tableaux n'ont quasiment jamais ces failles. On a donc bien un changement d'architecture qui éradique complètement un problème de sécurité.
C'est encore la même chose pour les failles d'injection SQL, qui sont liées à une interface rétrograde choisie à la frontière entre le langage serveur et la base de donnée.
Les exemples 1 ou 3 dans ton billet sont typiquement des choses qui pourraient être corrigées si l'architecture était plus solide. Ce sont des exemples du fait que sur une page web, les principaux (au sens de la littérature de sécurité, les agents ayant des intérêts différents) ne sont pas bien identifiés. Avec une architecture ou les principaux sont identifiés, et les éléments de la page sont compartimentés selon le principal auquel ils appartiennent, le DoS ne serait pas un problème (il suffit de limiter les ressources par principal, et de laisser l'utilisateur décider en cas d'abus) et les attaques cross-domaines seraient beaucoup plus difficiles. Il y a des gens qui travaillent sur ça, par exemple le projet Google Caja que j'ai déjà cité.
Je ne dis pas que c'est un problème facile à résoudre, ce n'est pas du tout le cas, surtout avec l'architecture (assez faible) actuelle (des navigateurs, mais surtout des langages de contenu et de script) et les contraintes de standardisation et de compatibilité très fortes. Mais ce sont bien des erreurs au niveau architectural que l'on pourrait régler en très grande partie avec une meilleure organisation. Il y a des gens qui travaillent sur ça et qui font des choses intéressantes, qui ont des impacts sur l'industrie.