Wann ist es am besten, Benutzereingaben zu bereinigen?

https://stackoverflow.com/questions/34896

09-06-2019
|

Frage

Benutzer ist nicht vertrauenswürdig.Vertrauen Sie niemals den Eingaben nicht vertrauenswürdiger Benutzer.Ich verstehe das.Allerdings frage ich mich, wann der beste Zeitpunkt zum Bereinigen von Eingaben ist.Speichern Sie beispielsweise Benutzereingaben blind und bereinigen Sie sie dann bei jedem Zugriff/jeder Verwendung, oder bereinigen Sie die Eingaben sofort und speichern dann diese „bereinigte“ Version?Vielleicht gibt es darüber hinaus noch einige andere Ansätze, an die ich noch nicht gedacht habe.Ich neige eher zur ersten Methode, da mit allen Daten, die aus Benutzereingaben stammen, immer noch vorsichtig umgegangen werden muss, da die „bereinigten“ Daten immer noch unwissentlich oder versehentlich gefährlich sein könnten.Wie auch immer, welche Methode halten die Leute für die beste und aus welchen Gründen?

Lösung

Ich möchte es so früh wie möglich bereinigen, was bedeutet, dass die Bereinigung erfolgt, wenn der Benutzer versucht, ungültige Daten einzugeben.Wenn es ein Textfeld für ihr Alter gibt und sie etwas anderes als eine Zahl eingeben, lasse ich den Tastendruck für den Buchstaben nicht durch.

Dann führe ich unabhängig davon, was die Daten liest (häufig ein Server), eine Plausibilitätsprüfung durch, wenn ich die Daten einlese, um sicherzustellen, dass nichts durch einen entschlosseneren Benutzer (z. B. manuelle Bearbeitung von Dateien oder sogar die Änderung von Paketen) eingeschleust wird !)

Bearbeiten:Insgesamt sollten Sie frühzeitig und jedes Mal desinfizieren, wenn Sie die Daten auch nur für eine Sekunde aus den Augen verloren haben (z. B.Datei speichern -> Datei öffnen)

Andere Tipps

Leider hat fast keiner der Teilnehmer jemals klar verstanden, wovon sie reden.Buchstäblich.Nur @Kibbee hat es geschafft, es klarzustellen.

In diesem Thema dreht sich alles um die Desinfektion.Aber die Wahrheit ist, dass so etwas wie die weit gefasste „Allzweck-Desinfektion“, über die jeder so gerne spricht, so ist existiert einfach nicht.

Es gibt eine Zillion verschiedener Medien, jeweils erforderlich Es handelt sich um eine eigene, eindeutige Datenformatierung. Darüber hinaus - sogar Einzelne bestimmte Medien erfordern unterschiedliche Formatierungen für ihre Teile.Angenommen, die HTML-Formatierung ist für in eine HTML-Seite eingebettetes Javascript nutzlos.Oder die Zeichenfolgenformatierung ist für die Zahlen in einer SQL-Abfrage nutzlos.

Tatsächlich ist eine solche „Reinigung so früh wie möglich“, wie sie in den meisten positiv bewerteten Antworten vorgeschlagen wird, gerechtfertigt unmöglich.Denn man kann einfach nicht sagen, in welchem bestimmten Medium oder Medienteil die Daten verwendet werden.Sagen wir, wir bereiten uns darauf vor, uns vor „SQL-Injection“ zu schützen und allem zu entgehen, was sich bewegt.Aber ups!- Einige erforderliche Felder wurden nicht ausgefüllt und wir müssen die Daten wieder in das Formular statt in die Datenbank eingeben ...mit allen Schrägstrichen hinzugefügt.

Andererseits sind wir allen „Benutzereingaben“ gewissenhaft entkommen...aber in der SQL-Abfrage haben wir keine Anführungszeichen, da es sich um eine Zahl oder einen Bezeichner handelt.Und keine „Desinfektion“ hat uns jemals geholfen.

Drittens – okay, wir haben unser Bestes getan, um die schrecklichen, nicht vertrauenswürdigen und verachteten „Benutzereingaben“ zu bereinigen …Aber in einem inneren Prozess haben wir genau diese Daten ohne jegliche Formatierung verwendet (da wir bereits unser Bestes gegeben haben!) – und schwups!haben die Einspritzung zweiter Ordnung in ihrer ganzen Pracht.

