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 Ma...
AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript Ma...
AgendaAlles wird anders: Architektur bei Web 2.0JavaScript-Security und Web 2.0Cross-Zone-Attacken, Plugins, JavaScript Ma...
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    ...
Wechsel von Server zur RIA            Browser            Controller    Model    Server      View
Wechsel von Server zur RIA            Browser            Controller                         Escaping    Model    Server   ...
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               ...
Wechsel von Server zur RIA                  Browser     Controller   Browser   View                   Model               ...
Wechsel von Server zur RIA                  Browser     Controller   Browser   View                   Model               ...
Wechsel von Server zur RIA                  Browser     Controller   Browser        View                   Input-Validieru...
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...
Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt...
Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt...
Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt...
Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt...
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 Att...
Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Att...
Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Att...
Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Att...
Web 2.0 für HackerNicht nur ein Vorteil für den Entwickler:Die Fortschritte in der JavaScript-EntwicklungLibraries und Att...
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 Ifram...
Intranet/VPN-Attacken  Erkennung der Browser-IP per Java / Liveconnect  nmap für Arme: Host- und Portscanning   über Ifram...
Intranet/VPN-Attacken  Erkennung der Browser-IP per Java / Liveconnect  nmap für Arme: Host- und Portscanning   über Ifram...
Intranet/VPN-Attacken  Erkennung der Browser-IP per Java / Liveconnect  nmap für Arme: Host- und Portscanning   über Ifram...
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, Saf...
Das Browser-ZonenmodellSicherheitszonen im Browser  IE: Restricted, Internet, Trusted, Intranet, Local Files  Firefox, Saf...
Das Browser-ZonenmodellSicherheitszonen im Browser  IE: Restricted, Internet, Trusted, Intranet, Local Files  Firefox, Saf...
Das Browser-ZonenmodellSicherheitszonen im Browser  IE: Restricted, Internet, Trusted, Intranet, Local Files  Firefox, Saf...
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://Skyp...
Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skyp...
Cross-Zone-AttackenInternet-Explorer: Bitlance Winter Security-Zone-BypassPDF/HTML/Word-Downloads mit Links auf file://Skyp...
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 g...
Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript g...
Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript g...
Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript g...
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ö...
Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript  Flash, PDF  QuickTime  ActiveX-PluginsDiese Plugins kö...
Plugins und JavaScriptViele Plugins unterstützen selbst JavaScript  Flash, PDF  QuickTime  ActiveX-PluginsDiese Plugins kö...
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...
MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper...
MashUp-AttackenJavaScript Hijacking (z.B. Google Mail)Mail-Kontakte als JavaScript-IncludeIndirektes Defacement und XSSper...
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 a...
XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm a...
XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm a...
XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm a...
XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm a...
XSS Würmer und VirenBenötigt wird: Code-Payload (persistenter XSS)Möglichkeit zur Distribution (CSRF)Beispiel: Samy-Wurm a...
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 ...
Aktueller Status Viren JavaScript-Viren und Würmer immer noch:   SpaceFlash auf MySpace   Yamanner auf Yahoo Mail   Orkut ...
Aktueller Status Viren JavaScript-Viren und Würmer immer noch:   SpaceFlash auf MySpace   Yamanner auf Yahoo Mail   Orkut ...
Aktueller Status Viren JavaScript-Viren und Würmer immer noch:   SpaceFlash auf MySpace   Yamanner auf Yahoo Mail   Orkut ...
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 abg...
Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze   Abschluss wurde aufgrund dieses Bilds abg...
Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze   Abschluss wurde aufgrund dieses Bilds abg...
Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze   Abschluss wurde aufgrund dieses Bilds abg...
Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze   Abschluss wurde aufgrund dieses Bilds abg...
Social Communities2005: Ich gebe meine Daten frei, und bekomme dafürKontakte2006: Ich sage, wem ich welche Daten freigebe,...
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...
Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack   NoScript   SafeHistory Firefox 3.0 löst eine...
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 ...
Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser   Keine ...
Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser   Keine ...
Zukunft: Vertrauen imBrowser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser   Keine ...
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 ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
Sicherheit in derEntwicklung: konkretXSS ist ein kritisches Problem bei Web 2.0  gezielter Einsatz von Libraries, Prüfung ...
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 ...
Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins ...
Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins ...
Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins ...
Sicherheit in derEntwicklung: ManagementSecurity-Guidelines für Plugins und JavaScriptAudits für Desktop-Clients, Plugins ...
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 de...
Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder de...
Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder de...
Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder de...
Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder de...
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 I...
Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur I...
Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur I...
Privacy im Web 2.0Relationship-basierte Rechtefreigabeflexible Gruppierung von Rechten und Personen überTaggingRegeln zur I...
Fragen?
Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de xing.com/profile/JohannPeter_Hartmann
Heisec 2008 web 2.0
Heisec 2008 web 2.0
Nächste SlideShare
Wird geladen in …5
×

Heisec 2008 web 2.0

472 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
472
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

    ×