Aloha ;)
Nein. Aber: Ich prüfe meine eigene Seite (und selbstverständlich die Einbindung) regelmäßig. Ich vertraue dem Betreiber der Seite, die ich einbinde, aus Gründen (zum Beispiel, weil er selbst einen Ruf zu verlieren hat, oder, weil ich ihn kenne, oder, weil ich andere Gründe dafür habe, ihm zu vertrauen, dass er aktiv auf seiner Seite keinen Schadcode verbreitet).
Ach und wie kommst du auf die Idee, dass jemand "aktiv" Schadcode verbreiten muss, damit Schadcode verbreitet wird?
Naja, davon gehe ich nicht per se aus. Aber es sind nunmal zwei Fälle, von denen einer gravierender ist als der andere, und der gravierendere liegt nicht vor. Mein gesamtes Posting plädiert dafür, dass es eben keine vollständige Sicherheit gibt, sondern dass immer ein Restrisiko bleibt, das einzuschränken, aber nicht notwendigerweise auszumerzen ist.
http genügt.
Ich will dir nicht per se widersprechen, weil ich nicht davon ausgehe, die Weisheit mit Löffeln gefressen zu haben - aber das musst du mir näher erläutern. HTTPS ist im Prinzip ja nur eine verschlüsselte HTTP-Verbindung. Die einzige Art und Weise, wie man da jetzt an Schadcode kommen könnte, (die mir einfällt), wäre ein Man-in-the-Middle-Angriff.
Nur, dass HTTPS da auch nicht immer schützt.
Man kann das Vertrauen aber auch überstrapazieren. Und dieser Fall ist hier gegeben, wo eine iframe-Lösung abgelöst werden soll (wenn es nach den Meinungen der Ratgeber gehen soll) durch etwas, das noch mehr Vertrauen beansprucht.
Nein. Du hast das originale Posting offensichtlich nicht ansatzweise gut genug gelesen! Ich zitiere daraus:
Da die Mutterseite eine .js Datei von mir lädt, lässt sich vielleicht was machen?
Die Einbindung von JavaScript in die Seite bestand also sowieso schon, das war nichts, was von uns ins Spiel gebracht wurde.
Genausowenig soll die iframe-Lösung abgelöst werden (als Fallback soll sie nach unserer Meinung vorhanden bleiben), sondern sie soll für die, die kein JS aktivieren wollen, vorhanden bleiben. Es macht also niemand bestehende Funktionalität kaputt.
Schon mal von PGP (Pretty Good Privacy) gehört? Auch das basiert auf einem Konzept von Vertrauen und ist eine effektive Methode zur Zertifizierung ohne Certificate Authority.
Das ist ein gutes Beispiel für geringstes Misstrauen, nicht für Vertrauen.
Nein. Das ist ein Beispiel für Vertrauen. PGP basiert auf der Idee des Web of Trust. Dabei geht es im wesentlichen darum, dass Vertrauen in Zertifikate bekannter (und selbst vertrauter) Kommunikationsteilnehmern an unbekannte Kommunikationsteilnehmer vererbt wird, und das ist ziemlich genau das, was hier auch passiert.
Aber ich möchte mal auf einer ähnlichen Ebene diskutieren.
Ich verwende derzeit auf meiner Site google fonts. Kein Problem, wenn die nicht geladen werden, da eine Ersatzglyphe auf jeden Fall existiert.
Aber denoch, im Grunde vertraue ich darauf dass die Fonts nicht kompromitiert sind.
Es gab in der Vergangenheit mehr als einen Fall wo Webfonts mehr Rechte beansprucht haben, als vorgesehen waren.
Soll ich mich nun zurücklehnen und sagen: Ach google hat so einen Ruf zu verlieren…
Google chrome hat auch für eine Weile ungefragt über das Mikrophon gelauscht.
Die Sache ist, es stört mich und ich bin hin und her gerissen.
Das kann ich nachvollziehen, aber…
Ich sehe mich bereits dabei, einen font zu clonen, die Interna zu prüfen und ihn dann selber zu hosten.
…das ist eine Schlussfolgerung, die im Internet und insgesamt in der IT heutzutage nicht mehr funktioniert. Damit bleibt man vielleicht (an dieser Front!) unangreifbar, kann sich dann aber doch irgendwann im Garten vergraben, weil man so nicht in der Lage ist, mit Bedürfnissen und Möglichkeiten, sowohl von Kunden (allgemeiner: Benutzern) als auch von Konkurrenten, mitzuhalten.
Vertrauen ist einfach nur ein schlechtes Argument.
Nein, ist es nicht. Man darf Vertrauen nur nicht mit Sicherheit verwechseln. Aber jeder, der sich auch nur ein bisschen damit auskennt, weiß, dass absolute Sicherheit in IT-Systemen gar kein Maßstab sein kann. Fakt ist, dass sich Sicherheit immer nach den Anforderungen richten muss. Das bedeutet aber auch, dass man als Webseitenbetreiber ein gewisses, auf Vertrauen beruhendes Rechtrisiko in Kauf nehmen darf, ja regelrecht muss.
Die Wirklichkeit ist nämlich eine ganz andere. Wir sehe heute das Vorantreiben von Security-Guidelines, allen voran, https als default aber keineswegs dort endend.
https als default ist nicht so sehr eine Frage der Sicherheit allgemein als vielmehr der Datensicherheit im Speziellen. Die Sicherheit gegenüber Schadcode muss an ganz anderer Stelle gewährleistet werden: Nicht da, wo der potenzielle Schadcode ins Web gelangt, sondern da, wo der Schadcode aus dem Browser ausbricht. Und in diesem Bereich wird wirklich sicherheitsrelevanter Fortschritt gemacht. Stichwort Sandboxing von Flash, Sandboxing von JavaScript, usw. usf…
Und damit können wir die Frage angehen:
Unter welchen Umständen wäre ich bereit, remso in meine Website einzubinden? Denn wenn ich jemandem Rat erteile, dann soll das ja mein eigenes Bewusstsein richtig wiedergeben und fair sein.
- Der Inhalt ist als iframe einzubinden (Trennung von Document-Structur)
- Der zu ladende Inhalt muss via https ausgeliefert werden und muss sich auf eine domain beschränken.
- optional darf die Ressource mit einem Parameter aufgerufen werden, der zur Folge hat, dass das CSS des iframes farblich und anderweitig zu meinem eigenen Site-Theme passt.
- natürlich auch Datenbank-relevante Parameter.
- Der Inhalt darf nicht über eine Funktionalität verfügen, die Abfragen darstellt, für die ich nicht gerade stehe (Abfragen zu Events, die ich nicht befürworte).
Das security-plus hier möchte ich gar nicht abstreiten…
Aber eventuell würde ich auch einen server-server Datenaustausch vorziehen, indem mein Server selber eine API auf remso.de benutzt, und das Resultat selber cacht. Für den Client wäre ich da selber verantwortlich, und könnte somit selbstverantwortlich bezüglich der Datenintegrität vorgehen.
…ebensowenig hier.
Aber mit beidem gibst du jeweils auch Dinge auf, vorrangig: Komfort, auch in der User Experience (sogar gar nicht so wenig), und das dürfte den meisten Webentwicklern dieses security-plus begründeterweise nicht wert sein.
Es ist genausowenig umsichtig, sich überhaupt nicht um security zu kümmern, wie security über alles Andere zu stellen. Und selbst wenn du das für dich so halten möchtest: anderen ohne driftige Gründe dasselbe raten oder sogar Leute, die das anders sehen, anzugreifen ist sicher nicht gerechtfertigt (und im Rahmen dieses Forums auch nicht erwünscht!).
Grüße,
RIDER
--
Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Zoller
#
Twitter #
Steam #
YouTube #
Self-Wiki #
Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
nicht angemeldet
Matthias Apsel
TS
MudGuard
JürgenB
Camping_RIDER
Julius