Aus der Sicht der realen Nutzung wäre also der einzig richtige Weg

Formatierung, nicht welche „Bereinigung“ auch immer
direkt vor dem Gebrauch
nach den bestimmten Medienregeln
und sogar das Befolgen von Unterregeln, die für die verschiedenen Teile dieses Mediums erforderlich sind.

Ich desinfiziere meine Benutzerdaten ähnlich wie Radu ...

Erste clientseitige Verwendung von REGEXs und die Kontrolle über zulässige Zeichen in gegebenen Formfeldern mit JavaScript oder JQuery, die an Ereignisse gebunden sind, wie z.Erkenne jedoch, dass dies wirklich nur den Einfluss hat, dass diese Benutzer auch wissen, dass die Daten auch serverseitig überprüft werden.Es ist mehr eine Warnung als jeder tatsächliche Schutz.
Zweitens, und ich sehe dies heutzutage selten mehr, dass der erste Scheck die Server-Seite ist, um den Ort zu überprüfen, an dem das Formular eingereicht wird.Indem Sie nur die Formulareingabe von einer Seite zuzulassen, die Sie als gültigen Ort bezeichnet haben, können Sie das Skript abtöten, bevor Sie überhaupt alle Daten gelesen haben.Zugegeben, dass an sich an sich unzureichend ist, kann ein guter Hacker mit seinem eigenen Server sowohl die Domain als auch die IP -Adresse „gefälscht“, damit es Ihrem Skript angezeigt wird, dass es von einem gültigen Formularort stammt.
Als nächstes, und ich sollte das nicht einmal sagen müssen, aber immer, und ich meine STETS, Führen Sie Ihre Skripte im Müdmodus aus.Dies zwingt Sie, nicht faul zu werden und in Schritt 4 fleißig zu sein.
Bereinigen Sie die Benutzerdaten so bald wie möglich mit gut geformten Regexes, die den Daten angemessen sind, die von einem bestimmten Feld auf dem Formular erwartet werden.Nehmen Sie keine Abkürzungen wie das berüchtigte. 'Zauberhorn des Einhorns'um deine Taint-Checks durchzublasen ...Oder Sie können auch die Mächte überprüft, die es für Ihre Sicherheit erledigt.Das ist so, als würde man einem Psychopath ein scharfes Messer geben, den Hals tragen und sagen: "Du wirst mich damit wirklich nicht verletzen.

Und hier unterscheidet ich mich in diesem vierten Schritt als die meisten anderen, da ich nur die Benutzerdaten, die ich tatsächlich verwenden werde JEDES Schreiben zum Speichern von Daten.Wenn ich nur die Dateneingaben von einem Benutzer benutze, um einen Vergleich mit Daten zu verwirklichen, die ich selbst auf dem System gespeichert habe (weshalb zu wissen, dass eigene Daten meine eigenen Daten sind), dann habe ich mich nicht darum, die Benutzerdaten zu desinfizieren, wie ich Gehen Sie uns niemals zu einem Weg, der sich als Sicherheitsproblem darstellt.Nehmen Sie beispielsweise einen Benutzernameneingang als Beispiel.Ich benutze den Benutzernameneingang vom Benutzer nur, um sie gegen eine Übereinstimmung in meiner Datenbank zu überprüfen. Wenn ich zutreffend ist, verwende ich die Daten aus der Datenbank, um alle anderen Funktionen auszuführen, die ich im Skript für das Skript aufrufen könnte, da ich weiß, dass es sicher ist und verwenden Sie die Benutzerdaten danach nie wieder.
Zuletzt soll heutzutage alle versuchten Auto-SubMits von Robotern mit einem "menschlichen Authentifizierungssystem" wie Captcha herausfiltern.Dies ist heutzutage wichtig genug, dass ich mir die Zeit genommen habe, mein eigenes Schema der menschlichen Authentifizierung zu schreiben, das Fotos und einen Eingang für den „Menschen“ verwendet, um das einzugeben, was sie auf dem Bild sehen.Ich habe dies getan, weil ich festgestellt habe, dass Captcha-Systemsysteme die Benutzer wirklich ärgern (Sie können anhand ihrer geschnittenen Augen feststellen, die verzerrten Buchstaben zu entschlüsseln ...normalerweise immer und immer wieder).Dies ist besonders wichtig für Skripte, die entweder Sendmail oder SMTP für E-Mail verwenden, da dies Favoriten für Ihre hungrigen Spam-Bots sind.

