In der Regel bin ich so der Typ “it-works” und das wars. Aber ab und zu komme ich auch auf dumme Gedanken. Wie ich dann feststellen musste, war ich nicht der Erste und das Ergebnis ist erschreckend.
JavaScript Template Engines, wie sie auch von Angular.js bereit gestellt wird, verlagern Logik vom Server zum Browser. Naturbedingt wird dann das Rad neu erfunden. Angular verwendet die doppelt geschweiften Klammern {{ }} um Ausdrücke auszuwerten. In der Praxis gedacht um Werte oder Expressions aus einem View Model zu binden. Diese Werte kommen in der Regel aus einer Datenbank. Klingelt es da? SQL Injection hat sich diesen Gedankengang vor langer Zeit zu eigen gemacht.
Also mal in die Testphase.
- {{1+2}} zeigt im Browser 3
- {{alert(‘hallo’)}} zeigt im Browser nichts
Der Grund liegt daran, das Angular nicht per eval den Code auswertet, sondern mit einem eigenen Interpreter. Wie genau kann man in der Angular Dokumentation nachlesen. Alles was auf das DOM zugreift und noch viel mehr wird gefiltert. Wer sich lange mit Security beschäftigt, wird wissen, das dies der völlig falsche Ansatz ist. Frühe Ansätze SQL Injection per Regular Expression zu verhindern, gingen den gleichen falschen Weg. Sichere System werden komplett dich gemacht und nur das erlaubt, was definiert für den Task benötigt wird.
Wie es Angular im Detail löst, entzieht sich meiner Kenntnis. Jedenfalls habe ich eine Menge an Tricks im Web gefunden, um aus dieser Sandbox auszubrechen. Alle basieren auf JavaScript als String, das mit ein wenig Tricks zu ausführbaren Code wird.
Matthias Karlsson demonstriert das unter anderem in einem Video. Dieses Exploit wurde vom Angular Team gefixt.
Der Fix löst aber das Problem nicht. Es gibt anders als bei einem Windows Betriebssystem weder ein automatisches Update, noch einen Hersteller der dafür haftet. Eine Microsoft kann es sich nicht erlauben, ein Security Issue ungefixt zu lassen. Open Source Lösungen schieben diese Verantwortung zum Betreiber der Lösung- also der Website. Gerade im Webumfeld lässt sich supereinfach die Version des JavaScript Framework feststellen und liefert damit einen Angriffsvektor.
Darüber hinaus existieren auch aktuelle Sicherheitslecks, um aus der Sandbox auszubrechen. Und es werden immer wieder Neue auftauchen.
Ein relativ neuer Angriff nimmt den $$watcher als Basis. Ganz leicht per JSFiddle für den nächsten Copy Paste Hack. Der Autor beschreibt den Sandbox Escape detailliert.
Ist das alles schlimm oder eher akademischer Natur. Alles easy solange es keiner ausnutzt. Die nächste XSS Attacke wartet nur.
Darüber hinaus habe ich ein Wiki gefunden, das Einstiegs Hilfe für den böswilligen Angreifer liefert.
Fazit
Erschreckend wie einfach man Angular basierte Websites hacken kann. Dabei liegt das Problem im Kern der JavaScript durch JavaScript ausführenden Web Frameworks. Experten können das mit überschaubaren Aufwand in den Griff bekommen. Das aber nur solange aktiv an den Bedrohungsmodellen gearbeitet wird. Die Agilität der JS Frameworks und die steigend Anzahl von Directive oder Modulen die schnell und gerne eingefügt werden, lassen einen sicheren Betrieb meiner Meinung nach im Grunde nach nicht zu.