SQL-Injections abfangen

[goth]

Original geschrieben von wahsaga
- du ziehst mit deinem script zu einem andern hoster um, und vergisst dich zu vergewissern, ob es aktiviert ist.
- dein hoster deaktiviert es irgendwann (z.b. beim wechsel auf eine neue php-version), und vergisst bescheid zu sagen oder macht es zu spät.
- ...


zusammenfassung: du möchtest dich bei einem sicherheitsrelevanten thema nicht auf umgebungseinstellungen verlassen, die deiner kontrolle entzogen sind und sich nach belieben ändern können.
stattdessen möchtest du selbst für das notwendige maß an sicherheit sorgen, in dem du überall dort wo es angebracht ist, mysql_(real_)escape_string() verwendest.

Genau das ... ! Zudem bringt, soweit vorhanden die Verwendung von mysql_real_escape_string() zusätzlich noch ein korrektes Handling von Charactersets durch die MySQL mit sich ... (dafür der 2. Parameter) ...

Definierte Zustände sind im Script zu schaffen ... und nicht durch den Konfiguration einer PHP-Installation ... alles andere ist fahrlässig ... und bestenfall einem Script-Kiddy gemäß ... !

PS.: Fogel schreibt man mit V ... also Vogel ... !

[webstar85]

Original geschrieben von afogel
man kann sich ja funktionen schreiben, die überprüfen, ob magic_quotes_* on oder off ist....
Das ist für mich also kein Argument....

Also ist es keine reine INI Einstellung, sondern muss im Programm überprüft werden. Das gleiche macht man, wenn man sein Script so arbeiten lässt, dass magic_quotes_gpc off ist, nur halt für die entgegengesetzte Wirkung.

[afogel]

und gott schreibt man mit tt und ned mit th...

argh! das ist das gegenteil einer ordentlichen konfiguration!

Hier geht es ned darum, ob man sich darauf verlassen kann, ob es an ist, sondern ob es was hilft....und es hilft definitiv, wenn es an ist....wahsaga zeigt eindeutig wer heir der noob ist...

mfg afogel

[wahsaga]

Original geschrieben von afogel
Hier geht es ned darum, ob man sich darauf verlassen kann, ob es an ist, sondern ob es was hilft....und es hilft definitiv, wenn es an ist....wahsaga zeigt eindeutig wer heir der noob ist...

ja, schön - einigen wir uns darauf, dass es "was hilft", wenn der programmierer des scriptes ein spacko ist, und nicht weiss was er tut - womit wir dann wieder beim noob und bei dir wären.

[goth]

Original geschrieben von afogel
und gott schreibt man mit tt und ned mit th...

Da kannst Du mal sehen wie wenig Ahnung Du hast ... weil "Goth" schlichtweg mein Muzikstil ist ... !

[MelloPie]

OffTopic:

---

also mir würds helfen wenn mir einer n Bier aufmacht

---

Eure Diskussion is mal shit hoch zehn.

[MaxP0W3R]

Wo lernt man das zeug den *zu wahrsaga schau*

Ich hab einige Bücher gewälzt, einige Links angesehen und sicher ein fundiertes Wissen, aber sobald es dann ins Detail geht, fehlen mir genau Infos bzw. Erfahrungswerte.

Ich kann alles Programmieren, was mit PHP Möglich ist, aber ich hab sicher nicht die schnellsten, effizientesten und am leichtesten erweiterbaren Skripte, die man sich vorstellen kann, gescheige denn die sichersten.

Hat einer ein paar Links, zum rumstöbern ?

Die links aus dem Security Forum hier hab ich durch, ganz interressant aber sicher nicht alles was man iwssen muss

cya max

[asp2php]

also Leute, ihr geht ja immer von MySQL aus, doch SQL-Injection ist ein
wichtiges Thema, sobald man DB im Backend hat.

Da ich auch PHP-Newbie bin und MySQL nicht einsetze, weiss ich im Grunde
genommen nicht was diese magic_quote auf die DB macht (die steht bei
mir ohnehin auf off ).

Doch wenn man z.B. MS-SQL oder Oracle oder ... als Backend und eine Suchformular hat, muss man unbedingt z.B. diesen Fall abfangen:

Eingabe des Suchbegriffes im Formular: bla bla; delete from tblName

Hilft denn was wenn man magic_quote_dingsbums auf on setzt?
Wie macht ihr dann hier?
Irgendwannwirds auch soweit sein, dass MySQL Stappelabfrage
bearbeiten kann, was wäre dann?

