SQL Injection: Schutz bei Login - welcher Weg

Hallo NG,

wie handelt Ihr den Schutz bei einfachen Login's (login/pass) vor SQL
Injections:

A) Schauen ob überhaupt ein böser Versuch gestartet wird: Überprüfung
der eingegebenen Zeichen und Abbruch (die()) wenn verdächtige
Zeichenketten nach dem $_POST erkannt werden? Sprich dem bösen Buben zu
verstehen geben, es wurde ein Versuch erkannt..... und abwürgen?

oder

B) Die Eingabe nicht überprüfen und weiterfahren mit stripslashes (bei
get_magic_quotes) und anschließendem mysql_real_escape_string einen
einfachen Login-Fehler ausgeben.



Danke Euch,
Peter
Peter Wittenberger [ Do, 18 Oktober 2007 16:57 ] [ ID #1848450 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Peter Wittenberger schrieb:
> wie handelt Ihr den Schutz bei einfachen Login's (login/pass) vor SQL
> Injections:
>
> A) Schauen ob überhaupt ein böser Versuch gestartet wird: Überprüfung
> der eingegebenen Zeichen und Abbruch (die()) wenn verdächtige
> Zeichenketten nach dem $_POST erkannt werden? Sprich dem bösen Buben zu
> verstehen geben, es wurde ein Versuch erkannt..... und abwürgen?

Ist es ein Versuch wenn mein Loginname Christoph's heißt? Also wohl eher
nicht diese Variante. :)

Aber auf jeden Fall niemals eine Meldung ausgeben wie "Hackversuch
erkannt". Erstens weißt du nie, ob es einfach nur ein Vertipper,
Dummheit oder Unwissenheit des Anwenders war und zweitens sollte man
nicht mehr Informationen raus geben, als unbedingt nötig. Und schon die
Tatsache, welche Eingaben du als Hackversuch deutest, ist eine
Information, die keinerlei Sinn bezweckt (außer einem Hacker nützliche
Informationen zu liefern).

Daher beim Login nur zwei Möglichkeiten anbieten:
a) Daten stimmen, Benutzer konnte sich einloggen, wunderbar.
b) Egal was, aber irgendwas ging schief, Meldung an den Benutzer
"Benutzername oder Passwort fehlerhaft" oder ähnliches und Eingabe
erneut versuchen lassen.

Somit ist der Benutzer eingeloggt oder er hat die Information, dass
etwas falsch war, was vollkommen ausreicht.

Im übrigen niemals den Benutzernamen oder das Passwort bei einem
Fehlerhaften versuch anzeigen. Kann bei einem Fehler von deiner Seite
her eine schöne Tür öffnen (Stichwort XSS), was vor allem im
Loginbereich "ärgerlich" ist.

> B) Die Eingabe nicht überprüfen und weiterfahren mit stripslashes (bei
> get_magic_quotes) und anschließendem mysql_real_escape_string einen
> einfachen Login-Fehler ausgeben.

Warum Login Fehler ausgeben? Wenn den String ordnungsgemäß escapet hast,
kannst Sie ohne Probleme in SQL Statements verwenden. Alternative im
übrigen sind Prepared Statements. Hier werden die Parameter automatisch
excapet.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Christoph Herrmann [ Do, 18 Oktober 2007 17:21 ] [ ID #1848454 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Christoph Herrmann wrote:

> Daher beim Login nur zwei Möglichkeiten anbieten:
> a) Daten stimmen, Benutzer konnte sich einloggen, wunderbar.
> b) Egal was, aber irgendwas ging schief, Meldung an den Benutzer
> "Benutzername oder Passwort fehlerhaft" oder ähnliches und Eingabe
> erneut versuchen lassen.

Das würde ich nicht machen. Ich mache es so, dass ich bestimmte Zeichen
zulasse und andere eben nicht. Typischerweise alphanumerische Zeichen, sowie
eine handvoll unkritische Zeichen wie bspw. [at] -_.

