MySQL - eintragen von Daten geht schief... (Seite 2)

Hallo Roman,
wtf ist Wochenende?

Vielen Dank für deinen Hinweis. Gegebenenfalls werde ich darauf zurückgreifen :>
Zuerst ist jedoch zu klären, ob die per Bot bei uns eingestellten Mitteilungen für uns von Relevanz sind (qualitativ hochwertige Beiträge) oder sowieso in die Mülltonne gehören, denn es geht ja primär darum dem "Nutzer" möglichst ansprechenden Content zu präsentieren, bzw. diesen Content zu archivieren.

Sollte ein hoher Anteil dieser Beiträge "gut" sein werde ich um ein Workaround-Skript zum Konvertieren wohl nicht herumkommen.

Viele Grüße
Johnny

Johannes, ich glaube da hab ich mich nicht deutlich genug ausgedrückt.
Bevor Du auf die Idee kommst, irgendwas in der Datenbank speichern zu wollen, solltest Du in jedem Falle die geposteten Inhalte überprüfen.

Bei der Gelegenheit, können die übergebenen Werte auch konvertiert werden.

Hallo Roman,
ich glaube ich stehe immer noch auf dem Schlauch...
inwiefern soll ich die Nutzereingaben denn überprüfen bevor sie eingetragen werden?

Also ich verwende natürlich strip_tags um html und php tags zu filtern, aber danach werden die Nutzereingaben in der DB gespeichert... dann werden diese redaktionell überprüft und ggf. freigegeben ("quergelesen" quasi).

Ob der Eintrag von einer Person oder einer Maschine getätigt wurde ist im ersten Moment ja nebensächlich, solange der Eintrag qualitativ hochwertig ist und alle Kriterien erfüllt wurden (Ansprechpartner + Kontaktemail angegeben etc.).

Entschuldige wenn ich gerade etwas langsam bin

Gruß
Johnny

Mit strip_tags eliminierst du aber z.B. nicht die Gefahr von SQL-Injections. Und vor XSS-Attacken kann strip_tags auch nicht vollständig schützen.
*_real_escape_string ist schon einmal dringend angeraten, denke ich. Du bekommst die Eingabe, validierst sie, dass sie generell deinen Erwartungen entspricht (Text vorhanden, alle nötigen Felder ausgefüllt, evtl. auch Captcha-Prüfung usw.).
Anschließend filtern (z.B. strip_tags) und dann escapen, also alle Steuerzeichen eliminieren (macht u.a. *_real_escape_string in php), aber auch htmlentities() verwenden, damit werden alle anderen möglichen Tags oder Anführungszeichen, die möglicherweise aus böser Absicht integriert sind, entkräftet. An dieser Stelle (bzw. ganz zu Anfang) kann man die Eingabe dann auch konvertieren. Und vielleicht hilft auch ein "accept-charset=\'UTF-8\'" im form-Tag...

Soviel Aufwand mache ich mir aber je nach Projekt gar nicht. Wenn klar ist, dass keinerlei Tags vorhanden sein dürfen, lehne ich teilweise die Eingabe einfach ab. Denn letztlich würde ich mich nie darauf verlassen, dass mein Skript wirklich alles findet - wer sich nicht an die Vorgaben hält, könnte vielleicht noch bessere Methoden kennen, sein Vorhaben zu verschleiern.

Da stimme ich dem Matthes zu,
Wir haben hier auf SR in den letzten beiden Wochen intensiv zum Thema Sicherheit und PHP diskutiert.
Dabei sind viele gute Artikel und Links zusammen gekommen. PHP Sicherheit ist Pflichtlektüre, hinterher ist immer Alles zu spät.

Du bist mit Deinem Vorgehen schon ein Schritt zu weit.

Eingabe in das Formular--> absenden -->server muss prüfen ob da gefährliche Daten dabei sind(das meinen Matthes und ich) --> Daten in die DB schieben(das ist Dein Ansatz)--> admin informieren->Admin prüft Content und veröffentlicht(Dein Handeln).

Wenn Du die Schritte einmal nachvollziehst, merkst wo der Hund begraben ist.
Am besten, du klemmst die Seite erstmal vom Server ab, damit Du die Sicherheitssachen machen kannst.
Gewiss haben diesen Threat bereits einige Leute gelesen. Und manche haben auch bis zum nächsten Spiel lange Weile.

strip_tags() ist doch kein Bestandteil von Sicherheit.
Benutzereingaben zu verarbeiten ist im Grunde super simpel:
Eingabe:
• der Benutzer schickt das Formular ab
• man wendet mysql_real_escape_string() auf den Input an
• man führt den Insert-Befehl (o.ä.) aus
Ausgabe:
• man liest den Eintrag aus der DB
• man wendet htmlspecialchars() auf den Output an
• man gibt den Eintrag aus..

Da gibt\'s weder SQL-Injection noch XSS-Lücken, und der Beitrag wird exakt so ausgegeben wie er eingegeben wurde.

Glaube dann fehlt auch noch ne Typenunterscheidung.
Die Länge der Spalte würde man gewiss auch prüfen müssen.

Nicht zu vergessen. Formular nur einmal annehmen und speichern.

Das geht dann aber schon weg vom Thema Sicherheit und hin in Richtung Formularvalidierung.

Benützt man für die Tabellen die selbe Rechtscheibung wie in den Skipten - Sichwort: Groß- und Kleinschreibung?

So gut ich weiß ist MySQL case insensitive, Groß- und Kleinschreibung ist also egal.

Aber was hat das mit dem Thema zu tun?