Um es kurz zusammenzufassen: Ich erkläre es so, wie ich es meiner Frau tue ...Ihr Server ist wie ein beliebter Nachtclub, und je mehr Türsteher Sie haben, desto weniger Ärger haben Sie wahrscheinlich im Nachtclub.Ich habe zwei Türsteher vor der Tür (clientseitige Validierung und menschliche Authentifizierung), einen Türsteher direkt in der Tür (überprüft, ob ein gültiger Ort für die Formularübermittlung vorliegt ...)"Ist das wirklich Sie auf dieser ID") und einige weitere Türsteher in unmittelbarer Nähe zur Tür (ausführender Modus ausführen und gute Regexes verwenden, um die Benutzerdaten zu überprüfen).

Ich weiß, dass dies ein älterer Beitrag ist, aber ich hielt ihn für wichtig genug, damit jeder, der ihn nach meinem Besuch hier liest, erkennt, dass es sich nicht um einen Beitrag handelt.Wunderwaffe', wenn es um Sicherheit geht, und all diese müssen zusammenwirken, um Ihre vom Benutzer bereitgestellten Daten sicher zu machen.Die alleinige Anwendung einer oder zweier dieser Methoden ist praktisch nutzlos, da ihre Wirksamkeit nur im Zusammenwirken aller vorhanden ist.

Oder zusammengefasst, wie meine Mutter oft sagen würde ...'Sicher ist sicher".

AKTUALISIEREN:

Eine weitere Sache, die ich heutzutage mache, ist die Base64-Codierung aller meiner Daten und die anschließende Verschlüsselung der Base64-Daten, die in meinen SQL-Datenbanken gespeichert werden.Es benötigt insgesamt etwa ein Drittel mehr Bytes, um es auf diese Weise zu speichern, aber meiner Meinung nach überwiegen die Sicherheitsvorteile die zusätzliche Größe der Daten.

Es hängt davon ab, welche Art von Desinfektion Sie durchführen.

Nehmen Sie zum Schutz vor SQL-Injection nichts an den Daten selbst vor.Verwenden Sie einfach vorbereitete Anweisungen, und auf diese Weise müssen Sie sich keine Sorgen machen, dass Sie mit den vom Benutzer eingegebenen Daten herumspielen und sich dadurch negativ auf Ihre Logik auswirken.Sie müssen ein wenig bereinigen, um sicherzustellen, dass Zahlen Zahlen und Datumsangaben Datumsangaben sind, da alles ein String ist, wie er aus der Anfrage stammt. Versuchen Sie jedoch nicht, Überprüfungen durchzuführen, um beispielsweise Schlüsselwörter oder ähnliches zu blockieren.

Zum Schutz vor XSS-Angriffen wäre es wahrscheinlich einfacher, die Daten vor der Speicherung zu reparieren.Wie andere bereits erwähnt haben, ist es jedoch manchmal schön, eine makellose Kopie dessen zu haben, was der Benutzer genau eingegeben hat, denn sobald Sie sie ändern, ist sie für immer verloren.Es ist fast schade, dass es keine narrensichere Möglichkeit gibt, sicherzustellen, dass Ihre Anwendung nur bereinigtes HTML ausgibt, und dass Sie durch die Verwendung vorbereiteter Abfragen sicherstellen können, dass Sie nicht von der SQL-Injection erwischt werden.

Das Wichtigste ist, bei der Flucht immer konsequent zu sein.Eine versehentliche doppelte Desinfektion ist lahm und eine unterlassene Desinfektion ist gefährlich.

Stellen Sie bei SQL einfach sicher, dass Ihre Datenbankzugriffsbibliothek Bind-Variablen unterstützt, die Werte automatisch maskieren.Jeder, der Benutzereingaben manuell in SQL-Strings verkettet, sollte es besser wissen.

