Broken Access Control
Thema 3 Benoist
Thema 3 Benoist
Was ist gemeint mit Access Control?
- Die Kontrolle, dass ein user nur innerhalb seiner Rechte agieren kann.
Wenn Fehler in der Access Control bestehen, was könnte passieren?
- Es können Files ohne authorisierung angeschaut oder gar modifiziert werden
- Es können Funktionen ausserhalb der Berechtigung ausgeführt werden.
Was ist die Vertikale Eskalation einer broken access control?
- z.B. anonymus user können private funktionen ausführen oder
- regular users können admin funktionen ausführen
Was ist die horizontale eskalation von broken access control?
- user können auf die daten anderer user zugrieffen, z.b. innerhalb selber berechtigungsgruppe
Wenn folgende Funktion in einer Website gebraucht wird:
require_once($_REQUEST['lang']."lang.php");
die URL sieht wie folgt aus:
http://mysite.com/program.php?lang=fr
Was ist hier die Gefahr?
- Es werden direkt Daten aus der URL eingelesen.
Wenn direkte Objektreferenzen in einer URL gemacht werden können und die authorisierung nicht geprüft wird. Was ist das Problem? Nenne ein Beispiel.
- Die Files können von unauthorisierten usern angeschaut werden ;-)
- Z.b. eine URL wie folgt http://mysite.com/program.php?page=124 -> ID kann geändert werden
Welche zwei Probleme haben wir grundsätzlich bei der folgenden URL http://mysite.com/program.php?file=1234, welche dann das file 1234.pdf anzeigt?
- Wenn Autorisierung nicht geprüft wird, kann der Attcker z.B. mit path-traversal den Input so anpassen, dass er irgendwelche weitere Dateien anzeigen kann. z.b. mit ../../frc1/otherDocument
- Es wird eine interne objekt Referenz gegen aussen präsentiert.
Nenne 3 Beispiele, wie solche Manipulationen mit HTTP gemacht werden können?
Wo kann dies auch noch gemacht werden?
- HTTP GET
- HTTP POST
- manipulation anderer HTTP header (cookies, languages, user-agent)
- grundsätzlich auf allen APIs, wo access control nicht geprüft wird.
Nenne einige Beispiele, welche schwieriger zu manipulieren sind als GET, POST etc.
Sie werden auch vom Browser abgesetzt, aber diese kann man nicht so einfach bearbeiten.
Es gibt jedoch ein Tool, welches dies für einem machen kann, wie heisst dieses?
- Cookies, URL rferer
- AJAX
- JSON
- Das Tool heisst ZAP - Zed Attack Proxy
Wenn wir als Beispielt eine API GET Abfrage machen und ein Cookie mitschicken, dass prüft, ob der User eingeloggt ist.
API GET:
GET /resource?item=11111 HTTP/1.1
Host: www.mysite.com
Cookie: SESSIONID=239e98d32c98b23a
Dann ändern wir die item ID ab und jetzt kriegt der User die Daten eines anderen Users zurück. Was ist bei diesem Authentifizierungsverfahren falsch gelaufen?
- Es wurde nur geprüft, ob der User ein Session Cookie hat wo er eingeloggt ist. Keine weitere Autorisierungsschritte wurden geprüft. Somit kann ein eingeloggter User alles sehen.
Wo muss grundsätzlich die Verifizierung stattfinden?
Wenn via URL auf ein Backendsystem (SQL) zugegrifen wird, wo muss diese authentifizierung stattfinden und für wen?
- Auf dem Server
- auf dem SQL server und auf den spezifischen User
Mit welchen zwei Prinzipien müssen einzelne Funktionen oder Seiten vor unzulässigem Zugriff geschützt werden?
- Prüfen, dass der User eingeloggt ist
- Korrekte Rechtevergabe für jede Seite!
Was machen die folgenden Queries?
- Es wird verifiziert, dass der user, welcher die Nummer der Guestbook ID anrfagt, auch berechtigt ist diese zu sehen, zusätzlich werden die Session-Daten der aktuellen Verbindung ausgelesen und geprüft.
Was sollte bzgl. Objektreferenzen verhindert werden?
- Sie sollten nicht direkt abrufbar/änderbar sein. Wie z.B. DB Primary Keys
Was kann gegen die Ausführung von manipulierten Files unternommen werden?
Wie kann nachdem nun doch ein manipuliertes File eingelesen wurde z.B. ein weiterer Interner oder auch externer Zugriff ab dem kompromitierten System verhindert werden?
Was ist zu tun, bovor man ein Programm schreibt?
- Nicht aktzeptieren des Userinputs, um ressourcen, bilder, xml oder scripts abzufragen.
- mittels firewall rules
- genaues/vorsichtiges Planen, deisgning der architektur und des programmes
Falls nun der User trotzdem Daten definieren und mitgeben kann, was muss mit diesem Input gemacht werden?
- Validiieren und protection Strategie "accept known good" anwenden.
-
-
- 1 / 16
-
Cartes-fiches
Was ist gemeint mit Access Control?
- Die Kontrolle, dass ein user nur innerhalb seiner Rechte agieren kann.
Wenn Fehler in der Access Control bestehen, was könnte passieren?
- Es können Files ohne authorisierung angeschaut oder gar modifiziert werden
- Es können Funktionen ausserhalb der Berechtigung ausgeführt werden.
Was ist die Vertikale Eskalation einer broken access control?
- z.B. anonymus user können private funktionen ausführen oder
- regular users können admin funktionen ausführen
Was ist die horizontale eskalation von broken access control?
- user können auf die daten anderer user zugrieffen, z.b. innerhalb selber berechtigungsgruppe
Wenn folgende Funktion in einer Website gebraucht wird:
require_once($_REQUEST['lang']."lang.php");
die URL sieht wie folgt aus:
http://mysite.com/program.php?lang=fr
Was ist hier die Gefahr?
- Es werden direkt Daten aus der URL eingelesen.
Wenn direkte Objektreferenzen in einer URL gemacht werden können und die authorisierung nicht geprüft wird. Was ist das Problem? Nenne ein Beispiel.
- Die Files können von unauthorisierten usern angeschaut werden ;-)
- Z.b. eine URL wie folgt http://mysite.com/program.php?page=124 -> ID kann geändert werden
Welche zwei Probleme haben wir grundsätzlich bei der folgenden URL http://mysite.com/program.php?file=1234, welche dann das file 1234.pdf anzeigt?
- Wenn Autorisierung nicht geprüft wird, kann der Attcker z.B. mit path-traversal den Input so anpassen, dass er irgendwelche weitere Dateien anzeigen kann. z.b. mit ../../frc1/otherDocument
- Es wird eine interne objekt Referenz gegen aussen präsentiert.
Nenne 3 Beispiele, wie solche Manipulationen mit HTTP gemacht werden können?
Wo kann dies auch noch gemacht werden?
- HTTP GET
- HTTP POST
- manipulation anderer HTTP header (cookies, languages, user-agent)
- grundsätzlich auf allen APIs, wo access control nicht geprüft wird.
Nenne einige Beispiele, welche schwieriger zu manipulieren sind als GET, POST etc.
Sie werden auch vom Browser abgesetzt, aber diese kann man nicht so einfach bearbeiten.
Es gibt jedoch ein Tool, welches dies für einem machen kann, wie heisst dieses?
- Cookies, URL rferer
- AJAX
- JSON
- Das Tool heisst ZAP - Zed Attack Proxy
Wenn wir als Beispielt eine API GET Abfrage machen und ein Cookie mitschicken, dass prüft, ob der User eingeloggt ist.
API GET:
GET /resource?item=11111 HTTP/1.1
Host: www.mysite.com
Cookie: SESSIONID=239e98d32c98b23a
Dann ändern wir die item ID ab und jetzt kriegt der User die Daten eines anderen Users zurück. Was ist bei diesem Authentifizierungsverfahren falsch gelaufen?
- Es wurde nur geprüft, ob der User ein Session Cookie hat wo er eingeloggt ist. Keine weitere Autorisierungsschritte wurden geprüft. Somit kann ein eingeloggter User alles sehen.
Wo muss grundsätzlich die Verifizierung stattfinden?
Wenn via URL auf ein Backendsystem (SQL) zugegrifen wird, wo muss diese authentifizierung stattfinden und für wen?
- Auf dem Server
- auf dem SQL server und auf den spezifischen User
Mit welchen zwei Prinzipien müssen einzelne Funktionen oder Seiten vor unzulässigem Zugriff geschützt werden?
- Prüfen, dass der User eingeloggt ist
- Korrekte Rechtevergabe für jede Seite!
Was machen die folgenden Queries?
- Es wird verifiziert, dass der user, welcher die Nummer der Guestbook ID anrfagt, auch berechtigt ist diese zu sehen, zusätzlich werden die Session-Daten der aktuellen Verbindung ausgelesen und geprüft.
Was sollte bzgl. Objektreferenzen verhindert werden?
- Sie sollten nicht direkt abrufbar/änderbar sein. Wie z.B. DB Primary Keys
Was kann gegen die Ausführung von manipulierten Files unternommen werden?
Wie kann nachdem nun doch ein manipuliertes File eingelesen wurde z.B. ein weiterer Interner oder auch externer Zugriff ab dem kompromitierten System verhindert werden?
Was ist zu tun, bovor man ein Programm schreibt?
- Nicht aktzeptieren des Userinputs, um ressourcen, bilder, xml oder scripts abzufragen.
- mittels firewall rules
- genaues/vorsichtiges Planen, deisgning der architektur und des programmes
Falls nun der User trotzdem Daten definieren und mitgeben kann, was muss mit diesem Input gemacht werden?
- Validiieren und protection Strategie "accept known good" anwenden.
-
