Achim Hoffmann on Session Managemen in Business Applications

Transcript

1. Achim Hoffmann | sic[!]sec GmbH Session-Management / Business-Logik in Webanwendungen
2. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 2 / 48 • Achim Hoffmann, achim.hoffmann@sicsec.de • spezialisiert auf Web Application Security >10 Jahre wer, was, wo, ... • AppSec EU 2013, OWASP Day 201x (Orga-Team) • OWASP Germany, Board Member (achim@owasp.org) • Penetrationstests • WAF – Web Application Firewall • SCA - Source Code Analysen • Guidlines, Policies • Workshop, Seminare (früher) • Web-Anwendungsentwicklung • System-Programmierung (Unix) • Software-Entwicklung (CAD)
3. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 3 / 48 Veröffentlichungen • BSI-Maßnahmenkatalog und Best Practices • OWASP Best Practices: Projektierung der Sicherheitsprüfung von Webanwendungen • OWASP Best Practices: Einsatz von Web Application Firewalls • WASC Web Application Firewall Evaluation Criteria • WASC-TC The WASC Threat Classification • HTTP State Management Mechanism (Cookie) – RFC 6265 → sic[!]sec GmbH www.sicsec.de
4. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 4 / 48 Veröffentlichungen (Links) • https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/306 32/WebSec_pdf.pdf • https://www.owasp.org/images/0/00/OWASP-Projektierung_der_ Sicherheitspr%C3%BCfung_von_Webanwendungen_v101.de.pdf • http://www.owasp.org/images/1/1b/Best_Practices_Guide_WAF.pdf • http://www.webappsec.org/projects/wafec/ • http://projects.webappsec.org/w/page/13246978/Threat%20Classification • http://www.ietf.org/rfc/rfc6265.txt Tools • https://github.com/OWASP/O-Saft https://github.com/EnDe/ReDoS • https://github.com/EnDe/EMiR https://github.com/EnDe/EnDe Veröffentlichungen
5. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 5 / 48 • Angriffspunkte: Session-Management • Angriffspunkte: Business-Logik • Maßnahmen • Beispiele aus der Praxis • Beispiele „Thema verfehlt“ Schwachstelle erklären – Angriffsmöglichkeiten – Maßnahmen Agenda
6. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 6 / 48 • Session-IDs • Session-Diebstahl (aka Session-Hijacking) • Session-Fixation • Session-Logout Session-Hijacking = Folge von Session-Diebstahl oder -Fixation Angriffspunkte: Session-Managment
7. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 7 / 48 • Session-Logout • Session-Reuse • Session-Replay • Cross-Site Request Forgery • Username-, Passwort-Enumeration • Passwort-vergessen-Funktion • Application-Lockout (Benutzerkonto sperren) (aka Session-Lockout, Application-, Session-DoS) Angriffspunkte: Bussines-Logik
8. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 8 / 48 XSS? Game Over!
9. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 9 / 48 • Session-ID im Cookie ohne „secure“-Flag, ohne ausreichendes „path“-Attribut – Auslesen mitttels XSS in der Anwendung – Auslesen in anderen Anwendungen • Session-ID in der URL – Problem nur bei XSS oder Referer-Leakage • Session-ID im HTTP-Authentication-Header – nur MiTM wenn kein HTTPS • Session-ID im Refer(r)er Angriffspunkt: Session-Diebstahl
10. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 10 / 48 • Session-ID im Cookie je nach „secure“-Flag, bzw. „path“-Attribut – alle Anwendungen in der selben Domain: *.me.tld – RFC 6265: → 8. Security Considerations • Session-ID in der URL – nur Anwendung selbst, Benutzer wegen C&P • Session-ID im HTTP-Authentication-Header – nur Anwendung selbst (aber sehr schwierig) Angriffspunkt: Session-Diebstahl - Angriffsoberfläche
11. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 11 / 48 Angriffspunkt: Session-Fixation • Session-ID im Cookie oder der URL – XSS irgendwo in Anwendungen auf *.victim.tld – <img src=http://victim.tld/vuln.do;jsessionid=bindrinn /> • Ursachen – Session-ID wird vor Login vergeben – Session-ID wird nach Login nicht erneuert – Session-ID wird wieder verwendet (selten) – Anwendung erlaubt Cookie und URL-Rewriting
12. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 12 / 48 • Session-ID im Cookie unabhängig von „secure“-Flag, bzw. „path“-Attribut! – alle Anwendungen in der selben Domain: *.me.tld – RFC 6265: → 8. Security Considerations • Session-ID in der URL – Webseite irgendwo • Session-ID im HTTP-Authorization-Header – Anwendung, Web-, Application-Server (schwierig) Angriffspunkt: Session-Fixation – Angriffsoberfläche
13. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 13 / 48 Angriffspunkt: Session-Logout • Session (in Anwendung) wird beim Logout nicht zerstört • Ursachen: – nur Session-ID wird „gelöscht“ – kein Timeout (absolut und „idle“) – multiple, concurrent Sessions nicht richtig verwaltet
14. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 14 / 48 Angriffspunkt: Session-Logout – „Angriffsoberfläche“ • Browser wird geschlossen • Benutzer „vergisst“ Session Maßnahmen • Logout erzwingen, serverseitigesTimeout • Session-Objekt in der Anwendung zerstören • Umgang mit Mehrfachsessions
15. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 15 / 48 Angriffspunkt: Session-Reuse • ist i.W. eine Folge der Session-Logout-Problematik • aber auch „Remember me“ und SSO • Logout erzwingen, serverseitigesTimeout • Session-Objekt in der Anwendung zerstören • kein SSO und „Remember me“ Maßnahmen
16. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 16 / 48 Angriffspunkt: Session-Replay • Aktion kann (beliebig) wiederholt werden • ist automatisierbar (Skript)
17. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 17 / 48 Angriffspunkt: Session-Replay – Angriffsoberfläche • Angreifer ist Benutzer selbst – kann GET oder POST benutzen (auch AJAX usw.) • Angreifer nutzt CSRF (Benutzer ist Opfer) – nur mit Cookie oder HTTP-Authentication-Header • zusätzliche Token für jede Aktion verwenden siehe Anti-CSRF-Token http://victim.tld/safe.do?aktion&token=random-unique Maßnahmen
18. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 18 / 48 Angriffspunkt: Cross-Site Request Forgery • URL löst Aktion aus • URL kann an beliebiger Stelle stehen, z.B. attacker.tld • URL ist (meist) unsichtbar, z.B. in <img src=...> Tag • betrifft: Cookie, HTTP-Authentication, SmartCard
19. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 19 / 48 Angriffspunkt: Cross-Site Request Forgery – Angriffsoberfläche • Session-ID im Cookie, HTTP-Authentication-Header – schadhafter Link kann irgendwo stehen • Session-ID in der URL – CSRF nicht möglich • zusätzliches Anti-CSRF-Token für jede Aktion notwendig • muss eindeutig, nicht-eratbar, zufällig sein http://victim.tld/safe.do?aktion&token=random-unique Maßnahmen
20. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 20 / 48 Maßnahmen: Frameworks, Application-Server • Apache Shiro • Spring • Tomcat • GlassFisch
21. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 21 / 48 Beispiel Apache Shiro • Authentication • Authorization • Cryptography (verschiedene Wrapper) • Web Features („protect all URLs“ → sehr einfach) • Session Management – Benutzt POJO (clusterfähig, SSO) – „Host Adress Retention“ (Client IP) – Passwort als SHA-Hash • shiro.ini → deklarativ: sehr einfach
22. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 22 / 48 Beispiel: Spring • Authentication – Form-based, HTTP-Authentication • Detecting Timeouts – löscht JSESSIONID-Cookie • Session Fixation Attack Protection – newSession, migrateSession, chnageSessionId, none • Concurrent Session Control • Passwort als SHA-Hash, auch gesalzen
23. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 23 / 48 Beispiel: Spring Security (neu in 3.2.x) • CSRF Protection • Click Jacking Protection • HTTP Security Header – X-FRAME-OPTION – X-Content-Type-Option – Strict-Transport-Security http://docs.spring.io/spring-security/ site/docs/3.2.2.RELEASE/reference/htmlsingle/
24. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 24 / 48 Maßnahmen: Konfiguration Session-Timeout • Shiro (shiro.ini) [main] securityManager.sessionManager. globalSessionTimeout = 2300000 [main] securityManager.sessionManager. globalSessionTimeout = 2300000 • Spring (z.B. Tomcat) <session­config> <session­timeout>2300</session­timeout> </session­config> <session­config> <session­timeout>2300</session­timeout> </session­config>
25. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 25 / 48 Maßnahmen: Konfiguration Session-Timeout • Tomcat (server.xml, ab 5.0: contecxt.xml oder $app.xml) <Context path="myApp" cookies="false" /> <session­config> <session­timeout>2300</session­timeout> </session­config> <Context path="myApp" cookies="false" /> <session­config> <session­timeout>2300</session­timeout> </session­config> • GlassFish (sun-web.xml, oder $app.xml) <sun­web­app> <session­config> <properties timeoutSeconds="2300" /> <!­­ oder Vorsicht: Minuten! ­­> <session­timeout>23</session­timout> </session­config> <sun­web­app> <session­config> <properties timeoutSeconds="2300" /> <!­­ oder Vorsicht: Minuten! ­­> <session­timeout>23</session­timout> </session­config>
26. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 26 / 48 Maßnahmen: Konfiguration Cookies • Shiro (shiro.ini) [main] securityManager.sessionManager. sessionIdCookieEnabled = true securityManager.sessionManager. SessioniDCookie.domain = me.my.tld [main] securityManager.sessionManager. sessionIdCookieEnabled = true securityManager.sessionManager. SessioniDCookie.domain = me.my.tld • Spring (web.xml) <session­config> <tracking­mode>COOKIE</tracking­mode> </session­config> <session­config> <tracking­mode>COOKIE</tracking­mode> </session­config> Aber: Session-Timeout, path-, secure- und HttpOnly-Flag im Tomcat einstellen!
27. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 27 / 48 Maßnahmen: Konfiguration Cookies • Tomcat (server.xml, ab 5.0: contecxt.xml oder $app.xml) <session­config> <http­only>true</http­only> <SessionCookie secure="true" httpOnly="true" /> </session­config> <session­config> <http­only>true</http­only> <SessionCookie secure="true" httpOnly="true" /> </session­config> • GlassFish (sun-web.xml, oder $app.xml) <session­config> <property name="enableCookies" value="false" /> <property name="cookieHttpOnly" value="false" /> <property name="cookieSecure" value="false" /> <property name="enableURLRewriting" value="true" /> </session­config> <session­config> <property name="enableCookies" value="false" /> <property name="cookieHttpOnly" value="false" /> <property name="cookieSecure" value="false" /> <property name="enableURLRewriting" value="true" /> </session­config>
28. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 28 / 48 Praxisbeispiel 1: Passwort als Hash in URL • Passwort-Reset-Funktion liefert URL zur Bestätigung http://victim.tld/recover.do/1cbb2ba737624db6c6d5cca6 c18e3c36/uid=0815 • altes Passwort soll noch nicht geändert werden • Benutzer soll Änderung bestätigen • keine Speicherung serverseitig („tote“ Daten vermeiden) Motivation der Entwickler
29. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 29 / 48 Praxisbeispiel 1: Passwort als Hash in URL – Angriffsoberfläche • Passwort-Preisgabe • DoS auf Benutzerkonto http://victim.tld/recover.do/deadbeaf/uid=0815 • DoS auf alle Benutzer • keine Passwörter in der URL, Hash immer salzen • Informationen (uid=0815) verschlüsseln • ORM, Datenbank Maßnahmen
30. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 30 / 48 Praxisbeispiel 2: Business-Logik und ORM-Injection • Anwendung liefert bei Fehleingaben Fehlermeldung • Anwendung liefert bei „Manipulation“ eine neue Seite • (blind) Hibernate-Injection • Passwort-Hash
31. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 31 / 48 Praxisbeispiel 2: ORM-Injection – Angriffsoberfläche • HQL unterstützt UNION-Operator nicht • jedes Teil-Statement, dass mit UNION eingeleitet wird, wird verworfen → fehlerhafte Statements werden ausgeführt • Anwendung liefert „user friendly“ Fehlermeldung • Passwort als MD5-Hash, ungesalzen!
32. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 32 / 48 Praxisbeispiel 2: Hibernate • Hibernate bildet Java-Objekte auf die Strukturen einer relationalen Datenbank ab • Hibernate unterstützt: – Hibernate Query Language (HQL) – natives SQL – Criteria – Syntax analog zu der von SQL – Referenziert werden nicht Tabellen und Spalten, sondern Objekte und Attribute
33. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 33 / 48 Praxisbeispiel 2: ORM-Injection – Annahmen • relationale Ebene – Tabelle BENUTZER existiert mit – Tabelle hat Spalten LOGIN und PASSWORT • Objekt-Ebene – Klasse User.java existiert mit – Attributen userLoginName und userPasswort • Mapping – Abbildung: Tabelle BENUTZER auf Klasse User.java – Abbildung: Spalte LOGIN auf Attribut userLoginName, usw.
34. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 34 / 48 Praxisbeispiel 2: Business-Logik – „Feature“ • Benutzer kann seinen Login-Namen ändern • vor Änderung des Login-Namens prüft das System, ob es den neuen Namen bereits gibt (uniqueness) • falls der neue Name bereits existiert, erfolgt keine Änderung und es erscheint eine Fehlermeldung:
35. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 35 / 48 Praxisbeispiel 2: Business-Logik – Feature admin admin' and u.userPasswort like '%' union admin' and u.userPasswort like 'n%' union admin' union egal
36. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 36 / 48 Praxisbeispiel 2: HQL – Implementierung • HQL Statement, analog zu select count(*) from ... • sUserLoginName kommt (ungeprüft) vom Client • Login-Name existiert falls lCount größer als Null ist → Fehlermeldung wird ausgegeben
37. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 37 / 48 Praxisbeispiel 2: HQL – Injection SELECT COUNT(u) FROM User u WHERE u.userLoginName = 'admin' and u.userPassword like '%' union' SELECT COUNT(u) FROM User u WHERE u.userLoginName = 'admin' and u.userPassword like '%' union' • union wirkt dabei wie ein Kommentar bis Zeilenende
38. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 38 / 48 Praxisbeispiel 3: Cookies • Set-Cookie: id=eins; path=/ • Set-Cookie: id=zwei; path=/2 • Set-Cookie: id=drei; path=/2/3 • Set-Cookie: id=vier; path=/; Secure → Cookie: id=eins; id=zwei; id=drei; id=vier Maßnahmen • Cookie-Wert signieren
39. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 39 / 48 Praxisbeispiel 4: Decimal Betrag: <input id=float type=text maxlength=6 > (max. 6 Zeichen: 0-9,.+- ) Betrag: <input id=float type=text maxlength=6 > (max. 6 Zeichen: 0-9,.+- )
40. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 40 / 48 Praxisbeispiel 4: BigDecimal() Betrag: <input id=float type=text maxlength=6 > (max. 6 Zeichen: 0-9,.+- ) Betrag: <input id=float type=text maxlength=6 > (max. 6 Zeichen: 0-9,.+- ) String input = getParamValue("float"); try { // nur 6 Zeichen von input BigDecimal value = BigDecimal(input); // process value } catch (NumberFormatException e) { // print error } String input = getParamValue("float"); try { // nur 6 Zeichen von input BigDecimal value = BigDecimal(input); // process value } catch (NumberFormatException e) { // print error }
41. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 41 / 48 Praxisbeispiel 4: BigDecimal() Translates the string representation of a BigDecimal into a BigDecimal. The string representation consists of an optional sign, '+' ( '\u002B') or '-' ('\u002D'), followed by a sequence of zero or more decimal digits ("the integer"), optionally followed by a fraction, Translates the string representation of a BigDecimal into a BigDecimal. The string representation consists of an optional sign, '+' ( '\u002B') or '-' ('\u002D'), followed by a sequence of zero or more decimal digits ("the integer"), optionally followed by a fraction, http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html optionally followed by an exponent. optionally followed by an exponent.
42. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 42 / 48 Praxisbeispiel 4: BigDecimal() Translates the string representation of a BigDecimal into a BigDecimal. The string representation consists of an optional sign, '+' ( '\u002B') or '-' ('\u002D'), followed by a sequence of zero or more decimal digits ("the integer"), optionally followed by a fraction, optionally followed by an exponent. The fraction consists of a decimal point followed by zero or more decimal digits. The string must contain at least one digit in either the integer or the fraction. The number formed by the sign, the integer and the fraction is referred to as the significand. The exponent consists of the character 'e' ('\u0065') or 'E' ('\u0045') followed by one or more decimal digits. The value of the exponent must lie between -Integer.MAX_VALUE (Integer.MIN_VALUE+1) and Integer.MAX_VALUE, inclusive. • Translates the string representation of a BigDecimal into a BigDecimal. The string representation consists of an optional sign, '+' ( '\u002B') or '-' ('\u002D'), followed by a sequence of zero or more decimal digits ("the integer"), optionally followed by a fraction, optionally followed by an exponent. The fraction consists of a decimal point followed by zero or more decimal digits. The string must contain at least one digit in either the integer or the fraction. The number formed by the sign, the integer and the fraction is referred to as the significand. The exponent consists of the character 'e' ('\u0065') or 'E' ('\u0045') followed by one or more decimal digits. The value of the exponent must lie between -Integer.MAX_VALUE (Integer.MIN_VALUE+1) and Integer.MAX_VALUE, inclusive. • http://docs.oracle.com/javase/6/docs/api/java/math/BigDecimal.html
43. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 43 / 48 Praxisbeispiel 4: BigDecimal() Betrag: <input id="float" type="text" maxlength="6"> (max. 6 Zeichen: 0-9,.+- ) Betrag: <input id="float" type="text" maxlength="6"> (max. 6 Zeichen: 0-9,.+- ) • 999,99 • -99999 • 999999 Eingaben • 9e9 • 999e9 • 9e9999 = 9.000.000.000 = 999.000.000.000 = 9.000 .. 9999 .. 000 • 9^9 • 9999^9 • 9^9999 = 387.420.489 = 999100359916012598740083996400089999 = ...
44. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 44 / 48 Praxisbeispiel 4: BigDecimal() String input = getParamValue("float"); try { // nur 6 Zeichen von input BigDecimal value = BigDecimal(input); // process value } catch (NumberFormatException e) { // print error } String input = getParamValue("float"); try { // nur 6 Zeichen von input BigDecimal value = BigDecimal(input); // process value } catch (NumberFormatException e) { // print error } if (input.matches("[^0­9,.+­]")) { // print error and exit } if (input.matches("[^0­9,.+­]")) { // print error and exit }
45. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 45 / 48 Praxisbeispiel 5: parseInt(s) Betrag: <input id=zahl type=text maxlength=8 > (max. 8 Zeichen: 0-9 ) Betrag: <input id=zahl type=text maxlength=8 > (max. 8 Zeichen: 0-9 ) String input = getParamValue("zahl"); try { // nur 8 Zeichen von input int value = Integer.parseInt(input); // process value } catch (NumberFormatException e) { // print error } String input = getParamValue("zahl"); try { // nur 8 Zeichen von input int value = Integer.parseInt(input); // process value } catch (NumberFormatException e) { // print error }
46. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 46 / 48 Praxisbeispiel 5: parseInt(s,r) Betrag: <input id=zahl type=text maxlength=8 > (max. 8 Zeichen: 0-9a-f ) Betrag: <input id=zahl type=text maxlength=8 > (max. 8 Zeichen: 0-9a-f ) String input = getParamValue("zahl"); try { // nur 8 Zeichen von input int value = Integer.parseInt(input,16); // process value } catch (NumberFormatException e) { // print error } String input = getParamValue("zahl"); try { // nur 8 Zeichen von input int value = Integer.parseInt(input,16); // process value } catch (NumberFormatException e) { // print error } → FFFFFFFF = 4.294.967.296
47. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 47 / 48 C++; nicht atomar! → nicht Thread-safe! synchronized void foo() { j++; } oder Import java.util.concurrent.locks.*; final Lock lock = new ReentrantLock(); lock.lock(); j++; lock.unlock(); 1.2 Design Goals http://web.archive.org/web/19990424114401/http://java.sun.com/docs/white/langenv/Intro.doc2.html 1.2.1 Simple, Object oriented, Familar
48. Session-Management / Business-Logik 17.03.2014, Achim.Hoffmann@sicsec.de 48 / 48 Vielen Dank für Ihre Aufmerksamkeit. http://sicsec.de/p/Session-Management_Business-Logik__ejug.pdf