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