Problem mit Get-Variablen
mark
- php
Hallo alle zusammen!
Ich habe folgendes Problem!
Ich habe eine PHP-Site welche mir einen url.php mit verschieden Get-Elemente erstellt...
Dies ist die URL:
kml.php?command=buffer&radius=1000
Diese wird dann über JavaScript geladen und ruft wiederrum eine PHP seite auf welche nun mit den mitgschickten Get-Variablen verschieden SQL-Abfragen machen soll!
Hier meine Aufruf in der empfänger PHP-Site:
if ($_GET["command"]=="buffer"){
$radius = $_GET['radius'];
$gastro = "select g.name, askml(g.the_geom), g.plz, g.ort, g.strasse, g.hausnummer,
g.wirt, p.preis, t.getraenk, g.ruhe, g.telefon, g.email, g.hp
from gastro g, preis p, getraenke t where
Contains (buffer(transform(the_geom,31286),$radius),
transform(GeometryFromText ( 'POINT (15.445940 47.059043)',4326), 31286 ))";
Mein Problem ist: Mir kommt vor das nur die erste Get-Variable verspeichert bzw. ausgelesen werden kann!
Weiß irgendjemand woran das liegen könnte!
lg, Mark
Hallo mark,
Weiß irgendjemand woran das liegen könnte!
Vielleicht wird ja zeitweise wirklich nur ein Parameter übermittelt - unabhängig davon solltest Du in jedem Fall prüfen, ob $_GET['radius'] existiert und zum anderen ob es den gewünschten Inhalt (vermutlich eine Zahl) enthält.
Mit freundlichem Gruß
Micha
Moin!
Hier meine Aufruf in der empfänger PHP-Site:
if ($_GET["command"]=="buffer"){
$radius = $_GET['radius'];
$gastro = "select g.name, askml(g.the_geom), g.plz, g.ort, g.strasse, g.hausnummer,
g.wirt, p.preis, t.getraenk, g.ruhe, g.telefon, g.email, g.hp
from gastro g, preis p, getraenke t where
Contains (buffer(transform(the_geom,31286),$radius),
transform(GeometryFromText ( 'POINT (15.445940 47.059043)',4326), 31286 ))";
>
> Mein Problem ist: Mir kommt vor das nur die erste Get-Variable verspeichert bzw. ausgelesen werden kann!
Wir programmieren. Uns kommt nichts vor. Etwas ist oder es ist nicht.
1\. Überprüfe, was ankommt:
~~~php
<pre>
<?php print_r($_GET); ?>
</pre>
zeigt es Dir. http://php.net/manual/de/function.print-r.php
2. Dein Code ist gefährlich! Es besteht die Gefahr von "SQL-Injections"!
http://de.wikipedia.org/wiki/SQL-Injection
Besser:
# Datenbank-Ressource ist in $DB
if (isset ($_GET['command']) && $_GET['command']=='buffer' && isset($_GET['radius'])) {
$gastro = 'SELECT
`g`.`name`,
ASKML(`g`.`the_geom`),
`g`.`plz`,
`g`.`ort`,
`g`.`strasse`,
`g`.`hausnummer`,
`g`.`wirt`,
`p`.`preis`,
`t`.`getraenk`,
`g`.`ruhe`,
`g`.`telefon`,
`g`.`email`,
`g`.`hp`
FROM `gastro` AS `g`, `preis` AS `p`, `getraenke` AS `t`
WHERE CONTAINS (
BUFFER(TRANSFORM(`the_geom`,31286),
'.mysql_real_escape_string($DB, $_GET['radius']).'),
TRANSFORM(GeometryFromText ( \'POINT (15.445940 47.059043)\',4326), 31286 )
)';
}
/*
Wenn Du eine Zahl erwartest genügt statt "mysql_real_escape_string($_GET['radius'])"
auch: "($_GET['radius']*1)";
*/
http://php.net/manual/de/function.mysql-real-escape-string.php
Weiß irgendjemand woran das liegen könnte!
In Deinem Fall vermute ich einen "Typo".
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Moin!
Ändere
'.mysql_real_escape_string($DB, $_GET['radius']).'),
in:
'.mysql_real_escape_string($_GET['radius'],$DB).'),
Jaja...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Hi!
- Dein Code ist gefährlich! Es besteht die Gefahr von "SQL-Injections"!
http://de.wikipedia.org/wiki/SQL-Injection
Ja, aber du machst es auch nicht besser, denn du hast vergessen, den String in Anführungszeichen zu setzen. Aufgabe von mysql_real_escape_string() ist es, dass einige Zeichen so umgeschrieben werden, dass der String-Kontext nicht verlassen werden kann. Du hast ihn gar nicht erst eingeleitet.
'.mysql_real_escape_string($DB, $_GET['radius']).'),
''.mysql_real_escape_string($DB, $_GET['radius']).''),
Wenn Du eine Zahl erwartest genügt statt "mysql_real_escape_string($_GET['radius'])"
auch: "($_GET['radius']*1)";
Die Rechnerei macht die Intention weniger gut deutlich als das Verwenden von intval() oder floatval().
Lo!
Moin!
Du hast recht - aber nicht ganz: "besser" mache ich es schon (die injection wird zweifelsfrei verhindert), nur nicht "ideal richtig". Das hast Du dann getan.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Hi!
Du hast recht - aber nicht ganz: "besser" mache ich es schon (die injection wird zweifelsfrei verhindert), nur nicht "ideal richtig". Das hast Du dann getan.
Nein, mysql_real_escape_string() kann nicht zaubern. Hier geht es nicht um einen Unterschied wie zwischen "richtig" und "richtig plus elegant" sondern um "falsch" und "richtig". Das ist ja grade der Punkt, wenn du keinen String einleitest, muss ich mir als Angreifer keine Mühe machen, ihn zu verlassen, denn ich bin bereits im Anweisungsteil und kann sofort loslegen, nachdem ich ungehindert von mysql_real_escape_string() die Anweisungsteil beendet habe. Im konkreten Fall muss nur mit ein paar schließenden Klammern das CONTAINS() beendet werden, und anschließend kann man weitere Bedingungen hinzufügen (OR 1=1, um sich unberechtigterweise alles ausgeben zu lassen) oder mit UNION Abfragen anderer Tabellen (die mit den Passwörtern oder -hashes vielleicht) hinzufügen.
Lo!
Moin!
Das ist ja grade der Punkt, wenn du keinen String einleitest, muss ich mir als Angreifer keine Mühe machen, ihn zu verlassen, denn ich bin bereits im Anweisungsteil und kann sofort loslegen, nachdem ich ungehindert von mysql_real_escape_string() die Anweisungsteil beendet habe. Im konkreten Fall muss nur mit ein paar schließenden Klammern das CONTAINS() beendet werden, und anschließend kann man weitere Bedingungen hinzufügen (OR 1=1, um sich unberechtigterweise alles ausgeben zu lassen) oder mit UNION Abfragen anderer Tabellen (die mit den Passwörtern oder -hashes vielleicht) hinzufügen.
Du hast damit vollständig recht. Ich hatte mich im Kontext der Frage und wegen der eigentlich erwarteten Zahl vollständig verrannt und keinen String eingeleitet.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
Hi!
Du hast damit vollständig recht. Ich hatte mich im Kontext der Frage und wegen der eigentlich erwarteten Zahl vollständig verrannt und keinen String eingeleitet.
Da das Thema ...-Injection / Kontextwechsel an sich immer wieder gern unbeachtet gelassen wird und auch gelegentlich das Zahlenproblem falsch angegangen wird, habe ich während deiner Forumsabstinenzzeit mal was vorbereitet:
Allgemein: Kontextwechsel erkennen und behandeln
Konkret: Zahlen im (My)SQL-Statement
Lo!