Bei HTML bevorzuge ich es, im letztmöglichen Moment zu entkommen.Wenn Sie Benutzereingaben zerstören, können Sie sie nie wieder zurückerhalten, und wenn sie einen Fehler machen, können sie sie später bearbeiten und korrigieren.Wenn Sie ihre ursprüngliche Eingabe zerstören, ist sie für immer verloren.

Früh ist gut, auf jeden Fall, bevor Sie versuchen, es zu analysieren.Alles, was Sie später ausgeben oder insbesondere an andere Komponenten (z. B. Shell, SQL usw.) übergeben, muss bereinigt werden.

Aber übertreiben Sie es nicht – zum Beispiel werden Passwörter gehasht, bevor Sie sie speichern (richtig?).Hash-Funktionen können beliebige Binärdaten akzeptieren.Und Sie werden nie ein Passwort ausdrucken (richtig?).Analysieren Sie Passwörter also nicht – und bereinigen Sie sie nicht.

Stellen Sie außerdem sicher, dass Sie die Bereinigung über einen vertrauenswürdigen Prozess durchführen – JavaScript/alles andere auf der Clientseite ist schlimmer als nutzlose Sicherheit/Integrität.(Es könnte jedoch eine bessere Benutzererfahrung bieten, frühzeitig zu scheitern – machen Sie es einfach an beiden Stellen.)

Perl verfügt über eine Taint-Option, die alle Benutzereingaben als „verdorben“ betrachtet, bis sie mit einem regulären Ausdruck überprüft werden.Verunreinigte Daten können verwendet und weitergegeben werden, aber sie verunreinigen alle Daten, mit denen sie in Kontakt kommen, bis sie unverfälscht werden.Wenn beispielsweise eine Benutzereingabe an eine andere Zeichenfolge angehängt wird, ist auch die neue Zeichenfolge fehlerhaft.Grundsätzlich gibt jeder Ausdruck, der fehlerhafte Werte enthält, ein fehlerhaftes Ergebnis aus.

Verunreinigte Daten können nach Belieben herumgeworfen werden (wodurch Daten verunreinigt werden), aber sobald sie von einem Befehl verwendet werden, der Auswirkungen auf die Außenwelt hat, schlägt das Perl-Skript fehl.Wenn ich also beschädigte Daten verwende, um eine Datei zu erstellen, einen Shell-Befehl zu erstellen, das Arbeitsverzeichnis zu ändern usw., schlägt Perl mit einem Sicherheitsfehler fehl.

Mir ist keine andere Sprache bekannt, die so etwas wie „Taint“ hat, aber die Verwendung dieser Sprache hat mir sehr die Augen geöffnet.Es ist erstaunlich, wie schnell sich verfälschte Daten verbreiten, wenn man sie nicht sofort bereinigt.Dinge, die für einen Programmierer selbstverständlich und normal sind, wie das Setzen einer Variablen basierend auf Benutzerdaten oder das Öffnen einer Datei, erscheinen bei aktiviertem Tainting gefährlich und riskant.Die beste Strategie, um Dinge zu erledigen, besteht also darin, die Daten zu entfernen, sobald Sie Daten von außen erhalten.

Und ich vermute, dass das auch in anderen Sprachen der beste Weg ist:Validieren Sie Benutzerdaten sofort, damit sich Fehler und Sicherheitslücken nicht zu weit verbreiten können.Außerdem sollte es einfacher sein, den Code auf Sicherheitslücken zu prüfen, wenn sich die potenziellen Lücken an einer Stelle befinden.Und man kann nie vorhersagen, welche Daten später zu welchem Zweck verwendet werden.

Meine Meinung ist, Benutzereingaben so schnell wie möglich auf der Client- und Serverseite zu bereinigen. Ich mache es so

(Client -Seite) Ermöglichen Sie dem Benutzer, nur bestimmte Schlüssel in das Feld einzugeben.
(Client -Seite) Wenn der Benutzer mit Onblur zum nächsten Feld geht, testen Sie die Eingabe, die er gegen einen Regexp eingegeben hat, und bemerken Sie den Benutzer, wenn etwas nicht gut ist.
(Serverseite) testen Sie die Eingabe erneut, wenn das Feld eine Ganzzahlprüfung dafür sein sollte (in PHP können Sie is_numeric () verwenden), wenn das Feld ein bekanntes Format hat, überprüfen Sie es mit einem Regexp, allen anderen (wie Textkommentare). Entkommen ihnen einfach.Wenn etwas verdächtig ist, stoppen Sie die Skriptausführung und senden Sie eine Benachrichtigung an den Benutzer zurück, dass die von ihm eingegebenen Daten ungültig sind.

