Erreurs à ne pas faire sur votre site web

Sécurité Site e-commerce Site internet

vulnerabilites du web xss

Voici une liste des erreurs à ne pas commettre pour votre site internet ! En cherchant un peu dans un moteur de recherche des informations sur la sécurité web, on trouve directement les failles de sécurité les plus connues, de la documentation sur les failles XSS, les injections SQL, les erreurs d’inclusion, etc. Pourtant même quand le webmaster connait ses erreurs de développement (et qu’il arrive à les corriger correctement, ce qui n’est bien souvent pas le cas), on trouve carrément des parties du logiciel à l’air libre, sans aucune protection. Voilà ce qu’il faut éviter à tout prix. (en plus du reste)

Protection côté client

Partez du principe que tout ce qui vient du client n’est pas sûr. Toutes les protections, sanitizations et filtres placés du côté client ne valent rien. En effet, le client est libre d’envoyer la requête HTTP qui lui plaît avec les headers qu’il souhaite, les champs GET et POST désirés, etc.

Fichiers/répertoires pensés inconnus

Ne considérez jamais non plus un nom de fichier comme inconnu et impossible à connaître de la part d’un pirate. Plus généralement, cela vaut pour toute information cachée. Pour vous en convaincre, dites-vous que cette information se trouve dans les logs du serveur, dans votre historique de navigation. Elle est accessible en sniffant le réseau ou par bruteforce.

Failles non-corrigées

Ca semble évidemment mais je peux vous affirmer que certains webmasters le font et peut-être même vous. La raison avancée est l’impossibilité présumée d’exploiter cette faille. Par exemple, une faille XSS dans l’espace membre d’un utilisateur… disons dans un message personnel s’affichant après la connexion. Certains développeurs pensent alors « Il ne va pas se hacker lui-même ».

Admettons maintenant qu’un pirate fasse visiter une page de son site à un visiteur où se trouve un formulaire qui envoie une requête de modification de ce message, ce qu’on appelle plus communément une attaque de type CSRF. La faille XSS est désormais exploitable.

En résumé, barricadez l’entièreté de votre application. Vous n’avez peut-être pas trouvé de moyen d’exploiter la faille mais peut-être qu’une personne mal-intentionnée sera plus « chanceuse ».

Confiance dans la base de données

Souvent les données provenant de la base de données sont renvoyées au client sans autre forme de procès car jugée comme saine. Le webmaster pense que les filtres avant l’écriture dans la base de données suffisent et donc ne filtrent pas en sortie.

C’est dangereux parce qu’on ne peut être sûr que les données se trouvant dans les tables proviennent effectivement des parties de l’application concernées, voire de l’application tout court. Plus généralement, ne faites jamais confiance à un autre composant dans un système informatique.

Pour arriver sur cette page, il faut…

Pendant la navigation sur un site web, il arrive de devoir suivre une procédure. C’est le cas lors d’une inscription. Il arrive alors qu’on tienne pour acquis que les étapes précédentes ont été exécutées et que, dès lors, on ne filtre plus les données par exemple. Cette hypothèse est fausse. Comme dit précédemment, le client est libre de forger les requêtes qu’il souhaite… n’importe lesquelles.

Identification via IP

On voit parfois des sites web identifier l’utilisateur grâce à son adresse IP ou un couple IP/signature du navigateur. D’abord, ce n’est pas efficace, plusieurs utilisateurs pouvant se trouver derrière le même LAN et partageant donc la même IP sur Internet (grâce au NAT). Ensuite, parce que des utilisateurs peuvent faire le choix de se placer derrière des proxys et de changer leur IP à une fréquence régulière par exemple.

La meilleure technique et la plus simple reste un identifiant de session stocké dans un cookie. Les informations de session restant stockées côté serveur ce qui permet d’en conserver le contrôle.

Certains sites conservent l’IP de l’utilisateur dans les données de session pour éviter les session hijhackings (ou détournements / vols de session). Cette précaution devrait rester un choix pour l’utilisateur pour augmenter sa sécurité. En effet, comme précisé ci-dessus, il existe des cas ou ce type de protection présente des inconvénients majeurs (déconnexions répétitives par exemple).

En conclusion, pour une sécurité plus élevée… restez parano au maximum !

Le partage c'est la vie !

Article publié le 8 décembre 2015 par weclain