Lade...
 

Sicherheitsrisiken

Sicherheitsrisiken

Diese Seite gibt einen Überblick über die wichtigsten Sicherheitslücken, die ein InstantView-Entwickler bei der Entwicklung vermeiden sollte.

 

OS Command Injection

Szenario

Diese Art von Attacken entsteht, wenn Shell-Funktionen wie RunSystemShell, System, System2, Execute, Execute2, etc. mit Variablen und nicht nur mit String-Konstanten benutzt werden. Die Gefahr besteht darin, dass diese Variablen Benutzereingaben enthalten können, sowohl direkt von aktuellen Benutzereingaben aus der Oberfläche oder von gespeicherten Daten in der Datenbank, die der Benutzer schon vorher manipuliert hat.

Durch Manipulieren des Command-Strings könnte der Angreifer alles auf dem Server ausführen, wofür die ClassiX-Instanz Rechte hat. Dies macht diese Angriffsart zu eine der folgenschwersten Attacken, deswegen muss bei jeder Benutzung einer solchen Anweisung extrem aufmerksam aufgepasst werden.

 
Gegenmaßnahmen

Diese Attacke kann leider durch das Basissystem nicht verhindert werden, ohne den Sinn der Shell-Funktionen zu verlieren. Am sichersten wäre, wenn diese Shell-Funktionen nicht existieren und alle Aufgaben per normale Methodenaufrufe erledigt würden. Insbesondere in Zusammenhang mit Legacy-Systemen gibt es allerdings Fälle, wo man auf die Shell-Funktionen nicht verzichten kann. 

Empfehlenswert wäre von der Basisseite aus, diese Shell-Funktionen auf eine einzige Funktion zu reduzieren und beim Code-Parsen in Development-IDE mit einer Warnung darauf aufmerksam zu machen, welche Gefahren diese Funktion birgt. 

Gegen Shell-Metacharacters wie [&, &&, |, ||, 0x0a, etc.] zu filtern ist keine empfehlenswerte Gegenmaßnahme, da die Erfahrung zeigt, dass die Blacklist-Filterung nie vollständig sein kann. Bei einer solchen schwerwiegenden Sicherheitslücke sollte man kein Risiko eingehen.

Die einzige Gegenmaßnahme besteht darin, nur White-Lists, Zahlen oder Alphanumerische Strings ohne Leer- oder Sonderzeichen zuzulassen.  

 

Query Injection

Szenario

Diese Attacke ist als SQL-Injection bekannter. Da wir in ClassiX keine SQL-Abfragen durchführen, sind wir gegen SQL-Injection-Angriffe geschützt. Die SQL-Injection-Attacke könnte man allerdings teilweise auf die Welt von ClassiX übertragen und sie als Query-Injection-Attacke definieren.

Query-Strings werden in ClassiX nur zur Datenabfrage mittels Find, FindExist, FindFirst, etc. benutzt. Daher kann man die Datenbank nicht direkt durch mit Schadcode behafteten Query-Strings manipulieren. Das ist ein wesentlicher Unterschied zur SQL-Injektion. Das einzige, was man allerdings tun kann, ist, die Query-Strings so zu gestalten, dass die Query mehr Objekte zurückgibt, als der Benutzer Rechte dazu hat. Durch das Anzeigen von solchen Objekten und durch eine fehlende Überprüfung der Rechte beim Verändern eines DB-Objektes kann man durch manipulierte Query-Strings indirekt die DB-Objekte verändern.

Diese Query-Injection-Attacke ist nur möglich, wenn der IV-Entwickler die „%s“ Parameter nicht benutzt und die Query-Strings selber durch Konkatenation mit anderen Variablen zusammensetzt. 

Gegenmaßnahmen

Die ausschließliche Benutzung von der Formatierungssyntax und das Vermeiden der einfachen Konkatenation von Query-Strings mit Variablen, auf die der Benutzer direkt oder indirekt Einfluss hat.

 

File Path Traversal

Szenario

Diese Attacke ist in ClassiX in Zusammenhang mit Anweisungen wie OpenDocument, LoadFromFile, SaveToFile etc. möglich, und ist prinzipiell ohne die Aufmerksamkeit des IV-Entwicklers nicht zu verhindern. Es handelt sich darum, dass der Angreifer durch Manipulation eines Dateinamens zu einer anderen Datei gelangt, auf die er kein Zugriffsrecht hat. Dies kann sowohl beim Lesen als auch beim Schreiben relevant sein.

Die Dateien manipulierenden Instruktionen dürfen ihre Parameter nicht blind aus Widgets beziehen, die direkt oder indirekt durch den Benutzer manipuliert werden. Fatal wäre es, wenn der Eingabe des Benutzers der ganze Pfad entnommen wird, dann kann der Benutzer nämlich auf jedes Laufwerk und jede Datei zugreifen. Typisch wird allerdings nach einem Dateinamen „gefragt“ und dieser wird mit einem Pfadpräfix kombiniert und hier kommt diese Attacke zustande, indem der Angreifer Traversierungszeichen wie „../“ verwendet, um das Pfadpräfix umzugehen.

Gegenmaßnahmen

Die Benutzereingabe muss vor der Konkatenation auf „..“ , „/“ und „\“ überprüft werden. Noch sicherer wäre es, nach der Konkatenation mittels IV-File/Directory-Befehle herauszufinden, ob der konkatenierte Pfad (also die Datei) sich im richtigen Verzeichnis (identisch mit dem Pfadpräfix) befindet.