Dafydd Stuttard, Marcus Pinto: "The Web Application Hacker's Handbook"
Lektüre-Notizen:
- "Introduction":
- Abgesehen von einem Rechtskonformitäts-Disclaimer gibt sich das Buch als so geschrieben, dass man davon sowohl lernen kann, Systeme sicherer zu machen, als auch, sie anzugreifen. Eigentlich interessiere ich mich ja nur für ersteres, da ich ein paar Sicherheits-Ideen für mein PlomWiki suche, aber letzteres klingt natürlich auch, ähm, reizvoll!
- "Web Application (In)security":
- Seit das Web nicht mehr aus statischen Seiten, sondern aus ganz viel Nutzer-Interaktion besteht, reicht schon ein Browser, um in Systeme einzubrechen. Und je mehr Funktionalität in Browser-Interaktionen aufgelöst wird, desto mehr kritische Systeme sind auf diese Weise hackbar.
- "Core Defense Mechanisms":
- Wie man den User-Input ungefährlich zu halten versucht. Zugriffskontrollen über, und die sind im Zweifelsfall natürlich alle stehlbar, Passwörter/Nutzer-Authentifizierungen und Session-IDs.
- Den User-Input filtern und säubern; wobei man über Säuberungs-Mechanismen auch wieder stolpern kann, wenn sie den weitergereichten Text verändern und verändern, denn so eine Veränderung kann ja vom Angreifer erwartet sein und der Schadcode als ihr Ergebnis entstehen. Einfacher Trick, um Skripte zu umgehen, die "<script"> aus dem User-Input löschen, wenn sie nicht rekursiv sind: "<scr<script>ipt>" schreiben!
- Womit man am Wenigsten falsch machen kann: Whitelists für erlaubten Input.
- Aufpassen, dass Fehlermeldungen dem Nutzer nicht zu viel verraten. Auch, Angriffe entschleunigen durch nicht-perfekte Lösungen; die perfekte Sicherheit hat man eh nie, und so gewinnt man im Zweifelsfall Zeit, um ein Leck zu stopfen.
- "Web Application Technologies":
- HTTP, Java-Zeugs, PHP usw. usf.
- Die HTTP-Spezifikation enthält einen nie korrigierten, technisch seitdem normalisierten Schreibfehler: "Referer".
- HTTP Basic Auth, zumal wenn über SSL (das eigentlich nicht mehr SSL, sondern TLS heißt!), ist auch nicht unsicherer als seine meisten heimgewachsenen Alternativen.
- Was man über verschiedene Zeichen-Kodierungen wissen muss, um das Kodierte als User-Input unterzuschieben.
- Niemand wäre so blöd, sicherheitsrelevanten Input via HTTP GET zu übermitteln.
- PHP zieht Unsicherheiten magisch an.
- "Mapping the Application":
- Wie man eine noch unbekannte Angriffs-Oberfläche einer Software durch Erprobungen und Ratespielchen erforscht. Scheint mir nur von geringem Interesse, wenn, wie in meinem PlomWiki-Idealfall, eh alles bis zum Quellcode außer den Passwörtern im Klartext jedem Nutzer vorliegen sollte.
- "Bypassing Client-Side Controls":
- Misstraue allem, was auf Klienten-Seite passiert: Kein sicherheitsrelevanter Prozess sollte dort statt finden, denn ein gewiefter Nutzer kann alles, was auf seiner Maschine abläuft, im Zweifelsfall manipulieren.
- "Attacking Authentication":
- Sicherheit lässt sich nicht durch Komplexität erkaufen. Multi-stage Authentifizierungs-Prozesse locken mehr Implementierungs-Fehler, und jeder Implementierungs-Fehler ist ein Einfallstor; so können sie, wenn man nicht beim Design sehr genau aufpasst und testet, unsicherer sein.
- Halte dich bedeckt in deinen Fehler-Nachrichten. Verrate nicht direkt oder indirekt, welcher Teil der Authentifizierung fehlerhaft sei, damit der Angreifer nicht weiß, wo er vielleicht schon einen Treffer gelandet hat. Am Besten, du gibst für jedes Scheitern exakt den selben Fehler-Code aus.
- Akzeptiere für ein Passwort-Feld oder einen Benutzer-Namen (vielleicht haben mehrere Benutzer den selben Namen, werden aber durch ihre Passwörter differenziert?) nicht mehrere Passwörter, denn alles, was die Zeit bis zu einem Erfolgs-Erlebnis des Angreifers reduziert, ist gefährlich.
- Anstatt zu einem bekannten Benutzernamen ein unbekanntes Passwort zu erraten, kann ein Angreifer auch einfach ein gern verwendetes Passwort nehmen und alle vorhandenen oder denkbaren Benutzernamen dazu ausprobieren; irgendwer wird schon fahrlässig genug gewesen sein.
- Setze nicht hintenrum über Passwort-Erinnerungs- oder Passwort-Veränderungs-Funktionalitäten unzureichender Vorsicht alternative Einfallstore. Auch das stärkste Passwort ist nur so sicher wie die E-Mail-Adresse, an die es zur Erinnerung gesendet wird, oder die Sicherheitsfrage nach dem Taufnamen der Mutter, die einem Passwort-Veränderungs-Bildschirm vorgeschaltet wird.
- Bereite dich auf den Ernstfall gestohlener Passwort-Listen vor, indem du sie intern nur als appropriately gesalzene Krypto-Hashes speicherst, statt im Klartext; so dass ein Angreifer immer noch ein bisschen Rechenzeit investieren muss, eh er durchbricht.
- Reiche an den Nutzer/Client nie mehr zurück, als du ihm im derzeitigen Zustand seiner Authentifizierung guten Gewissens offen als Bildschirmtext anzeigen würdest.
- Blockiere Brute-Force-Attacken aufs Passwort-Eingabefeld mit ansteigender Login-Verzögerung, aber pass auf, dass du es Angreifern nicht zu einfach machst, auf diese Weise legitimen Nutzern das Einloggen durch zu drastische Versuchs-Sperren unmöglich zu machen. Begegne automatisierten Angriffen mit Captchas.
- "Attacking Session Management":