Lorsque le besoin d'un site Web ou d'un intranet se fait sentir au sein de l'entreprise, il est tentant de vouloir éviter le coût d'un développement extérieur en confiant le projet à l'équipe informatique... qui elle-même n'hésite pas à déléguer : « En général, les sites Web sont confiés au stagiaire, qui en profite pour se former à PHP et à la programmation Web » , observe Aurélien Cabezon, consultant sécurité et fondateur d'iSecurelabs.

Certes, le résultat est alors un site qui fonctionne, mais qui se révèle également très tolérant envers les pirates. « Avec ce genre de développement, on retrouve beaucoup d'erreurs PHP classiques qui permettent d'exécuter des commandes sur le serveur ou d'explorer le système à partir du site Web, ce qui facilite grandement le travail de l'auditeur », poursuit Aurélien Cabezon.

Aujourd'hui, pour les consultants comme pour les pirates, les sites Web développés en interne sont devenus une cible privilégiée : « On commence souvent par là, car on y trouve beaucoup d'informations facilement accessibles, par exemple grâce à des scripts d'administration placés dans un répertoire au nom évocateur, tel que le classique " admin ". Ou encore grâce à des applications mal conçues qui écrivent leurs journaux directement dans l'arborescence du site, les rendant ainsi accessibles à n'importe qui », révèle Nicolas Jombart, consultant sécurité chez Hervé Schauer Consultants.

Et l'ensemble des consultants du cabinet HSC ajoutent que, très souvent, bien que le répertoire d'administration semble protégé, il est possible malgré tout d'accéder aux scripts qu'il contient tout simplement en les appelant directement : en effet, le contrôle d'accès ne porte parfois que sur la page d'index du répertoire...

Autre erreur classique et souvent exploitée : l'oubli à la racine du serveur de versions de développement des scripts. Celles-ci n'ont plus l'extension par défaut (par exemple.php ou.asp), mais plutôt une extension spécifique laissée par l'éditeur de texte, tel le tilde (~) cher à Emacs. En essayant le nom des scripts du serveur suivi de cette extension, il est parfois possible d'afficher le code source du script, et de révéler ainsi les mots de passe qui sont stockés en clair (c'est souvent le cas avec les scripts de connexion aux bases de données). Un risque d'ailleurs accru lorsque le concepteur du site se connecte directement à la base de données, sans inclure un script de connexion dédié.

Et de telles erreurs ne sont pas seulement l'apanage des stagiaires, les développeurs Web les commettent également.

« Le constat est que les développeurs ne sont pas du tout sensibilisés à la sécurité, quelle que soit leur spécialité. Nous rencontrons trop souvent des développeurs internes qui ignorent encore ce qu'est un dépassement de mémoire tampon [la faille la plus courante de ces vingt dernières années, NDLR] ou ne sont pas du tout au courant qu'il est possible d'injecter des informations dans une base de données à partir d'un formulaire Web, par exemple », conclut Thomas Lebouc, de Thales Security Systems.