Das hat den Vorteil einem verblufften normalen Benutzer auch sagen zu
können, dass nur diese Zeichen zulässig sind. Alles andere stiftet nur
Verwirrung, weil der Benutzer sonst keine Assoziation zum "Nicht Gelingen"
hat und eher Frustration als Ursachenbehebung macht.

Es ist auch unkritisch einem Benutzer oder Hacker zu sagen, das nur ein Set
von Zeichen zulässig ist. Prozentzeichen, Kaufmannsund, #, diverse
Hochkommata etc. sollte man sich allerdings sparen.

Ein anschliessendes Anwenden von Prepared Statements schadet natürlich
nicht.

Ich würde es auf jedenfall unterlassen irgendjemandem zu sagen, was er ist,
was er tut oder was er meiner Meinung nach "verbricht".

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.
Johannes Mueller [ Do, 18 Oktober 2007 17:35 ] [ ID #1848456 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

..oO(Peter Wittenberger)

>wie handelt Ihr den Schutz bei einfachen Login's (login/pass) vor SQL
>Injections:
>
>A) Schauen ob überhaupt ein böser Versuch gestartet wird: Überprüfung
>der eingegebenen Zeichen und Abbruch (die()) wenn verdächtige
>Zeichenketten nach dem $_POST erkannt werden? Sprich dem bösen Buben zu
>verstehen geben, es wurde ein Versuch erkannt..... und abwürgen?

Nö. Sowas kann nie 100% funktionieren, da es oftmals mehrere
Möglichkeiten, bestimmte Dinge oder Zeichen "einzuschleusen".

>oder
>
>B) Die Eingabe nicht überprüfen und weiterfahren mit stripslashes (bei
>get_magic_quotes) und anschließendem mysql_real_escape_string einen
>einfachen Login-Fehler ausgeben.

Ich nehme die Daten wie sie sind und reiche sie per prepared statement
(PDO) an die DB. Fertig. Sollen die Leute doch eintippen, was sie
wollen. Das bezieht sich übrigens nicht nur auf den Login, sondern auch
auf andere Dinge. Falls nötig, erfolgen einfache Plausibilitäts-
prüfungen, z.B. ob überhaupt was eingegeben wurde, ob ein Datum gültig
ist, ob ein Wert aus den vorgegebenen Zeichen besteht und eine bestimtme
Länge hat etc., ansonsten gehen die Daten aber direkt per PDO in the DB.
Diese kümmert sich dann selbst um die korrekte Verarbeitung von
speziellen Zeichen wie "'".

Natürlich muß das dann auch konsequent durchgezogen werden, d.h. auch
Daten, die schon in der DB stehen und z.B. im Rahmen einer UPDATE-Query
erneut reingeschaufelt werden, müssen _grundsätzlich_ ebenfalls wieder
per prepared statement gespeichert werden.

Der Vollständigkeit halber sei erwähnt, daß auch bei der Ausgabe solcher
Daten auf einer HTML-Seite Vorkehrungen zu treffen sind, um Probleme zu
vermeiden. Konkret heißt das i.d.R. htmlspecialchars().

