Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (19)
Similaire à Web 2.0 revisited
Similaire à Web 2.0 revisited (20)
Plus de Johann-Peter Hartmann
Plus de Johann-Peter Hartmann (17)
Web 2.0 revisited
- 1. Web 2.0 Security Revisited
- 2. ?
- 3. Angriffssituation Web 1.0: 2/3
- 4. 20 % 26 % SQL Injection 17 % Information Disclosure 10 % Known Exploits XSS Missing Authentication 12 % Other 15 %
- 5. Web 1.0 Applikation Browser Server
- 6. Web 1.0 Applikation Browser Model Server
- 7. Web 1.0 Applikation Browser Controller Model Server
- 8. Web 1.0 Applikation Browser Controller Model Server View
- 9. Web 1.0 Applikation Browser Controller Model Server View
- 10. Web 1.0 Applikation Browser Controller Model Server View
- 11. Web 1.0 Applikation Browser Controller Model Server View
- 12. Web 1.0 Applikation Browser Input-Validierung Controller Model Server View
- 13. Web 1.0 Applikation Browser Controller Model Server View
- 14. Web 1.0 Applikation Browser Controller Escaping Model Server View
- 15. Web 1.0 Applikation Browser Controller Model Server View
- 16. RIA-Applikation Browser Controller Model Server View
- 17. RIA-Applikation Browser Browser Controller Model Server View
- 18. RIA-Applikation Browser Browser View Controller Model Server
- 19. RIA-Applikation Browser Controller Browser View Model Server
- 20. RIA-Applikation Browser Controller Browser View Model Server
- 21. RIA-Applikation Browser Controller Browser View Input-Validierung ? Model Server
- 22. XSS
- 23. Ein Einbruch in JavaScript
- 24. Ein Einbruch in JavaScript Variablen lassen sich überschreiben
- 25. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) jedes Objekt lässt sich überschreiben
- 26. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben
- 27. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) jedes Objekt lässt sich überschreiben Jede Methode lässt sich überschreiben alle Browser-eigenen Methoden!
- 28. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) 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
- 29. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) 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
- 30. Ein Einbruch in JavaScript Variablen lassen sich überschreiben (Fast) 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
- 31. JavaScript Würmer JavaScript Viren Cookie Stealing Transaktionen Information Disclosure Intranet / VPN-Attacken
- 34. Mash-Ups Browser Server
- 35. Mash-Ups Map- Browser Widget Server Map-Service
- 36. Mash-Ups Embedded Map- Application Browser Widget Embedded Server Map-Service Application
- 37. Mash-Ups Embedded Map- Application Browser Widget Embedded Server Map-Service Application
- 38. crossdomain.xml JSON Hijacking ClickJacking JavaScript Rootkits Google Wave Facebook
- 42. Schutz für Embedded Applications HTML, JS und SQL werden ersetzt Facebook: FBML, FBJS und FBQL ADsafe Google, Yahoo, MySpace: Caja
- 43. FBML/FBJS function hello(name) { var greeting = {name:name}; $(“greetingdiv“).innerHTML = greeting.name; } function a21987_hello(name) { var a21987_greeting = {name:name}; $(“greetingdiv“).setInnerFBML(a21987_greeting.name); }
- 44. Caja
- 45. Caja Capability-Based Security für JavaScript Security-Modell ähnlich ACL, RBACL etc Statt Objekten/Referenzen werden Capabilities übergeben
- 46. Caja Capability-Based Security für JavaScript Security-Modell ähnlich ACL, RBACL etc Statt Objekten/Referenzen werden Capabilities übergeben Resource: /tmp/cookie_file Capability: $fd = fopen(‘/tmp/cookie_file‘, ‘r‘);
- 47. Mash-Ups Embedded Map- Application Browser Widget Embedded Server Map-Service Application
- 48. Caja JavaScript/HTML/CSS wird rewritten „Virtual IFrame“ keine Zugriffe auf globale Entities Embedded Valija Cajoler App
- 49. Neue Features == Neue Injections!
- 50. Facebook Privacy „Wenn Du eine Anwendung autorisierst, kann diese auf jegliche Informationen Deines Kontos zugreifen, die diese benötigt, um zu funktionieren.“
- 51. Facebook Privacy „Wenn einer Deiner Freunde eine Anwendung besucht oder diese autorisiert, kann die Anwendung unter anderem auf die Freundesliste deines Freundes sowie auf Informationen über die darin enthaltenen Personen zugreifen.“
- 52. Facebook Privacy The Month of the Facebook Bugs: „Many Facebook applications, even widely used or seemingly trustworthy ones, lack basic security precautions.“ 6 der Top 10 waren betroffen.
- 53. Realtime Web Die Verbreitung von Viren und Würmern wird schneller im besten Fall Denial of Service im schlechtesten Fall Beyond Repair (das ist neu)
- 54. RIA-Cloud Service-Cloud
- 55. RIA-Cloud Browser Service-Cloud
- 56. RIA-Cloud Browser Mobile Widget Service-Cloud
- 57. RIA-Cloud Browser Mobile Widget RIA-Client Service-Cloud
- 58. Cross-Zone-Exploits Geo-Data-Access PIM-Data-Access
- 60. phonegap
- 61. Browser Security location-Spoofing-Schutz JSON HiJacking (alle aktuellen Browser) XSS in CSS verbieten (alle aktuellen Browser) Origin/Access-Control Headers als CSRF-Schutz Content Security Policy JSON.parse() toStaticHTML (IE8)
- 62. Browserbasierte JS- Sicherheit Cross-Document-Messaging: otherWindow.postMessage(‘Hi!‘, ‘http://google.de/‘); window.addEventListener(“message“, receiveMessage, senderWindow); function receiveMessage(event) { if (event.origin !== ‘http://bing.com‘) return; ...
- 63. Sichere Web 2.0 Applikationen Browser-Features und Header, falls möglich, nutzen Wer Widgets / Mashups / UGC mit JS erlaubt: Caja nutzen! Widgets Caja-konform entwickeln Applikationen _müssen_ XSS und CSRF-Schutz enthalten
- 64. Vielen Dank! Weitere Fragen: johann-peter.hartmann@sektioneins.de
Notes de l'éditeur
- Die größte Attack Surface der Welt - nun noch größer.\n
- Vorstellen!\nWer war schon auf dem Talk vor 2 Jahren? \nWer ist Developer? \nWer hat schon mal Facebook-Applikationen entwickelt? \nWer entwickelt RIA-Applikationen? \nDojo? JQuery? Was ist besser? \nWer kennt XSS? CSRF? \nIch setze XSS vorraus\n\n
- Wie sieht es bisher im Web 1.0 aus?\n2/3-Regel: \n2/3 aller Exploits richten sich gegen Webapplikationen\nAttack-Surface ist das Web\nKritische Daten finden im Web statt\n2/3 aller untersuchten Angriffe sind monetär motiviert\n\n\n
- Sicherheitssituation Web 1.0\nDaten von untersuchten Angriffen\n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Klassische Webanwendung:\nMVC erklären: Model, View, Controller\nDer Browser ist eine 3270, mit schönem Layout und ohne eigene Intelligenz. \nDie Intelligenz findet zu 100% im Server statt.\nDie Sicherheit auch:\n- alle eingehenden Daten werden validiert \n- alle ausgehenden Daten werden escaped \n- die Logik ist verlässlich, denn sie findet komplett im Server statt\nVerschiebung bei Web 2.0:\n- Browser enthält Logik, verdient aber kein Vertrauen\n- Der View findet über das Toolkit im Client statt\n- Der Programmfluss wird von der Browser - Logik gesteuert\n- Der Server ist auf das Model, dh. die Businesslogik reduziert\n- Problem: Input-Validierung? Kann man den Angaben vom Controller trauen? \n\n
- Probleme bei RIA-Applikationen\n- Bei XSS ist die komplette Applikation gehijacked\n- Auch der Kommunikation mit dem Server ist nicht zu trauen\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- Mit XSS kann man mit JavaScript machen was man will. \n\n
- \n
- - Backend von BEEF\n- JavaScript-Snippet per XSS - oder direkt auf der Seite eingebunden\n- Jeder Nutzer taucht als Zombie in der Liste auf\n- Clipboard auslesen\n- Intranet Spidern\n- Intranet exploiten\n
- \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- Crossdomain erklären\nCrossdomain-Unfall bei Facebook \nJSON-Hijacking per { und (\nRootkit: dem JS manipulierte Daten liefern \nGoogle Wave und Facebook: real existierende Mashup-Welten\n
- Embedded Applications: \nFacebook Apps\nGoogle Wave Widgets\nJavaScript Widgets \n... \n
- Wichtig für Clickjacking: Iframes. \n
- FBJS: Virtueller Scope über einen Prefix vor jeden Funktionsnamen und jede Variable. \nDom-Methoden werden durch eigene Methoden ersetzt. \nsetInnerXHTML: eigener XSS-Cleaner (Beta - viel Glück!)\n\nADsafe: JavaScript-Verifier, der prüft, ob das JavaScript „Unsichere“ aktionen durchführt und etwa globale Objekte anfässt\n\n\n
- \n
- \n
- Google 2007\nCaja ist ein Transformer, mit einem Kommadozeilenaufruf\nCapabilities: Objekt + das Recht für die geplante Nutzung, und wer es benutzen darf\nOpenSocial setzt Caja ein\nBroken by design, aber besser als nichts. \n
- - wenn ich auf einen Button klicke, wo wird der Code ausgeführt?\n- wer sieht die Boundaries of Trust? \n
- \n
- Beispiel: XSS-Cleaner in FBJS\n
- 2 Probleme entstehen: \n- Ich kann meine Daten nur auf der ursprünglichen Plattform zurückziehen.\n- Der Nutzer gibt seine Daten nur für andere Nutzer frei - nicht für Spider.\n
- 2 Probleme entstehen: \n- Ich kann meine Daten nur auf der ursprünglichen Plattform zurückziehen.\n- Der Nutzer gibt seine Daten nur für andere Nutzer frei - nicht für Spider.\n
- 2 Probleme entstehen: \n- Ich kann meine Daten nur auf der ursprünglichen Plattform zurückziehen.\n- Der Nutzer gibt seine Daten nur für andere Nutzer frei - nicht für Spider.\n
- 2 Probleme entstehen: \n- Ich kann meine Daten nur auf der ursprünglichen Plattform zurückziehen.\n- Der Nutzer gibt seine Daten nur für andere Nutzer frei - nicht für Spider.\n
- \n
- \n
- \n
- \n
- \n
- \n
- geolocation.getCurrentPosition\nCamera.getPictureFromLibrary\nContacts.getAllContacts\nFile.deleteFile\nSettings.getVoiceMailNumber\n
- location-spoofing alle ausser IE8\n( und { lassen sich nicht mehr überschreiben\nOrigin/Access-Control-Header: \n- Header, der die Prüfung des Origins eines Requests erlaubt, werden vom Browser geschickt\n- der Server sendet, wer den Request abschicken durfte. \n\nContent Security Policy:\n- Header, der sagt, von welchen Domains JS-Code kommen kann\n- sämtlicher Inline-Code wird nicht mehr ausgeführt\n- nur noch JS-Files\n- seit dem 2.10.09 gibt es einen Preview für Firefox mit CSP\n\n
- postMessage erzwingt gezieltes Hören für Mitteilungen von einer \n
- \n
- \n