Wenn etwas wirklich wie ein möglicher Angriff aussieht, sendet mir das Skript eine E-Mail und eine SMS, damit ich es so schnell wie möglich überprüfen und möglicherweise verhindern kann. Ich muss nur das Protokoll überprüfen, in dem ich alle Benutzereingaben protokolliere, und die Schritte, die das Skript ausgeführt hat, bevor es die Eingabe akzeptiert oder ablehnt.

Bereinigen Sie die Daten, bevor Sie sie speichern.Im Allgemeinen sollten Sie keine Vorformungen vornehmen BELIEBIG SQL-Aktionen ohne vorherige Bereinigung der Eingaben.Sie möchten sich keinem SQL-Injection-Angriff aussetzen.

Ich halte mich gewissermaßen an diese Grundregeln.

Ändern Sie nur SQL-Aktionen wie INSERT, UPDATE, DELETE über POST.Nie bekommen.
Entkomme allem.
Wenn Sie erwarten, dass es sich bei der Benutzereingabe um etwas handelt, stellen Sie sicher, dass es sich um etwas handelt.Wenn Sie beispielsweise eine Nummer anfordern, stellen Sie sicher, dass es sich um eine Nummer handelt.Nutzen Sie Validierungen.
Verwenden Sie Filter.Bereinigen Sie unerwünschte Zeichen.

Benutzer sind böse!

Nun, vielleicht nicht immer, aber mein Ansatz besteht darin, immer sofort zu desinfizieren, um sicherzustellen, dass nichts Riskantes in die Nähe meines Backends gelangt.

Der zusätzliche Vorteil besteht darin, dass Sie dem Benutzer Feedback geben können, wenn Sie die Eingabestelle bereinigen.

Gehen Sie davon aus, dass alle Benutzer böswillig sind.Bereinigen Sie alle Eingaben so schnell wie möglich.Punkt.

Ich bereinige meine Daten unmittelbar bevor ich sie verarbeite.Möglicherweise muss ich die Felder „Vorname“ und „Nachname“ in ein drittes Feld verketten, das in die Datenbank eingefügt wird.Ich werde die Eingabe bereinigen, bevor ich überhaupt die Verkettung durchführe, damit keine Verarbeitungs- oder Einfügefehler auftreten.Je früher desto besser.Selbst die Verwendung von Javascript im Frontend (in einem Web-Setup) ist ideal, da dies geschieht, ohne dass Daten von vornherein an den Server gesendet werden.

Das Beängstigende daran ist, dass Sie vielleicht sogar damit beginnen möchten, auch die Daten aus Ihrer Datenbank zu bereinigen.Die jüngste Welle von ASPRox SQL-Injection-Angriffen ist doppelt tödlich, da sie alle Datenbanktabellen in einer bestimmten Datenbank infiziert.Wenn Ihre Datenbank an einem Ort gehostet wird, an dem mehrere Konten in derselben Datenbank gehostet werden, werden Ihre Daten aufgrund des Fehlers einer anderen Person beschädigt, aber jetzt gehören Sie zu den Schadsoftware-Hostern für Ihre Besucher, ohne dass Sie dafür ursprünglich etwas verschuldet haben .

Sicherlich bedeutet dies im Vorfeld eine Menge Arbeit, aber wenn die Daten von entscheidender Bedeutung sind, ist es eine lohnende Investition.

Ich finde, dass die sofortige Reinigung zwei Vorteile hat.Erstens können Sie es validieren und dem Benutzer Feedback geben.Zweitens müssen Sie sich keine Sorgen darüber machen, dass die Daten an anderen Orten verbraucht werden.

Benutzereingaben sollten immer als böswillig behandelt werden, bevor sie in tiefere Schichten Ihrer Anwendung gelangen.Behandeln Sie die bereinigenden Eingaben immer so schnell wie möglich und sollten Sie sie aus keinem Grund in Ihrer Datenbank speichern, bevor sie auf böswillige Absichten überprüft werden.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow