[php] vreemde tekens in url

[mac-er]

Hallo,

Ik ben aan een bepaald script bezig dat we hier intern zullen gaan gebruiken.

Hierbij zijn php pagina's die mssql data laten zien, maar het is ook mogelijk naar een andere pagina te gaan voor b.v. de query uit te lezen, of om de query nogmaals uit te voeren waarna er een excel bestand wordt gemaakt.

Kortom, de query moet met een link naar een andere pagina worden meegestuurd.

De query hard meesturen door b.v. doelpagina.php?query=<en hier de query> is natuurlijk niet verstandig door vreemde tekens die er in voor kunnen komen.

Daarom gebruik ik de functie base64_encode(<hier de query>) om de data te coderen en zo mee te sturen, hierna kan ik deze met get uitlezen en decoderen.

Probleem is nu alleen dat er nu bij sommige query's na het coderen ervan ook tekens als = in voorkomen waardoor het alsnog mis gaat. Wat kan ik nu het beste doen om via een simpele link toch die query mee te sturen?

Ik zeg wel alvast erbij dat jullie mijn oplossing waarschijnlijk niet bepaald veilig zullen vinden omdat zo de query kan worden aangepast. Dat klopt, maar dat maakt in ons geval totaal niks uit. Het is namelijk een interne site waar maar enkele medewerkers bij kunnen komen, en diegene mogen alle data uit de hele database inkijken. Verder kunnen ze niks aanpassen omdat de database user alleen maar leesrechten heeft.

Ik heb me wel al vanalles zitten te bedenken, zoals htmlentities en om dit als post ipv. get te sturen, maar ik denk dat het dan al snel toch wat te gecompliceerd gaat worden. En ik wil dit zo simpel mogelijk oplossen omdat dit ook duidelijk moet zijn naar enkele collega's met amper PHP kennis.

[Osiris]

urlencode()?

[Guillome]

Kan je niet de query in een database opslaan? In een tijdelijke tabel, en dan de ID van dat record meesturen.
Of in cookie of sessie, maar dat is ook niet echt ju van het.

[ReseTTim]

ik ben benieuwd naar jou reden om een sql regel via de adresbalk te sturen. er zijn diverse andere oplossingen voor, bijv opsplitsen in query=insert&table=blaat&values = x. maar dit is ook niet mooi!

ik ben benieuwd naar jou redenering waarom je zo een query gaat aanroepen ipv bijv een functie.

en collega's met amper / geen php kennis, dan is de vraag wil je het wel zo maken dat zij er wat mee kunnen?

[MueR]

Je wil geen queries in je url opnemen. Dat is al geprobeerd en dat faalde.

[Cartman!]

Misschien moet je eerst begrijpen waarom er soms een = toegevoegd wordt bij base64_encode. Waarom zou je een bepaalde encoding gaan gebruiken als je niet weet hoe het werkt?

Verder ben ook wel benieuwd naar waarom je queries wil vervoeren via een GET-var. Ik hoop dat je rechten van de gebruikte user in orde zijn, anders is het natuurlijk wachten op problemen.

[Kalentum]

Cartman! schreef op maandag 05 juli 2010 @ 16:13:
Verder ben ook wel benieuwd naar waarom je queries wil vervoeren via een GET-var. Ik hoop dat je rechten van de gebruikte user in orde zijn, anders is het natuurlijk wachten op problemen.

Hij wil de query op een later moment nog eens gebruiken.

Verder: gebruik POST en sla voor het vervolg de query op in een sessie of evt in een database.

[mac-er]

Ik weet het, dit is niet de meest verstandige oplossing, maar daar heb ik wel redenen voor. Om eerlijk te zijn zou ik dit in mijn andere paketten ook zeker nooit gebruiken!

Bedankt iig. voor de hulp, urlencode did the trick!

[TJHeuvel]

MueR schreef op maandag 05 juli 2010 @ 15:59:
Je wil geen queries in je url opnemen. Dat is al geprobeerd en dat faalde.

Je wilt even het hele bericht doorlezen:

Ik zeg wel alvast erbij dat jullie mijn oplossing waarschijnlijk niet bepaald veilig zullen vinden omdat zo de query kan worden aangepast. Dat klopt, maar dat maakt in ons geval totaal niks uit. Het is namelijk een interne site waar maar enkele medewerkers bij kunnen komen, en diegene mogen alle data uit de hele database inkijken. Verder kunnen ze niks aanpassen omdat de database user alleen maar leesrechten heeft.

[LuCarD]

CyCloneNL schreef op maandag 05 juli 2010 @ 16:24:
[...]


Je wilt even het hele bericht doorlezen:


[...]

Maar dat betekent nog niet dat het goed is?

Het zal niet de eerste applicatie zijn die alleen voor intern is ontwikkeld. Nadat het management het gezien heeft het zo mooi vinden en in al hun wijsheid ook maar besluit voor klanten open te stellen. Naderhand extra beveiliging toevoegen is lastiger dan gelijk goed programmeren.

