«Sécurité des applications Web est à son pire: nous avons presque toujours trouver des défauts, ce qui montre que les développeurs n'ont pas pris en compte les aspects de sécurité. Et cela mai proviennent de sociétés de logiciels de classe mondiale (HSC) »
«Depuis beaucoup trop de professionnels du développement, sécurité des applications Web se compose uniquement de produire des applications qui sont fonctionnels et stables, ne pas construire la protection hacker dans le code ou le contrôle des vulnérabilités d'injection SQL (SPI Dynamics)»
Protocoles Web ne sont pas sécurisés par défaut. Mais les développeurs d'applications web pourrait fortement améliorer les normes de sécurité avec les bons principes de codage. Comme le dit M. Andrews et J. Whittaker mentionner dans leur Guide to Web Application Security: «Si seuls les développeurs ont validé leur contribution à ce qu'ils s'attendent à donner, plutôt que d'essayer de filtre pour les intrants malveillants (voire pas du tout), puis 80 -- 90% des vulnérabilités des applications web s'en irait. SQL Injection - parti, XSS - parti, paramètre altérations - disparu. "
Ce n'est pas si simple. M. Graff et K. van Wyk dans "Codage sécurisé: Principes et pratiques (O'Reilly, 2003)" considère qu'il ya trois ensembles de facteurs qui vont à l'encontre de codage sécurisé. Si nous nous référons à des applications Web de codage:
- Les facteurs techniques (la complexité de la tâche sous-jacente elle-même): des dizaines de scripts, langages (PHP, ASP, Perl, Python, JavaScript, ActiveX, SQL, ...), les applications, les bibliothèques, sont développés soit en interne, à l'intérieur plein communautés d'origine ou par des éditeurs de logiciels. Cela génère de la complexité et implique une connaissance approfondie et des contrôles.
- Facteurs psychologiques et humaines (les «modèles mentaux»): vous ne voyez que les erreurs que vous savez! Et la vérification des erreurs, les essais ne sont pas les plus nobles ' «pièces de programmeurs d'emploi! Les trous de sécurité surgissent souvent en raison (utilisateur ou hacker!) À un comportement imprévisible n'a pas été pris en compte. Ou parce que, par exemple, les contributions attendues n'ont pas été précisées assez!
- Real-World facteurs (économiques et autres facteurs sociaux qui vont à l'encontre de la qualité de la sécurité): programmation web est plus facile que de coder en assembleur, écrire un script ou une page HTML ne nécessitent pas beaucoup d'expérience et les compétences d'ingénieur en informatique. Viennent ensuite les aspects économiques: les programmeurs professionnels sont généralement évalués sur la façon facile et rapide, ils peuvent écrire des nouvelles fonctionnalités du logiciel non sur la capacité d'obtenir le code.
Malheureusement, la perspective d'un fabricant du logiciel: le lancement d'un nouveau produit sur le temps est plus important que de lancer une connexion sécurisée (d) le logiciel!
Partie suivante parlera des limites des outils traditionnels
Richard Touret est gestionnaire au Binarysec, http://www.binarysec.com, l'édition de logiciels de sécurité entreprise un softwall intelligente des applications web ou pare-feu logiciel. Ce module Apache s'adapte sur la plupart des sites web, l'apprentissage du trafic légitime de bloquer toute demande malveillants, notamment par injection SQL, cross-site scripting, traversée de répertoire, la navigation avec force, l'injection de commandes, paramètres falsification, faux-fuyants attaque de type buffer overflow, ...
