Heisec 2008 web 2.0
Upcoming SlideShare
Loading in...5
×
 

Heisec 2008 web 2.0

on

  • 409 views

 

Statistics

Views

Total Views
409
Views on SlideShare
406
Embed Views
3

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Heisec 2008 web 2.0 Presentation Transcript

  • Web 2.0 zwischen Nutzenund GefahrHeise Security Conference 2008
  • AgendaAlles wird anders: Architektur bei Web 2.0
  • AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0
  • AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript Malware
  • AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript MalwarePrivacy und/oder das Web 2.0
  • 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
  • Desktop-Entwickler haben es einfacher
  • Web und Sicherheit
  • Web und Sicherheit
  • 2/3 aller Exploits richten sich gegen Webapplikationen.
  • 2/3 aller Angriffe sindkommerzieller Natur.
  • Was sich im Web 2.0 ändert
  • Wechsel von Server zur RIA Browser Server
  • Wechsel von Server zur RIA Browser Model Server
  • Wechsel von Server zur RIA Browser Controller Model Server
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Input-Validierung Controller Model Server View
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Controller Escaping Model Server View
  • Wechsel von Server zur RIA Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Browser Controller Model Server View
  • Wechsel von Server zur RIA Browser Browser View Controller Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • Wechsel von Server zur RIA Browser Controller Browser View Input-Validierung ? Model Server
  • Große Teile der Applikationwandern nach JavaScript
  • Ein Einbruch in JavaScript
  • Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben
  • Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben
  • Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben
  • 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!
  • 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
  • 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
  • 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
  • Die eigene Applikationist nicht mehrvertrauenswürdig.
  • Web 2.0 für Hacker
  • Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-Entwicklung
  • Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Attack-Toolkits in JavaScript
  • 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
  • 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
  • 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
  • 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
  • Angriffe und Exploits
  • Intranet/VPN-Attacken
  • Intranet/VPN-AttackenErkennung der Browser-IP per Java / Liveconnect
  • Intranet/VPN-AttackenErkennung der Browser-IP per Java / Liveconnectnmap für Arme: Host- und Portscanning
  • 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);“ />
  • 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
  • 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
  • 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)
  • Live-Demo: BeEf
  • Cross-Zone-Exploits:Attacken auf den lokalenRechner
  • Das Browser-Zonenmodell
  • Das Browser-ZonenmodellSicherheitszonen im Browser
  • Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files
  • Das Browser-ZonenmodellSicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)
  • 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
  • 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
  • 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
  • Cross-Zone-Attacken
  • Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-Bypass
  • Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://
  • Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone Scripting
  • Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone ScriptingApple Quicktime
  • Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skype Cross Zone ScriptingApple QuicktimeFirefox Firebug Extension
  • Plugins
  • Plugins und Security
  • Plugins und Security Malware-Quelle Nr 1: Browser Plugins
  • Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ...
  • Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert
  • 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
  • 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
  • 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
  • Plugins und JavaScript
  • Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins
  • 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
  • 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
  • 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
  • MashUp-Attacken
  • MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-Include
  • MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper RSS-Feed, User-Generated Content, Services
  • 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
  • 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
  • Willkommen im Web:Viren
  • XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)
  • XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)
  • XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm auf MySpace
  • 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
  • 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
  • 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
  • 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
  • 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
  • Aktueller Status Viren
  • Aktueller Status Viren JavaScript-Viren und Würmer immer noch:
  • Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace
  • Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail
  • Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007)
  • 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:
  • 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
  • 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
  • Privatsphäre unddas Web 2.0
  • Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze
  • Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt
  • Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com
  • 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
  • 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
  • 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
  • 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
  • Das Vertrauensmodell vonSocial Communities reicht inZukunft nicht mehr aus.
  • Mit der Gefahr leben
  • Sicherheit im Client
  • Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack
  • Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript
  • Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory
  • Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory Firefox 3.0 löst eine ganze Reihe von Problemen
  • 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
  • Zukunft: Vertrauen imBrowser
  • Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum
  • Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser
  • Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk
  • 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
  • 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.
  • 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
  • Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0
  • Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Sicherheit in derEntwicklung: Management
  • Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScript
  • Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScript
  • Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-Schulungen
  • Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins und JavaScriptregelmässige Entwickler-SchulungenRisikoanalyse mit Data Flow Diagrammen
  • 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
  • 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
  • Sicherheit auf Serverseite
  • Sicherheit auf Serverseite Web Application Firewalls gegen XSS
  • Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst
  • Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy
  • 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
  • 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
  • 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
  • Privacy im Web 2.0
  • Privacy im Web 2.0Relationship-basierte Rechtefreigabe
  • Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTagging
  • Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur Interoperabilität: wer darf welche Datenweitergeben
  • 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
  • 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
  • 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
  • Fragen?
  • Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de xing.com/profile/JohannPeter_Hartmann