Sicherheit prüfen

[Dj Mik]

Danke ^^ ich konnte mich gerade eben nicht entscheiden, welches von beidem ich nehmen sollte ^^

Frage noch:

Brauche ich bei hidden ...
[CODE]<input name="ID" type="hidden"...[CODE]
auch den schutz vor SQL-Injectionen?

[Blackgreetz]

Theorie: Alle Felder die übergeben werden können manipuliert werden.
Leute können sich das formular kopieren, bei sich zuhause einfügen, und das hidden etc. löschen und dann abschicken. (Firefox WebDeveloger bietet glaube auch die möglichkeit alles sichrbat zu machen)

Praxis: Man sollte, auch wenn sich Leute selten die Arbeit zu sowas machen, da es wieder Zeit kostet etc.: alle Felder auch überprüfen.

Was du mit einem verstecken Hiddenfeld einer ID willst, weiß ich nicht ganz genau.
Bei IDs bzw. generell bei ganzen Zahlen würde ich auf intval() zurückgreifen oder ggf. is_numeric()(nutze selber nur intval)

mfg
Edit: @wahsaga: Wurde gerade gefragt im MSN(dem hab ich deine AW gezeigt, da er aus Prinzip Adds. nutzt) ob man also nun htmlspecialchars und mysql_real_escape_string nutzen soll, oder ..kein oder^^ .. Da ich es nicht gut erklären kann oder er es nicht versteht(?) frag ich nun hier mal.. vlt kanns ja wer besser als ich.

[Dj Mik]

Original geschrieben von Blackgreetz

Was du mit einem verstecken Hiddenfeld einer ID willst, weiß ich nicht ganz genau.

gehört zum Sicherheitsabfrage Bildercode.

<td width="50%"><input name="ID" type="hidden" value="<?php echo$ID; ?>">
<input maxlength="6" name="EingegebenerCode" size="6" type="text"></td>

also ist es egal, ob 6 Zeichen oder sogar weniger erlaubt werden.
Es kann immer gecknackt werden?

[JimmDaBimm]

@wahsaga: jutti, allet klar. Dann werd ich gegen mein Idiotendasein auch mal schleunigst was tun xD.

[wahsaga]

Original geschrieben von Dj Mik
Brauche ich bei hidden ...
<input name="ID" type="hidden"...
auch den schutz vor SQL-Injectionen?

Natürlich - bei absolut jedem Wert, der von aussen kommt.

Es kann immer gecknackt werden?

Es braucht überhaupt nicht "geknacht" zu werden - es reicht schon aus, den Formularinhalt per Javascript oder bspw. über eine Developer Toolbar zu ändern.

Und Spammer/Angreifer benutzen idR. sowieso nicht deine Seite, um irgendwas zu versuchen - die senden einfach einen POST-Request, sowas wie ein "Browser" ist dafür nicht mal erforderlich.

Alles, was du weisst, ist, dass ein Request für den Aufruf deines Scriptes gesorgt hat - das ist auch schon absolut alles, darüber hinaus weisst du gar nichts.

Original geschrieben von Blackgreetz
ob man also nun htmlspecialchars und mysql_real_escape_string nutzen soll, oder

Daten sind immer entsprechend dem Kontext zu behandeln, in den sie aktuell überführt werden sollen.
Wenn der Kontext MySQL-Query heisst, dann mysql_real_escape_string.
Wenn der Kontext HTML-Ausgabe heisst (in der keine Manipulation möglich sein soll, sondern nur reine Textausgabe), dann htmlspecialchars.
...

[Blackgreetz]

Original geschrieben von wahsaga
Daten sind immer entsprechend dem Kontext zu behandeln, in den sie aktuell überführt werden sollen.
Wenn der Kontext MySQL-Query heisst, dann mysql_real_escape_string.
Wenn der Kontext HTML-Ausgabe heisst (in der keine Manipulation möglich sein soll, sondern nur reine Textausgabe), dann htmlspecialchars.
...

Fazit: Speichern erstmal unter mysql_real_escape_string-Anwendung und bei der Ausgabe evtl. htmlspecialchars anwenden

Bj Mik schrieb:
gehört zum Sicherheitsabfrage Bildercode.

Wenn du die ID noch in ein hidden-Feld schreibst, kann man dabei sogar noch realtiv einfach Bots entwickeln, die das hidden-Feld auslesen und es bei deinem Captcha eintragen. Wäre also nicht besonders sinnvoll. Weiteres siehe wahsagas Beitrag.

mfg

[TobiaZ]

