Sécurité des sites Web pour les webmasters

Jeudi 12 mai 2011

Les utilisateurs apprennent à se protéger contre les programmes malveillants en installant un logiciel antivirus sophistiqué, mais souvent ils peuvent également confier leurs informations privées à des sites Web comme le vôtre, auquel cas il est important de protéger leurs données. Il est également très important de protéger vos propres données ; si vous avez une boutique en ligne, vous ne voulez pas vous faire voler.

Au fil des ans, les entreprises et les webmasters ont appris — souvent à leurs dépens — que la sécurité des applications Web n’est pas une blague ; nous avons vu des mots de passe d’utilisateurs divulgués en raison de
SQL injection
attaques, des cookies volés avec
XSS, et des sites Web piratés en raison d’une validation des entrées négligente.

Aujourd’hui, nous allons vous montrer quelques exemples de la façon dont une application Web peut être exploitée afin que vous puissiez en tirer des leçons ; pour cela, nous utiliserons
Gruyere, une application intentionnellement vulnérable que nous utilisons également en interne pour la formation à la sécurité. Ne sondez pas les sites Web des autres à la recherche de vulnérabilités sans autorisation car cela peut être perçu comme du piratage ; mais vous êtes invités — voire encouragés — à exécuter des tests sur Gruyere.

Manipulation de l’état du client – Que se passera-t-il si je modifie l’URL ?

Disons que vous avez un site d’hébergement d’images et que vous utilisez un script PHP pour afficher les images que les utilisateurs ont téléchargées :

Alors, que fera l’application si je modifie l’URL pour qu’elle ressemble à ceci et que userpasswords.txt est un fichier réel ?

Obtiendrai-je le contenu de userpasswords.txt ?

Un autre exemple de manipulation de l’état du client est lorsque les champs de formulaire ne sont pas validés. Par exemple, disons que vous avez ce formulaire :

Il semble que le nom d’utilisateur de la personne qui soumet le formulaire soit stocké dans un champ de saisie masqué. Eh bien, c’est super ! Cela signifie-t-il que si je change la valeur de ce champ pour un autre nom d’utilisateur, je peux soumettre le formulaire en tant que cet utilisateur ? C’est fort possible ; l’entrée de l’utilisateur n’est apparemment pas authentifiée avec, par exemple, un jeton qui peut être vérifié sur le serveur.

Imaginez la situation où ce formulaire ferait partie de votre panier d’achat et où je modifierais le prix d’un article de 1 000 $ à 1 $, puis passerais la commande.

Protéger votre application contre ce type d’attaque n’est pas facile ; jetez un œil à la troisième partie de Gruyere pour obtenir quelques conseils sur la façon de défendre votre application.

Cross-site scripting (XSS) – Les entrées des utilisateurs ne sont pas fiables

Une URL simple et inoffensive :

Mais est-elle vraiment inoffensive ? Si je décode les
caractères encodés en pourcentage
, j’obtiens :

Gruyere, tout comme de nombreux sites avec
des pages d’erreur personnalisées, est conçu pour inclure le composant de chemin dans la page HTML. Cela peut introduire des bugs de sécurité, comme XSS, car cela introduit l’entrée de l’utilisateur directement dans la page HTML rendue de l’application Web. Vous pourriez dire : « C’est juste une boîte d’alerte, et alors ? » Le fait est que, si je peux injecter une boîte d’alerte, je peux très probablement injecter autre chose aussi, et peut-être voler vos cookies que je pourrais utiliser pour me connecter à votre site en tant que vous.

Un autre exemple est lorsque l’entrée utilisateur stockée n’est pas assainie. Disons que je rédige un commentaire sur votre blog ; le commentaire est simple :

Si d’autres utilisateurs cliquent sur mon lien innocent, j’ai leurs cookies :

Vous pouvez apprendre à trouver des vulnérabilités XSS dans votre propre application Web et comment les corriger dans la deuxième partie de
Gruyere; ou, si vous êtes un développeur avancé, jetez un œil aux fonctionnalités d’échappement automatique dans les systèmes de modèles dont nous avons parlé sur notre
Online Security blog.

Falsification de requête inter-sites (XSRF) – Dois-je faire confiance aux requêtes provenant d’evil.com ?

Oups, une image cassée. Elle ne peut pas être dangereuse — elle est cassée après tout —, ce qui signifie que l’URL de l’image renvoie un 404 ou elle est simplement malformée. Est-ce vrai dans tous les cas ?

Non, ce n’est pas le cas ! Vous pouvez spécifier n’importe quelle URL comme source d’image, quel que soit son type de contenu. Il peut s’agir d’une page HTML, d’un fichier JavaScript ou d’une autre ressource potentiellement malveillante. Dans ce cas, la source de l’image était l’URL d’une page simple :

