Angriffe auf Webanwendungen – Teil 4: CSRF

Publiziert am 28. November 2010 von david

Vorherige Teile der Serie

CSRF steht für Cross-Site Request Forgery und läuft komplett beim Opfer ab. Das einzige, was der Angreifer tut, ist dem Opfer einen speziellen Link zuzuschicken. GMail war mal anfällig für CSRF-Attacken. Dass klar wird, was sich genau dahinter verbirgt, gibts erstmal ein Beispiel.

Beispielangriff

Das Opfer ist bei facebook eingeloggt – was man ja sowieso als facebook-User quasi immer ist, auch wenn man nicht auf der Seite selbst unterwegs ist. Jetzt schickt der Angreifer dem Opfer einen durch einen URL-Shortener verschlüsselten Link zu, der aber in echt 

http://www.facebook.com?deleteAccount=1
… Den ganzen Post lesen
Veröffentlicht unter php, Security, webdev | 6 Kommentare

Angriffe auf Webanwendungen – Teil 3: SQL-Injection

Publiziert am 28. November 2010 von david

Vorherige Teile der Serie

Okay, ich schäme mich fast, darüber noch was zu schreiben. Man möchte doch meinen, dass SQL Injection DER bekannteste Angriff überhaupt ist. Möchte man meinen. Bisher hat sichs aber immer noch nicht bis zum letzten Webentwickler rumgesprochen, weswegen ich hier mal 2 konkrete Beispiele liefere, an denen man herumexperimentieren kann.

Was ist SQL-Inection?

Wenn ein Benutzer der Anwendung die Möglichkeit hat, selbst SQL einzuschleusen spricht man von SQL-Injection. Besonders beliebt sind (gerade in älteren Webanwendungen) das Einschleusen von SQL per $_GET. Beispiel gefällig?

Angriffsszenario 1: Der Login

Eigentlich das Musterbeispiel dafür: Folgender Code wird zum validieren eines Login-Formulars verwendet:

<?php
… Den ganzen Post lesen
Veröffentlicht unter php, Security, webdev | 2 Kommentare

Angriffe auf Webanwendungen – Teil 2: Session-Highjacking und Session-Fixation

Publiziert am 28. November 2010 von david

Dieser Post setzt die Kenntnis von XSS und die des PHP Session Managements voraus.

Disclaimer

Ich beschreibe diese Attacke aus Angreifer-Sicht. Wenn man sich in die Rolle des Angreifers hineinversetzen kann, fällt es leichter, weitere Sicherheitslücken zu identifizieren. Ich bin also nicht zur dunklen Seite gewechselt und stifte auch nicht dazu an, es zu tun.

Was ist Session-Highjacking / Session-Fixation

Eigentlich handelt es sich um ganz simple Verfahren. Beim Session-Highjacking versuche ich, an die Session-ID (m)eines Opfers heranzukommen und setze diese Session-ID bei mir selbst. Auf diese Art und Weise gaukle ich dem Server also vor, dass es sich um die selbe Person handelt.… Den ganzen Post lesen

Veröffentlicht unter php, Security, webdev | 8 Kommentare

PHP Session-Management erklärt

Publiziert am 28. November 2010 von david

Anmerkung: Dieser Post ist dem Teil über Session-Highjacking und Session-Fixation vorgeschaltet, da der Artikel darüber sonst zu lang geworden wäre.

In dem Moment, indem der Benutzer per 

session_start();

eine Session verpasst bekommt, wird ein Session-Cookie auf dem PC des Benutzers angelegt, der bei jedem folgenden Request wieder an den Server übertragen wird. Dieser Cookie hat den Name PHPSESSID und im Inhalt steht der Session-Name. Der sieht etwa so aus: 3cm12d11d14fg0ssklulk1k274. Dieser Session-Cookie wird verwendet, um den Benutzer wiedererkennen zu können. Mit Firebug oder dem coolen Firefox-Addon Edit Cookies (welches wir später sowieso noch brauchen) lässt sich gut sehen, welche Cookies übertragen werden und was deren Inhalt ist.… Den ganzen Post lesen

Veröffentlicht unter php, Security, webdev | 3 Kommentare