Micha
Michael Fesser [ Do, 18 Oktober 2007 17:43 ] [ ID #1848457 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Johannes Mueller schrieb:
> Das würde ich nicht machen. Ich mache es so, dass ich bestimmte Zeichen
> zulasse und andere eben nicht. Typischerweise alphanumerische Zeichen, sowie
> eine handvoll unkritische Zeichen wie bspw. [at] -_.
>
> Das hat den Vorteil einem verblufften normalen Benutzer auch sagen zu
> können, dass nur diese Zeichen zulässig sind. Alles andere stiftet nur
> Verwirrung, weil der Benutzer sonst keine Assoziation zum "Nicht Gelingen"
> hat und eher Frustration als Ursachenbehebung macht.

Sag einem möglichen Hacker, dass der Benutzername richtig ist und nur
das Passwort falsch und du hast diesen gerade 50% seiner Arbeit für
erfolgreich abgestempelt.

> Es ist auch unkritisch einem Benutzer oder Hacker zu sagen, das nur ein Set
> von Zeichen zulässig ist. Prozentzeichen, Kaufmannsund, #, diverse
> Hochkommata etc. sollte man sich allerdings sparen.

Ich hasse solche Seiten, die mir verbieten sichere mit Sonderzeichen
behaftete Passwörter zu verwenden. ^^

Ich wüsste keinen Grund, irgendwelche Zeichen zu verbieten. Es hat
keinerlei sicherheitsrelevanten nutzen, sondern schränkt die Sicherheit
eher ein. Bzw. mir fällt überhaupt kein Nutzen ein.


Was ich noch dazusagen wollte: Man sollte der Möglichkeit halber den
Benutzernamen nirgends anzeigen bzw. gegebenenfalls den Nicknamen zur
Anzeige unabhängig des Loginnamens wählen können. Sonst kann ein Hacker
sich die Mitgliederliste anschauen und braucht "nur" noch die Passwörter
raus finden. Anders hätte er wesentlich mehr Aufwand.

Problematisch sehe ich die Verwendung von E-Mail Adressen als Loginnamen
(auch wenn ich dies der Einfachheit halber selbst verwende, da Sie ein
eindeutiges Merkmal einer Person ist und zur Identifikation eingesetzt
werden kann). Es ist in der Regel einfach die E-Mail Adresse eines
Benutzers heraus zu finden.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Christoph Herrmann [ Do, 18 Oktober 2007 17:55 ] [ ID #1848458 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Christoph Herrmann wrote:

>> Das hat den Vorteil einem verblufften normalen Benutzer auch sagen zu
>> können, dass nur diese Zeichen zulässig sind. Alles andere stiftet
>> nur Verwirrung, weil der Benutzer sonst keine Assoziation zum "Nicht
>> Gelingen" hat und eher Frustration als Ursachenbehebung macht.
>
> Sag einem möglichen Hacker, dass der Benutzername richtig ist und nur
> das Passwort falsch und du hast diesen gerade 50% seiner Arbeit für
> erfolgreich abgestempelt.

Ich weiss nicht, wie Du jetzt darauf kommst, dass ein Benutzername bereits
existiert, nur weil ich ein Set von Zeichen voraussetze - aber eventuell
habe ich mich nicht klar genug ausgedrückt.

>> Es ist auch unkritisch einem Benutzer oder Hacker zu sagen, das nur
>> ein Set von Zeichen zulässig ist. Prozentzeichen, Kaufmannsund, #,
>> diverse Hochkommata etc. sollte man sich allerdings sparen.
>
> Ich hasse solche Seiten, die mir verbieten sichere mit Sonderzeichen
> behaftete Passwörter zu verwenden. ^^

1. Sind die Passwörter nur so sicher, wie sie auch in der Datenbank
gespeichert werden.
2. Sind Passwörter nicht per se sicher, nur weil sie ein Sonderzeichen
enthalten.
3. Solange jemand sein Passwort selber festlegen darf, ist vom schlimmsten
Fall auszugehen.
4. dürften Fälle wie deiner einer Minderheit angehören und wahrscheinlich
auch nicht zu einer Nicht-Nutzung eines Intenetangebotes führen

> Ich wüsste keinen Grund, irgendwelche Zeichen zu verbieten. Es hat
> keinerlei sicherheitsrelevanten nutzen, sondern schränkt die
> Sicherheit eher ein. Bzw. mir fällt überhaupt kein Nutzen ein.

Der Nutzen ist, dass man sich bei Migrationen nicht mit eventuellen
Zeichensatzproblemen (Benutzername) rumschlagen muss, bzw. sich selbst
Schussligkeitsfehler erschwert.

> Was ich noch dazusagen wollte: Man sollte der Möglichkeit halber den
> Benutzernamen nirgends anzeigen bzw. gegebenenfalls den Nicknamen zur
> Anzeige unabhängig des Loginnamens wählen können. Sonst kann ein
> Hacker sich die Mitgliederliste anschauen und braucht "nur" noch die
> Passwörter raus finden. Anders hätte er wesentlich mehr Aufwand.

Kannst du doppelte Benutzernamen effizient vermeiden ohne beim User
Verwirrung zu stiften, wenn Du ihm nicht sagst, dass er doch bitte einen
anderen Benutzernamen auswählen soll. Ich bin mir momentan keiner anderen
effektiven Lösung bewusst. Beim Login-Vorgang (nicht Anmeldung) trifft dein
Statement natürlich zu.

Es wird übrigens fast immer Benutzernamen wie, mueller oder ähnliches geben.
In der Welt der Freemailer ist es sowieso Standard, dass man sich mit der
Email anmeldet, also sozusagen dein Benutzername immer öffentlich ist. Ich
sage nicht, dass es deswegen gut ist, ich sage aber, dass ich mir wenige
Web-Szenarien vorstellen kann, die im semiprofessionellen Bereich liegen, wo
man mit einer panischen Sicherheitslückenphobie rangehen müsste (sprich alle
Sonderzeichen, keine Angabe von Kollisionen etc.).

> Problematisch sehe ich die Verwendung von E-Mail Adressen als
> Loginnamen (auch wenn ich dies der Einfachheit halber selbst
> verwende, da Sie ein eindeutiges Merkmal einer Person ist und zur
> Identifikation eingesetzt werden kann). Es ist in der Regel einfach
> die E-Mail Adresse eines Benutzers heraus zu finden.

Da sind wir uns ja einig. Leider habe ich oben schon geantwortet, bevor ich
zu dieser Passage vorgedrungen bin, weswegen ich jetzt zu faul bin den
entsprechenden Part oben wieder zu löschen. Fest steht jedenfalls für mich,
solange Passwörter im Klartext in Datenbanken stehen[1], kann ich auch
Passwörter als Hashes (mit Salt) speichern OHNE Sonderzeichen ohne mich
deswegen schlecht fühlen zu müssen :)

Grüße
Johannes

[1] googlen nach studiVZ (Gerücht?) und diverse andere

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.
Johannes Mueller [ Do, 18 Oktober 2007 18:49 ] [ ID #1848459 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Johannes Mueller schrieb:
> Ich weiss nicht, wie Du jetzt darauf kommst, dass ein Benutzername bereits
> existiert, nur weil ich ein Set von Zeichen voraussetze - aber eventuell
> habe ich mich nicht klar genug ausgedrückt.

ich sollt doch mal besser lesen. ^^ Mir ging es darum, dass man beim
Misslingen nicht den Grund mitgeben sollte im Sinne von "Benutzername
ist richtig, aber Passwort falsch".

> 1. Sind die Passwörter nur so sicher, wie sie auch in der Datenbank
> gespeichert werden.

Ich hoffe ja nicht als Klartext, denn solche Leute gehören erschlagen.
:) Aus solch einem Grund sollte man für jede Anwendung ein anderes
Passwort verwenden, falls eine Anwendung gekapert wird und das Passwort
bekannt wird. So bleibt der Schaden für mich innerhalb dieser Anwendung
und kann nicht für andere Anwendungen ausgenutzt werden.

(Wer für Online Banking das selbe Passwort wie für diverse andere
Webseiten verwendet gehört auch erschlagen, oder in dem Falle
ausgeraubt, ist lukrativer :) )

