zurück zur Startseite
  


Zurück XHTMLforum > Webentwicklung (außer XHTML und CSS) > Javascript & Ajax
Seite neu laden Javascript und Sicherheit

Antwort
 
LinkBack Themen-Optionen Ansicht
  #1 (permalink)  
Alt 25.03.2007, 13:51
Erfahrener Benutzer
XHTMLforum-Mitglied
Thread-Ersteller
 
Registriert seit: 15.05.2006
Beiträge: 126
Kirsten befindet sich auf einem aufstrebenden Ast
Standard Javascript und Sicherheit

Ich werde für meinen kleinen Websitetext-Editor unter anderem Javascript einsetzen. Da das Ganze irgendwann auch von Kunden bedient werden soll, mache ich mir Gedanken, welche Fragen kommen könnten und auf welche Probleme ich aufmerksam machen muss respektive wo tatsächlich Risiken liegen und wo nicht. Da taucht natürlich auch unter anderem das Thema "Sicherheit vor Angriffen und Javascript" auf.

Im Netz wird viel erzählt, so eine richtig überzeugenden Darstellung hab ich nicht gefunden.
Ich muss noch dazusagen, dass ich selbst sehr gut schlafe, weil ich nicht mit Microsoft-Produkten surfe
Aber meine Kunden werden das sicher tun.

Mein Fazit bisher wäre:
Es gibt Trojaner/Dialer/ichweissnichtwas, die Javascript nutzen (öfter jedoch dieses MS Aktive X). Das heisst, wenn man beim IE Javascript immer eingeschaltet hat, geht man damit ein gewisses Risiko ein.
Aber wie hoch ist dieses Risiko zu bewerten?
Und: Wäre/ist Firefox da sicherer?

Ultima Ratio wäre natürlich, dass ich sage: "Liebe Leute, aktiviert bitte Javascript, wenn Ihr mit meinem Editor arbeiten wollt. Von meiner Webseite gehen keine finsteren Angriffe aus, also ist das vollkommen gefahrlos. Was Ihr sonst macht, soll mir wurscht sein."
Find ich aber ein wenig – sehr kurz gegriffen.

Wie wäre denn Euer Resumee?
Was würdet Ihr als den aktuellen Stand der Sicherheits-Diskussion sehen?
__________________
Schöne Grüße

von Kirsten
Mit Zitat antworten
Sponsored Links
  #2 (permalink)  
Alt 25.03.2007, 22:09
Benutzer
neuer user
 
Registriert seit: 11.04.2004
Beiträge: 61
molily wird schon bald berühmt werden
Standard

Tatsächlich ist JavaScript und alles was damit zusammenhängt mittlerweile einer der wichtiges Angriffsvektoren bei Browsern. Das gilt nicht nur für MSIE/ActiveX, auch wenn man sich die Mozilla-Advisories anschaut, wird klar, dass JavaScript dort für zahlreiche Sicherheitslücken »verantwortlich« ist. Firefox ist mittlerweile auch ein ziemlich dickes Stück Software und JavaScript kann da durch Schnittstellen und Zugriff auf Interna prinzipiell ähnlich sicherheitskritisches wie IE.

Je konsequenter zentrale Webanwendungen von JavaScript Gebrauch machen, desto kritischer werden solche Lücken. Aber weniger, weil deine Anwendung durch JavaScript-Gebrauch anfällig ist. Wichtig sollte sein, dass die Webanwendung gegen XSS- und CSRF-Angriffe geschützt ist. Diese können sich JavaScript ggf. zu Nutze machen, Gefahrenpotenzial besteht aber auch ohne. Außerdem, wenn es nur um einen Editor (designMode/contentEditable usw.?) geht, sollte JavaScript die Anwendung nicht unsicherer machen als sie ohne JavaScript ist.

Wenn deine Kunden nun Vorbehalte gegenüber JavaScript-Lösungen haben, so kann ich das bis zu einem gewissen Punkt nachvollziehen. Manche Firmen setzen da ziemlich harsche Proxies ein, die JavaScript filtern oder sonstwie verändern. Trotzdem gibt es aus Sicht der heutigen Browser keinen Grund, dass Admins JavaScript auf Clients komplett ausschalten. Ausgewählte Webanwendungen, zu denen ein solcher Editor zählen würde, kann man per Whitelist erlauben (IE hat so ein Zonenmodell standardmäßig; Firefox auch, nur standardmäßig ohne User-Interface, bedarf also des NoScript-Plugins).

Sicher, wenn der Kunde sagt »sowas kann/will ich nicht installieren«, bist du erst einmal aufgeschmissen. Aber es gibt doch keinen Ausweg: Einen vernünftigen webbasierten Editor bekommt man halt nur mit JavaScript dynamisch, ohne wären die meisten Features unmöglich bzw. ein Krampf. Alternative ist ein nicht-webbasiertes Programm, das irgendeine definierte Schnittstelle nutzt. Das zu programmieren und einzurichten wäre viel mehr Aufwand. Deshalb sind webbasierte Anwendungen mit JavaScript ja gerade so cool. Das sollte soweit auch dem Kunden klar sein.

Mathias
Mit Zitat antworten
Sponsored Links
  #3 (permalink)  
Alt 26.03.2007, 11:13
Erfahrener Benutzer
XHTMLforum-Mitglied
Thread-Ersteller
 
Registriert seit: 15.05.2006
Beiträge: 126
Kirsten befindet sich auf einem aufstrebenden Ast
Standard

Vielen Dank für die ausführliche, interessante Antwort!
Mein Fazit ist, dass ich wohl vermitteln muss, dass ein User für die eine, spezielle Funkionaliät auf meiner (ansonsten ungefährlichen) Website Javascript aktivieren muss. Das ist der kleinste gemeinsame Nenner. Das bringt den User (in dem Fall nur einzelne Kunden mit Password) nicht in Gefahr, weil ers ja anschließend wieder ausschalten kann (oder per whitelist managen kann) und ich muss mich nicht allzusehr verrenken, um auf jeden Fall Javascript zu vermeiden.
__________________
Schöne Grüße

von Kirsten
Mit Zitat antworten
Antwort

Themen-Optionen
Ansicht

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Erkennen ob JavaScript deaktiviert ist und anderen Inhalt anzeigen Ares Javascript & Ajax 7 02.02.2011 13:45
Wort in Javascript Code einfügen; dann Javascript Code ausgeben Sp33dy G0nz4l3s Javascript & Ajax 1 23.05.2008 10:37
Impressumsaufruf mit Javascript Sinclair Javascript & Ajax 6 19.05.2008 16:41
Barrierefreiheit und Textarea-Editor kratzbaum Barrierefreiheit 18 07.03.2007 19:37
Javascript, Datentabelle und Screenreader laborix Barrierefreiheit 8 02.04.2006 19:25


Alle Zeitangaben in WEZ +2. Es ist jetzt 23:36 Uhr.