nicht angemeldet
MySQL Query Übergabe sprengt URL in Adressleiste
Ich habe eine sehr sehr sehr lange Abfrage an eine MySQL-Datenbank, welche ich mittels
<form action="<? echo $PHP_SELF?>" method="get">
weitergebe.
Jetzt sprengt mir das natürlich immer die Adressanzeige im Browser.
Da steht dann z.B.
http://domain.tld/abfrage.php?query=select%20s.stammnummer%20KuNr,%20s.lfdnummer%20LfdNr,%20s.fallzaehler%20Fall,%20s.nachname%20Nachname,%20s.vorname%20Vorname,%20a.amt%20Amt,%20s.strasse%20Straße,%20s.plz%20PLZ,%20s.wohnort%20Wohnort,%20s.geburtsdatum%20Geburtsdatum%20from%20stammdaten%20s,%20amt%20a%20where%20s.amt_id%20=%20a.amt_id
;-) und ich bin wohl noch nicht fertig, glaube ich. Da fehlen z.B. noch weitere Sortier- und Filteroptionen, und wahrscheinlich muss ich auch noch andere Datenbanktabellen ansprechen. Das alles führt dann dazu, dass ich eine irre lange URL bekomme.
-
Hallo Verona,
eine Formularübergabe über POST könnte Dir helfen. Die unterliegt nämlich keinen generellen Längenrestriktionen.
Gruß
Eidgenosse
-
danke dir,
gibbet keine Möglichkeit, die URL-Anzeige zu beeinflussen. Es soll dann z.B. nur die $PHP_SELF da stehen und nicht die abfrage.php?blablablablabla.
Oder einfach alles nach dem "?" verschwinden lassen. Geht das? Ich stelle mir nämlich gerade einen User vor, der die URL sieht und sich wundert.
-
Hallo Verona,
ich verstehe Deine Frage nicht ganz. Wenn Du die Formulardaten mit POST übergibst, steht im Normalfall nichts hinter dem Fragezeichen.
Gruß
Eidgenosse
-
Hallo,
gibbet keine Möglichkeit, die URL-Anzeige zu beeinflussen. Es soll dann z.B. nur die $PHP_SELF da stehen und nicht die abfrage.php?blablablablabla.
Oder einfach alles nach dem "?" verschwinden lassen. Geht das? Ich stelle mir nämlich gerade einen User vor, der die URL sieht und sich wundert.lesen heisst das Zauberwort, denn "genau das macht" POST
in der URL steht nur noch die Zieladresse und die Daten werden im Body des headers weitergeben und sind somit für den Anwender nicht sichtbar!romy
--
DIE ROMY AUS L. AN DER P. SAGT DANKE UND AUF WIEDERSEHEN
->Alles ist gut wenn es aus Schokolade ist-
hio,
lesen heisst das Zauberwort, denn "genau das macht" POST
in der URL steht nur noch die Zieladresse und die Daten werden im Body des headers weitergeben und sind somit für den Anwender nicht sichtbar!Wieso sind sie nicht sichtbar? Einfach mal den Quelltext betrachten, dann das Formular speichern und beliebig rumfummeln und dann von lokal abschicken. Mal ein wenig mit "insert" und "delete" spielen und sich freuen wenn nix mehr geht auf der Seite ;)
So erreicht man keinen Schutz, auch den Referer zu prüfen (also woher kamen die POST-Daten) bringt 0,0, den kann man auch beliebig manipulieren, und sooo viel Ahnung brauchts dazu auch net.gl & hf
Thorsten
-
-
Vielleichts gehts ja auch mit dirname() oder so?
-
-
Hallo,
eine Formularübergabe über POST könnte Dir helfen. Die unterliegt nämlich keinen generellen Längenrestriktionen.
Auch Sicherheitstechnisch ist POST besser geeignet, da sonst jeder mitlesen und verändern kann was Du so an Daten zu übermitteln hast.
255 Zeichen kann GET glaube ich auch fehlerfrei übertragen (in bestimmten Fällen AFAIK auch mehr)
ciao
romy--
DIE ROMY AUS L. AN DER P. SAGT DANKE UND AUF WIEDERSEHEN
->Alles ist gut wenn es aus Schokolade ist-
Hallo Romy,
GET kann deutlich mehr als 255 Zeichen übertragen. Nach meiner Erinnerung kam es erst bei deutlich über Tausend Zeichen zu Problemen. Von welchen Parametern das abhängt, kann ich jedoch nicht sagen.
Gruß
Eidgenosse
-
Moin!
Auch Sicherheitstechnisch ist POST besser geeignet, da sonst jeder mitlesen und verändern kann was Du so an Daten zu übermitteln hast.
Diese Aussage ist falsch. Nur weil die GET-Daten in der URL erscheinen, heißt das noch lange nicht, dass man POST-Daten nicht auch mitlesen und verändern kann. Solange die Daten nicht verschlüsselt übertragen werden, sind beide Verfahren gleich unsicher. Bei GET hat man den leichten Vorteil, dass man die Daten direkt in der URL-Zeile ändern kann, bei POST müßte man (wenn man es sich leicht machen will) das Formular speichern und manipulieren (Schritt 1: Die Action-Angabe mit der kompletten URL des verarbeitenden Skriptes ausstatten, inkl. "http://").
255 Zeichen kann GET glaube ich auch fehlerfrei übertragen (in bestimmten Fällen AFAIK auch mehr)
Die Länge einer URL ist nirgendwo im HTTP-Standard begrenzt. Aber die verschiedenen Implementationen setzen Grenzen. Apache kriegt IIRC 8 KB GET-Daten verarbeitet - das ist schon recht viel. Manche Systeme sollen nicht mehr als 1 KB verarbeiten können. Bedenke auch, dass es nicht allein auf den verwendeten Originalserver ankommt, damit es funktioniert, sondern auch auf den verwendeten Browser _und_ alle dazwischenliegenden Proxy-Server.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
-
-
-
Jo Hallo Dir auch! Ich finds doch immer wieder toll wie hier einige das Forum begrüßen!
Ich habe eine sehr sehr sehr lange Abfrage an eine MySQL-Datenbank, welche ich mittels
<form action="<? echo $PHP_SELF?>" method="get">
Aua mit get... POST ist viiiiel sicherer! Soll denn jeder deine Abfragen sehen?
weitergebe.
Jetzt sprengt mir das natürlich immer die Adressanzeige im Browser.
Da steht dann z.B.
http://domain.tld/abfrage.php?query=select%20s.stammnummer%20KuNr,%20s.lfdnummer%20LfdNr,%20s.fallzaehler%20Fall,%20s.nachname%20Nachname,%20s.vorname%20Vorname,%20a.amt%20Amt,%20s.strasse%20Straße,%20s.plz%20PLZ,%20s.wohnort%20Wohnort,%20s.geburtsdatum%20Geburtsdatum%20from%20stammdaten%20s,%20amt%20a%20where%20s.amt_id%20=%20a.amt_id
;-) und ich bin wohl noch nicht fertig, glaube ich. Da fehlen z.B. noch weitere Sortier- und Filteroptionen, und wahrscheinlich muss ich auch noch andere Datenbanktabellen ansprechen. Das alles führt dann dazu, dass ich eine irre lange URL bekomme.
Ja dir auch einen netten Gruß
cg
-
hio,
Ich habe eine sehr sehr sehr lange Abfrage an eine MySQL-Datenbank, welche ich mittels
<form action="<? echo $PHP_SELF?>" method="get">
weitergebe.
Jetzt sprengt mir das natürlich immer die Adressanzeige im Browser.
Da steht dann z.B.
http://domain.tld/abfrage.php?query=select%20s.stammnummer%20KuNr,%20s.lfdnummer%20LfdNr,%20s.fallzaehler%20Fall,%20s.nachname%20Nachname,%20s.vorname%20Vorname,%20a.amt%20Amt,%20s.strasse%20Straße,%20s.plz%20PLZ,%20s.wohnort%20Wohnort,%20s.geburtsdatum%20Geburtsdatum%20from%20stammdaten%20s,%20amt%20a%20where%20s.amt_id%20=%20a.amt_id
irgendwie kann ich das Schema nicht so ganz 100% nachvollziehen, was würde den passieren wenn ich stattdesseb schreibe
http://domain.tld/abfrage.php?query=delete%20from%20tabellenname.imho ist es absoluter quatsch einen SQL-Query zu übergeben und den von einem Skript ausführen zu lassen. Und das spielt imho keine Rolle ob nun GET oder POST. Geb mir einfach mal deine Adresse und du brauchst das query-Problem nicht mehr lösen, mangels Datenbanktabellen ;) nene. Du solltest das anders lösen z.b.
http://domain.tld/abfrage.php?show=Kunden
und dann z.b.
<?phpif (isset($_GET["Kunden"]) AND $_GET["Kunden"])) {
$SQL = "SELECT .... ";
}das ist nun keine definitive Lösung, soll aber zeigen was um einiges sicher ist, nun können die Parameter beliebig manipuliert werden, _ohne_ das ich man gleich schlimmes befürchten muss ;)
Deine Filterfunktionen kannst du auch anhängen
http://domain.tld/abfrage.php?show=Kunden&start=0&limit=20 oder so.
Wie immer du willst, jedoch wichtig ist und bleibt, niemals Daten zu trauen die nicht von dir kommen! Niemals diese Daten direkt "ausführen" z.b. als SQL-query. Das kann dicke ins Auge gehen.gl & hf
Thorsten
-
hio,
noch ein kleiner Nachtrag,
;-) und ich bin wohl noch nicht fertig, glaube ich. Da fehlen z.B. noch weitere Sortier- und Filteroptionen, und wahrscheinlich muss ich auch noch andere Datenbanktabellen ansprechen. Das alles führt dann dazu, dass ich eine irre lange URL bekomme.
was hat den eine URL mit einer Datenbankabfrage und Datenbanktabellen zu tun? oder anders gefragt, warum bekommt man eine irre lange URL wenn man aus mehreren Datenbanktabellen auslesen will?
Kam mit gerade so, musste das mal fragen ;)
Ich denke, wie in meinem anderen posting, überlege dir nochmals wie weit du mit diesem Schema kommst, ich denke nicht sehr weit.gl & hf
Thorsten
-
irgendwie kann ich das Schema nicht so ganz 100% nachvollziehen, was würde den passieren wenn ich stattdesseb schreibe
http://domain.tld/abfrage.php?query=delete%20from%20tabellenname.Nun, ich würde sagen, du hättest meine Daten gelöscht. :-) Aua!
imho ist es absoluter quatsch einen SQL-Query zu übergeben und den von einem Skript ausführen zu lassen. Und das spielt imho keine Rolle ob nun GET oder POST. Geb mir einfach mal deine Adresse und du brauchst das query-Problem nicht mehr lösen, mangels Datenbanktabellen ;) nene. Du solltest das anders lösen z.b.
http://domain.tld/abfrage.php?show=Kunden
und dann z.b.
<?phpif (isset($_GET["Kunden"]) AND $_GET["Kunden"])) {
$SQL = "SELECT .... ";
}Stimmt, habe ich gemacht. Danke! Was ist denn, wenn sich dann jemand meine PHP-Datei anschaut? Dann kennt er die Struktur doch auch. Und query funktioniert trotzdem noch, oder?
Danke Verona
-
Hallo Verona,
Deine PHP-Datei kann sich aber nicht jeder beliebige Mensch, der am Internet hängt ansehen, sondern nur die, die Zugriff auf die Maschine haben. Zudem würde er dann zwar die Struktur der Datenbank kennen, aber keine bösen Manipulationen vornehmen können. Es geht halt nur, was Du vorher definiert hast.
Gruß
Eidgenosse
-
Unter Umständen kann es wünschenswert erscheinen, wenn der sql-string übertragen wird.
Abhängig von den Daten kann man den String ja auf "Badwords" untersuchen:
drop, delete, insert, update ...
und das Script nach dem Loggen aller verfügbaren Daten in den Heldentot schicken. Im Fall des Falles führt dies zu einem Fehler... aber die Daten bleiben unmanipuliert.
Dennoch bleibt auch dieses Verfahren ein Krücke, weil man dann die mySQL- Doku ziemlich genau auf schädigendes untersucht haben muss.
phpMyAdmin macht es übrigens genau so...
fastix
-
Moin!
Abhängig von den Daten kann man den String ja auf "Badwords" untersuchen:
drop, delete, insert, update ...
und das Script nach dem Loggen aller verfügbaren Daten in den Heldentot schicken. Im Fall des Falles führt dies zu einem Fehler... aber die Daten bleiben unmanipuliert.
Das ist aber doch ein ziemlicher Aufwand, weil man dann den SQL-String echt parsen muss - und zwar mit SQL-Logik. Es reicht nicht, zu gucken, ob irgendwo das Wort "delete" vorkommt. Wäre schön doof, wenn auf diese Weise englische Texte nicht in die Datenbank eingefügt werden könnten.
Dennoch bleibt auch dieses Verfahren ein Krücke, weil man dann die mySQL- Doku ziemlich genau auf schädigendes untersucht haben muss.
Außerdem muss man den SQL-Parser zumindest einigermaßen nachbauen - unnötiger Aufwand.
phpMyAdmin macht es übrigens genau so...
Nicht ganz. phpMyAdmin hat zwar eine badwords.txt, diese wird aber nur benutzt, um bei MySQL-Versionen kleiner als 3.23.06 zu prüfen, ob Tabellen- und Feldernamen aus reservierten Worten bestehen (das dürfte wohl ansonsten zu Fehlern führen). Es wird nicht geprüft, ob der SQL-String Sinn macht - würde bei einem SQL-Admin-Tool auch keinen Sinn ergeben, gewisse Befehle auszuklammern. Wenn ein Datenbankbenutzer (Benutzer im Sinne von "der User, als der sich das Skript verbindet") nichts löschen dürfen können soll (tolle Wortkombi ;) ), regelt man das am Besten über die entsprechenden Rechte dieses Datenbankuseraccount.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
-
-
-
-
-
Danke an alle!
Ich habe den Rat von Thorsten Steffen befolgt. Nur zur Info: Die Sache wird lokal installiert und auch nur von vorerst fünf Angestellten benutzt. Es ist natürlich wichtig, dass keiner unbewusst was löschen kann, aber absichtlich wird es hier keiner machen.
Gruß Verona