SlideShare ist ein Scribd-Unternehmen logo

Heisec 2008 web 2.0

Johann-Peter Hartmann, profile picture
Johann-Peter Hartmann

Die Heise Security Conference 2008 thematisiert die Risiken und Herausforderungen von Web 2.0, insbesondere im Hinblick auf JavaScript-Sicherheit, Cross-Zone-Exploits und die Gefahren durch Browser-Plugins. Es wird aufgezeigt, dass viele Angriffe auf Webanwendungen abzielen und dass die Sicherheitsaudits oft hinterherhinken, was durch steigende Komplexität und neue Technologien wie AJAX verschärft wird. Außerdem wird die Notwendigkeit betont, Privatsphäre und Vertrauen in sozialen Netzwerken neu zu bewerten, da persönliche Daten zunehmend verwertet werden können.

1 von 162
Downloaden Sie, um offline zu lesen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
Web 2.0 zwischen Nutzen und Gefahr Heise Security Conference 2008
Agenda Alles wird anders: Architektur bei Web 2.0
Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0
Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware
Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware Privacy und/oder das Web 2.0
Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware Privacy und/oder das Web 2.0 Lö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.
Heisec 2008 web 2.0
2/3 aller Angriffe sind kommerzieller 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 Applikation wandern 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 Applikation ist nicht mehr vertrauenswürdig.
Web 2.0 für Hacker
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche Beispiel Dojo: Ein JavaScript Toolkit erweitert den HTML-Syntax: jeder XSS-Filter auf Serverseite versagt
Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche Beispiel Dojo: Ein JavaScript Toolkit erweitert den HTML-Syntax: jeder XSS-Filter auf Serverseite versagt WAFs können nicht mehr auf URL-Navigation prüfen
Angriffe und Exploits
Intranet/VPN-Attacken
Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect
Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap 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 lokalen Rechner
Das Browser-Zonenmodell
Das Browser-Zonenmodell Sicherheitszonen im Browser
Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files
Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)
Das Browser-Zonenmodell Sicherheitszonen 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-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome) IE: Ausführung von ActiveX-Plugins -> Shell Executions Firefox: Ausführung von JavaScript mit vollem lokalen File-Zugriff -> Überlieferung an dritte Parteien
Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome) IE: Ausführung von ActiveX-Plugins -> Shell Executions Firefox: Ausführung von JavaScript mit vollem lokalen File-Zugriff -> Überlieferung an dritte Parteien Safari: lokale Ausführung mit vollem Internetzugriff -> Auslesen des Intra/Internets ohne Beschränkung
Cross-Zone-Attacken
Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass
Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file://
Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting
Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting Apple Quicktime
Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting Apple Quicktime Firefox 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 JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins
Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren
Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren Jedes Plugin vervielfältigt die Angriffsfläche
Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren Jedes Plugin vervielfältigt die Angriffsfläche crossdomain.xml bei Flash und Silverlight
MashUp-Attacken
MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include
MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services
MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services Grundproblem: weniger Vertrauen, gleiche Rechte
MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services Grundproblem: weniger Vertrauen, gleiche Rechte Same-Origin-Policy stirbt mit MashUps
Willkommen im Web: Viren
XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS)
XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS) Möglichkeit zur Distribution (CSRF)
XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS) Möglichkeit zur Distribution (CSRF) Beispiel: Samy-Wurm auf MySpace
XSS Würmer und Viren Benö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 Viren Benö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 Viren Benö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 Viren Benö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 Viren Benö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 und das 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
Heisec 2008 web 2.0
Social Communities 2005: Ich gebe meine Daten frei, und bekomme dafür Kontakte 2006: Ich sage, wem ich welche Daten freigebe, und kann dies zurückziehen 2007: Meine Daten werden weiterverwertet ich kann meine Daten nur noch auf der ursprünglichen Plattform zurückziehen OpenID und OpenSocial: Schnellere Verbreitung
Das Vertrauensmodell von Social Communities reicht in Zukunft 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 im Browser
Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum
Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser
Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk
Zukunft: Vertrauen im Browser 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 im Browser 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 im Browser 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 der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
Sicherheit in der Entwicklung: Management
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen Audits eingebundener Services
Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen Audits eingebundener Services Es gibt kein universelles Escaping und keine universelle Validierung
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.0 Relationship-basierte Rechtefreigabe
Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging
Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben
Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten
Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten Freigaben mit Verfallsdatum
Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten Freigaben mit Verfallsdatum Spidering-Protection
Fragen?
Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de xing.com/profile/JohannPeter_Hartmann

