35 Zeichen html frei - Sicherheitsrisiko?

[Tachyoon]

Hallo.

In einer Web-Applikation können Leute von extern Daten eingeben; unter anderem in Texteingabefelder. Diese Daten schauen sich intern Sachbearbeiter an.

Problem: In den Texteingabefeldern können auch html-Befehle eingegeben werden. Sie verhalten sich dann bei der Anzeige der Daten, als ob man sie sich auf einer Website anschauen würde (tut man ja eigentlich auch).

Frage: Wie viel Schaden kann durch maximal 35 Zeichen html-Code verursacht werden?

Info:

Ich hab versucht einen <a href> Link einzubauen. Das geht im Prinzip schon, aber in der dann im Formular angezeigten Adresse wird unser Firmen-Intranetserver vorrangestellt. ( Link= www.gmx.de ; Aufgerufen = https:meinServer:meinPort/"http://www.gmx.de" ) -> Link geht nicht (so einfach).

Ob ich das ins Webdesign posten sollte? :confused:

Vielen Dank für eure Antworten.

[ThrawnMDK]

Würd kein Risiko eingehen...

Versuch doch, die Zeichen zu escapen oder einfach nur eine bestimmte Menge von Zeichen zuzulassen von denen Du weißt dass sie harmlos sind (A-Z, a-z, 0-9, " ", ".", ","). Eventuell reicht auch wenn man < und > rausfiltert aber dann besteht die Gefahr dass da irgendwas anderes drin ist was Du nicht bedacht hast.

Thrawn

Edit: Bei PHP gibts z.B. auch fertige funktionen die das escapen übernehmen. escape_html() glaub ich.

[Wolle]

Original geschrieben von Tachyoon

Ob ich das ins Webdesign posten sollte?

Wuerde da besser passen, ich schiebs mal rueber

[Spike]

Mit JavaScript kann man das nicht lösen, "böse User" könnten das ausschalten.

Die beste Möglichkeit ist (wenn du es nicht schon nutzt) eine Serverseitige Sprache wie PHP oder ASP, dort kann man HTML-Tags rausfiltern.

Oder sind die gewünscht?

Dann filter einfach evtl schädliche raus die ihr nicht braucht (alle mit Objekt etc).

[Tachyoon]

Herausfiltern gerne...

aber das ist natürlich auch ein gewisser Aufwand, weshalb ich ja wissen will, ob diese 35 Zeichen die man eingeben kann, bereits ein Risiko darstellen oder ob man für schädliche Scripte einfach mehr braucht.

Edit:

Die Eingabe-Seite ist in JavaScript, der Server und die weitere Verarbeitung gehen mit ASP.

Edit2:

Au verdammt... vergesst das mit den 35 Zeichen. Ist ja Javascript... das kann sich jeder Angreifer selbst definieren, wie viele Zeichen er dort reingibt. Ich werde wohl eine serverseitige Prüfung vorschlagen müssen...

[Spike]

Wenn du Inputfelder nimmst kannst du die max 35 Zeichen per HTML definieren

Ich wüsste nicht was man mit 35 Zeichen anrichten könnte, aber bin auch nicht der Profihacker

Mit PHP z.B. ist das kein Aufwand, dazu gibt es Funktionen.

Was es vergleichbares in ASP gibt, weiss ich leider nicht ...

[Tachyoon]

Original geschrieben von Spike

Wenn du Inputfelder nimmst kannst du die max 35 Zeichen per HTML definieren

Ich wüsste nicht was man mit 35 Zeichen anrichten könnte, aber bin auch nicht der Profihacker

Ein Angreifer speichert sich die JavaScript Seite lokal, ändert die Übergabe-URL, so dass es auch von seiner lokalen Festplatte aus geht und ändert die Länge von 35 Zeichen auf das Maximum.

Daher: Die 35-Zeichen Begrenzung ist eher wirkungslos.

[Spike]

Darum ja kein JavaScript

Eine Serverseitige Sprache könnte sichergehen das die Variablen nicht "böse" sind und die Länge nachträglich nochmal auf 35 Zeichen überprüfen.

