Ankündigung

Einklappen
Keine Ankündigung bisher.

POST-Injection im Formular des Gaestebuchs

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • POST-Injection im Formular des Gaestebuchs

    Ich hab ein kleines Sicherheitsproblem mit meinem Formular, ich hab fuer mein Gaestebuch ein Formular, das per POST arbeitet, dieselbe Datei verarbeitet das Formular dann auch.
    Da es jetzt dazu kam, dass jemand tausende sinnloser Nachrichten gepostet hat, moecht ich so eine "POST-Injection" verhindern und irgendwie verhindern, dass eine andere Datei die Daten an die verarbeitende Datei schickt.
    Ich waere froh, wenn es eine solche Moeglichkeit gaebe, aber ich komm nicht selber auf eine.

    MfG Marc und Danke im Vorraus

  • #2
    Du kannst für jede IP den jeweils letzten Zeitpunkt eines Beitrages speichern.
    Am einfachsten in einer Datenbank, u.a. weil Du dort alte Einträge leicht wieder entfernen kannst.
    Dann vor dem Eintragen eines neuen Beitrages jeweils testen, ob die IP "lange genug gewartet hat". Zum Beispiel eine Minute oder auch fünf - wer muss sich in einem normalen Gästebuch häufiger verewigen? Die 20köpfige WG hat dann halt Pech gehabt.
    Wasserdicht ist das natürlich nicht. Erneut beim Provider einwählen=>neue IP und schon geht's weiter. Oder über anonymizer, die jeden request über eine andere IP weiterleiten; war da nicht mal was bei aol? Keine Ahnung mehr.
    Jedenfalls nicht wasserdicht.
    Wird's wohl auch ohne Anmeldezwang nicht werden können.

    Kommentar


    • #3
      Dazu hab ich auch noch einmal eine Frage. POST Injection ist ja nicht immer ganz uninteressant, und kann durchaus nerven. Vorallem Woltlab-Produkte (Gästebuch, Foren) werden gerne mal mit selbergebastelten Bots und Post-Requests vollgespammt. IP-Sperre hilft vielleicht, aber wie du schon gesagt hast gibt es auch dagegene eine recht einfache Lösung (IP-Wechsel).
      Eine andere Idee von mir war mal, mit Cookies zu arbeiten - sprich der User bekommt einen Cookie angepappt, und nur mit diesem kann er dann ins Gästebuch schreiben. Allerdigns gibt es ja auch User, die keine Cookies zulassen - darunter gehört wohl auch so ein Bot (oder irre ich mich?) - also wäre diese Möglichkeit nicht sehr benutzerfreundlich.

      Eine andere Frage - wie wäre es mit einem dynamischen Namen für den Submitbutton? Soll heißen in der quasi aktuellen Session (oder DB) wird ein zufallsgenerierter, nicht zu langer String als submitbutton verwendet:
      PHP-Code:
      <?php
      echo '<input type="submit" name="' $hash '" value="Absenden" />';
      ?>
      Dies müsste man in der submit.php eben noch abfragen..?

      Mit dem referer zu arbeiten bringt so oder so nicht viel, den geben manche Browser sowieso nicht mit.
      Gibt es für die Frage eine Lösung oder wird der Anmeldezwang die einzige sein

      Kommentar


      • #4
        Der dynamische Name ist sicher eine sehr gute Idee. Aber dann holt der bot die Seite tatsächlich ab und besorgt sich so einen gültigen Namen
        Das sind alles "nur" Stolpersteine, aber eben keine echte Sicherheit.

        Kommentar


        • #5
          Danke, für den Tipp, Ip-Sperre hatte ich eigentlich schon drin, daher dacht ich, dass es so nicht funktioniert, aber ich hab nen riesen Anfängerfehler gemacht und damit meine IP-Sperre direkt wieder ausgehebelt, indem ich die IP im Formular versteckt weitergeschickt hab, anstatt die erst direkt vor dem Eintragen in die Datenbank festzustellen *Gg*
          Aber jetzt tut es

          Kommentar


          • #6
            aber man könnte doch in den cookie die zeit rein machen und nur den zugang gewähren, wenn man den wieder auslesen kann. wenn kein cookie mehr da is, kommt er nicht ins gäste buch..
            Homepage: http://www.rbs-page.de

            Kommentar


            • #7
              Oder sowas: http://www.phpfriend.de/forum/viewtopic.php?t=42281

              Kommentar


              • #8
                Jetzt tut wieder alles, die IP-Sperre funktioniert jetzt wie geplant, weil die IP nicht mehr im Formular steht, sondern erst danach besorgt wird, und dann nicht als $_GET['IP'] sondern als direkte Variable in die DB eingetragen wird. Cookies könnte man da zu leicht als Client abschalten und wieder kann man endlos posten, mit IP-Sperre ist das schon recht gut unterbunden, da wohl niemand um 6000 Posts zu machen seinen Router 6000 mal neustarten lässt *Gg* und die unbeteiligten, deren Einträge dadurch verhindert werden dürften sich in Grenzen halten.

                Also Danke an alle, ich hätte den Fehler in der IP-Sperre wohl sonst nicht gefunden

                Kommentar

                Lädt...
                X