OWASP WebGoat - sécurité des applications WEB
Conclusion
Développement sécurisé d'application WEB
Malheureusement l'utilisation de protocole tel SSL/TLS pour chiffrer via HTTPS les communications entre un serveur WEB et ses clients, ou l'utilisation de pare-feus s'avèrent insuffisant pour assurer une sécurité totale. En effet, la majorité des attaques concernent des injections de type SQL ou XSS et sont insensibles à ces types de barrière défensive. L'application WebGoat nous enseigne qu'il est également important de sécuriser les échanges avec des services externes, commes les annuaires (injections LDAP) ou les Web services. Enfin, le projet WebGoat permet, selon moi, une prise de conscience et met l'accent sur la qualité du code source et sur le développement sécurisé, en insistant sur quelques points :
Double input validation
Concurrence
Qualité du code : erreurs, oublis et commentaires
Rappelons qu'il est nécessaire de ne pas se contenter d'une validation basée côté client, exécutée depuis le navigateur Web: par exemple à l'aide d'ActiveX ou de Javascript, car ces sécurités sont aisément outrepassables. Il serait tout aussi dommage de se passer de ces mécanismes, car ils réduisent le nombre de traitements effectués sur le serveur et libèrent de la bande passante.
En revanche, il est indispensable de mettre en place une validation “miroir” côté serveur, afin de s'assurer que les données n'ont pas été modifiées entre l'envoi effectué par le navigateur client et la réception par le serveur. Cette validation des données soumises par l'utilisateur, concerne principalement le type, la taille et l'analyse en vu de caractères autorisés ou non (tout ce qui ne doit pas appaître doit être effacé ou échappé).
Dans le cadre d'application Java, l'utilisation de Threads doit être sécurisé (ThreadSafe) et les modules basés principalement sur des classes immutables (Objets qui une fois instancié ne peuvent être modifié), lorsque Jeff se connecte il n'écrase pas la session de Dave connecté précedemment.
Personne n'est infaillible, même le meilleur développeur au monde reste humain et peut donc faire des erreurs. Il faut donc remettre son code en question, le tester et le donner à tester, car c'est une étape importante dans le cycle de vie d'un projet. Ne pas sous-estimer les commentaires pouvant être insérés au code source HTML (visible par tous) car cela peut également être un vecteur de fuite d'informations importantes.