[jomama]

Mal ne ganz doofe Frage: Was soll den HTML bitte ausrichten können?(bzw. JavaScript) beide können nicht im geringsten was mit irgendwelchen Serverdaten anstellen, da sie Clientseitig arbeiten. Ergo sind die Daten sicher, egal was der USER dort eingibt. Das einzige, was passieren kann, ist, das dein Design danach nicht mehr stimmt. Die Links, die da eingetragen werden können, sind doch eh durch Disclaimer geschützt.

[Tachyoon]

So, es wurde entschieden, dass wir serverseitig die < und > herauslöschen, falls die in solchen Feldern drinne stehen sollten.

Nein, es ging auch primär nicht um den Server, sondern darum, dass eher wenig PC-erfahrene Nutzer diese Daten angezeigt kriegen und bei einer Fehleinstellung ihres Browsers (zu lasche Sicherheit) dadurch Daten auf ihrer Festplatte gelöscht werden könnten. Und weil da z.T. Kundendaten drauf sind, die nicht immer täglich gesichert werden (können), könnte das ärgerlich sein und für den Besitzer des Client ggf. zu einigen 1000 Euro Schaden führen.

[Jaraz]

Original geschrieben von jomama

Mal ne ganz doofe Frage: Was soll den HTML bitte ausrichten können?(bzw. JavaScript) beide können nicht im geringsten was mit irgendwelchen Serverdaten anstellen, da sie Clientseitig arbeiten. Ergo sind die Daten sicher, egal was der USER dort eingibt. Das einzige, was passieren kann, ist, das dein Design danach nicht mehr stimmt. Die Links, die da eingetragen werden können, sind doch eh durch Disclaimer geschützt.

Stichwort: SQL Injection

http://www.google.com/search?q=sql+injection&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

Alle Daten mit denen auf dem Server was gemacht wird, müssen überprüft werden.

Aktuelles Beispiel, was passieren kann wenn man Daten einfach nicht prüft oder mit globalen Variablen arbeitet die von extern überschrieben werden können.

http://www.heise.de/newsticker/result.xhtml?url=/newsticker/data/dab-23.06.03-000/default.shtml&words=phpBB

Gruß Jaraz

[jomama]

Das geht auch nur, wenn die Abfrage direkt über Globale Variablen ausgeführt wird und man noch dazu ein unsicheres Passwort benutzt. Und das wird man ja wohl doch nicht tun.

[Jaraz]

Original geschrieben von jomama

Das geht auch nur, wenn die Abfrage direkt über Globale Variablen ausgeführt wird und man noch dazu ein unsicheres Passwort benutzt. Und das wird man ja wohl doch nicht tun.

Das ist ja nur ein Beispiel, außerdem wird hier das gehashte Passwort ausgelesen, das kann also so sicher wie nur irgendwas sein, es hilft dir trotzdem nicht.

SQL Injection ist generell mit jeder Variable die in die Datenbank geschrieben wird möglich. Egal ob global oder nicht.

Welcher Schaden damit angerichtet werden kann, hängt aber von der dahinter liegenen Datenbank ab. Mysql ist aufgrund seines beschränkten Funktionsumfangs noch relativ sicher.

Wenn subselects oder Systembefehlaufrufe mit der Datenbank möglich sind, wird es aber schon spaßiger.

Benutzeingaben müssen IMMER geprüft werden.

[Jaraz]

Original geschrieben von Jaraz

Das ist ja nur ein Beispiel, außerdem wird hier das gehashte Passwort ausgelesen, das kann also so sicher wie nur irgendwas sein, es hilft dir trotzdem nicht.

Nachtrag:

Sicher steigt der Aufwand und die Dauer einer Brute Force Attacke auf das Passwort, wenn das mehr Zeichen enthält und länger ist aber Offline sind mit heutiger Hardware mehrere Tausend Versuche pro Sekunde möglich, es dauert also nur etwas länger.

Gruß Jaraz