web-dev-qa-db-fra.com

Vulnérabilité dans le framework Javascript populaire (Angularjs)

J'ai trouvé un bogue qui vous permet d'échapper au bac à sable du modèle AngularJS. Angular est un langage de modèle basé sur la moustache. Il vous permet de mettre des expressions qui sont évaluées dans votre html. Par exemple, {{1 + 1}} s'affiche à 2

Le sandbox permet aux utilisateurs de ne pas accéder aux fenêtres/constructeurs depuis l'intérieur Angular dans les expressions. Vous ne pouvez pas faire {{{} .constructor = ...}} par exemple. C'est car ces opérations sont considérées comme dangereuses si le site enregistre également des modèles à partir des entrées utilisateur. Il ouvre le site à XSS.

En parcourant le code source, j'ai trouvé qu'il y avait une vérification pour obj === {} .constructor qui peut être contourné.

Fondamentalement, cela revient à contourner cela:

if (obj) {
    if (obj === (0).constructor || obj === (false).constructor || obj ===     ''.constructor ||
      obj === {}.constructor || obj === [].constructor || obj ===     Function.constructor) {
      throw $parseMinErr('isecaf',
      'Assigning to a constructor is disallowed! Expression: {0}',      fullExpression);
    }
}

J'ai pu dépasser ces vérifications en cachant mes appels de constructeur dans un autre objet (littéral objet ou littéral tableau).

En tant qu'objet littéral: 

{{x = {'y':''.constructor.prototype}; x['y'].charAt=[].join;$eval('x=alert(`Evaluated Object Literal`)');}}

Ou sous forme de tableau: 

{{x = [''.constructor.prototype]; x[0].charAt=[].join; $eval('x=alert(`Evaluated Array`)');}}

Comment améliorer au mieux les vérifications ci-dessus pour que ces cas échouent?

J'ai essayé de remplacer les vérifications obj === {} .constructor par instanceof à la place et cela fait fonctionner les vérifications, mais je pense que cela peut introduire ses propres problèmes de sécurité. Je voudrais soumettre une demande d'extraction, mais j'espère que d'autres chercheurs en sécurité pourraient contribuer à la conversation afin de rendre le bac à sable aussi solide que possible.

Voici mon problème publié sur Angular pour référence: https://github.com/angular/angular.js/issues/14939

Voici du matériel connexe: http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html

Voici un jsFiddle: https://jsfiddle.net/ianhickey/5sb665we/

javascriptsandboxangularjs
17
ialexander

Utilisateurs angulaires: Arrêtez de sauvegarder l'entrée utilisateur NON ANTISAISIE .

J'ai des sentiments mitigés sur la réponse à ma propre question. À partir de Angular version 1.6, l'équipe Angular a décidé de supprimer complètement le bac à sable. Le bac à sable (bien qu'il ne soit pas parfait) offrait à l'utilisateur un niveau de protection superficiel) par rapport à ses propres choix lors de la construction d'une Angular. Le bac à sable était vraiment très bon et de mieux en mieux. Mais le bac à sable n'a également jamais été destiné à être un Il était là pour essayer d'aider à appliquer les principes de conception propre.

Avec le bac à sable disparu, l'utilisateur Angular va être forcé de réfléchir aux implications en termes de sécurité de l'enregistrement d'entrées utilisateur non approuvées et non filtrées. Ce que je pense personnellement est une bonne chose. Si, et seulement si, les gens se rendent compte que cette mise à niveau pourrait potentiellement ouvrir des problèmes de sécurité plus larges qu'ils avaient précédemment ignorés. J'espère que ce message contribuera à créer une certaine prise de conscience lorsque les gens recherchent la "sécurité angulaire 1.6".

La réponse à cette question est que Angular a supprimé le bac à sable à partir de 1.6 pour répondre au fait que les utilisateurs utilisaient le bac à sable comme mécanisme de sécurité où il n'a jamais été destiné.

Article de blog sur la suppression de Sandbox angulaire

4
ialexander