Rolf B: Login-System mit AJAX, Sicherheitslücke?

Beitrag lesen

Hallo Hans,

grundsätzlich ist es so, dass ein fetch() oder XMLHttpRequest, der in einem Script von Origin A abgesetzt wird, nur auf Ressourcen des Origin A zugreifen darf.

Das kann man mittels CORS aufweichen (Access-Control-* Header), womit der Server explizit erlauben kann, dass ein Script, das auf einer Seite ausgeführt wird, auch auf Ressourcen von Origin B und C zugreifen darf.

Wenn DU jetzt eine Fake-Seite auf Origin F baust und dort eigene Scripte hast, die im Hintergrund auf Origin A zugreifen und dort Schabernack treiben, hast Du es in der Hand, diesen Zugriff per CORS zu gestatten.

Weshalb es zwingend notwendig ist, Berechtigungen auch Serverseitig zu überprüfen. Ein Login darf nicht nur clientseitig erfolgen, es muss auch mit dem Server abgeglichen werden, und nur, wenn der Server den Login bestätigt und eine Session-ID (oder ein Authentication-Token oder was weiß ich was sonst) darf der Client weitermachen. Server-Requests benötigen dieses Token und der Server muss stets prüfen, ob die Aktion, die mit diesem Token ausgeführt werden soll, dem Besitzer dieses Tokens auch gestattet ist.

Natürlich kann man clientseitig ebenfalls Berechtigungen verwalten, um einem Benutzer keine Funktionen anzubieten, die sie eh nicht ausführen darf. Das ist aber letztlich eine Komfort-Funktion und nicht die eigentliche Security-Hürde.

Ich nehme an, dass die ersten naiven Ajax-Seiten das nicht beachtet haben. Die richtigen Vordenker werden sicherlich dazu etwas gesagt haben, aber Hobbyentwickler, die das dann begeistert selbst eingebaut haben, dürften etliche Löcher gelassen haben. Die damaligen Browser hatten auch noch keine Idee von Cross-Site Scripting und CORS-Headern. Dementsprechend gab es genug Schindluder. Das hat sich erst im Laufe der Jahre entwickelt und immer weiter verschärft.

Rolf

--
sumpsi - posui - obstruxi