> 2. Sind Passwörter nicht per se sicher, nur weil sie ein Sonderzeichen
> enthalten.

Aber den Raum der möglichen Kombinationen wird erheblich erweitert,
wodurch es sehr erschwert wird, per Brute Force oder ähnliche Methoden
schnell auf ein Passwort zu kommen.

> 3. Solange jemand sein Passwort selber festlegen darf, ist vom schlimmsten
> Fall auszugehen.

Da hast natürlich recht. Wird immer Leute geben die "123" oder "asd" als
Passwort benutzen. Allerdings tut dies nur wenig zur Sache. In so Fällen
ist der Benutzer für sich selbst verantwortlich.

PS: Je nach Grad des Sicherheitsbedürfnisses sollte man auch die
Komplexität oder die Länge der Gültigkeit eines Passwortes erzwingen.

> 4. dürften Fälle wie deiner einer Minderheit angehören und wahrscheinlich
> auch nicht zu einer Nicht-Nutzung eines Intenetangebotes führen

Das mit der Nichtnutzung versteh ich nicht. Aber nur weil ich zu einer
Minderheit gehöre und auf meine Sicherheit achte heißt es nicht, dass
man mich in meiner Sicherheit einschränken sollte...

> Der Nutzen ist, dass man sich bei Migrationen nicht mit eventuellen
> Zeichensatzproblemen (Benutzername) rumschlagen muss, bzw. sich selbst
> Schussligkeitsfehler erschwert.