Weitere ähnliche Inhalte

KEY
Web 2.0 revisited
Johann-Peter Hartmann
 
PDF
Vernetzte Services
Dirk Zimmermann
 
PDF
Step 1 - Neues Projekt anlegen und Cubefaces importieren
Harald Bendschneider
 
PDF
2012_BPK_Rede.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
PI ImageAward.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
Staples - Unternehmenspräsentation
Staples Germany
 
PDF
Bong - Umweltbroschüre
Staples Germany
 
PDF
Rein Melissa Fragebogen.pdf
unn | UNITED NEWS NETWORK GmbH
 
Web 2.0 revisited
Johann-Peter Hartmann
 
Vernetzte Services
Dirk Zimmermann
 
Step 1 - Neues Projekt anlegen und Cubefaces importieren
Harald Bendschneider
 
2012_BPK_Rede.pdf
unn | UNITED NEWS NETWORK GmbH
 
PI ImageAward.pdf
unn | UNITED NEWS NETWORK GmbH
 
Staples - Unternehmenspräsentation
Staples Germany
 
Bong - Umweltbroschüre
Staples Germany
 
Rein Melissa Fragebogen.pdf
unn | UNITED NEWS NETWORK GmbH
 

Andere mochten auch (7)

PDF
Offene Wahlen Webcast #1
Stefan Kasberger
 
PDF
HI Sport und Fußpflege.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
MarktkommentarRenten.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
Interview Tenbrink.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
PM 11-12-15 BKK Gesundheitsreport.pdf
unn | UNITED NEWS NETWORK GmbH
 
PDF
10 bittere Wahrheiten über das Social Web
Social Event GmbH
 
PPT
DOSS2012 MobileLearning Keynote IsaJahnke
Isa Jahnke
 
Offene Wahlen Webcast #1
Stefan Kasberger
 
HI Sport und Fußpflege.pdf
unn | UNITED NEWS NETWORK GmbH
 
MarktkommentarRenten.pdf
unn | UNITED NEWS NETWORK GmbH
 
Interview Tenbrink.pdf
unn | UNITED NEWS NETWORK GmbH
 
PM 11-12-15 BKK Gesundheitsreport.pdf
unn | UNITED NEWS NETWORK GmbH
 
10 bittere Wahrheiten über das Social Web
Social Event GmbH
 
DOSS2012 MobileLearning Keynote IsaJahnke
Isa Jahnke
 
Anzeige

Ähnlich wie Heisec 2008 web 2.0 (20)

PPTX
CQRS in der Praxis - Newsletter Double-Opt-In
PHP in DD
 
PDF
API-Design, Microarchitecture und Testing
OPEN KNOWLEDGE GmbH
 
PDF
HTML5 und node.js Grundlagen
Mayflower GmbH
 
PPTX
Wie viel Client braucht das Web?JSF, Vaadin und AngularJS im Vergleich
gedoplan
 
PDF
Vaadinator erweitern
Daniel Nordhoff-Vergien
 
PDF
Ein Blick in die Zukunft von in-STEP RED und objectiF RM
microTOOL GmbH
 
PPTX
SignalR
Robin Sedlaczek
 
PDF
Java-Webanwendungen mit Vaadin 8
gedoplan
 
ODP
Effiziente Fehlersuche in Web 2.0 Anwendungen
Martin Leyrer
 
PPT
1. Technologie-Tag - Webstandards
Nico Steiner
 
