6. Web Entwickler¶

6.1. HTTP Protocol (optional)¶

6.1.1. Grundverständnis des Protokols in Bezug auf Request und Response Header (optional)¶

6.1.2. Grundverständnis des Cachings (optional)¶

6.1.3. Grundverständnis von redirects (location header) (optional)¶

6.2. Sicherheit¶

6.2.1. Denial-of-service attacks (optional)¶

6.2.2. HTTPS / HTTP Mixed content (optional)¶

6.2.3. Referer header: privacy and security concerns (optional)¶

6.2.4. Same-origin policy (z.B. bei Ajax) (optional)¶

6.2.5. Session hijacking (optional)¶

6.2.6. SQL Injection¶

Als „SQL Injection“ wird ein Angriff bezeichnet, bei welchem schadhaftes SQL ausgeführt wird. Dies kann bei jeder Interaktion mit der Datenbank geschehen. Typische Angriffszenarios sind z.B.:

Löschen von Informationen: Bei diesem Angriff werden Inhalte, oder ganze Datenbanken gelöscht.
Zugriff auf geschützte Informationen: Bei diesem Angriff wird versucht weitere Daten auszugeben, z.B. in einer Übersicht von Kontaktdaten auch Kontaktdaten anderer Nutzer.
Manipulieren geschützter Informationen: Bei diesem Angriff wird versucht Daten zu manipulieren, z.B. das Anlegen eines eigenen Administrator Accounts.

Grundsätzlich kann der Angriffsweg nahezu neutralisert werden, wenn die zur Verfügung stehende API von Extbase und Doctrine korrekt genutzt wird. In diesen Fällen werden alle Parameter escaped. Wird eine low-level API verwendet, oder die vorhandene API nicht korrekt, so müssen etwaige Parameter manuell abgesichert werden.

Die entsprechenden APIs und Hinweise sind unter createNamedParameter() dokumentiert.

Bemerkung

Grundsätzlich gilt nach wie vor, Nutzereingaben sind potenzielle Angriffe.

6.2.7. Remote Code Execution¶

Konkretes Beispiel „“File Operation Induced Unserialization via the „phar://“ Stream Wrapper“ (PDF). Secarma Labs. 2018.“:

The way links are processed as they are inserted into content within the application allows an attacker (with the ability to add content to the system) to completely control the value used in a call to „file_exists“:

The relevant code was located within /typo3/sysext/core/Classes/Database/SoftReferenceIndex.php:
1
2
3
} elseif ($containsSlash || $isLocalFile) { // file (internal)
   $splitLinkParam = explode('?', $link_param);
   if (file_exists(rawurldecode($splitLinkParam[0])) || $isLocalFile) {
This couldbe reached from a variety of user controlled input, a simple example is when attaching a link to an image -by setting a value such as „phar%3a//../fileadmin/user_upload/typo3.jpg/xxx.txt“ (note: „:“ must be urlencoded to „%3a“ to follow the vulnerable code path) the application would attempt to access typo3.jpg as a Phar file and unserialize any metadata contained therein.

—https://cdn2.hubspot.net/hubfs/3853213/us-18-Thomas-It’s-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-….pdf?

Weitere Infos zu der Sicherheitslücke: https://typo3.org/security/advisory/typo3-core-sa-2018-002/

Grundsätzlich gibt es etliche Stellen an welchen Code ausgeführt wird oder werden kann. Eine Stelle ist das deserializieren was in PHP an etlichen Stellen geschieht. Das obige Beispiel veranschaulicht dies anhand von phar Dateien. Gleiches gilt aber auch beim deserializieren von PHP Objekte, z.B. in der Nutzersession oder der Datenbank und Caches.

Darüber hinaus werden teilweise Systembefehle ausgeführt. Ein Beispiel hierfür ist die Extension https://github.com/web-vision/typo3-wv_pdfgen. Um PDFs zu erzeugen wird das Programm wkhtmltopdf mittels exec aufgerufen. Dabei sollten alle Argumente und Befehle escaped werden. Ansonsten können Angreifer beliebige Befehle auf dem System ausführen.

Inhalt