Angriffe auf Webanwendungen – Teil 1: XSS (+Beispielangriff)

Publiziert am 28. November 2010 von david

Das ist der Anfang einer kleinen Serie, die das Thema „Websecurity“ umreißt. Dabei werde ich mit konkreten Angriffsszenarien auf die Techniken XSS, Session Highjacking + Session Fixation, SQL Injection und CSRF eingehen. Die Grundlage legen wir mit diesem Artikel und XSS, da viele der späteren Angriffe auf XSS aufsetzen.

Was ist XSS / Cross-Site-Scripting?

Sollte doch eigentlich mittlerweile jeder wissen, oder? Jegliche Möglichkeit, als Angreifer eigenen Javascript-Code auf eine Webseite zu schleusen.

Varianten von XSS

Grundsätzlich unterscheidet man zwischen 2 verschiedenen Arten des Cross-Site-Scriptings: Die dauerhafte Unterbringung von eigenem Code auf einer Webseite und die temporäre. Auf beide gehe ich nachher mit konkreten Angriffsszenarien ein.… Den ganzen Post lesen

Veröffentlicht unter php, Security, webdev | 7 Kommentare

PHP-Errors zu Exceptions konvertieren

Publiziert am 25. November 2010 von david

Wie wir ja alle wissen, ist der @-Fehlerunterdrückungs-Operator gemeinhin böse. Was aber nun, wenn wir mit PHP-eigenen Funktionen arbeiten müssen, die im Fehlerfall eine Warning produzieren?
Was ich meine ist z.B. file_get_contents. Wenn die aufzurufende URL nicht erreichbar ist, heißt es

Warning: file_get_contents() [function.file-get-contents]: php_network_getaddresses: getaddrinfo failed: Der angegebene Host ist unbekannt

Unschön. Glücklicherweise kann man mittels eines eigenen Errorhandlers einen Workaround basteln, indem der Fehler zu einer Exception konvertiert wird:

function errorhandler($code, $error, $file, $line)
{
	throw new ErrorException($error, $code, 0, $file, $line);
}

set_error_handler("errorhandler");

try
{
	echo file_get_contents("http://www.this-is-not-a-real-url.org");
}
catch (ErrorException $ex)
{
	echo "Die Webseite ist gerade nicht erreichbar";
}

Im Produktivbetrieb sollten die Fehler bekanntlich ohnehin nur geloggt und nicht angezeigt werden, trotz allem fühle ich mich wohler mit solch einer Lösung.… Den ganzen Post lesen

Veröffentlicht unter php, Quicktips, webdev | Hinterlasse einen Kommentar

Codevisualisierung mit pfff: PHP Frontend For Fun

Publiziert am 24. November 2010 von david

Das von facebook stammende Tool soll vor allem eine Hilfe zur Codevisualisierung und beim Refactoring sein. Kennt ihr diese anschaulichen Grafiken, die euren Festplatteninhalt visualisieren und auf vermeintliche Platzfresser aufmerksam machen (sowas in der Art)? Das macht pfff – nur eben auf Sourcecode zugeschnitten.

Was sagt facebook selbst dazu?

pfff is a set of tools and APIs to perform some static analysis, dynamic analysis, code visualizations, code navigations, or style-preserving source-to-source transformations such as refactorings on source code.

Finde ich – ohne es bis jetzt produktiv eingesetzt zu haben – zumindest mal eine nette Spielerei (…was ja auch der Namensbeisatz for Fun andeutet).… Den ganzen Post lesen

Veröffentlicht unter php, Quicktips, webdev, misc IT | 1 Kommentar

Yahoo Placefinder-API Tutorial

Publiziert am 23. November 2010 von david

Habe mich gestern auf Arbeit für eine Geo-Location Klasse mit der Placefinder API auseinandergesetzt und war ganz angetan davon, deswegen gebe hier mal die „Essentials“ wieder.

Was kann Placefinder?

Placefinder hat 2 Haupt-Einsatzbereiche:

  • Finde die Lat/Long-Koordinaten einer eingegebenen Adresse (Bspw: Neckarstraße 15, Darmstadt -49.869220, 8.645537)
  • Finde zu angegebenen Lat/Long-Koordinaten die nächstgelegene Adresse (Bspw: 48.1431,8.4176 -Am Doniswald 8, 78126 Königsfeld Im Schwarzwald)

