ALSO NOCHMAL

[Johannes Zeller]

Hallo,

es mag sein, dass du mir jetzt vorwerfen wirst, dass ich dein Problem nicht verstehe. Dem ist nicht so, ich verstehe sehr gut, was du meinst - aber dein Hauptproblem liegt darin, dass du einen konzeptionellen Fehler hast, weil du versucht mit Web-Formularen wie bei einer "normalen" Anwendungssoftware zu arbeiten.

die Tatsache, dass die Formulare aus 1000 Feldern und mehr bestehen können ist kein Designfehler.

Es ist eine Software, keine poppelige Homepage.

Im Grunde macht es keinen wirklichen Unterschied, der Aufbau und die Anforderungen sind die gleichen. Lediglich die Komplexität ist bei dir anscheinend höher als bei den meisten Projekten.

On-the-fly Quelltextänderung - sehr brisant wenn ihr mich fragt. Es ist, da das System einen Login verlangt nicht "einfach" möglich das System von außen mit Schrott zu füttern.
Mit der Quelltext-Änderung im Browser via FireBug (u.ä.) ist das leicht möglich - und nach wie vor bin ich mir nicht im klaren wie ich mich dagegen vernünftig/effizient schützen kann.

Doch, ist es. FireBug oder ähnliche Tools tun nichts, was der Benutzer nicht auch von Hand könnte. Um das zu Verstehen hilft es, sich den Vorgang der Formularverarbeitung einmal genauer anzusehen.

Dein Script, dass die Daten verarbeitet, erhält vom Client diese Daten geschickt. Es gibt dabei keine Möglichkeit, zu erkennen ob der Besucher die Daten von Hand eingetippt oder die Daten vom Browser oder von einem anderen Programm kommen, da alle Indikatoren beliebig gefälscht werden können.

Du musst also in deinem Script die Benutzereingabe auf jeden Fall überprüfen.

Dein Formular dient eigentlich nur dazu, dem Client zu sagen welche Daten und in welcher Form und an welches Script er sie schicken soll. Um es dem Benutzer bequemer zu machen, erzeugen normale Browser aus dem Formular eine Eingabemaske, die es dem Benutzer erlauben, die Daten einzugeben ohne sich um die technischen Details zu kümmern. Ob das auf der Client-Seite tatsächlich so oder komplett anders abläuft hat den Server nicht zu interessieren, er kann es, wie gesagt, auch nicht überprüfen. Deswegen hat ein Konzept, das derartige Informationen benötigt, prinzipielle Schwachstellen und sollte noch einmal überarbeitet werden.

Die Personenverwaltung, Ändern von Personendaten:

• In der DB sind 3 Angestellte, A, B und C, mit Pers_ID 1, 2, 3.
• User öffnet Person B (Pers_ID = 2)
• User "hacked" HTML Code und setzt Pers_ID (hidden-field) von 2 auf 3
• submit -> falscher Datensatz wird geändert
  Lösung: Vergleich von geladenem und empfangenem Datensatz - ja, kein Problem bei einem STATISCHEN hidden-field, und einem Datensatz.

Was aber wenn's mehrere hidden-fields sind, mehrere Datensätze und evtl. diese hidden-fields durch User-Interaktion VALIDE geändert werden. Dann reicht auch ein primitiver servereitiger Check nicht mehr - dann ist's keine Fleißarbeit mehr.

Wie gesagt, das Prinzip ist gleich wie bei einem hidden-Feld, lediglich die Komplexität ändert sich. Normalerweise löst man dieses Beispielproblem allerdings, indem man überprüft ob der Besucher berechtigt ist, Datensatz 2 zu bearbeiten. Falls dies der Fall ist: kein Problem (ein Besucher, der das Formular manipuliert sollte wissen, was zu tun ist. Der Server muss nur darauf achten, dass der Besucher nichts anstellen kann, wozu er nicht berechtigt ist.) Falls der Besucher keine Berechtigung hat, gibt's stattdessen eine Fehlermeldung.

Was würdet ihr sagen, wenn man in eurem Betriebssystem einfach mal rechts-klicket auf einen gesperrten Button, und schwupps ist er klickbar.

Wie bereits weiter oben gesagt, Web-Formulare müssen programmiertechnisch anders behandelt werden als die GUIs bei lokalen Programmen (die sich übrigens auch manipulieren lassen, wenn auch nur mit deutlich höherem Aufwand.)

Ich bleib dabei, das ist eine maßive Schwachstelle von HTML, das der USER das Programmverhalten beeinträchtigen kann.

Das liegt daran, dass HTML ursprünglich nicht für Programme konzipiert wurde. Das Problem tritt aber in allen Fällen der Server-Client-Kommunikation auf, da der Server nicht überprüfen kann, wie genau ein Request auf der Client-Seite zustande gekommen ist.

Das bedeutet jedenfalls einen ERHEBLICHEN Mehraufwand beim Erstellen von Web-Applikationen, und ich glaube nicht dass das jeder Hersteller berücksichtigt hat.

Das mag sein. Dadurch öffnet er aber in seiner Anwendung erhebliche Sicherheitslücken. Diese Vorgehensweise ist also nicht zur Nachahmung zu empfehlen,

Johannes