Neue Risiken durch HTML5

Ganz so wild sehen ich das ganze nicht.
Sicherlich, es gibt mehr Möglichkeiten für Angreifer eine gehackte Seite zu manipulieren, aber das Hacken der Seite selbst ist ja durch HTML5 nicht einfacher geworden.
Solange Serverseitig alles richtig gemacht wird, ist alles in Ordnung, erst danach wirds kritisch.

Schön zu lesen, dass HTML5 nicht schlimmer ist als ältere Doctypes. Gehackt wurde ja schon immer.
Gruß. Petra

Hallo alle miteinander,

neue Techniken bringen i.d.R. leider auch immer neue Gefahren. Sicherlich ist Hacking nichts neues und ein gut gesicherter Server ist schon mal die halbe Miete, aber das ist nicht alles.

Wenn das Erstellen einer Webseite einfacher und attraktiver wird (erstaunlich, was mit HML5 alles so geht) dann werden sich mehr dafür interessieren und ggf. auch eine eigene WebSeite erstellen. Aber wer von diesen neuen Web-Admins hat a) einen eigenen Server und b) kann diesen auch konfigurieren. Man kauft heute vieles aus der Box ohne (!) das man genau weiss was drin ist. Das ist einfach ein Risiko, welches sich potenzieren wird.

Oder um mal wieder lästig zu werden ... wer hat ein Monitoring seiner Webseite eingerichtet? Wer prüft mindestens einmal in der Woche, ob die eigene URL auf einer Blacklist steht? Wer macht einmal in der Woche einen Security-Check?

Die wenigsten

Und da ist das Problem, an Security denken die wenigsten - und dadurch wird es zum Problem für alle. Würde jeder ein wenig machen, wäre es für alle sicherer (NEIN, ich bin kein Missionar, ist nur meine Meinung ).

HTML5 wird Sicherheitsrisiken bringen, ggf. nicht durch HTML5 selbst, aber durch das, was damit in Bewegung gesetzt wird.

Beste grüße Ralph

PS: An alle die bis hier gelesen haben ... wie wäre es denn mal eben mit einem Check der eigenen Webseite. Schnell und einfach geht es z.B. mit sucuri.net und es ist auch GRAIS. Danke und viel Erfolg!

rdombach schrieb:

Oder um mal wieder lästig zu werden ... wer hat ein Monitoring seiner Webseite eingerichtet? Wer prüft mindestens einmal in der Woche, ob die eigene URL auf einer Blacklist steht? Wer macht einmal in der Woche einen Security-Check?

Die wenigsten

Und da ist das Problem, an Security denken die wenigsten - und dadurch wird es zum Problem für alle. Würde jeder ein wenig machen, wäre es für alle sicherer (NEIN, ich bin kein Missionar, ist nur meine Meinung ).

Hallo Ralph,

liegt vermutlich an der Denkweise - das passiert nur den Anderen, bis es einen dann doch erwischt.

Wer prüft mindestens einmal in der Woche, ob die eigene URL auf einer Blacklist steht?

Das wäre doch ein Punkt, den man bei der SR-Analyse unter "Sicherheit und Datenschutz"
mit abfragen könnte.
Aber wie ich Matthias kenne, steht das schon auf seiner ToDo - Liste.

Gruß
hansen

Hallo

Irgendwie finde ich das echt blöde. HTML5 als Risiko darstellen wenn es an Möglichkeiten durch Javascript liegt.

Und da zähle ich die ganzen Javascript Eventhandler halt eben dazu.

Und es wird wieder alles in den Begriff HTML5 geworfen obwohl es andere Techniken betrifft.

Gruß
Jörg

Hallo Jörg,

da hast Du nicht unrecht. Bei genauer Betrachtung ist das auch einer der realen Ursachen.

joerg schrieb:


Irgendwie finde ich das echt blöde. HTML5 als Risiko darstellen wenn es an Möglichkeiten durch Javascript liegt.

Allerdings leben wir in einer Welt, die sprachlich nicht immer korrekt ist. Beispielsweise sprechen wir ja auch von einem "Autounfall", obwohl mehrheitlich der Fahrer bzw. der Mensch den Fehler gemacht hat und nicht das Auto. Demnach sollte man eigentlich korrekterweise "Menschunfall" sagen - oder?

Aber ich weiss worauf Du hinaus willst und damit hast Du auch recht. Aber wie so oft, zitiert man lieber die Umstände als die eigentlichen Ursachen.


Beste Grüße
Ralph

Hallo Ralph

Also ich würde dann eher als Substantiv Unfall verwenden. Das da eine Zusammensetzung mit dem womit vorgenommen wird du ich habe keine Ahnung wie man sprachlich so ein Vorgehen bezeichnet.

Bei deinem Beispiel ist sollte aber jeder imstande sein zu wissen auf was du hinaus willst.

In diesem Fall ist es aber so. Reisserische Ãœberschrift nachdem Motto es wird alles durch HTML5 schlimmer. Dabei sehe ich jetzt aber wirklich keinen Punkt der durch HTML5 grössere Risiken birgt.

Hat halt eben dann eine andere Ursache. URL Manipulation oder nicht genügende Ãœberprüfung durch Formularfelder.

Beispielsweise dieses form Attribut. Erst mal muss ich dem Formular keine Id zuweisen, Wenn ich es dann aber doch tue kann ich immer noch viel prüfen ob ein Kommentareintrag zulässig ist.

Erstmal kann ich alle Elemente mit Attributangaben ablehnen. Dann ist das Thema Eventhandler dicht. Zum anderen würde ich wenn ich schon HTML Elemente erlaube immer eine Positivliste zur Ãœberprüfung einsetzen und keine Negativliste und sowas kann man auch theorethisch für Attribute einführen.

Bei dem Artikel wird meiner Ansicht nach nicht genügend herrausgestellt das andere Ursachen im Grunde das Risiko darstellen.

Auch werden keine Lösungswege vorgeschlagen.

Im Grunde ist das für meiner Ansicht nach ein sehr ungenügender Artikel.

Ich weiss wie lang alleine ein Abschnitt über vernünftige Ãœberprüfung eines Formulares werden kann.

Wer sich an der Stelle aber allein auf Javascript oder auch auf die Ãœberprüfung der neuen Input Typen unter HTML5 verlässt ist es selbst schuld.

Was die URL Manipulation anbetrifft kann man vieles bereits über die htaccess oder PHP steuern. Aber da sind wir an dem Punkt angelangt das der Punkt Sicherheit allgemein zu nachlässig behandelt wird.

Wenn gewisse Zeichen in einer URL verwendet werden kann man solche Abfragen auch entschärfen indem man auf eine Seite umleitet. In der Regel betrifft es ja auch nur den Query String.

Man kann aber auch anders vorgehen. Welche Parameter sind überhaupt erlaubt. Sind weitere Parameter gesetzt dann auf keinen Fall was machen.

Das ganze Javascript Thema betrifft aber auch nicht nur HTML, XHTML sondern halt eben auch andere Formate wie SVG, XSLT wo man auch in der Lage ist Javascript einzusetzen. Im Grundsatz also mehr oder weniger alle XML Formen.

Bei reinen statischen Dateien sollte das dann abhelfen.

[html]
RewriteCond %{REQUEST_URI} \\.(xml|xsl|svg)$
RewriteCond %{QUERY_STRING} !^$
RewriteRule (.*) /$1? [L,R=301][/html]

Was ich immer innerlich verfluche ist es wenn jemand ein Thema behandelt aber das entweder nicht praktisch dann auch auf der Seite einsetzt oder auch nur ein Problem zwar darstellt aber im Grunde dann auch keinen einzigen Lösungsansatz bietet als zusätzlichen Mehrwert.

Du ich habe gestern mir die data Attribute in HTML5 angeschaut. Eine ausgezeichnete Möglichkeit valide an gewissen Stellen zu werden wo man mit Javascript gewisse Parameter benötigt.

Ich habe länger als du bereits HTML5 beziehungsweise in meinem Fall XHTML5 für gescheite Browser im Einsatz. Die ganzen Möglichkeiten sind meiner Ansicht nach ein Mehrwert den man nicht mehr missen möchte.

Und solche Artikel schrecken nur unnötig ab weil zu jeder Zeit solche Möglichkeiten existiert haben. Die Frage ist immer inwieweit man Lücken in Hinsicht Sicherheit schliesst. Du ich bin mir persönlich auch nicht sicher wo unter Umständen weitere Lücken bei mir existieren. Nur wenn ich was entdecke dann schliesse ich diese Stellen und das ist bei mir Priorität Eins.

Sorry der ganze Mist kann nur geschehen wenn man dem Aspekt Sicherheit nicht genügend Vorrang vor anderen Dingen einräumt. Und das ist meiner Ansicht nach das Grundproblem neben unter Umständen mangelnder Information.

Gruß
Jörg

Hallo Zusammen,

HTML an sich ist Daten-Dumm. Es zeigt nur an, egal in welcher HTML-Version.
Sobald die Seite an den Client-Rechner/Browser ausgeliefert ist hat man als Admin keinen Einfluss mehr auf die Seite. Nützliche Webwerkzeuge wie der Firebug eignen sich hervorragend für die "Nachbearbeitung" der Seite auf dem Client :lol:.

Explizit müssen aber die neuen Attribute per SERVER-Script entwertet werden.
Der Rest sollte an sich schon für die HTML-Vorgänger erledigt worden sein.