ODP
Effiziente Fehlersuche In Web 2.0 Anwendungen - Graz Edition
Martin Leyrer
 
PDF
OSMC 2012 | End2End-Monitoring von Webapplikationen mit SAHI by Simon Meggle
NETWAYS
 
PDF
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
OPEN KNOWLEDGE GmbH
 
PDF
Serverless: The Missing Manual
OPEN KNOWLEDGE GmbH
 
PDF
Acceptance Testing - Automatisierte Web App Tests mit CasperJS
Björn Wilmsmann
 
PDF
Ruby on Rails in a metro session
Virttoo org
 
PDF
Wieviel client braucht das web
gedoplan
 
PPT
Ivory Soa Suite
Predrag61
 
PDF
Back to the Frontend – aber nun mit Microservices
André Fleischer
 
PDF
Django - The Web framework for perfectionists with deadlines
Markus Zapke-Gründemann
 
CQRS in der Praxis - Newsletter Double-Opt-In
PHP in DD
 
API-Design, Microarchitecture und Testing
OPEN KNOWLEDGE GmbH
 
HTML5 und node.js Grundlagen
Mayflower GmbH
 
Wie viel Client braucht das Web?JSF, Vaadin und AngularJS im Vergleich
gedoplan
 
Vaadinator erweitern
Daniel Nordhoff-Vergien
 
Ein Blick in die Zukunft von in-STEP RED und objectiF RM
microTOOL GmbH
 
SignalR
Robin Sedlaczek
 
Java-Webanwendungen mit Vaadin 8
gedoplan
 
Effiziente Fehlersuche in Web 2.0 Anwendungen
Martin Leyrer
 
1. Technologie-Tag - Webstandards
Nico Steiner
 
Effiziente Fehlersuche In Web 2.0 Anwendungen - Graz Edition
Martin Leyrer
 
OSMC 2012 | End2End-Monitoring von Webapplikationen mit SAHI by Simon Meggle
NETWAYS
 
From Zero to still Zero: Die schönsten Fehler auf dem Weg in die Cloud
OPEN KNOWLEDGE GmbH
 
Serverless: The Missing Manual
OPEN KNOWLEDGE GmbH
 
Acceptance Testing - Automatisierte Web App Tests mit CasperJS
Björn Wilmsmann
 
Ruby on Rails in a metro session
Virttoo org
 
Wieviel client braucht das web
gedoplan
 
Ivory Soa Suite
Predrag61
 
Back to the Frontend – aber nun mit Microservices
André Fleischer
 
Django - The Web framework for perfectionists with deadlines
Markus Zapke-Gründemann
 
Anzeige

Mehr von Johann-Peter Hartmann (20)

PPTX
The End of my Career
Johann-Peter Hartmann
 
PDF
E-Commerce vs Architektur CodeTalks.Commerce_2018
Johann-Peter Hartmann
 
PDF
DevOps beyond the Tools
Johann-Peter Hartmann
 
PDF
Warum die it nicht um new work herumkommt
Johann-Peter Hartmann
 
PDF
Legacy php - Sanieren oder Ablösen?
Johann-Peter Hartmann
 
PDF
RoofTop Brains & BBQ: Ein Gästbuch für China
Johann-Peter Hartmann
 
PDF
Die Architektur, die man kann
Johann-Peter Hartmann
 
PDF
NewWork in der Praxis
Johann-Peter Hartmann
 
PDF
Von Kutschern, Managern und Systemadministratoren
Johann-Peter Hartmann
 
PDF
Das Ende der Karriere
Johann-Peter Hartmann
 
PDF
DevOps jenseits der Tools
Johann-Peter Hartmann
 
PDF
Reparier Deine Unternehmenskultur!
Johann-Peter Hartmann
 
PDF
Lügen, schlimme Lügen und IT-Verträge
Johann-Peter Hartmann
 
PDF
How not to screw the operating system of your startup
Johann-Peter Hartmann
 
