Sicherheit in CONTENTSERV ab CS11 Frank Ipfelkofer

TOP 10 Sicherheitsrisiken ( A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross-Site Request Forgery (CSRF) A6:Security Misconfiguration A7: Insecure Cryptographic Storage A8: Failure to Restrict URL Access A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards

Injection - Probleme Eingabeparameter werden ungeprüft und nicht escaped übergeben: Systemaufrufe: Exec („ls“. $_GET[„folderName“]); folderName=„/|rm –r“ PHP-Aufrufe: Include($_GET[„file“]);&file=„/etc/...“ Eval($_GET[„phpCode“]); Dateioperation: FileXXX($GET[„file“]), Unlink($_GET[„file“]),... Datenbank SQL Injection: ‘SELECT * FROM WHERE ID = “‘.$id.’ “‘ id= 0“ OR 1=1 “

Injection - Absicherung Alle Request-Parameter mittels CSSecurity.xml schützen Dynamische Parameter vermeiden und auf jeden Fall escapen: ’...AND ID = “ ‘.Database::quote($id) Keine dynamischen Includes (wenn dann unbedingt geschützt) Wenn möglich keinen dynamischen PHP-Code ausführen. CSSecurity::evalCommand($phpCode, $context = array()) verwenden (könnte zentral abgesichert werden – ist aber kein 100% Schutz) CSFileUtils nutzen für Dinge wie readfile, fopen,... Prozesse über CSSystemUtils::executeCommand ausführen...

Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) Per Javascriptcode COOKIES auslesen bzw. Code ausführen, z.B. im Sessioncontext irgendwelche Aktionen ausführen. foo= ' 〉〈 script 〉 document.location= ' bin/cookie.cgi?foo='+document.cookie 〈 /script 〉 echo $_GET[‚title‘]; title = alert(„attack“) Universelles Angriffspattern ( ';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))/ /--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>=&{}

Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF) – Absicherung Alle Ausgaben mit CS::htmlentities() verwandeln echo CS::htmlentities($_GET[‚title‘]); Dynamische Parameter mit HTML-Eingabe vermeiden CSSecurity.xml nutzen Schnellabsicherung: CSSecurity.xml verwenden

Insecure Direct Object References Failure to Restrict URL Access Rechteprüfung von Objekten ist nicht ausreichend. Gib mir alle Objekte oder zeige Objekt XYZ an. showProduct&ProductID=2showProduct=5 Ob Seiten aufgerufen werden dürfen wird nur an der Stelle überprüft, an dem Links erstellt werden. Wenn dieser Link bekannt ist, kann man auch ohne das Recht die Seite sehen, z.B. früher beim Rolleneditor

Insecure Direct Object References Failure to Restrict URL Access Objektrechteprüfung sollten bewusst bedacht werden - ist z.B. in der Standard-API bei Massenanfragen wie getChildren und search schon der Fall – aber nicht bei Einzelabfragen CSPdm::getProduct(). Seiten, die sensible Daten beinhalten oder ändern können, sollten direkt zu Beginn überprüfen, ob ein Benutzer das Recht hat, auf diese zuzugreifen. CSSecurity.xml mit verwenden

Unvalidated Redirects and Forwards Seiten könnten geschützt sein, z.B. durch CSSecurity.xml, ZBV,... Wenn man diese jedoch direkt inkludiert, (bzw. über redirects aufruft) kann diese Sicherung umgangen werden Include(„.../popups/“.$_GET[„file“]);

Unvalidated Redirects and Forwards - Absicherung s. Injection: keine oder nur abgesicherte dynamische Includes oder redirects verwenden

Absicherung mit der CSSecurity.xml CSSecurity.xml – Dateien können an allen Stellen eingebunden werden, die: direkt über &forward= inkludiert werden ein Template einer Story im CMS sind Entweder platziert man eine Absicherung direkt neben der Datei oder in einem Überordner

Beispiel einer CSSecurity.xml gui/dialogs/RenameFile.php...

Aufbau der CSSecurity.xml Security ist das Root-Element und kann beliebig verschachtelt werden, wenn z.B. Variablen oder Rechte in einem Ordner definiert sind, gelten sie für alle Unterordner. Includes enthält die Pfade aller erlaubten Dateien (relativ zu der CSSecurity.xml – Datei) Variables definiert alle erlaubten Variablen Rights definiert welche Rechte ein Benutzer haben muss, damit er die definierten Pfade verwenden darf.

Includes und Path Elemente Path enthält die Pfade zu den Dateien, die mit forward oder in einem CMS-Template eingebunden werden dürfen. Pfade sind relativ zu der CSSecurity.xml Der Platzhalter * darf verwendet werden, sollte aber vermieden werden, da damit wieder unerlaubte Zugriffe ermöglicht werden könnten.

Variables - Elemente Variables definiert, welche Variablen durchgelassen werden. Alle Variablen, die dort nicht erlaubt sind, werden aus allen REQUEST- Variablen entfernt. Das Attribut name definiert den Namen von erlaubten Attributen: Mehrere können durch | getrennt werden Platzhalter * ist erlaubt (aber auch hier mit Vorsicht genießen) Reguläre Ausdrücke möglich (Beginnt mit „/“): name="/^Text[0-9]+$/" Mit type kann man die Variable auf get oder post beschränken Mit pattern kann man einen regulären Ausdruck angeben, auf den die Variable zutreffen muss

