Quels sont les exploits web courants que je dois connaître ?

Question

Je suis encore assez novice en matière de programmation web, j'ai passé la plupart de mon temps sur des applications client. Je suis donc curieux de savoir quels sont les exploits courants que je dois craindre ou tester sur mon site.

Answer 1

J'affiche le Liste abrégée de l'OWASP Top 2007 ici pour que les gens n'aient pas à chercher un autre lien et au cas où la source tomberait.

Cross Site Scripting (XSS)

• Les failles XSS se produisent lorsqu'une application prend des données fournies par l'utilisateur et les envoie à un navigateur web sans valider ou coder ce contenu au préalable. XSS permet aux attaquants d'exécuter script dans le navigateur de la victime, ce qui peut détourner des sessions utilisateur, défigurer des sites web, éventuellement introduire des vers, etc.

Défauts d'injection

• Les failles d'injection, notamment l'injection SQL, sont courantes dans les applications web. L'injection se produit lorsque des données fournies par l'utilisateur sont envoyées à un interpréteur dans le cadre d'une commande ou d'une requête. Les données hostiles de l'attaquant incitent l'interpréteur à exécuter des commandes non souhaitées ou à modifier des données.

Exécution de fichiers malveillants

• Le code vulnérable à l'inclusion de fichiers à distance (RFI) permet aux attaquants d'inclure du code et des données hostiles, ce qui entraîne des attaques dévastatrices, comme la compromission totale du serveur. Les attaques par exécution de fichiers malveillants affectent PHP, XML et tout cadre qui accepte des noms de fichiers ou des fichiers de la part des utilisateurs.

Référence directe à un objet non sécurisé

• Une référence directe à un objet se produit lorsqu'un développeur expose une référence à un objet d'implémentation interne, tel qu'un fichier, un répertoire, un enregistrement de base de données ou une clé, sous forme d'URL ou de paramètre de formulaire. Les attaquants peuvent manipuler ces références pour accéder à d'autres objets sans autorisation.

Falsification de demande intersites (CSRF)

• Une attaque CSRF force le navigateur d'une victime connectée à envoyer une requête pré-authentifiée à une application web vulnérable, qui force ensuite le navigateur de la victime à effectuer une action hostile au profit de l'attaquant. CSRF peut être aussi puissant que l'application web qu'il attaque.

Fuite d'informations et traitement incorrect des erreurs

• Les applications peuvent involontairement divulguer des informations sur leur configuration, leur fonctionnement interne ou violer la vie privée par le biais de divers problèmes d'application. Les attaquants utilisent cette faiblesse pour voler des données sensibles ou mener des attaques plus graves.

Authentification et gestion des sessions cassées

• Les informations d'identification du compte et les jetons de session ne sont souvent pas correctement protégés. Les attaquants compromettent les mots de passe, les clés ou les jetons d'authentification pour prendre l'identité d'autres utilisateurs.

Stockage cryptographique non sécurisé

• Les applications Web utilisent rarement les fonctions cryptographiques de manière appropriée pour protéger les données et les informations d'identification. Les attaquants utilisent des données faiblement protégées pour commettre des usurpations d'identité et d'autres délits, comme la fraude à la carte de crédit.

Communications non sécurisées

• Les applications omettent souvent de chiffrer le trafic réseau alors qu'il est nécessaire de protéger les communications sensibles.

Absence de restriction de l'accès aux URL

• Souvent, une application ne protège les fonctionnalités sensibles qu'en empêchant l'affichage de liens ou d'URL aux utilisateurs non autorisés. Les attaquants peuvent utiliser cette faiblesse pour accéder et effectuer des opérations non autorisées en accédant directement à ces URL.

L'Open Web Application Security Project

-Adam

Answer 2

OWASP conserve une liste des Top 10 les attaques web à surveiller, ainsi qu'une tonne d'autres informations utiles en matière de sécurité pour le développement web.

Answer 3

Ces trois éléments sont les plus importants :