Sollst nicht gleich alle chinesischen Zeichen und den gesamten Unicode
Bereich erlauben. Aber alles was ich mit dem Auge auf der Tastatur an
druckbaren Zeichen erblicke wird ja wohl erlaubt sein und sollte keinem
Probleme machen.

> Kannst du doppelte Benutzernamen effizient vermeiden ohne beim User
> Verwirrung zu stiften, wenn Du ihm nicht sagst, dass er doch bitte einen
> anderen Benutzernamen auswählen soll. Ich bin mir momentan keiner anderen
> effektiven Lösung bewusst. Beim Login-Vorgang (nicht Anmeldung) trifft dein
> Statement natürlich zu.

An die Anmeldung hab ich gar nicht gedacht. :) Aber ja, das kann man.
Lässt den Benutzernamen seine E-Mail Adresse eingeben, darauf hin
bekommt er eine E-Mail mit einem Link (Request/Response Methode heißt
das glaub ich). Folgt er dem Link wird er registriert und bekommt einen
eindeutigen Benutzernamen *zugewiesen*. Bei meinem Webanbieter bekomme
ich zum Beispiel Benutzernamen für Datenbanken und FTP Zugänge ebenfalls
zugewiesen und darf mir nur ein Passwort ausdenken.

> Es wird übrigens fast immer Benutzernamen wie, mueller oder ähnliches geben.
> In der Welt der Freemailer ist es sowieso Standard, dass man sich mit der
> Email anmeldet, also sozusagen dein Benutzername immer öffentlich ist. Ich
> sage nicht, dass es deswegen gut ist, ich sage aber, dass ich mir wenige
> Web-Szenarien vorstellen kann, die im semiprofessionellen Bereich liegen, wo
> man mit einer panischen Sicherheitslückenphobie rangehen müsste (sprich alle
> Sonderzeichen, keine Angabe von Kollisionen etc.).

Gleiches Problem wie beim Passwort. Solange du die dem Benutzer freie
Wahl lässt ohne eine Komplexität zu erzwingen wird man immer auf solche
Dinge treffen.