Daarnaast word het meeste bedrijfsinformatie nog steeds gestolen door werknemers en niet door klanten.

[TJHeuvel]

Nee, maar het geeft wel aan dat karstenmeijers dit risico al overwegen heeft, en de gevaren begrijpt. Om nou alleen maar te roepen `dat is dom, valideer je input` voegt dan vrij weinig toe.

[YopY]

karstenmeijers schreef op maandag 05 juli 2010 @ 16:21:
Ik weet het, dit is niet de meest verstandige oplossing, maar daar heb ik wel redenen voor.

Zijn die redenen zodanig kosten- en/of tijdsintensief (ook op de langere duur, neem aan dat dit niet een tooltje is dat maar een week in gebruik is) dat je niet een uurtje hier extra aan kunt besteden om dit just af te handelen? Zou eerder kiezen voor een tabel met queries, zodat je gewoon URLs met IDtjes door kunt sturen - eventueel met parameters indien je queries hebt die andere params aan kunnen.

[ Voor 6% gewijzigd door YopY op 05-07-2010 16:47 ]

[MueR]

CyCloneNL schreef op maandag 05 juli 2010 @ 16:24:
Je wilt even het hele bericht doorlezen:

Leuk dat ie al heeft bedacht dat het niet verstandig is. Als ie dat al weet en met een heel simpele oplossing hier al omheen kan is het nog steeds een kulargument. Nu is het een interne applicatie, nu heeft de database user alleen leesrechten, nu mogen die paar collegas alles zien. Wie zegt dat iemand niet ooit op het heldere idee komt om die user ook voor andere dingen te gebruiken? Wie zegt dat er ooit iemand bij gaat komen die niet alles mag zien in de database?

Les 1 van prorgammeren: programmeer defensief. Die les moet je _nooit_ opzij schuiven. Ook niet voor interne applicaties. Scheelt achteraf een hoop gedoe. En laten we wel wezen, hoe veel moeite is het nou om een query tijdelijk op te slaan in een sessie danwel tabel? Met twee regels code heb je een manier van query transporteren die niet door iedereen aan te passen is. Om te roepen dat het toch niet uitmaakt, dat voegt pas niets toe, want iedereen hier weet dat het onzin is. Indien je dat niet weet moet je echt terug naar school.

[mac-er]

Ok, toch nog allemaal bedankt voor de reacties.

Ik zal dan inderdaad toch query's in een tijdelijke db op gaan slaan...

[Cartman!]

Begrijp je nu ook waarom base64_encode niet je oplossing was en waar die = vandaan kwamen? Klakkeloos de oplossing gebruiken zonder meer na te denken heb je niks aan.

[ACM]

Cartman! schreef op maandag 05 juli 2010 @ 19:37:
Begrijp je nu ook waarom base64_encode niet je oplossing was en waar die = vandaan kwamen? Klakkeloos de oplossing gebruiken zonder meer na te denken heb je niks aan.

base64 levert domweg twee karakters op die niet url-safe zijn (de + en de /), bovendien wordt het eind van de string met =-en aangevuld tot voldoende blokken. Die =-en kan je iig in het geval van php's base64-codering overigens gewoon weghalen en als je wat zinvols doet met de + en de / (bijv vervangen door _ en -, zoals base64url), dan kan je je base64-string gewoon gebruiken.
Desalniettemin is het altijd veiliger om daadwerkelijk de goede encodering te gebruiken (urlencode of rawurlencode in dit geval), ipv eentje die ook meestal zou moeten voldoen.

[Cartman!]

Goed gedaan, nu hoeft de TS zelf het niet meer op te zoeken

[!GN!T!ON]

Cartman! schreef op maandag 05 juli 2010 @ 22:31:
Goed gedaan, nu hoeft de TS zelf het niet meer op te zoeken

Maar ik heb er weer wat van geleerd, bedankt ACM

[FragFrog]

karstenmeijers schreef op maandag 05 juli 2010 @ 17:30:
Ok, toch nog allemaal bedankt voor de reacties.

Ik zal dan inderdaad toch query's in een tijdelijke db op gaan slaan...

Wellicht is in een sessie variabele makkelijker. In PHP kun je die erg eenvoudig uitlezen (sterker nog, simpeler zelfs dan een URL variabele die je eerst met unencoden) en het voorkomt dat iemand voor de grap een XSRF aanval uitvoert op een collega - sterker nog, een slimme aanvaller zou zo met een beetje geluk zelfs van buitenaf kwaadaardige queries kunnen uitvoeren (als de user tenminste ooit ook schrijfrechten krijgt).

!GN!T!ON schreef op woensdag 07 juli 2010 @ 14:00:
Maar ik heb er weer wat van geleerd, bedankt ACM

Idem

[ Voor 11% gewijzigd door FragFrog op 07-07-2010 14:18 ]