Heisec 2008 web 2.0

484 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
484
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Web 2.0 hat zwei Grundprobleme: \na) Technische Implikationen: JavaScript und co\nb) Implikationen auf die Privatsphäre \nversuch: eher blick von oben als detailliert\n
  • Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas ändert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zusätzlich zu Jürgens\nzweites thema: privacy \nlösungswege für problemfeld technik, aktuellen diskussionsstand für problemfeld privacy \n
  • Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas ändert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zusätzlich zu Jürgens\nzweites thema: privacy \nlösungswege für problemfeld technik, aktuellen diskussionsstand für problemfeld privacy \n
  • Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas ändert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zusätzlich zu Jürgens\nzweites thema: privacy \nlösungswege für problemfeld technik, aktuellen diskussionsstand für problemfeld privacy \n
  • Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas ändert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zusätzlich zu Jürgens\nzweites thema: privacy \nlösungswege für problemfeld technik, aktuellen diskussionsstand für problemfeld privacy \n
  • Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas ändert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zusätzlich zu Jürgens\nzweites thema: privacy \nlösungswege für problemfeld technik, aktuellen diskussionsstand für problemfeld privacy \n
  • \n
  • \n
  • 1. Mitre Common Vulnerability Enumeration\n2. Security Incident Database Breach Security \nBei Ajax-Applikationen gibt es einen ähnlichen Paradigmenwechsel\n\n
  • \n
  • Einfache Variante: Ajaxifizierung der bestehenden Lösungen, weniger Page-Reloads \n- applikationen wie google maps oder google mail sehen deutlich anders aus \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
  • Hiermit haben wir es mit noch einem Paradigmenwechsel zu tun.\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • XSS haben wir vorhin gehört - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • \n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Fazit: \nErwartung wäre, dass deutlich mehr komplexe JavaScript-Angriffe möglich werden.\nDie nächsten Folien werden zeigen, was davon stimmt.\n25%\n
  • Was machen die Web 2.0 Hacker mit diesen Möglichkeiten \n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • Ich werde gleich mal demonstrieren, wie einfach das ist. \n- Es gibt eine Weiterentwicklung einer Idee von Jeremiah Grosman durch Ilia Alshanewsky, bei der das Scanning voellig ohne JavaScript erfolgt. \n\n
  • \n
  • \n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Ein bischen Theorie zum Thema browsersicherheit\n
  • Sobald der File-Zugriff da ist, kann er mit lokalen XSS exploitet werden.\nerhebliche eskalation der rechte \nWeb 2.0: Applikationen werden vernetzt \nbei lokalen tools die auf services / web 2.0-applikationen zugreifen.\n
  • Sobald der File-Zugriff da ist, kann er mit lokalen XSS exploitet werden.\nerhebliche eskalation der rechte \nWeb 2.0: Applikationen werden vernetzt \nbei lokalen tools die auf services / web 2.0-applikationen zugreifen.\n
  • Sobald der File-Zugriff da ist, kann er mit lokalen XSS exploitet werden.\nerhebliche eskalation der rechte \nWeb 2.0: Applikationen werden vernetzt \nbei lokalen tools die auf services / web 2.0-applikationen zugreifen.\n
  • Sobald der File-Zugriff da ist, kann er mit lokalen XSS exploitet werden.\nerhebliche eskalation der rechte \nWeb 2.0: Applikationen werden vernetzt \nbei lokalen tools die auf services / web 2.0-applikationen zugreifen.\n
  • Sobald der File-Zugriff da ist, kann er mit lokalen XSS exploitet werden.\nerhebliche eskalation der rechte \nWeb 2.0: Applikationen werden vernetzt \nbei lokalen tools die auf services / web 2.0-applikationen zugreifen.\n
  • \n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu gehören URL-Moniker, Plugins und Browser-Erweiterungen\n
  • Crossdomain.xml umgeht die Same-Origin-Policy. \nMit einer Crossdomain.xml kann Flash jedes Dokument im XML-Format auf dem Server auslesen.\nCrossdomain-Beispiel:\nhttp://ilove.de/crossdomain.xml\n
  • Crossdomain.xml umgeht die Same-Origin-Policy. \nMit einer Crossdomain.xml kann Flash jedes Dokument im XML-Format auf dem Server auslesen.\nCrossdomain-Beispiel:\nhttp://ilove.de/crossdomain.xml\n
  • Crossdomain.xml umgeht die Same-Origin-Policy. \nMit einer Crossdomain.xml kann Flash jedes Dokument im XML-Format auf dem Server auslesen.\nCrossdomain-Beispiel:\nhttp://ilove.de/crossdomain.xml\n
  • Crossdomain.xml umgeht die Same-Origin-Policy. \nMit einer Crossdomain.xml kann Flash jedes Dokument im XML-Format auf dem Server auslesen.\nCrossdomain-Beispiel:\nhttp://ilove.de/crossdomain.xml\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • was passiert bei bösen payloads? \n\n
  • Wikipedia und Blogging kein Sicherheitsthema\nPrivatsphäre sehr wohl.\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • \n
  • Interesse der Community: Namen findbar \nbei hinreichender größe nicht mehr nötig \nweiterverwertung nicht nur per spidern\nOpenSocial: Social Community als Eigentschaft von Applikationen\nFlexibler Austausch und Weiterverbreitung von Daten\n
  • \n
  • \n
  • Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Same Origin ist kaputt\nersatz muss her \n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • Beste Lösung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Es gibt diverse Ansätze, auf der Serverseite XSS-Probleme zu lösen. \nXSS auf dem server nur begrenzt: \n- kontext \n - aktueller Browserzustand\n - eingebundenen MashUps\n - eingebundene Toolkits \n - Verhalten der HTML-Engine\n - Verhalten des JavaScript-Interpreters. \n75%\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • Zur zeit: keine wirkliche lösung\nNicht google- und spiderbar \nFreiwilliger Schutz überhaupt machbar und wirksam? Schutz der Freigaben mit DRM? Möglichkeit zum Zurückziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche möglichkeiten\n
  • \n
  • \n
  • Heisec 2008 web 2.0

    1. 1. Web 2.0 zwischen Nutzenund GefahrHeise Security Conference 2008
    2. 2. AgendaAlles wird anders: Architektur bei Web 2.0
    3. 3. AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0
    4. 4. AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript Malware
    5. 5. AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript MalwarePrivacy und/oder das Web 2.0
    6. 6. AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript MalwarePrivacy und/oder das Web 2.0Lösungswege für Client und Server und Nutzer
    7. 7. Desktop-Entwickler haben es einfacher
    8. 8. Web und Sicherheit
    9. 9. Web und Sicherheit
    10. 10. 2/3 aller Exploits richten sich gegen Webapplikationen.
    11. 11. 2/3 aller Angriffe sindkommerzieller Natur.
    12. 12. Was sich im Web 2.0 ändert
    13. 13. Wechsel von Server zur RIA Browser Server
    14. 14. Wechsel von Server zur RIA Browser Model Server
    15. 15. Wechsel von Server zur RIA Browser Controller Model Server
    16. 16. Wechsel von Server zur RIA Browser Controller Model Server View
    17. 17. Wechsel von Server zur RIA Browser Controller Model Server View
    18. 18. Wechsel von Server zur RIA Browser Controller Model Server View
    19. 19. Wechsel von Server zur RIA Browser Controller Model Server View
    20. 20. Wechsel von Server zur RIA Browser Input-Validierung Controller Model Server View
    21. 21. Wechsel von Server zur RIA Browser Controller Model Server View
    22. 22. Wechsel von Server zur RIA Browser Controller Escaping Model Server View
    23. 23. Wechsel von Server zur RIA Browser Controller Model Server View
    24. 24. Wechsel von Server zur RIA Browser Browser Controller Model Server View
    25. 25. Wechsel von Server zur RIA Browser Browser View Controller Model Server
    26. 26. Wechsel von Server zur RIA Browser Controller Browser View Model Server
    27. 27. Wechsel von Server zur RIA Browser Controller Browser View Model Server
    28. 28. Wechsel von Server zur RIA Browser Controller Browser View Model Server
    29. 29. Wechsel von Server zur RIA Browser Controller Browser View Model Server
    30. 30. Wechsel von Server zur RIA Browser Controller Browser View Model Server
    31. 31. Wechsel von Server zur RIA Browser Controller Browser View Input-Validierung ? Model Server
    32. 32. Große Teile der Applikationwandern nach JavaScript
    33. 33. Ein Einbruch in JavaScript
    34. 34. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben
    35. 35. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben
    36. 36. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben
    37. 37. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben alle Browser-eigenen Methoden!
    38. 38. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben alle Browser-eigenen Methoden! Jeder Inhalt der Seite kann geändert und verraten werden
    39. 39. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben alle Browser-eigenen Methoden! Jeder Inhalt der Seite kann geändert und verraten werden Alle Rechte der Seite - Same Origin und Cookies
    40. 40. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben alle Browser-eigenen Methoden! Jeder Inhalt der Seite kann geändert und verraten werden Alle Rechte der Seite - Same Origin und Cookies Prototype Hijacking: jeder Datenfluss in JavaScript lässt sich korrumpieren
    41. 41. Die eigene Applikationist nicht mehrvertrauenswürdig.
    42. 42. Web 2.0 für Hacker
    43. 43. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-Entwicklung
    44. 44. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScript
    45. 45. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScriptTools zur Automatisierung und Fernsteuerung
    46. 46. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScriptTools zur Automatisierung und FernsteuerungAjax, JavaScript-Libraries und MashUps:Vergrößerte Angriffsfläche
    47. 47. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScriptTools zur Automatisierung und FernsteuerungAjax, JavaScript-Libraries und MashUps:Vergrößerte AngriffsflächeBeispiel Dojo: Ein JavaScript Toolkit erweitert denHTML-Syntax: jeder XSS-Filter auf Serverseite versagt
    48. 48. Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScriptTools zur Automatisierung und FernsteuerungAjax, JavaScript-Libraries und MashUps:Vergrößerte AngriffsflächeBeispiel Dojo: Ein JavaScript Toolkit erweitert denHTML-Syntax: jeder XSS-Filter auf Serverseite versagtWAFs können nicht mehr auf URL-Navigation prüfen
    49. 49. Angriffe und Exploits
    50. 50. Intranet/VPN-Attacken
    51. 51. Intranet/VPN-AttackenErkennung der Browser-IP per Java / Liveconnect
    52. 52. Intranet/VPN-AttackenErkennung der Browser-IP per Java / Liveconnectnmap für Arme: Host- und Portscanning
    53. 53. Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap für Arme: Host- und Portscanning über Iframes, Img-Tags, JavaScript, ohne JavaScript über Timing von <link>-Includes:<img src=“http://192.168.2.1:80/“onError=“stoptimer(“192.168.2.1“, 80);“ />
    54. 54. Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap für Arme: Host- und Portscanning über Iframes, Img-Tags, JavaScript, ohne JavaScript über Timing von <link>-Includes:<img src=“http://192.168.2.1:80/“onError=“stoptimer(“192.168.2.1“, 80);“ /> Dictionary-Attacken auf das Intranet
    55. 55. Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap für Arme: Host- und Portscanning über Iframes, Img-Tags, JavaScript, ohne JavaScript über Timing von <link>-Includes:<img src=“http://192.168.2.1:80/“onError=“stoptimer(“192.168.2.1“, 80);“ /> Dictionary-Attacken auf das Intranet Erkennung von Devices und vorhandener Logins über URLs, History-Hack
    56. 56. Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap für Arme: Host- und Portscanning über Iframes, Img-Tags, JavaScript, ohne JavaScript über Timing von <link>-Includes:<img src=“http://192.168.2.1:80/“onError=“stoptimer(“192.168.2.1“, 80);“ /> Dictionary-Attacken auf das Intranet Erkennung von Devices und vorhandener Logins über URLs, History-Hack Breite Angriffe (zB Drive-By-Pharming)
    57. 57. Live-Demo: BeEf
    58. 58. Cross-Zone-Exploits:Attacken auf den lokalenRechner
    59. 59. Das Browser-Zonenmodell
    60. 60. Das Browser-ZonenmodellSicherheitszonen im Browser
    61. 61. Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files
    62. 62. Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)
    63. 63. Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)IE: Ausführung von ActiveX-Plugins -> Shell Executions
    64. 64. Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)IE: Ausführung von ActiveX-Plugins -> Shell ExecutionsFirefox: Ausführung von JavaScript mit vollem lokalenFile-Zugriff -> Überlieferung an dritte Parteien
    65. 65. Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)IE: Ausführung von ActiveX-Plugins -> Shell ExecutionsFirefox: Ausführung von JavaScript mit vollem lokalenFile-Zugriff -> Überlieferung an dritte ParteienSafari: lokale Ausführung mit vollem Internetzugriff ->Auslesen des Intra/Internets ohne Beschränkung
    66. 66. Cross-Zone-Attacken
    67. 67. Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-Bypass
    68. 68. Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://
    69. 69. Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone Scripting
    70. 70. Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone ScriptingApple Quicktime
    71. 71. Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone ScriptingApple QuicktimeFirefox Firebug Extension
    72. 72. Plugins
    73. 73. Plugins und Security
    74. 74. Plugins und Security Malware-Quelle Nr 1: Browser Plugins
    75. 75. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ...
    76. 76. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert
    77. 77. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert Kritischer Zeitraum zwischen Bekanntwerden der Lücke und Fix, Ursache für Browserupdates
    78. 78. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert Kritischer Zeitraum zwischen Bekanntwerden der Lücke und Fix, Ursache für Browserupdates Gewerblicher Verkauf von Browser-Lücken
    79. 79. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert Kritischer Zeitraum zwischen Bekanntwerden der Lücke und Fix, Ursache für Browserupdates Gewerblicher Verkauf von Browser-Lücken Sehr grosse Reichweite: Superbowl Dolphin Stadium
    80. 80. Plugins und JavaScript
    81. 81. Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins
    82. 82. Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-PluginsDiese Plugins können z.T. in beide Richtungen mit demJavaScript des Browser interagieren
    83. 83. Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-PluginsDiese Plugins können z.T. in beide Richtungen mit demJavaScript des Browser interagierenJedes Plugin vervielfältigt die Angriffsfläche
    84. 84. Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-PluginsDiese Plugins können z.T. in beide Richtungen mit demJavaScript des Browser interagierenJedes Plugin vervielfältigt die Angriffsflächecrossdomain.xml bei Flash und Silverlight
    85. 85. MashUp-Attacken
    86. 86. MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-Include
    87. 87. MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper RSS-Feed, User-Generated Content, Services
    88. 88. MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper RSS-Feed, User-Generated Content, ServicesGrundproblem: weniger Vertrauen, gleiche Rechte
    89. 89. MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper RSS-Feed, User-Generated Content, ServicesGrundproblem: weniger Vertrauen, gleiche RechteSame-Origin-Policy stirbt mit MashUps
    90. 90. Willkommen im Web:Viren
    91. 91. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)
    92. 92. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)
    93. 93. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace
    94. 94. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert
    95. 95. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert Blacklist-Filter hatte Lücken, XSS wurde möglich
    96. 96. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert Blacklist-Filter hatte Lücken, XSS wurde möglich CSRF über Token geschützt, durch XSS korrumpiert
    97. 97. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert Blacklist-Filter hatte Lücken, XSS wurde möglich CSRF über Token geschützt, durch XSS korrumpiert Innerhalb von 15 Stunden auf 1 Million Accounts verbreitet
    98. 98. XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert Blacklist-Filter hatte Lücken, XSS wurde möglich CSRF über Token geschützt, durch XSS korrumpiert Innerhalb von 15 Stunden auf 1 Million Accounts verbreitet
    99. 99. Aktueller Status Viren
    100. 100. Aktueller Status Viren JavaScript-Viren und Würmer immer noch:
    101. 101. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace
    102. 102. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail
    103. 103. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007)
    104. 104. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007) Aus der Praxis, ein CSRF-Only-Wurm:
    105. 105. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007) Aus der Praxis, ein CSRF-Only-Wurm: Bild-URL: /addfriend/johannhartmann
    106. 106. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007) Aus der Praxis, ein CSRF-Only-Wurm: Bild-URL: /addfriend/johannhartmann Bisher war die Applikation SPoF der Viren
    107. 107. Privatsphäre unddas Web 2.0
    108. 108. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze
    109. 109. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt
    110. 110. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com
    111. 111. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com Suizid aufgrund von Verleumdung
    112. 112. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com Suizid aufgrund von Verleumdung sexuelle Belästigung
    113. 113. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com Suizid aufgrund von Verleumdung sexuelle Belästigung aber: führte auch zur Entdeckung von Straftätern
    114. 114. Social Communities2005: Ich gebe meine Daten frei, und bekomme dafürKontakte2006: Ich sage, wem ich welche Daten freigebe, undkann dies zurückziehen2007: Meine Daten werden weiterverwertetich kann meine Daten nur noch auf der ursprünglichenPlattform zurückziehenOpenID und OpenSocial: Schnellere Verbreitung
    115. 115. Das Vertrauensmodell vonSocial Communities reicht inZukunft nicht mehr aus.
    116. 116. Mit der Gefahr leben
    117. 117. Sicherheit im Client
    118. 118. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack
    119. 119. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript
    120. 120. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory
    121. 121. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory Firefox 3.0 löst eine ganze Reihe von Problemen
    122. 122. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory Firefox 3.0 löst eine ganze Reihe von Problemen Browser Shielding: Signaturen bekannter Angriffe kommen nicht mehr zum Browser
    123. 123. Zukunft: Vertrauen imBrowser
    124. 124. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum
    125. 125. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser
    126. 126. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk
    127. 127. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk JavaScript kann für Bereiche der Seite verboten werden
    128. 128. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk JavaScript kann für Bereiche der Seite verboten werden Komponenten entscheiden selbst, welche anderen Komponenten auf sie zugreifen dürfen.
    129. 129. Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk JavaScript kann für Bereiche der Seite verboten werden Komponenten entscheiden selbst, welche anderen Komponenten auf sie zugreifen dürfen. MashUpOS: Browserbasierte granulare Rechte
    130. 130. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0
    131. 131. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung
    132. 132. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter
    133. 133. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting FilterCSRF wird einfacher
    134. 134. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting FilterCSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare
    135. 135. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting FilterCSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der FormulareJede Boundary of Trust muss geprüft werden
    136. 136. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting FilterCSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der FormulareJede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
    137. 137. Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting FilterCSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der FormulareJede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
    138. 138. Sicherheit in derEntwicklung: Management
    139. 139. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScript
    140. 140. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScript
    141. 141. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-Schulungen
    142. 142. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-SchulungenRisikoanalyse mit Data Flow Diagrammen
    143. 143. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-SchulungenRisikoanalyse mit Data Flow DiagrammenAudits eingebundener Services
    144. 144. Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-SchulungenRisikoanalyse mit Data Flow DiagrammenAudits eingebundener ServicesEs gibt kein universelles Escaping und keine universelleValidierung
    145. 145. Sicherheit auf Serverseite
    146. 146. Sicherheit auf Serverseite Web Application Firewalls gegen XSS
    147. 147. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst
    148. 148. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy
    149. 149. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy Die Integration wird auf den Server verlegt
    150. 150. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy Die Integration wird auf den Server verlegt der Server validiert und säubert die Daten aus den externen Quellen
    151. 151. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy Die Integration wird auf den Server verlegt der Server validiert und säubert die Daten aus den externen Quellen
    152. 152. Privacy im Web 2.0
    153. 153. Privacy im Web 2.0Relationship-basierte Rechtefreigabe
    154. 154. Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTagging
    155. 155. Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur Interoperabilität: wer darf welche Datenweitergeben
    156. 156. Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur Interoperabilität: wer darf welche DatenweitergebenFreigaben sind Sticky und folgen den Daten
    157. 157. Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur Interoperabilität: wer darf welche DatenweitergebenFreigaben sind Sticky und folgen den DatenFreigaben mit Verfallsdatum
    158. 158. Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur Interoperabilität: wer darf welche DatenweitergebenFreigaben sind Sticky und folgen den DatenFreigaben mit VerfallsdatumSpidering-Protection
    159. 159. Fragen?
    160. 160. Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de xing.com/profile/JohannPeter_Hartmann

    ×