PS: Alles was hier besprochen wird ist relativ zu sehen. Wer keine
sensiblen Daten anbietet, der braucht auch keine hohe Sicherheit. Beim
Online Banking beispielsweise würde ich aber vielleicht etwas strenger
darauf achten. Aber ein Mindestmaß an Sicherheit sollte immer
dazugehören (Passwörter nicht als Klartext speichern z.B.). Viele der
oben genannten Dinge streiten sich etwas mit der Benutzerfreundlichkeit.
Deswegen würde ich diese nur in erwägung ziehen, wenn die Anwendung dies
erfordert.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Christoph Herrmann [ Do, 18 Oktober 2007 19:39 ] [ ID #1848462 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Christoph Herrmann wrote:

>> 4. dürften Fälle wie deiner einer Minderheit angehören und
>> wahrscheinlich auch nicht zu einer Nicht-Nutzung eines
>> Intenetangebotes führen
>
> Das mit der Nichtnutzung versteh ich nicht. Aber nur weil ich zu einer
> Minderheit gehöre und auf meine Sicherheit achte heißt es nicht, dass
> man mich in meiner Sicherheit einschränken sollte...

Sollte nur heissen, nur weil Du keine Sonderzeichen benutzen darfst würde es
dich wahrscheinlich nicht davon abhalten dich trotzdem anzumelden. Eventuell
würdest du vielleicht aufstöhnen und dir an den kopf fassen, aber du würdest
die Pille schlucken!

> An die Anmeldung hab ich gar nicht gedacht. :) Aber ja, das kann man.
> Lässt den Benutzernamen seine E-Mail Adresse eingeben, darauf hin
> bekommt er eine E-Mail mit einem Link (Request/Response Methode heißt
> das glaub ich). Folgt er dem Link wird er registriert und bekommt
> einen eindeutigen Benutzernamen *zugewiesen*. Bei meinem Webanbieter
> bekomme ich zum Beispiel Benutzernamen für Datenbanken und FTP
> Zugänge ebenfalls zugewiesen und darf mir nur ein Passwort ausdenken.

....also ich persönlich steh ja gar nicht auf sowas. Weil ich nämlich immer
so schlecht organisiert bin, dass ich das nie finde, wenn ich es suche - von
der warte würde ich mich total freuen, wenn es anders wäre. Aber es zwingt
einen halt dazu gewisse Mindeststandards und Gebote einzuhalten. Wobei man
halt auch erwähnen sollte, dass sich die Hoster damit eine halbe
Benutzerverwaltung sparen ;p

Grüße
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.
Johannes Mueller [ Do, 18 Oktober 2007 23:03 ] [ ID #1848470 ]

Re: SQL Injection: Schutz bei Login - welcher Weg

Johannes Mueller schrieb:
> Sollte nur heissen, nur weil Du keine Sonderzeichen benutzen darfst würde es
> dich wahrscheinlich nicht davon abhalten dich trotzdem anzumelden. Eventuell
> würdest du vielleicht aufstöhnen und dir an den kopf fassen, aber du würdest
> die Pille schlucken!

Muss halt die entsprechenden Sonderzeichen in meinem Passwort Generator
an- und abhaken. Wenn ich mich anmelden will tu ich das auch. Natürlich
hindert es mich nicht daran, aber das steht hier ja auch weniger zur
Debatte. ;)

> ...also ich persönlich steh ja gar nicht auf sowas. Weil ich nämlich immer
> so schlecht organisiert bin, dass ich das nie finde, wenn ich es suche - von
> der warte würde ich mich total freuen, wenn es anders wäre. Aber es zwingt
> einen halt dazu gewisse Mindeststandards und Gebote einzuhalten. Wobei man
> halt auch erwähnen sollte, dass sich die Hoster damit eine halbe
> Benutzerverwaltung sparen ;p

Mir ist sowas egal. Ich hab mein Passwort Manager für den ich mein
Master Passwort weiß und den ich immer dabei habe. Der besitzt alle
Passwörter jeder kleinen Seite oder Programm, bei dem ich angemeldet
bin. Was will man mehr. (Ich weiss, gleich kommt eine passende Antwort
darauf, was man noch so haben muss) :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/
Christoph Herrmann [ Do, 18 Oktober 2007 23:12 ] [ ID #1848471 ]
PHP » de.comp.lang.php.misc » SQL Injection: Schutz bei Login - welcher Weg

Vorheriges Thema: date bug?
Nächstes Thema: Was bedeutet dieser Fehler? (REG_EBRACK)