Au cœur de toute application basée sur le Web est la manière dont elle maintient l'état et contrôle ainsi l'interaction de l'utilisateur avec le site. La gestion de la session couvre largement tous les contrôles d'un utilisateur à partir de l'authentification jusqu'au momoment où il quitte l'application. HTTP est un protocole sans état, ce qui signifie que les serveurs Web répondent aux demandes des clients sans les lier les unes aux autres. La logique d'une application, même simple nécessite que les multiples requêtes d'un utilisateur soient associées les unes aux autres à travers une “session” Cela nécessite des solutions tierces -.. Soit par intergiciels Off-The-Shelf-(OTS) et des solutions de serveur Web, soit par des implémentations de développement sur mesure. Les plus populaires environnements d'applications Web, telles que ASP et PHP, fournissent aux développeurs des routines de manipulation de session intégrées. une sorte de jeton d'identification sera normalement émis, qui sera considéré comme un “session ID” ou Cookie.
Il y a un certain nombre de façons dont une application Web peut interagir avec un utilisateur. Chacune dépend de la nature du site, de la sécurité, et de la disponibilité de l'application. Alors qu'il existe un certain nombre de meilleures pratiques de développement d'applications, telles que celles décrites dans le Guide de l'OWASP pour la création d'applications Web sécurisées, il est important que la sécurité des applications soitt considérée dans le contexte des exigences et des attentes du fournisseur . Dans ce chapitre, nous décrivons les éléments suivants.
testing_for_session_management_schema
Afin d'éviter l'authentification en continu pour chaque page d'un site ou d'un service, les applications Web mettent en œuvre divers mécanismes pour stocker et valider les informations d'identification pour un laps de temps prédéterminé. Ces mécanismes sont connus sous le nom de gestion de session et, alors qu'ils sont utilisés pour augmenter la facilité d'utilisation et la convivialité de l'application, ils pourraient être exploités par un testeur de pénétration afin d'accéder à un compte d'utilisateur, sans avoir besoin de fournir des informations d'identification correctes. Dans ce test, nous voulons vérifier que les cookies et autres jetons de session sont créés de manière sécurisée et imprévisible. Un attaquant qui est capable de prédire et de forger un cookie faible peut facilement détourner des sessions des utilisateurs légitimes.
testing_for_cookies_attributes
Les cookies sont souvent un vecteur d'attaque clé pour les utilisateurs malveillants (en général lorsqu'ils ciblent d'autres utilisateurs) et, à ce titre, l'application doit toujours prendre toutes les mesures nécessaires pour protéger les cookies. Dans cette section, nous allons examiner comment une application peut prendre les précautions nécessaires lors de l'attribution des cookies, et comment tester que ces attributs(‘HTTP Only’, ‘Secure’, et 'time validity')ont été correctement configurés.
Lorsqu'une application ne renouvelle pas son cookie de session(s) après une authentification de l'utilisateur, il pourrait être possible de trouver une faille de fixation de session et forcer un utilisateur d'utiliser un cookie délivré par l'attaquant. Dans ce cas, un attaquant pourrait voler la session de l'utilisateur (session hijacking).
testing_for_exposed_session_variables
testing_for_cross_site_request_forgery_csrf_
testing_for_session_token_not_restricted_properly
- Un domain ou un path pas servi proprement
- Une Session établie sur http
testing_for_logout_functionality
- Le token de session n'est pas supprimé sur le serveur après la déconnexion
- Le fonction de déconneion n'est pas correctement implémentée
- Le token de session est Persistant (NOTE: ceci n'est pas un vulnérabilité si le time out es correctement configuré)
- Il n'existe pas de journal des événements dauthentification des users
- Établissement de multiples sessions avec le même compte