Wenn du die ID noch in ein hidden-Feld schreibst, kann man dabei sogar noch realtiv einfach Bots entwickeln, die das hidden-Feld auslesen und es bei deinem Captcha eintragen. Wäre also nicht besonders sinnvoll.

ID ist doch hoffentlich was anderes als der CODE.

[tontechniker]

ID ist doch hoffentlich was anderes als der CODE.

ID ist hier das was im Captcha steht ...

[TobiaZ]

Wo ist der :wall: smilie....

[Deniz1982]

Sicherheit Sicherheit

1. Im Fourm gibst tausende Threads über sicherheit

Aber hier mal ein paar Funktionen die PHP bereitstellt um eingaben unschädlich zu machen:

- strip_tags() - Entfernt alle HTML-Tags einer Zeichenkette (Verwende ich immer, damit kein user HTML code irgendwo einfügen kann. Funktionert auch gegen Javascript code also kann kein Javascript mehr rein)
- htmlentities() ähnlich wie oben
- htmlspecialchars() ähnlich wie oben

- mysql_real_escape_string ist klar wurde hier schon diskutiert und ich empfehle wirkliche jedem, der was mit einer Variable in die Datenbank schickt mit dem befehl unschädlich zu machen

- Session sind sicher ausser man kann sie klauen *grins naja aber ich änder zusätzlcih noch den Session Pfad und speichere sie da wo sie niemand finden kann

Grundregel: Alles was ein User eingeben kann muss unschädlich gemacht werden php hilft da. Bisschen die manuel durchlesen. Manche glauben POST wäre sichere als GET stimmt nicht beides muss mit gleicher sorgfalt überprüft werden.

Falls du include verwendest: Ich mache das immer so, dass meine Include Dateien nicht im Hauptordner sind. Ich lege sie in einen anderen. *g Diesen schließe ich per .htaccess dann ab. php kann, die Include Dateien dennoch abrufen, da er das Dateisystem durchsucht und es kommt keine Passwortabfrage es sei denn man will die Dateien direkt abrufen.

Naja ich denke wenn man das alles einhält passiert schon nichts.

[jahlives]

Aber hier mal ein paar Funktionen die PHP bereitstellt um eingaben unschädlich zu machen:

Ich würde den generierten Code eh als md5() Hash in der DB speichern. Wenn man dann die Usereingabe ebenfalls mit md5() bearbeitet kann man das "Unschädlichmachen" der Daten auch der DB überlassen:

$sql = "SELECT COUNT(*) FROM captcha WHERE code='md5($code)'"; 

Just my 5 Cents
Gruss

tobi

[Deniz1982]

md5() verwende ich nur bei passwörter. Wenn man z.B ein Gästebuch hat, dann ist wohl besser auf andere Funktionen zurückzugreifen da hilft md5 nicht wirklich grins

[Schnoop]

Ich verarbeite alle ankommenden Parameter (egal ob POST oder GET oder COOKIE) in einem Parameterobject. Dies benutze ich dann anstatt der Superglobalen in der gesamten Anwendung.

Man jemand mag das für unsinnig bzw zu aufwendig halten, aber so geh ich 100% sicher das nicht irgendwo ein ungefiltertes $_POST verwendent wird.

[TobiaZ]

Session sind sicher ausser man kann sie klauen *grins naja aber ich änder zusätzlcih noch den Session Pfad und speichere sie da wo sie niemand finden kann

"Session-Klau" findet afaik in der Regel außerhalb des Servers statt, indem man die ID "klaut", da hilft der Pfad nicht viel. Oder was meintest du genau?

md5() verwende ich nur bei passwörter. Wenn man z.B ein Gästebuch hat, dann ist wohl besser auf andere Funktionen zurückzugreifen da hilft md5 nicht wirklich grins

Hmm, dieser Satz lässt mich vermuten, dass du a) nicht weißt, was md5() bewirkt, b) entsprechend auch nicht weißt, warum du es bei Passwörtern anwendest, c) folglich auch nicht nachvollziehen kannst, warum es in diesem Fall sehr wohl ein Schutz sein kann.

Voraussetzung ist natürlich, dass man den String, so wie Tobi php-Seitig hasht (das wird mangels "Stings nicht richtig getrennt", leider nicht auf den ersten blick deutlich). Ob ein Count wirklich erforderlich ist, oder ein SELECT LIMIT 1 nicht reicht, wäre dann ne andere Sache.

[jahlives]

so wie Tobi php-Seitig hasht

Wieso PHP seitig ? MySql hat auch ne md5() Funktion und die gehört in den String