PDF
Einfangen eines technisch kaputten projektes
Johann-Peter Hartmann
 
PDF
Agile versus Management WJAX 2014
Johann-Peter Hartmann
 
PDF
Leadership in der IT
Johann-Peter Hartmann
 
PDF
Vom Entwickler zur Führungskraft
Johann-Peter Hartmann
 
PDF
Erfolgreiche rewrites
Johann-Peter Hartmann
 
PDF
Surviving Complexity
Johann-Peter Hartmann
 
The End of my Career
Johann-Peter Hartmann
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
Johann-Peter Hartmann
 
DevOps beyond the Tools
Johann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
Johann-Peter Hartmann
 
Legacy php - Sanieren oder Ablösen?
Johann-Peter Hartmann
 
RoofTop Brains & BBQ: Ein Gästbuch für China
Johann-Peter Hartmann
 
Die Architektur, die man kann
Johann-Peter Hartmann
 
NewWork in der Praxis
Johann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
Johann-Peter Hartmann
 
Das Ende der Karriere
Johann-Peter Hartmann
 
DevOps jenseits der Tools
Johann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
Johann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Johann-Peter Hartmann
 
How not to screw the operating system of your startup
Johann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
Johann-Peter Hartmann
 
Agile versus Management WJAX 2014
Johann-Peter Hartmann
 
Leadership in der IT
Johann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
Johann-Peter Hartmann
 
Erfolgreiche rewrites
Johann-Peter Hartmann
 
Surviving Complexity
Johann-Peter Hartmann
 

Heisec 2008 web 2.0

  • 1. Web 2.0 zwischen Nutzen und Gefahr Heise Security Conference 2008
  • 2. Agenda Alles wird anders: Architektur bei Web 2.0
  • 3. Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0
  • 4. Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware
  • 5. Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware Privacy und/oder das Web 2.0
  • 6. Agenda Alles wird anders: Architektur bei Web 2.0 JavaScript-Security und Web 2.0 Cross-Zone-Attacken, Plugins, JavaScript Malware Privacy und/oder das Web 2.0 Lösungswege für Client und Server und Nutzer
  • 10. 2/3 aller Exploits richten sich gegen Webapplikationen.
  • 12. 2/3 aller Angriffe sind kommerzieller Natur.
  • 13. Was sich im Web 2.0 ändert
  • 14. Wechsel von Server zur RIA Browser Server
  • 15. Wechsel von Server zur RIA Browser Model Server
  • 16. Wechsel von Server zur RIA Browser Controller Model Server
  • 17. Wechsel von Server zur RIA Browser Controller Model Server View
  • 18. Wechsel von Server zur RIA Browser Controller Model Server View
  • 19. Wechsel von Server zur RIA Browser Controller Model Server View
  • 20. Wechsel von Server zur RIA Browser Controller Model Server View
  • 21. Wechsel von Server zur RIA Browser Input-Validierung Controller Model Server View
  • 22. Wechsel von Server zur RIA Browser Controller Model Server View
  • 23. Wechsel von Server zur RIA Browser Controller Escaping Model Server View
  • 24. Wechsel von Server zur RIA Browser Controller Model Server View
  • 25. Wechsel von Server zur RIA Browser Browser Controller Model Server View
  • 26. Wechsel von Server zur RIA Browser Browser View Controller Model Server
  • 27. Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • 28. Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • 29. Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • 30. Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • 31. Wechsel von Server zur RIA Browser Controller Browser View Model Server
  • 32. Wechsel von Server zur RIA Browser Controller Browser View Input-Validierung ? Model Server
  • 33. Große Teile der Applikation wandern nach JavaScript
  • 34. Ein Einbruch in JavaScript
  • 35. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben
  • 36. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben
  • 37. Ein Einbruch in JavaScript Jede Variable lässt sich überschreiben Jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben
  • 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!
  • 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
  • 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
  • 41. 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
  • 42. Die eigene Applikation ist nicht mehr vertrauenswürdig.
  • 43. Web 2.0 für Hacker
  • 44. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung
  • 45. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript
  • 46. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung
  • 47. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche
  • 48. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche Beispiel Dojo: Ein JavaScript Toolkit erweitert den HTML-Syntax: jeder XSS-Filter auf Serverseite versagt
  • 49. Web 2.0 für Hacker Nicht nur ein Vorteil für den Entwickler: Die Fortschritte in der JavaScript-Entwicklung Libraries und Attack-Toolkits in JavaScript Tools zur Automatisierung und Fernsteuerung Ajax, JavaScript-Libraries und MashUps: Vergrößerte Angriffsfläche Beispiel Dojo: Ein JavaScript Toolkit erweitert den HTML-Syntax: jeder XSS-Filter auf Serverseite versagt WAFs können nicht mehr auf URL-Navigation prüfen
  • 53. Intranet/VPN-Attacken Erkennung der Browser-IP per Java / Liveconnect nmap für Arme: Host- und Portscanning
  • 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);“ />
  • 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
  • 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
  • 57. 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)
  • 62. Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files
  • 63. Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome)
  • 64. Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome) IE: Ausführung von ActiveX-Plugins -> Shell Executions
  • 65. Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome) IE: Ausführung von ActiveX-Plugins -> Shell Executions Firefox: Ausführung von JavaScript mit vollem lokalen File-Zugriff -> Überlieferung an dritte Parteien
  • 66. Das Browser-Zonenmodell Sicherheitszonen im Browser IE: Restricted, Internet, Trusted, Intranet, Local Files Firefox, Safari: Internet und Local Files, (Chrome) IE: Ausführung von ActiveX-Plugins -> Shell Executions Firefox: Ausführung von JavaScript mit vollem lokalen File-Zugriff -> Überlieferung an dritte Parteien Safari: lokale Ausführung mit vollem Internetzugriff -> Auslesen des Intra/Internets ohne Beschränkung
  • 69. Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file://
  • 70. Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting
  • 71. Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting Apple Quicktime
  • 72. Cross-Zone-Attacken Internet-Explorer: Bitlance Winter Security-Zone- Bypass PDF/HTML/Word-Downloads mit Links auf file:// Skype Cross Zone Scripting Apple Quicktime Firefox Firebug Extension
  • 75. Plugins und Security Malware-Quelle Nr 1: Browser Plugins
  • 76. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ...
  • 77. Plugins und Security Malware-Quelle Nr 1: Browser Plugins Flash, Quicktime, ActiveX(!), ... Lücken werden per JavaScript getriggert
  • 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
  • 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
  • 80. 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
  • 82. Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins
  • 83. Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren
  • 84. Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren Jedes Plugin vervielfältigt die Angriffsfläche
  • 85. Plugins und JavaScript Viele Plugins unterstützen selbst JavaScript Flash, PDF QuickTime ActiveX-Plugins Diese Plugins können z.T. in beide Richtungen mit dem JavaScript des Browser interagieren Jedes Plugin vervielfältigt die Angriffsfläche crossdomain.xml bei Flash und Silverlight
  • 87. MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include
  • 88. MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services
  • 89. MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services Grundproblem: weniger Vertrauen, gleiche Rechte
  • 90. MashUp-Attacken JavaScript Hijacking (z.B. Google Mail) Mail-Kontakte als JavaScript-Include Indirektes Defacement und XSS per RSS-Feed, User-Generated Content, Services Grundproblem: weniger Vertrauen, gleiche Rechte Same-Origin-Policy stirbt mit MashUps
  • 92. XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS)
  • 93. XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS) Möglichkeit zur Distribution (CSRF)
  • 94. XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS) Möglichkeit zur Distribution (CSRF) Beispiel: Samy-Wurm auf MySpace
  • 95. XSS Würmer und Viren Benötigt wird: Code-Payload (persistenter XSS) Möglichkeit zur Distribution (CSRF) Beispiel: Samy-Wurm auf MySpace Aus Usability HTML-Eingaben erlaubt und gefiltert
  • 96. XSS Würmer und Viren Benö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
  • 97. XSS Würmer und Viren Benö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
  • 98. XSS Würmer und Viren Benö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. XSS Würmer und Viren Benö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
  • 101. Aktueller Status Viren JavaScript-Viren und Würmer immer noch:
  • 102. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace
  • 103. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail
  • 104. Aktueller Status Viren JavaScript-Viren und Würmer immer noch: SpaceFlash auf MySpace Yamanner auf Yahoo Mail Orkut Virus (Dezember 2007)
  • 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:
  • 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
  • 107. 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
  • 109. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze
  • 110. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt
  • 111. Privacy 2.0 Stacy Snyder: Lehramtsanwärterin mit MySpace-Foto mit Piratenmütze Abschluss wurde aufgrund dieses Bilds abgelehnt http://mycrimespace.com
  • 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
  • 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
  • 114. 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
  • 116. Social Communities 2005: Ich gebe meine Daten frei, und bekomme dafür Kontakte 2006: Ich sage, wem ich welche Daten freigebe, und kann dies zurückziehen 2007: Meine Daten werden weiterverwertet ich kann meine Daten nur noch auf der ursprünglichen Plattform zurückziehen OpenID und OpenSocial: Schnellere Verbreitung
  • 117. Das Vertrauensmodell von Social Communities reicht in Zukunft nicht mehr aus.
  • 118. Mit der Gefahr leben
  • 120. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack
  • 121. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript
  • 122. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory
  • 123. Sicherheit im Client Browser-Extensions für den Firefox: XSS & History Hack NoScript SafeHistory Firefox 3.0 löst eine ganze Reihe von Problemen
  • 124. 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
  • 126. Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum
  • 127. Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser
  • 128. Zukunft: Vertrauen im Browser Granulare Rechtevergabe auf die HTML-Resourcen/ DOM-Baum Sichere Defaults im Browser Keine Zugriffe auf das Netzwerk
  • 129. Zukunft: Vertrauen im Browser 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
  • 130. Zukunft: Vertrauen im Browser 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.
  • 131. Zukunft: Vertrauen im Browser 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
  • 132. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0
  • 133. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung
  • 134. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter
  • 135. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher
  • 136. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare
  • 137. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden
  • 138. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
  • 139. Sicherheit in der Entwicklung: konkret XSS ist ein kritisches Problem bei Web 2.0 gezielter Einsatz von Libraries, Prüfung der Nutzung kein HTML erlauben, oder Whitelisting Filter CSRF wird einfacher CSRF-Schutz über Token-Authentifzierung der Formulare Jede Boundary of Trust muss geprüft werden MashUps, RSS-Feeds, Web Services
  • 141. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript
  • 142. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript
  • 143. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen
  • 144. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen
  • 145. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen Audits eingebundener Services
  • 146. Sicherheit in der Entwicklung: Management Security-Guidelines für Plugins und JavaScript Audits für Desktop-Clients, Plugins und JavaScript regelmässige Entwickler-Schulungen Risikoanalyse mit Data Flow Diagrammen Audits eingebundener Services Es gibt kein universelles Escaping und keine universelle Validierung
  • 148. Sicherheit auf Serverseite Web Application Firewalls gegen XSS
  • 149. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst
  • 150. Sicherheit auf Serverseite Web Application Firewalls gegen XSS Virus / Worm/ Spidering Detection in Webserver, WAF oder der Applikation selbst MashUp-Proxy
  • 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
  • 152. 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
  • 153. 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
  • 155. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe
  • 156. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging
  • 157. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben
  • 158. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten
  • 159. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten Freigaben mit Verfallsdatum
  • 160. Privacy im Web 2.0 Relationship-basierte Rechtefreigabe flexible Gruppierung von Rechten und Personen über Tagging Regeln zur Interoperabilität: wer darf welche Daten weitergeben Freigaben sind Sticky und folgen den Daten Freigaben mit Verfallsdatum Spidering-Protection
  • 162. Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de xing.com/profile/JohannPeter_Hartmann