Dabei ist der Placefinder sehr „tolerant“, spuckt also auch zu mies formatierten Eingaben oder Tippfehlern korrekte Ergebnisse aus.

Wie spreche ich die API an?

Yahoo bittet euch, erstmal einen API-Key zu besorgen (das geht hier). Komischerweise hat Yahoo aber auch nichts dagegen, wenn bei Anfragen kein API-Key angegeben wird – aber sicher ist sicher.… Den ganzen Post lesen

Veröffentlicht unter php, webdev | 3 Kommentare

Grundprinzipien der objektorientierten Programmierung

Publiziert am 23. November 2010 von david

Loose Coupling – Schwache Kopplung

  • Definiert, wie sehr Systembesstandteile voneinander abhängen
  • Klassen sollten so strukturiert sein, dass sie auf möglichst wenige andere Klassen angewiesen sind, um funktionieren zu können
  • Erhöht Wiederverwendbarkeit der Klassen enorm!

sinnvolle Abhängigkeiten

  • Stark zusammengehörende Code-Teile sollten zusammengefasst werden
  • Nicht zusammenhängende Code-Teile sollten ausgelagert werden (don’t do too much!)
  • Veränderungen einer Klasse sollten im Optimalfall keine Änderung an weiteren Klassen hervorrufen

Information Hiding – Geheimnisprinzip

  • Jede Klasse gibt nur das nötigste nach außen und „weiß“ selbst auch nur das, was sie zum funktionieren wissen muss
  • Keine Interna werden nach außen getragen. Ich muss nicht wissen, dass intern ein Stack als Datenstruktur verwendet wird, um die Klasse zu benutzen
  • Änderungen innerhalb der Klasse selbst sollten nach außen nicht sichtbar sein, da andere Klassen nur das nötigste von ihr kennen
  • Spielt auf sinnvolle Verwendung von public / private / protected an

Homogenität

  • Vergleichbare Probleme sollten mit vergleichbarer Komplexität gelöst werden
  • Wiederverwendung von bereits bestehenden Lösungen soweit wie möglich
  • Leitlinie: „Erwartungshaltung“ anderer Teammitglieder sollte erfüllt werden, was den Umfang der Realisierung einer Klasse angeht

Don’t repeat yourself – Redundanzfreiheit

  • Jede Funktionalität ist an genau einer Stelle vorhanden und wird – bei Bedarf – von anderen Systembestandteilen verwendet (Don’t reinvent the wheel)
  • Sollte Code mehrfach verwendet worden sein (Copy & Paste aus Faulheit), wird eine neue Funktion daraus erschaffen, die dann von allen Teilen aus aufgerufen wird
  • Vorteil: Bei einem Fehler muss nur an einer Stelle korrigiert werden und alle anderen, davon abhängigen Teile sind automatisch „gefixt“
… Den ganzen Post lesen
Veröffentlicht unter Software Engineering, webdev | 4 Kommentare

Die Wahrheit über den Doctype

Publiziert am 22. November 2010 von david

Mit dem neuen, ultracoolen und leicht zu merkenden HTML 5-Doctype 

<!DOCTYPE html>

kamen viele Bedenken auf. Ist meine Webseite dann überhaupt noch standardkonform? Falle ich nicht dem Quirks-Mode der Browser zum Opfer? Nichts davon ist der Fall. Der Doctype ist generell extrem überschätzt! Kein Browser wird sich wirklich darum kümmern, was für ein Doctype angegeben ist.

Was in Wirklichkeit passiert

Es wird (einheitlich bei allen Browsern) danach geschaut, ob überhaupt ein Doctype angegeben wurde. Ist das nicht der Fall, gehts direkt in den Quirksmode. Wird nun ein Doctype gefunden, gibt es nur noch eine „Chance“, doch noch in den Quirksmode zu geladen: Es wird ein Uralt-Doctype wie 

<!DOCTYPE
… Den ganzen Post lesen
Veröffentlicht unter Quicktips, webdev | 2 Kommentare