La navigation privée / privée empêche-t-elle les attaques XSS?
Lors du démarrage d'une session de navigation privée/privée, aucun cookie provenant d'autres profils de navigation ne doit exister. Par exemple, si je suis connecté à un site sur mon profil de navigation principal, puis que je démarre une nouvelle session de navigation privée, je ne suis pas connecté à ce même site (cookies non reportés). En supposant qu'il s'agit d'une nouvelle session de navigation privée, il ne devrait pas y avoir de cookies existants ou d'informations sensibles disponibles.
Cela a-t-il également pour effet secondaire d'empêcher ou d'annuler les attaques XSS puisqu'il n'y a pas de données sensibles à voler? Ou c'est un faux sentiment de sécurité?
Une attaque XSS ne concerne pas principalement les cookies. Il ne s'agit pas non plus de voler des données sensibles. Il s'agit plutôt d'exécuter du code contrôlé par l'attaquant côté client dans le contexte du site que vous visitez. Le type de préjudice pouvant être causé par ce code dépend du site et du contexte réels.
L'utilisation d'une session de navigation privée n'empêchera pas XSS par elle-même, mais elle pourrait limiter l'impact des dommages que XSS peut faire - c'est-à-dire qu'elle n'a pas accès aux cookies ou autres données stockées de la session de navigateur non privée. Cela pourrait cependant faire du mal, mais encore une fois cela dépend du contexte spécifique et du site que vous visitez.
Il existe principalement deux types d'attaques XSS: Persistant et ad-hoc.
Une session de navigation privée vous protégera contre les attaques XSS ad hoc, mais pas contre les attaques persistantes.
Un XSS persistant fonctionne par un attaquant injectant du code de script quelque part dans la page sensible, cela pourrait être fait en vous envoyant un message préparé sur la plate-forme, ou par un autre moyen d'injecter des données dans le stockage de la page sensible. Lorsque vous vous connectez à la page sensible pour afficher certaines données, les données injectées seront chargées par le serveur et transférées vers votre navigateur et seront exécutées si le site est vulnérable. Un exemple serait un message préparé dans une transaction bancaire en ligne. L'attaquant vous enverrait une transaction réelle et la partie message contiendrait un script nuisible. Aucune autre page n'est impliquée, vous ne pouvez donc pas vous protéger contre cela, seul le propriétaire de la page peut le faire.
Un XSS ad hoc peut fonctionner en vous amenant à cliquer sur un lien préparé, qui inclut des données d'injection. Un tel lien pourrait ressembler à https://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script> où le script injecté fait partie du lien. L'attaquant tentera de vous faire cliquer sur ce lien, ou tentera de l'exécuter en arrière-plan via JavaScript à partir de sa propre page préparée. Donc, si vous ouvrez des liens e-mail et des pages non fiables dans une session distincte, votre compte d'utilisateur sur la page sensible sera à l'abri de ce type d'attaque, car vous n'êtes pas connecté sur la page sensible dans la session incognito. Ainsi, bien que XSS puisse encore s'exécuter, il ne peut pas nuire à votre propre compte sur la page sensible, ce que nous voulons protéger.
Comme Steffen l'a déjà mentionné, une XSS (cross attaque de script de site), par définition ne fonctionne pas uniquement avec les cookies. Si quelqu'un accède à une base de données et modifie certains champs, qui contiennent des balises de script pouvant s'exécuter sur certaines pages Web, il peut exécuter une attaque XSS.
Cela signifie simplement que quelqu'un exécute des scripts dans votre navigateur sur la page que vous visitez pour récupérer des informations sur vous (peut-être des cookies) ou vous tromper en ajustant le DOM pour par exemple lier un bouton de paiement à son site Web défectueux.