Unterelemente von Variables konvertiert den Wert in eine Zahl oder entfernt die Variable erlaubt nur unkritischen Text, d.h. keine Größer- /Keinerzeichen oder Anführungszeichen überprüft, ob ein Boolean ist („true“, „1“, „on“, „0“,...) und gibt diesen Wert zurück – ansonsten wird die Variable entfernt entfernt die Variable immer jagt den übergebenen Text immer, durch CS::htmlentitites, so dass hiermit z.B. Titel an Dialoge übergeben werden könnten, die direkt ausgegeben werden. erlaubt jegliche Eingabe. Ist somit ein möglicher Angriffspunkt. Lässt sich aber leider nicht überall umgehen (Inputs, die HTML enthalten können)

Unterelemente von Variables- Teil 2 Dateinamen können über geschützt werden Mit werden relative Pfade erlaubt, die nur in Unterverzeichnisse oder../{PROJEKT} oder../admin zeigen dürfen. (Keine führenden Slashes, Doppelpunkte, “../“, etc. Eine bestimmte Anzahl von Werten kann in Listen definiert werden: bar bar2

Unterelemente von Variables- beste Sicherheit erlaubt nur Variablen die geschützt sind mittels: ‘&'.CSSecurityUtils::getSecuredURLParameter('uwaUrl', $uwaURL)  &uwaUrl=portal%2FCSStudioWidget.php&d18=a3 erlaubt die Variable nur, wenn alle aus in einer komplett geschützten URL unverändert vorhanden sind: CSSecurityUtils::getSecuredURL('forward.php?foo1=bar&foo2=bar‘) Weitere nicht geschützte dürften hinten hinzugefügt werden. Formulare können bei Erstellung mit einer CSGuiForm geschützt werden.

Vordefinierte Variablen Mit können schon einmal definierte Variablen wiederverwendet werden. XXX zeigt auf einen globale ID: XXX zeigt auf eine mit definierte Definition innerhalb derselben Datei XXX zeigt auf eine mit definierte Definition innerhalb einer anderen Datei refid=“modules/pdm/CSSecurity.xml#foo“

Beispiel: admin/dialogs/CSSecurity.xml RecordInputDialog.php......

Absicherung von JSON-Strings Auch JSON-Objekte können abgesichert werden: JSON beginnt dabei die Variable und wird beim Fehler komplett entfernt. Object definiert ein Objekt Arrays brauchen in ihren Elementen kein name Attribute {ID:0, Dateien:[{ID:2, Pfad=„volumes/datei.txt“, Dateien:[{...}] }] }

Rechtevergabe Mit kann man Rechte definieren, die erfüllt sein müssen, damit ein Benutzer den Include sehen darf (Failure to Restrict URL Access) Darin kann man zwei Arten von Rechten definieren: if (!($record = CS::getRecord(getStringVariable('Class'))) return „no record!“;

Unterelemente von Variables- mit Rechten Auch einzelne Variablen können mit Rechten abgesichert werden

Prinzipielle Sicherheitsüberlegungen Wenn man Absicherungen erstellt, sollte man versuchen Whitelisten zu verwenden und keine Blacklisten, da man leicht irgendwas übersieht: Beispiel: /ˆ[a-zA-Z0-9_]*$/ und nicht /ˆ[ˆ<>]*$/‘ Wenn möglich sollte man Daten über POST übertragen, da diese ein wenig sicherer sind. Upload von Dateien nur in Ordner (oder Volumes), die gegen direkten Zugriff geschützt sind (z.B. mit.htaccess), so dass man dort keine Skripte ausführen darf.

Prinzipielle Sicherheitsüberlegungen – Teil 2 Alle Einstiegspunkte (außerhalb den definierten) sind über.htaccess unterbunden worden (im admin und im Projekt), d.h. alle PHP-Dateien außer index.php im Projekt sind verboten und werden immer über die index.php angesprochen werden. Anfragen auf folgende Dateiendungen werden durchgelassen: css|js|gif|jpg|png|swf|htm|txt Folgende PHP-Dateien sind Sicherheitsgeprüft und dürfen direkt aufgerufen werden (der Rest nur über abgesicherte Includes): blank.editor.php | loading.php | FileServer.php | forward.php | ImageServer.php | index.php | login.php | install.php | internalforward.php | loading.php | ping.php | portal.php core/extensions/skin/CSSkinImage.php | classes/utils/CSAjaxAction.php

Wie (de-)aktiviert man die Sicherheit In admin.local/conf eine Datei Security.ini anlegen: debug_security_warnings = on (Produktiv: off) use_security_xml = on check_security_path = ignore(Produktiv: on) check_security_variables = exception (oder Produktiv: remove) check_security_rights = full In CS11.1 ist ein Editor dafür geplant. Hilfsskript: admin/forward.php?forward=core/extensions/security/CSSecurityCreator. php analysiert die Debugdatei (data/logs/debug/requests.csv) und gibt alle darin enthaltenen Includes und Variablen als XML aus.

Beispiel der CSSecurityCreator.php Ausgabe

Zusammenfassung Optimal wäre es alle URLs mit CSSecurity::getSecurityURL() zu schützen und mit überprüfen. Ist aber teilweise aufwendiger und geht nicht für dynamische Variablen Formulare mit der CSGuiForm aufbauen Ansonsten für alle Templates, forward-URLs und Projektmodule alle erlaubten Variablen mit CSSecurity.xml versehen Alles andere über.htaccess schützen Zentrale Methoden verwenden: CSSecurityUtil::evalCommand CSystemUtils::executeCommand CSFileUtils::readFile, CSFileUtils:...