Cette page ne fonctionnera que si je suis connecté et que j’ai certains cookies définis. Étant donné que j’étais effectivement connecté à l’application, lorsque le navigateur a essayé de récupérer l’image en accédant à l’URL de la source de l’image, il a également supprimé mon premier extrait. Cela ne semble pas particulièrement dangereux, mais si je connais un peu l’application, je pourrais également invoquer une URL qui supprime le profil d’un utilisateur ou permet aux administrateurs d’accorder des autorisations à d’autres utilisateurs.

Pour protéger votre application contre les XSRF, vous ne devez pas autoriser l’appel d’actions modifiant l’état via
GET; la méthode POST a été inventée pour ce type de requête modifiant l’état. Ce changement à lui seul aurait pu atténuer l’attaque ci-dessus, mais ce n’est généralement pas suffisant et vous devez inclure une valeur imprévisible dans toutes les requêtes modifiant l’état pour empêcher les XSRF. Veuillez vous rendre sur Gruyere si vous souhaitez en savoir plus sur les XSRF.

Inclusion de scripts inter-sites (XSSI) – Tous vos scripts nous appartiennent

De nos jours, de nombreux sites peuvent mettre à jour dynamiquement le contenu d’une page via des requêtes JavaScript asynchrones qui renvoient des données JSON. Parfois, le JSON peut contenir des données sensibles et, si les précautions appropriées ne sont pas prises, il est possible qu’un attaquant vole ces informations sensibles.

Imaginons le scénario suivant : j’ai créé une page HTML standard et je vous ai envoyé le lien ; comme vous me faites confiance, vous visitez le lien que je vous ai envoyé. La page ne contient que quelques lignes :

Puisque vous êtes connecté à Gruyere et que vous possédez un extrait privé, vous verrez une boîte d’alerte sur ma page vous informant du contenu de votre extrait. Comme toujours, si j’ai réussi à déclencher une boîte d’alerte, je peux faire tout ce que je veux d’autre ; dans ce caso il s’agissait d’un simple extrait, mais cela aurait pu être aussi votre plus grand secret.

Il n’est pas trop difficile de défendre votre application contre les XSSI, mais cela demande tout de même une réflexion minutieuse. Vous pouvez utiliser des jetons comme expliqué dans la section XSRF, configurer votre script pour qu’il ne réponde qu’aux requêtes POST, ou simplement commencer la réponse JSON par ‘n’ pour vous assurer que le script n’est pas exécutable.

SQL Injection – Pensez-vous toujours que l’entrée utilisateur est sûre ?

Que se passera-t-il si j’essaye de me connecter à votre application avec un nom d’utilisateur tel que
JohnDoe'; DROP TABLE members;--

Bien que cet exemple spécifique n’expose pas les données des utilisateurs, il peut causer de grands maux de tête car il a le potentiel de supprimer complètement la table SQL où votre application stocke des informations sur les membres.

En général, vous pouvez protéger votre application contre les injections SQL grâce à une réflexion proactive et à la validation des entrées. Tout d’abord, êtes-vous sûr que l’utilisateur SQL doit avoir l’autorisation d’exécuter
DROP TABLE membersNe serait-il pas suffisant d’accorder uniquement des droits SELECT En définissant soigneusement les autorisations de l’utilisateur SQL, vous pouvez éviter des expériences douloureuses et de nombreux problèmes. Vous souhaiterez peut-être également configurer la génération de rapports d’erreurs de telle sorte que les noms de la base de données et de ses tables ne soient pas exposés en cas d’échec d’une requête.

Deuxièmement, comme nous l’avons appris dans le cas de XSS, ne faites jamais confiance aux entrées des utilisateurs : ce qui vous ressemble à un formulaire de connexion ressemble à une porte d’entrée potentielle pour un attaquant. Nettoyez toujours et protégez avec des guillemets l’entrée qui sera stockée dans une base de données, et chaque fois que possible, utilisez des instructions généralement appelées instructions préparées ou paramétrées disponibles dans la plupart des interfaces de programmation de bases de données.

Savoir comment les applications Web peuvent être exploitées est la première étape pour comprendre comment les défendre. À la lumière de cela, nous vous encourageons à suivre le
cours Gruyere, à suivre d’autres cours de sécurité Web de la
Google Code University
et à consulter
skipfish
si vous recherchez un outil de test automatisé de la sécurité des applications Web. Si vous avez d’autres questions, veuillez les publier dans notre
Webmaster Help Forum.

Écrit par
Gary Illyes, Analyste des tendances des webmastersSécurité des sites Web pour les webmasters | Alien Road