Ich machs immer manuell die Überprüfung bevor ich irgendeine
Usereingabe zum DB sende. Und somit stehe ich immer gut da, egal
wasfür Backend eingesetzt ist, und egal, wasfür Einstellung der
Provider hat

[afogel]

wenn magic_quotes_runtime auf on steht, werden alle werte die ein ' oder eine " beinhalten escaped. Das heißt, dass sie z.B. in '' oder in \" umgewandelt werden. (eigtl. genau das gleiche wie mit escape_string...o.ä.)

Wenn du immer manuell überprüfst, ist das sicherlich ein gute Lösung.

Die Art der Datenbank spielt keine Rolle.

Ich will aber nochmal zurück zur vorherigen Diskussion kommen.

und bestenfall einem Script-Kiddy gemäß ... !

du siehst selber ein, dass es was hilft? wir haben nicht darüber gesprochen wie professionell das ganze ist, sondern ob es überhaupt was hilft.

ja, schön - einigen wir uns darauf, dass es "was hilft", wenn der programmierer des scriptes ein spacko ist, und nicht weiss was er tut - womit wir dann wieder beim noob und bei dir wären.

traurig, dass ein so großes Forum wie dieses hier, solche erbärmlichen Leute als Moderatoren nötig hat.

Seh einfach ein, dass du mal nicht Recht hattest, und här auf hier den großen raushängen zu lassen...damit wäre vielen geholfen...

mfg afogel

[meikel]

Original geschrieben von afogel
wenn magic_quotes_runtime auf on steht, werden alle werte die ein ' oder eine " beinhalten escaped. Das heißt, dass sie z.B. in '' oder in \" umgewandelt werden. (eigtl. genau das gleiche wie mit escape_string...o.ä.)

Wenn du immer manuell überprüfst, ist das sicherlich ein gute Lösung.

Es ist nur ein Lösungsansatz.

# $_REQUEST korrigieren:
unset ($_REQUEST);
$_REQUEST = ($_SERVER['REQUEST_METHOD'] == 'GET') ? $_GET : $_POST;

# ab jetzt ausschließlich $_REQUEST verwenden

# ' und " maskieren

if (!ini_get('magic_quotes_gpc')) 
 foreach ($_REQUEST as $key => $val) $_REQUEST[$key] = addslashes ($val); 

Im Weiteren:
alle Variablen auf erlaubte Inhalte kontrollieren.
selbst Strings dürfen außer \t, \n und \r keine Zeichen < 32 enthalten

In Variablen, die in MySQL Strings verwendet werden, sollte zusätzlich noch das % maskiert werden.

[meikel]

Zusatz:

In Variablen, die in MySQL Strings verwendet werden, sollte zusätzlich noch das % maskiert werden. Da MySQL ebenfalls automatisches Typecasting beherrscht, sollte man grundsätzlich alle Variablenwerte mit '$var' einrahmen.

[marc75]

mysql escape string

dclp: sql Injection

[wahsaga]

Original geschrieben von afogel
du siehst selber ein, dass es was hilft? wir haben nicht darüber gesprochen wie professionell das ganze ist, sondern ob es überhaupt was hilft.

wir haben auch darüber gesprochen, ob man sich darauf verlassen sollte.

Seh einfach ein, dass du mal nicht Recht hattest

ich behaupte nach wie vor, recht zu haben mit der behauptung, dass man sich eben nicht auf magic_quotes_gpc verlassen sollte, wenn man daten in eine mysql-query übernimmt, sondern dass man dazu die funktionen nutzen sollte, die extra dafür bereitgestellt werden - und du bist so ziemlich der einzige hier, der das nicht einsehen will, und stattdessen immer noch versucht, unkenntnis/faulheit des programmierers zu rechtfertigen.

[goth]

Dummheit passt besser ... !

[meikel]

Original geschrieben von marc75
mysql escape string

Das verhindert keine "bösen Bytes" im Textfenster (außer ", ' und %).

Die Variable muß schlicht und einfach auf ihren Inhalt geprüft werden, ob der dem Erwarteten entspricht, bevor sie (auch im einem SQL String) weiter verwurstet wird. Wenn die Variable maskiert wurde, dürfen sich darin keine Zeichen < 32 befinden. Ausnahme: \t, \r und \n, wenn es sich um ein Textarea handelt.

Wenn Du Dir schon mal die GET Strings angeguckt hast, mit denen zB. via Gallery der Webserver geknackt werden kann, wirst Du einsehen, daß es Augenwischerei ist, sich ausschließlich auf addslashes () u/omysql_escape_string zu verlassen.