it-swarm.com.de

Sicherheitslücke im beliebten Javascript Framework (Angularjs)

Ich habe einen Fehler gefunden, mit dem Sie der AngularJS-Vorlagensandbox entkommen können. Angular ist eine auf Schnurrbart basierende Vorlagensprache. Sie können Ausdrücke einfügen, die in Ihrem HTML ausgewertet werden. Beispielsweise wird {{1 + 1}} bei 2 gerendert

Die Sandbox macht es so, dass Benutzer nicht von innen auf Fenster/Konstruktoren zugreifen können Angular innerhalb von Ausdrücken. Sie können zum Beispiel nicht {{{} .constructor = ...}} ausführen. Dies ist Da diese Vorgänge als unsicher gelten, sollte die Site auch Vorlagen aus Benutzereingaben speichern. Dadurch wird die Site für XSS geöffnet.

Beim Durchgehen des Quellcodes stellte ich fest, dass eine Überprüfung auf obj === {} .constructor vorliegt, die umgangen werden kann.

Grundsätzlich kommt es darauf an, dies zu umgehen:

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);
    }
}

Ich konnte diese Prüfungen überwinden, indem ich meine Konstruktoraufrufe in einem anderen Objekt (Objektliteral oder Arrayliteral) versteckte.

Als wörtliches Objekt:

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

Oder als Array:

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

Wie können die oben genannten Überprüfungen am besten verbessert werden, damit diese Fälle fehlschlagen?

Ich habe versucht, die obj === {} .constructor-Prüfungen stattdessen in instanceof zu ändern, damit die Prüfungen funktionieren, aber ich denke, dass dies zu eigenen Sicherheitsproblemen führen kann. Ich möchte eine Pull-Anfrage einreichen, hoffe aber, dass andere Sicherheitsforscher da draußen zum Gespräch beitragen, um die Sandbox so stark wie möglich zu machen.

Hier ist mein Problem, das an Angular Projekt als Referenz gesendet wurde: https://github.com/angular/angular.js/issues/14939

Hier ist verwandtes Material: http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html

Hier ist eine jsFiddle: https://jsfiddle.net/ianhickey/5sb665we/

17
ialexander

Winkelbenutzer: Speichern der nicht sanitären Benutzereingabe beenden .

Ich habe gemischte Gefühle bezüglich der Antwort auf meine eigene Frage. Ab Angular Version 1.6) hat das Angular Team beschlossen, die Sandbox vollständig zu entfernen. Die Sandbox (obwohl nicht perfekt) bot dem Benutzer einen oberflächlichen Schutz gegen ihre eigenen Entscheidungen beim Erstellen einer Angular App. Die Sandbox war wirklich ziemlich gut und wurde immer besser. Aber die Sandbox war auch nie beabsichtigt, um eine zu sein Sicherheitsgrenze. Es war da, um zu versuchen, saubere Designprinzipien durchzusetzen.

Wenn die Sandbox weg ist, wird der Benutzer Angular) gezwungen sein, über die Sicherheitsauswirkungen des Speicherns nicht vertrauenswürdiger, nicht bereinigter Benutzereingaben nachzudenken. Was ich persönlich für eine gute Sache halte. und nur wenn die Leute erkennen, dass sie bei diesem Upgrade möglicherweise umfassendere Sicherheitsprobleme eröffnen, die sie zuvor ignoriert hatten. Hoffentlich hilft dieser Beitrag dabei, ein gewisses Bewusstsein zu schaffen, wenn Leute nach "Angular 1.6-Sicherheit" suchen.

Die Antwort auf diese Frage lautet: Angular hat die Sandbox ab 1.6 entfernt, um die Tatsache zu beheben, dass Benutzer die Sandbox als Sicherheitsmechanismus verwendet haben, wo sie niemals vorgesehen war.

Angular Sandbox Removal Blog-Beitrag

4
ialexander