Sie befinden sich hier im Forenarchiv von phpforum.de wenn Sie direkt ins Forum möchten, klicken Sie bitte hier. Zur Startseite kommen Sie hier.

Kurz & Kanckig: Wie verhindere ich SQL-Injectionen?

Hi! Jaja, ich weiss, schon zum 400'000xMal beantwortet worden. Aber wie es scheint gibt es sehr viele varianten um SQL-Injectionen zu verhindern. Ich hab keinen blassen was von allem jetzt eine SQL-Injection absolut unöglich macht.

Also bitte kurz & knackig: Was mach ich mit einer Variable bevor ich sie in die DB schreibe?

Hier gehts zum Orginal Eintrag "Kurz & Kanckig: Wie verhindere ich SQL-Injectionen?" im Forum

Antworten

Zitat:
Badie postete
Jaja, ich weiss, schon zum 400'000xMal beantwortet worden.
Und warum sollten wir dann die 400.001ste Antwort dazu auch noch geben? Also siehe: Klick mich

*** Nobody ***


2.

Kurz und Knackig:

Reguläre Ausdrücke in Verbindung mit MySQL_Real_Espace sollte das schlimmste verhindern.

So...hab ich was vergessen?


3.

Ne, da findet man des eben nirgends kurz & knackig....

Ich möchst eigentlich nur so wissen:

Code:                   In Zwischenablage kopieren (nur IE)
1">

edit:

aha! Von dem hab ich auch schon mal irgendwo gelesen. Also
müsste da jetzt noch stehen:

Code:                   In Zwischenablage kopieren (nur IE)
2">

Stimmt das so?
Ist eine Injection so absolut unmöglich?


4.

[doc]mysql_real_escape_string[/doc]
*** Nobody ***


5.

öhm, wieso setzt der escape_string eigentlich backslashes? Was hat des denn für einen Sinn?
Würde eine Injection denn nicht auch verwindert wenn man alle ' im Text durch diese HTML ersatzteiler die mit & anfangen ersetzt?


6.

Boah, also nun denk mal für ein Fünferl mit:

Es kann ja wohl sein, dass jemand gerne auch mal ein ' oder " in der Datenbank eintragen würde und eben NICHT möchte, dass das rausgefiltert wird und das vielleicht auch NICHT als HTML speichern will. Wenn Du mysql_escape_string anwendest werden Strings GENAU SO in die Datenbank eingetragen, wie sie vorher waren, und das will man ja meistens.


7.

hmmm..... '$gedicht' da ist $gedicht ja mit 2 ' eingepackt. die gefahr, dass aber das ' frühzeitig geschlossen wird, würde dann ja verhindert wenn man alle ' im Text durch die & variante erstetzen würde.

Aber ich lass das mal bleiben. mysql_real_escape_string() ist genau das was ich suche.


Danke - >Keine weiteren Fragen - >Super Forum!:):):)


MfG Badie


8.

Zitat:
Also bitte kurz & knackig: Was mach ich mit einer Variable bevor ich sie in die DB schreibe?
Kurz und knackig: indem Du die Angabe "interpretierst". Egal wie aufwändig, egal wie "schlapp". Einfach nicht ungeprüft übernehmen, sondern den (vom bösen bösen Anwender) eingegeben "Code" auf egal welche Weise "intepretieren"; "auswerten" oder wie auch immer.

Die Möglichkeit, nur "mysql_real_escape_string" zu benutzen, ist semantisch die blödeste: sie kümmert sich "nur" im Infektionsvermeidung. Das ist nur das Minimum und geht davon aus, dass der Endanwender SQL beherrscht - was sicherlich nicht unbedingt der Fall sein muss.

In aller Regel sollten Benutzerinterfaces komfortabler sein als "natives SQL". Und schon brauchst Du eine "Umsetzung" der Eingabe in SQL-Code. Womit automatisch eine SQL-Injection verhindert wird.


9.

@Rana: Es ging darum, SQL-Injections zu vermeiden. Da ist ein mysql_escape_string genau die richtige Methode, da gibts es doch nichts dran rumzumäkeln. Wenn ich einen Benutzer Freitext eingeben lasse, dann muss ich da nichts mehr "interpretieren" oder aufbereiten...


10.

Zitat:
Wenn ich einen Benutzer Freitext eingeben lasse, dann muss ich da nichts mehr "interpretieren" oder aufbereiten...
Wenn. Diesen Fall hatte ich ja eingeschlossen. Was ich aber (in den meisten Fällen) für eine schlechte "API" halte, denn natives SQL ist nur wenig endbenutzerfreundlich. Vielleicht für Admins geeignet, aber nicht für "normale" 0815-Internetbenutzer.


11.

Hä? Wovon sprichst Du, Rana? Ich glaub, Du bist diesmal auf dem echt falschen Dampfer ;)


12.

Wie wärs denn mit Prepared Statements? ;)


13.

Stimmt es, dass real_excape_string nur in sprintf() funktioniert?


14.

Nein.


15.

kann ich es also auch so machen wie ich das gesagt habe?


16.

Ja.


17.

Hab noch ne ähnliche Frage:

da sql-injectionen nun verhindert werden, gehts jetzt denn sonstigen einschleusungen wie z.B. html code an den Kragen.

Wie verhinderte ich es am besten solche einschleusungen?

ist eine solche einschleusung schon verhindert, wenn ich alle < > duch &lt; &gt; ersetze?

net oder?

wenn man z.B. eine url für n Bild angeben könnte, da könnt man ja schonmal auf die Idee kommen anstatt z.B

http://meineHomepage/bilder/meinBild.jpg

folgendes einzugeben:

http://meineHomepage.ch/bilder/meinBild.jpg" onClick="location='http://meineHomepage.ch'

