Isolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012

Transkript

1 Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012

2 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false); con.settransactionisolation( Connection.TRANSACTION_READ_UNCOMMITTED); con.commit(); con.close();

3 Transaktions-Isolationsstufen read uncommitted schwächste Stufe, uncommittete Änderungen werden auch gelesen read committed nur committeteänderungen werden gelesen (keine dirty reads) repeatable read erneutes Lesen enthält mindestens die vorher gelesenen; es können aber neue hinzugekommen sein (keine dirty reads und non-repeatable reads) serializable garantiert eine serielle Ausführung

4 Übersicht Isolationsstufen Isolationsebene Dirty Read Non-Repeatable Read Phantom Read Read Uncommitted möglich möglich möglich Read Committed nicht möglich möglich möglich Repeatable Read nicht möglich nicht möglich möglich Serializable nicht möglich nicht möglich nicht möglich

5 Auszug aus SQL 92 1) P1 ("Dirty read"): SQL-transaction T1 modifies a row. SQL-transaction T2 then reads that row before T1 performs a COMMIT. If T1 then performs a ROLLBACK, T2 will have read a row that was never committed and that may thus be considered to have never existed. 2) P2 ("Non-repeatable read"): SQL-transaction T1 reads a row. SQL- transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted. 3) P3 ("Phantom"): SQL-transaction T1 reads the set of rows N that satisfy some <search condition>. SQL-transaction T2 then executes SQL-statements that generate one or more rows that satisfy the <search condition> used by SQL-transaction T1. If SQL-transaction T1 then repeats the initial read with the same <search condition>, it obtains a different collection of rows.

6 Transaktions-Isolationsstufen Man beachte in Java: Wird eine Isolationsstufe nicht unterstützt, kann diese durch eine höhere Stufe substituiert werden. Eine SQLExceptionwird nur dann geworfen, wenn dies nicht möglich ist. Die möglichen Isolationsstufen können über DatabaseMetaData.supportsTransactionIsolationL evel erfragt werden.

7 MySQL5.1 Referenzhandbuch Besonderheiten des DBMS beachten!!! Statements können nicht zurückgerollt werden Es gibt Anweisungen, für die kein Rollback möglich ist. Hierzu gehören DDL-Anweisungen (Data Definition Language), z.b. solche, mit denen Datenbanken erstellt oder gelöscht oder Tabellen oder gespeicherte Routinen erstellt, gelöscht oder geändert werden.

8 Anweisungen, die implizite Commits verursachen Alle folgenden Anweisungen (und ggf. auch ihre Synonyme) beenden eine Transaktion implizit so als ob Sie vor Ausführung der Anweisung eine COMMIT- Anweisung abgesetzt hätten: ALTER FUNCTION, ALTER PROCEDURE, ALTER TABLE, BEGIN, CREATE DATABASE, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP FUNCTION, DROP INDEX, DROP PROCEDURE, DROP TABLE, LOAD MASTER DATA, LOCK TABLES, RENAME TABLE, SET AUTOCOMMIT=1, START TRANSACTION, TRUNCATE TABLE, UNLOCK TABLES.

9 Lock Escalation Hierunter versteht man den Wechsel auf eine höhere Sperrgranularität, z.b. von Attribut Tupel Tabelle Dieser Wechsel ist nicht unproblematisch. Es Dieser Wechsel ist nicht unproblematisch. Es kann zu Verklemmungen (Deadlocks) und Performanceeinbrüchen kommen.

10 Unterstützung des DBMS DBMS Parameter beachten, z.b. wie viel Platz ist zum Halten der Sperren vorgesehen? Beispiel IBM DB2: LOCKLIST die Speichergröße für Sperren MAXLOCKS gibtan wievielprozenteine Anwendung die Sperrliste belegen muss, damit eine Lock Escalation durchgeführt wird.

11 Unterstützung des DBMS <transaction access mode> ::= READ ONLY READ WRITE SET TRANSACTION READ ONLY; select [for update LOCK IN SHARE MODE]; (DB2): Sperrgranularitätkannauchdurchden Anwender definiert werden, z.b. mit: ALTER TABLE <table_name> LOCKSIZE { ROW TABLE }

12 SQL Injection

13 Mögliche Gefahren Zusätzliche Statements einzufügen: Eingabe: 1; drop mytable # select * from mytable where id = 1; drop mytable #?? Direkter Schaden an der Datenbank, eventuell Ausfall der Applikation.

14 Mögliche Gefahren Zusätzliche Bedingungen einzufügen: Eingabe: 1 or id > 1 or name like % select * from mytable where id = 1 or 1 or name like %?? Daten der Tabelle können ausgespäht werden.

15 Mögliche Gefahren Verknüpfung mit UNION: Eingabe: 1 union select * from yourtable where id = 1# select * from mytable where id = 1 union select * from yourtable where id = 1#?? Daten auch anderer Tabellen können ausgespäht werden. man beachte, dass beim UNION-Operator die Anzahl der Spalten und deren Typen gleich sein muss!

16 Was möglich ist hängt ab von DBMS Erlaubt es mehrere SQL-Statements gleichzeitig auszuführen? Welche Zeichen werden als Kommentare interpretiert? (z.b.:--oder#) Verbindungsart / Programmiersprache JDBC, ODBC,???

17 Gegenmaßnahmen DB-Verbindung nur mit den Rechten, die nötig sind aufbauen! (siehe GRANT und REVOKE) Nutzungvon Prepared Statements (in Java) Nutzung von statischem SQL, z.b. SQLJ Möglichst wenig Informationen über die Datenbank nach außen geben! z.b. bei Fehlermeldungen Eingaben auf Sonderzeichen und ungültige Werte prüfen(möglichstzurückweisen!) Anwendungdiesbezüglichtesten(testenlassen)

18 GegenmaßnahmenPHP Positivlisten Methode wurde eingegeben was man erwartet? Negativlisten Methode Ablehnung von Schlüsselwörtern Gegebene Funktion in PHP: mysql_real_escape_string() Sie Maskiert alle Zeichen mit denen man aus den Anführungszeichen ausbrechen kann. Kombination aller 3 ist die sicherste Variante. Siehe auch:

19 Literaturhinweise Handling Java Web Application Input, Part 1 von Stephen Enright Advanced SQL Injection In SQL Server Applications von Chris Anley (more)