XSS en tant que vecteur d'attaque même si les données XSS ne sont pas stockées?

Question

J'ai une question à propos de XSS

Les formulaires peuvent-ils être utilisés comme vecteur pour XSS même si les données ne sont pas stockées dans la base de données et utilisées plus tard?

dire en php le code serait:

<form input="text" value="<?= @$_POST['my_field'] ?>" name='my_field'> 

Afficher un message d'alerte (démontrer que JS peut être exécuté) sur votre propre navigateur est trivial avec le code ci-dessus. Mais est-ce aussi exploitable dans les navigateurs? Le seul scénario que je vois est celui où vous incitez quelqu'un à visiter une certaine page, c'est-à-dire une combinaison de CSRF et XSS. "Stocké dans une base de données et utilisé plus tard": le scénario que je comprends sur CSS est l'endroit où vous pouvez publier des données sur un site qui exécute JavaScript et est affiché sur une page dans un navigateur qui a une plus grande/différents privilèges que le vôtre. Mais, pour être clair, c'est pas wat je parle de plus haut.

Answer 1

Oui, c'est toujours un vecteur d'attaque.

Ce que vous devez considérer est:

Peut-être un utilisateur authentifié dupé en visualiser cette page avec des données construits de manière malveillante?

La réponse est oui (en supposant que vous avez des utilisateurs authentifiés). Parce qu'il est possible de diriger quelqu'un vers votre site et de transmettre des variables malveillantes à ce champ.

Answer 2

Je pense que ce que vous voulez dire est, puisque l'utilisateur 2 ne peut pas montrer les données précédentes ajoutées par l'utilisateur 1, de même le XSS peut-il arriver? Donc, si l'utilisateur 1 pirate l'URL de sorte que certains paramètres $ _GET soient affichés sur la page Web (et même, changez-le en tinyurl), et diffusez cette URL en disant qu'il vaut vraiment la peine de voir cette page, etc, puis ça pourrait être possible.

Il est donc préférable d'échapper tous les paramètres lors de l'affichage de la page.

Answer 3

C'est absolument une forme valide de XSS. XSS existe sous deux formes - stockées et réfléchies. Reflété est beaucoup plus commun, mais stocké a le potentiel d'être plus dommageable. XSS réfléchi est généralement utilisé dans le cadre d'une attaque d'ingénierie sociale. Un attaquant crée une URL comme suit: http://host.com/page.php?my_field=malicious_code Ils vont souvent raccourcir l'URL avec tinyutl ou bit.ly, et le sortir avec les méthodes d'ingénierie sociale habituelles (email, babillard, twitter, comptes facebook détournés, etc.)

Answer 4

Oui, c'est toujours un vecteur d'attaque, bien que l'impact soit plus situationnel.

est ici un scénario artificiel qui se développe sur les réponses précédentes si le formulaire requiert une authentification à atteindre (et est plus facile si le site ne se soucie pas si les formulaires sont soumis par POST ou GET):

1) Attacker utilise CSRF pour se connecter à la victime en utilisant les informations d'identification de l'attaquant (par exemple < iframe src = http://../login?id=...&pass= ... "> </iframe >) De cette façon, l'attaquant apporte le formulaire à la victime et peu importe si la victime n'a pas
2) L'attaquant utilise un autre CSRF pour exécuter XSS contre le formulaire, ce qui demande à la victime des informations d'identification, etc.(C'est là que l'ingénierie sociale convaincante doit se produire ou l'attaquant a du JavaScript utile à utiliser dans la même origine du navigateur pour le site.)

Un autre scénario artificiel dans lequel la forme vulnérable effectue une action importante, comme le transfert d'argent. entre les comptes:

0) La forme vulnérable utilise des champs de formulaire cachés avec des valeurs aléatoires pour empêcher le CSRF. L'attaquant ne sait pas quelles sont les valeurs et ne peut pas mettre en place une attaque appropriée.
1) L'attaquant crée une charge utile CSRF qui inclut JavaScript pour lire les jetons csrf aléatoires d'un formulaire (c'est-à-dire les extraire du DOM du navigateur).
2) La victime se connecte au site.
3) L'attaquant attire la charge utile CSRF, CSRF amorce la requête de formulaire avec les jetons csrf corrects car il s'exécute dans le navigateur de la victime, dans la même origine du site victime et utilise la session d'authentification de la victime. L'attaquant n'a pas besoin de connaître les jetons csrf, il suffit de pouvoir manipuler les champs de formulaire qui les stockent. 4) L'attaquant bénéficie que la victime soumette le formulaire - pas de pop-ups ou d'ingénierie sociale nécessaire en plus d'attirer la victime sur la charge CSRF, mais le formulaire doit faire quelque chose de «utile» pour l'attaquant.