• Falsification de requête intersite
• Cross Site Scripting
• Injection SQL

Answer 4

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}

Answer 5

Tout le monde va dire "Injection SQL", car c'est la vulnérabilité la plus effrayante et la plus facile à appréhender. Le Cross-Site Scripting (XSS) arrive en deuxième position, car il est également facile à comprendre. La "mauvaise validation des entrées" n'est pas une vulnérabilité, mais plutôt l'évaluation d'une bonne pratique de sécurité.

Essayons de voir les choses sous un angle différent. Voici des fonctionnalités qui, lorsqu'elles sont mises en œuvre dans une application Web, sont susceptibles de vous mettre dans le pétrin :

• SQL dynamique (par exemple, les constructeurs de requêtes de l'interface utilisateur). Vous savez probablement déjà que la seule façon sûre d'utiliser SQL dans une application Web est d'utiliser des requêtes paramétrées, dans lesquelles chaque paramètre de la requête est explicitement lié à une variable. Les applications Web enfreignent le plus souvent cette règle lorsque l'entrée malveillante n'est pas un paramètre évident (comme un nom), mais plutôt un attribut de la requête. Un exemple évident est celui des constructeurs de requêtes "Smart Playlist" de type iTunes que l'on voit sur les sites de recherche, où des éléments tels que les opérateurs de la clause where sont transmis directement au backend. Une autre pierre à retourner est le tri des colonnes de tableaux, où vous verrez des choses comme DESC exposées dans les paramètres HTTP.

• Téléchargement de fichiers. Le téléchargement de fichiers perturbe les gens parce que les noms de fichiers ressemblent étrangement aux noms d'URL, et parce que les serveurs web facilitent l'implémentation de la partie "téléchargement" en dirigeant les URL vers les répertoires du système de fichiers. Sept des dix gestionnaires de téléchargement que nous testons permettent aux attaquants d'accéder à des fichiers arbitraires sur le serveur, parce que les développeurs d'applications ont supposé que les mêmes autorisations étaient appliquées à l'appel "open()" du système de fichiers que celles appliquées aux requêtes.

• Stockage du mot de passe. Si votre application peut me renvoyer par mail mon mot de passe brut lorsque je le perds, vous échouez. Il n'y a qu'une seule réponse fiable pour le stockage des mots de passe, qui est bcrypt ; si vous utilisez PHP, vous voulez probablement PHPpass.

• Génération de nombres aléatoires. Une attaque classique sur les applications web : réinitialiser le mot de passe d'un autre utilisateur, et, parce que l'application utilise la fonction "rand()" du système, qui n'est pas crypto-forte, le mot de passe est prévisible. Cela s'applique également partout où l'on fait de la cryptographie. Ce que, d'ailleurs, vous ne devriez pas faire : si vous vous appuyez sur la cryptographie quelque part, vous êtes très probablement vulnérable.

• Sortie dynamique. Les gens font trop confiance à la validation des entrées. Vos chances de débarrasser les entrées des utilisateurs de tous les métacaractères possibles, surtout dans le monde réel, où les métacaractères sont des parties nécessaires des entrées des utilisateurs, sont faibles. Une bien meilleure approche consiste à mettre en place un régime cohérent de filtrage des sorties de bases de données et à les transformer en entités HTML, comme quot, gt et lt. Rails le fera automatiquement pour vous.

• Courriel. De nombreuses applications mettent en œuvre une sorte de fonctionnalité de courrier sortant qui permet à un attaquant de créer un compte anonyme, ou de ne pas utiliser de compte du tout, pour envoyer des messages contrôlés par l'attaquant à des adresses électroniques arbitraires.

Au-delà de ces fonctionnalités, l'erreur n°1 que vous êtes susceptible de commettre dans votre application est d'exposer un ID de ligne de base de données quelque part, de sorte que l'utilisateur X puisse voir les données de l'utilisateur Y simplement en changeant un nombre de "5" en "6".