A5 - Zugriffskontrolle

vorige Präsentation: A4 - XXE | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A6 - Fehlkonfiguration

Auf Platz 5 der OWASP Top 10 2017: Fehler in der Zugriffskontrolle

Die OWASP beschreibt dieses Problem allgemein so:

[…] Anwendungen realisieren Zugriffsberechtigungen nur durch das Anzeigen oder Ausblenden von Funktionen in der Benutzeroberfläche. Allerdings muss auch beim direkten Zugriff auf eine geschützte Funktion eine Prüfung der Zugriffsberechtigung auf dem Server stattfinden, ansonsten können Angreifer durch gezieltes Manipulieren von Anfragen ohne Autorisierung trotzdem auf diese zugreifen.

Nur was serverseitig geprüft wird ist sicher

Bei der Programmierung von Web-Applikationen muss man sich immer bewusst sein, dass Alles was im Client passiert, bzw vom Client geschickt wird, manipuliert werden kann. Meine serverseitigen Programme müssen jeden Input den sie bekommen selbst prüfen, und können sich nicht darauf verlassen dass so eine Prüfung bereits am Client passiert ist.

Gängige Fehleinschätzungen dieser Art sind:

Beispiele

Ich benutze ein Online Banking System. Die URL meines Kontos ist

https://www.onlinebank.com/user?acct=6065

Ich verändere die URL, und probiere aus ob ich so Zugang zu weiteren Konten erhalte:

https://www.onlinebank.com/user?acct=6066

Ich benutze ein Galerie um Fotos zu betrachten. Die URL für ein bestimmtes Bild ist

https://www.photos.com/show?img=100-0011_IMG.jpg&text=100-0011_IMG.txt

Ich verändere die URL, und versuche so die Anzeige von interessanten Dateien im System zu verursachen:

https://www.photos.com/show?img=100-0011_IMG.jpg&text=/etc/passwd

Jede PHP-Datei, Jede URL ist ein Einstiegspunkt

Jede einzelne PHP-Datei die im Webspace liegt kann auch direkt über HTTP aufgerufen werden. Es bietet sich deswegen an in jeder PHP-Datei zuerst die Zugriffsrechte zu prüfen.

Php Code Prüfung der Zugriffsrechte am Anfang jeder PHP-Datei

<?php
  include "functions.php";
  check_permissions();
  // .... 

Mit der Funktion check_permissions haben wir hier eine zentrale Stelle geschaffen, an der alle Zugriffsrechte konfiguriert werden können.

Vermeidung von unsichere direkten Referenzen

Und in jedem Fall:

Slugs statt Keys

Slugs sind lesbare Texte, die einen Datensatz eindeutig identifizieren. Sie werden in der URL statt IDs verwendet. Sie sind auch unter dem namen “friendly urls” und (z.B. in Wordpress) “permalinks” bekannt.

Die Verwendung von Slugs hat mehrere Vorteile:

  1. Das erraten eines weiteren Keys ist nicht so leicht wie bei Zahlen
  2. URLs werden dadurch leichter lesbar und sind leichter zu erinnern
  3. Auch Suchmaschinen lesen den Text des Slugs, die Seite kann auch unter den Stichwörtern des Slugs gefunden werden

Mit folgender Konfigurations-Datei .htaccess wir der Apache-Webserver angewiesen beim Aufruf der URL /item/text-der-slug in Wirklichkeit das PHP-Programm view_item.php mit dem Parameter slug=text-der-slug aufzurufen:

Plain Code .htaccess

RewriteEngine on

RewriteRule ^item/([-a-z]+) view_item.php?slug=\$1

Die Zugriff auf den Parameter in PHP erfolgt wie gewohnt über $_GET.

Kein Zugriff auf beliebige Dateien

Die Erwähnung von Dateinamen als Parameter in der URL ist immer eine schlechte Idee. Betrachten wir das schlechte Beispiel von Oben noch einmal:

https://www.photos.com/show?img=100-0011_IMG.jpg&text=100-0011_IMG.txt

Eine denkbar schlechte Implementiereung dieser Galerie wäre:

Html Code Beliebiger Zugriff auf Dateien - NICHT SO PROGRAMMIEREN!

  <img src="<?= $_GET['img'] ?>">
  <?php
  include $_GET['text'];  // nicht so programmieren!!!
  ?>

Mit diesem Programm kann man durch einfaches ändern der URL beliebige Dateien am Server “erforschen”.

Gegen diese Art von Attacke kann man an mehreren Linien verteidigen:

Mehr

Die OWASP bietet noch vertiefende Informationen zu diesem Thema an:

A5 - Zugriffskontrolle

vorige Präsentation: A4 - XXE | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A6 - Fehlkonfiguration

/

#