Hab des zwar noch net ausprobiert, aber ich bin mir ziemlich sicher, dass das funtzen würde. Wie verhindert man solche ärgerlichen sachen?


18.

[doc]strip_tags[/doc]


19.

@Rana: Das ist aber alles andere als benutzerfreundlich. Manchmal will man ja die Zeichen < und > auch in mathematischen Zusammenhängen oder als grafisches Element benutzen. Besser wäre es, bei der Ausgabe von Text

[doc]htmlentities[/doc]

anzuwenden, dann erscheint der Text auf dem Bildschirm genauso wieder, wie der Benutzer ihn eingegeben hat und die Verwunderung beim User ist am kleinsten.


20.

Hallo !

Zum Thema sql-injection: Ist folgendes sinvoll ?

Nehmen wir an, es soll die variable $ort per Url übergeben werden, z.b. im Menü, um davonabhängig Daten aus der DB zuholen. Wäre sowas bei wenigen Belegungsmöglichkeiten von $ort sinvoll ?.
Code:                   In Zwischenablage kopieren (nur IE)
3">

Und was ist, wenn ich in einer DB statt vortlaufende Personalnummern nur deren Hashwerte speicher und die Personalnummer via GET-Variable einlese
Code:                   In Zwischenablage kopieren (nur IE)
4">

Ist in einem der beiden Fälle noch etwas zubeachten bzgl. sql injection ?
Ich habe gehört, das md5 Kollisionen erzeugen kann, könnte es also sein, das im 2ten beispiel 2 verschiedene personalnummern den gleichen Hash erzeugen ? Dass könnte ja beim Eintrag der Daten in die DB abgefangen bzw geprüft werden.


21.

[quote]Toxo postete
Code:                   In Zwischenablage kopieren (nur IE)
5">

[/quote] Genau solcher Code öffnet SQL-Injections Tür und Tor. Du übernimmst die $_GET Variable ungeprüft. Ein potentieller Angreifer braucht nur die URL ein wenig anzupassen und schon hättest du ein Problem...

Ich finde den Guide auf der MySQL Seite sehr gut - vielleicht liest du dich mal ein (ist aber auf englisch) http://dev.mysql.com/tech-resources/articles/guide-to-php-security-ch3.pdf

Gruß Thorsten


22.

ich übernehme die $_GET Variable ungeprüft, das stimmt, die Überprüfung entfällt, da ich nur Variablen benutze, für die das assoziative Array $ort[] einen Eintrag besitzt. Ansonsten, d.h. wenn die GET-Variable manipuliert wurde, ist die Variable $sqlort leer und die sql-abfrage wird nicht ausgeführt, also zum bessern Verständnis:
Code:                   In Zwischenablage kopieren (nur IE)
6">

Es geht mir in beiden Fällen darum, "direkt" mit den GET (das selbe gilt natürlich auch für POST) Variablen zuarbeiten, aber trotzdem sql-injection zuverhindern.


23.

Grundsätzlich muss es $array['wert'] heißen und nicht $array[wert].

Davon abgesehen ist es natürlich immer eine gute Idee, für Variablen auch nur die Werte zuzulassen, die auch gültig sind. Allerdings würde ich mir das doppelte Ausschreiben der Städte sparen und z.B. [doc]in_array[/doc] verwenden:

Wenn $_GET[...] in Array, dann kann es benutzt werden.

Trotzdem ist die Verwendung von mysql_escape_string danach nicht falsch, sondern vielleicht noch nützlich.

Das mit MD5 ist richtig: Theoretisch kann zu zwei verschiedenen Zahlen derselbe Hashwert erzeugt werden. MD5 wurde zwar so angelegt, dass das möglichst unwahrscheinlich ist, aber ausschließen lässt es sich nicht.


24.

Besten Dank !
Zitat:
oimel posteteGrundsätzlich muss es $array['wert'] heißen und nicht $array[wert].

Stimmt natürlich!
Zitat:
Allerdings würde ich mir das doppelte Ausschreiben der Städte sparen und z.B. in_array verwenden:
Wenn $_GET[...] in Array, dann kann es benutzt werden.

Da hast Du recht. Aber wenn ich nicht in_array verwende, könnte ich im Array direkt noch andere Bedingungen stellen, z.b. wenn die $GET-Variable etwas über einen Menüpunkt aussagt o.ä.
z.b.
Code:                   In Zwischenablage kopieren (nur IE)
7">

Daher hab ich das Beispiel recht allgemeingültig gehalten.
Zitat:
Das mit MD5 ist richtig: Theoretisch kann zu zwei verschiedenen Zahlen derselbe Hashwert erzeugt werden. MD5 wurde zwar so angelegt, dass das möglichst unwahrscheinlich ist, aber ausschließen lässt es sich nicht.
Ok, falls ich das irgendwann mal einsetzen sollte, werde ich einfach nachsehen, ob ein Hash schon belegt ist und in dem Fall die entsprechende ID überspringen. Danke fürs Feedback !


25.

[quote]Toxo postete
Da hast Du recht. Aber wenn ich nicht in_array verwende, könnte ich im Array direkt noch andere Bedingungen stellen, z.b. wenn die $GET-Variable etwas über einen Menüpunkt aussagt o.ä.
z.b.
Code:                   In Zwischenablage kopieren (nur IE)
8">

[/quote] Naja, ist ist dann aber schon eine ziemliche quick&dirty-Lösung. Ich bin immer ein ziemlicher Fan davon, immer nur genau so viel Arbeit zu machen, wie im Moment unbedingt notwendig ist, ohne sich die Zukunft zu verbauen ;)


Hier gehts zum Orginal Eintrag "Kurz & Kanckig: Wie verhindere ich SQL-Injectionen?" im Forum
 
phpforum.de | Impressum