nicht angemeldet
Spamprüfung im Admin-Bereich - sinnvoll/Unsinn?
Hi!
Ich hoffe, ich blamiere mich jetzt nicht bei euch mit meiner Frage, aber ich überlege gerade, ob es sinnvoll ist, Formularen im Admin-Bereich des CMS einer Homepage eine Spamprüfung hinzuzufügen.
Ich denke da z.B. an hidden-fields mit einem timestamp, an Eingabefelder ausserhalb des Viewports u.ä. bekannte Techniken.
Dagegen spricht ganz klar, dass eh schon alles zu spät ist, wenn ein Angreifer Zugang zum Admin-Bereich des CMS einer HP hat.
Wie ist da eure Meinung? Wie geht man damit "normalerweise" um?
Chriz
-
Dagegen spricht ganz klar, dass eh schon alles zu spät ist, wenn ein Angreifer Zugang zum Admin-Bereich des CMS einer HP hat.
Ja.
Wie ist da eure Meinung? Wie geht man damit "normalerweise" um?
Man sichert Eingabemasken im Backend gegen versehentliche Manipuliation (mehrfaches absenden desselben Formulars) - eine Reloadsperre reicht aus.
Und natürlich sollten Manipulation am Code nicht entsprechende Rechte umgehen. z.B. dass sich ein Redakteur selbst URLs zum Löschen beliebiger Datensätze basteln kann.
Aber ein Spamschutz bzw. ein Turing-Test ist nicht notwendig.
-
Und natürlich sollten Manipulation am Code nicht entsprechende Rechte umgehen. z.B. dass sich ein Redakteur selbst URLs zum Löschen beliebiger Datensätze basteln kann.
Das kann man im einfachsten Fall durch eine Übertragung per post sicherstellen. Was gibt es sonst noch dabei beachten?
Chriz
-
Und natürlich sollten Manipulation am Code nicht entsprechende Rechte umgehen. z.B. dass sich ein Redakteur selbst URLs zum Löschen beliebiger Datensätze basteln kann.
Das kann man im einfachsten Fall durch eine Übertragung per post sicherstellen.
Und du glaubst auch noch an den Osterhasen?
Was gibt es sonst noch dabei beachten?
Dass du dich ggf. vorher etwas mit der Materie auseinandersetzen solltest, bevor du ein Backend entwickelst.
Wenn du der Meinung bist, dass ein man einen POST-Request nicht manipulieren kann, ist es mit der Sicherheit wohl allgemein nicht weit her.
-
Wenn du der Meinung bist, dass ein man einen POST-Request nicht manipulieren kann, ist es mit der Sicherheit wohl allgemein nicht weit her.
Nein, der Meinung bin ich nicht.
Bei Nutzern mit mehr als 2 Level (z.B. Admin und User) ist z.B. natürlich noch eine Prüfung der Nutzerrechte erforderlich.Mein Frage war eher in die Richtung, ob/welche zusätzlichen Überprüfungen, ausser z.B. nach post und dem Nutzer-Level, noch sinnvoll wären.
Chriz
-
Mein Frage war eher in die Richtung, ob/welche zusätzlichen Überprüfungen, ausser z.B. nach post und dem Nutzer-Level, noch sinnvoll wären.
Alle. Denn alle Daten gehören zu einem bestimmten Datentyp und müssen somit der Syntax dieses Datentyps entsprechen.
Es steht dir ja frei für den Datentyp Month ein Wort 'Superbla' zu akzeptieren. Damit verlagerst du aber dann nur die Problembehandlung.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische -
Wenn du der Meinung bist, dass ein man einen POST-Request nicht manipulieren kann, ist es mit der Sicherheit wohl allgemein nicht weit her.
Nein, der Meinung bin ich nicht.
Bei Nutzern mit mehr als 2 Level (z.B. Admin und User) ist z.B. natürlich noch eine Prüfung der Nutzerrechte erforderlich.Ich denke, Du weißt nicht, worauf die Vorredner abzielten.
Es geht nicht nur um das Userlevel, sondern viel mehr darum, dass sämtliche mögliche Lücken hinreichend geschlossen sind. Hierfür muss man "nur" entsprechend kreativ sein.
Ein Beispiel:
Deine User dürfen sich Nachrichten zusenden. Diese dürfen auch gelöscht werden. Dann musst Du zwingend im Backend nochmals prüfen, ob dieser User genau diese Nachricht auch wirklich löschen darf oder ob z.b. das eine Nachricht eines anderen Users ist. Eine Frontendprüfung reicht nicht aus, sonst bastelt der User sich da Dinge über eigene Frontends zusammen, die Dein System stürzen können/werden.
Weiteres Stichwort ist die erkennung von Kontextwechseln.
Im Grunde läufts darauf hinaus, dass man seinem eigenen Frontend nicht trauen darf. Es kann Dir und Deinen Usern helfen, aber das Backend macht die Arbeit. Vor allem die Sicherheitstechnische.
Gruss, Steffen
-
-
-
Hi,
Und natürlich sollten Manipulation am Code nicht entsprechende Rechte umgehen. z.B. dass sich ein Redakteur selbst URLs zum Löschen beliebiger Datensätze basteln kann.
Das kann man im einfachsten Fall durch eine Übertragung per post sicherstellen. Was gibt es sonst noch dabei beachten?
Dass du mit der Behauptung bzgl. POST kolossal falsch liegst.
Per POST kann ich dir alles schicken, was du dir nur vorstellen kannst - und vermutlich noch mehr.
Ich kann bspw. mittels Firebug das Formular manipulieren, wie es mir gefällt. Und vielleicht nutze ich nicht mal einen „Browser“, um einen Request an dein Script zu senden.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
-
-
-
Wie ist da eure Meinung? Wie geht man damit "normalerweise" um?
Eingabeprüfungen sind notwendig, damit ein User nichts falsches machen kann.
Dabei geht es aber nicht um Spam, sondern schlicht darum, unfreiwillige Fehler bei Eingaben in einer API abzufangen.Vor allem sollte man Webformulare lediglich als GUI zu einer weitaus wichtigeren API verstehen. Es gibt keinen Grund zur Annahme, dass eine API immer durch diese GUI genutzt werden soll/muss.
Sollte wohl klar sein.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische -
ob es sinnvoll ist, Formularen im Admin-Bereich des CMS einer Homepage eine Spamprüfung hinzuzufügen.
Dagegen spricht ganz klar, dass eh schon alles zu spät ist, wenn ein Angreifer Zugang zum Admin-Bereich des CMS einer HP hat.
Richtig. Mehr gibt's dazu eigentlich nicht zu sagen.
(Dass deine Software keine Sicherheitslücken haben sollte, auch im zugangsgeschützten Bereich, wie die anderen meinen, anmerken zu müssen, versteht sich von selbst. Spam gehört aber per se nicht in den Bereich Sicherheitslücke, sondern ist über vorhandene Kanäle eingereichter Inhalt.)