Hinweis der Redaktion

  • #2: Web 2.0 hat zwei Grundprobleme: \na) Technische Implikationen: JavaScript und co\nb) Implikationen auf die Privatsph&amp;#xE4;re \nversuch: eher blick von oben als detailliert\n
  • #3: Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas &amp;#xE4;ndert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zus&amp;#xE4;tzlich zu J&amp;#xFC;rgens\nzweites thema: privacy \nl&amp;#xF6;sungswege f&amp;#xFC;r problemfeld technik, aktuellen diskussionsstand f&amp;#xFC;r problemfeld privacy \n
  • #4: Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas &amp;#xE4;ndert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zus&amp;#xE4;tzlich zu J&amp;#xFC;rgens\nzweites thema: privacy \nl&amp;#xF6;sungswege f&amp;#xFC;r problemfeld technik, aktuellen diskussionsstand f&amp;#xFC;r problemfeld privacy \n
  • #5: Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas &amp;#xE4;ndert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zus&amp;#xE4;tzlich zu J&amp;#xFC;rgens\nzweites thema: privacy \nl&amp;#xF6;sungswege f&amp;#xFC;r problemfeld technik, aktuellen diskussionsstand f&amp;#xFC;r problemfeld privacy \n
  • #6: Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas &amp;#xE4;ndert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zus&amp;#xE4;tzlich zu J&amp;#xFC;rgens\nzweites thema: privacy \nl&amp;#xF6;sungswege f&amp;#xFC;r problemfeld technik, aktuellen diskussionsstand f&amp;#xFC;r problemfeld privacy \n
  • #7: Ausgangssituation: Sicherheitsstatus _bevor_ web 2.0 passiert. \nwas &amp;#xE4;ndert sich in der Entwicklung\nwas sind die implikationen\nwas sind die exploits - zus&amp;#xE4;tzlich zu J&amp;#xFC;rgens\nzweites thema: privacy \nl&amp;#xF6;sungswege f&amp;#xFC;r problemfeld technik, aktuellen diskussionsstand f&amp;#xFC;r problemfeld privacy \n
  • #8: \n
  • #9: \n
  • #10: 1. Mitre Common Vulnerability Enumeration\n2. Security Incident Database Breach Security \nBei Ajax-Applikationen gibt es einen &amp;#xE4;hnlichen Paradigmenwechsel\n\n
  • #11: \n
  • #12: Einfache Variante: Ajaxifizierung der bestehenden L&amp;#xF6;sungen, weniger Page-Reloads \n- applikationen wie google maps oder google mail sehen deutlich anders aus \n\n
  • #13: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #14: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #15: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #16: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #17: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #18: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #19: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #20: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #21: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #22: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #23: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #24: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #25: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #26: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #27: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #28: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #29: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #30: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #31: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #32: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #33: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #34: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #35: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #36: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #37: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #38: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #39: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #40: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #41: Klassische Webanwendung:\nMVC erkl&amp;#xE4;ren: Model, View, Controller\nDer Browser ist eine 3270, mit sch&amp;#xF6;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&amp;#xE4;sslich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enth&amp;#xE4;lt Logik, verdient aber kein Vertrauen\n- Der View findet &amp;#xFC;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
  • #42: Hiermit haben wir es mit noch einem Paradigmenwechsel zu tun.\n
  • #43: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #44: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #45: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #46: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #47: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #48: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #49: XSS haben wir vorhin geh&amp;#xF6;rt - Mit XSS kann man mit JavaScript machen was man will. \n\n
  • #50: \n
  • #51: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #52: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #53: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #54: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #55: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #56: Fazit: \nErwartung w&amp;#xE4;re, dass deutlich mehr komplexe JavaScript-Angriffe m&amp;#xF6;glich werden.\nDie n&amp;#xE4;chsten Folien werden zeigen, was davon stimmt.\n25%\n
  • #57: Was machen die Web 2.0 Hacker mit diesen M&amp;#xF6;glichkeiten \n
  • #58: 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
  • #59: 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
  • #60: 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
  • #61: 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
  • #62: 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
  • #63: 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
  • #64: 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
  • #65: \n
  • #66: \n
  • #67: Ein bischen Theorie zum Thema browsersicherheit\n
  • #68: Ein bischen Theorie zum Thema browsersicherheit\n
  • #69: Ein bischen Theorie zum Thema browsersicherheit\n
  • #70: Ein bischen Theorie zum Thema browsersicherheit\n
  • #71: Ein bischen Theorie zum Thema browsersicherheit\n
  • #72: Ein bischen Theorie zum Thema browsersicherheit\n
  • #73: 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
  • #74: 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
  • #75: 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
  • #76: 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
  • #77: 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
  • #78: \n
  • #79: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #80: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #81: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #82: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #83: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #84: Der Browser kommt nicht alleine, sondern bringt meistens eine Reihe von Tools mit. \nDazu geh&amp;#xF6;ren URL-Moniker, Plugins und Browser-Erweiterungen\n
  • #85: 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
  • #86: 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
  • #87: 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
  • #88: 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
  • #89: \n
  • #90: \n
  • #91: \n
  • #92: \n
  • #93: \n
  • #94: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #95: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #96: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #97: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #98: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #99: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #100: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #101: HTML-Blacklisting ist immer defekt. \nWhitelisting funktioniert, ist aber teuer.\n
  • #102: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #103: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #104: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #105: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #106: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #107: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #108: was passiert bei b&amp;#xF6;sen payloads? \n\n
  • #109: Wikipedia und Blogging kein Sicherheitsthema\nPrivatsph&amp;#xE4;re sehr wohl.\n
  • #110: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #111: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #112: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #113: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #114: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #115: StudiVZ-Spider gab es in deutschland\n\nYasni bekannt?\n\n
  • #116: \n
  • #117: Interesse der Community: Namen findbar \nbei hinreichender gr&amp;#xF6;&amp;#xDF;e nicht mehr n&amp;#xF6;tig \nweiterverwertung nicht nur per spidern\nOpenSocial: Social Community als Eigentschaft von Applikationen\nFlexibler Austausch und Weiterverbreitung von Daten\n
  • #118: \n
  • #119: \n
  • #120: Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • #121: Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • #122: Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • #123: Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • #124: Das hilft den betreibern recht wenig\naber: probleme werden abgenommen. \n
  • #125: Same Origin ist kaputt\nersatz muss her \n
  • #126: Same Origin ist kaputt\nersatz muss her \n
  • #127: Same Origin ist kaputt\nersatz muss her \n
  • #128: Same Origin ist kaputt\nersatz muss her \n
  • #129: Same Origin ist kaputt\nersatz muss her \n
  • #130: Same Origin ist kaputt\nersatz muss her \n
  • #131: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #132: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #133: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #134: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #135: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #136: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #137: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #138: Beste L&amp;#xF6;sung: HTML verbieten\naber: auch dann gibt es XSS \nEs gibt keinen einfachen weg!\n
  • #139: \n
  • #140: \n
  • #141: \n
  • #142: \n
  • #143: \n
  • #144: \n
  • #145: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #146: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #147: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #148: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #149: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #150: Es gibt diverse Ans&amp;#xE4;tze, auf der Serverseite XSS-Probleme zu l&amp;#xF6;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
  • #151: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #152: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #153: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #154: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #155: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #156: Zur zeit: keine wirkliche l&amp;#xF6;sung\nNicht google- und spiderbar \nFreiwilliger Schutz &amp;#xFC;berhaupt machbar und wirksam? Schutz der Freigaben mit DRM? M&amp;#xF6;glichkeit zum Zur&amp;#xFC;ckziehen.\nOpenSocial selbst implementiert selbst leider noch keine solche m&amp;#xF6;glichkeiten\n
  • #157: \n
  • #158: \n