[PHP] Variabele doorgeven, non-visible in URL

[McKaamos]

Hoi allemaal,

Ik ben op het moment bezig aan een website-je voor mezelf.
Doe vannalles met PHP en MySQL enzo..

Anyway, het menu wordt opgebouwd door een tabel te lezen. Elke row heeft een ID veld.
Dat ID wordt gebruikt om een link te maken, en dan via $_GET wordt het doorgegeven.
for example:

HTML:

<A Href="./index.php?pageid=10">Dit is een link naar pagina 10</A>

In PHP wordt dat dan weer afgevangen, en gecontroleerd of het wel klopt (is_numeric enzo) en dan wordt een tabel met een overeenkomstig nummer geopend in de database, waar dan weer de inhoud van de nieuwe pagina staat.

Het probleem is alleen dat je in de adresbalk kan zien dat pageid=10 wordt opgeroepen.
Ik heb het idee dat dat een beetje uitnodigend is voor scriptkiddies e.d. om een (sql?) code injection te proberen oid.

Is het ook mogelijk om het onzichtbaar te doen, zonder enorm lastige constructies?
Via $_POST is wel een optie, maar hoe krijg ik een link zo gek om de waarden via $_POST mee te nemen ipv $_GET?

[MTWZZ]

Als je gebruik kunt maken van cookies dan kun je aan de gang met sessions.
Overigens had je dit ook wel op de PHP site kunnen vinden IMHO.

[McKaamos]

mjah, ok, sessions en koekjes ben ik nog niet in thuis... kan ik me in gaan inlezen ofcourse, maar on the other hand, sommige mensen schakelen cookies uit en dan kom je nogsteeds nergens...

[Bosmonster]

Ja het is mogelijk, maar neit zonder problemen. Je kunt POST'en of het opslaan in een sessie/cookie.

De vraag is waarom? Je moet zorgen dat er geen beveiligingsgaten in je site zitten, anders is het niet zo'n probleem dat je id's gewoon zichtbaar zijn (dat zijn ze op zo'n beetje iedere website).

Hierboven in het forum zie je toch ook gewoon de ID staan?

[Verwijderd]

via post is natuurlijk helemaal geen optie. Hoe kan je dan ooit deeplinken naar een pagina?
als jij je script gewoon goed schrijft hoe je niet bang te zijn voor SQL injection (klepel).

[Voutloos]

Het moet gewoon robuust werken en als je altijd je user input grondig checkt kan er weinig mis gaan. Je linkjes obfuscaten is ook een beetje dubieus, het maakt je navigatie onhelder en je pagina ook lastiger te doorgronden voor zoekmachines.
Heldere navigatie is belangrijker dan het voorkomen van een parameter welke je toch veilig weet af te vangen...

[Bosmonster]

Verwijderd schreef op woensdag 08 februari 2006 @ 13:51:
via post is natuurlijk helemaal geen optie. Hoe kan je dan ooit deeplinken naar een pagina?
als jij je script gewoon goed schrijft hoe je niet bang te zijn voor SQL injection (klepel).

POST, sessies of cookies, het is allemaal een bagger 'oplossing'.

Het probleem is niet dat de id's zichtbaar zijn, maar dat ie blijkbaar niet weet hoe die het dicht moet timmeren

[McKaamos]

Bosmonster schreef op woensdag 08 februari 2006 @ 13:49:
Ja het is mogelijk, maar neit zonder problemen. Je kunt POST'en of het opslaan in een sessie/cookie.

De vraag is waarom? Je moet zorgen dat er geen beveiligingsgaten in je site zitten, anders is het niet zo'n probleem dat je id's gewoon zichtbaar zijn (dat zijn ze op zo'n beetje iedere website).

Hierboven in het forum zie je toch ook gewoon de ID staan?

good point...
dan ga ik gewoon zorgen dat er geen rotzooi in gegooid kan worden. netjes afvangen e.d.

btw, ik heb ff zitten kijken naar cookies, maar die moet je sturen voor het document.
hoe krijg ik die link zo gek dat er cookiewaarde wordt gestuurd?
* McKaamos don't get it

$_POST is nog wel te doen.. elke link een form geven should work, right?

Bosmonster schreef op woensdag 08 februari 2006 @ 13:53:
[...]


POST, sessies of cookies, het is allemaal een bagger 'oplossing'.

Het probleem is niet dat de id's zichtbaar zijn, maar dat ie blijkbaar niet weet hoe die het dicht moet timmeren

dichttimmeren moet opzich niet zo'n probleem zijn hoor... vooral als het om van die kleine waarden gaat... hooguit een paar tekens. gewoon letten op is_numeric en de lengte truncaten zou al een hoop moeten doen afaik...

Voutloos schreef op woensdag 08 februari 2006 @ 13:53:
Het moet gewoon robuust werken en als je altijd je user input grondig checkt kan er weinig mis gaan. Je linkjes obfuscaten is ook een beetje dubieus, het maakt je navigatie onhelder en je pagina ook lastiger te doorgronden voor zoekmachines.
Heldere navigatie is belangrijker dan het voorkomen van een parameter welke je toch veilig weet af te vangen...

point taken.
dat een search indexing bot de site normaal kan doorzoeken is belangrijk.

maargoed, twas maar een vraag enzo... vroeg me af of het makkelijk te doen was...
deeplinking is voor mij geen probleem, maar stel dat ik een keer een site moet maken ergens voor waar dat wel een probleem oplevert, dan is het wel handig om te weten.

de vraag kwam gewoon bij me op tijdens het schrijven van de code

[ Voor 52% gewijzigd door McKaamos op 08-02-2006 14:00 ]

[arieleks]

McKaamos schreef op woensdag 08 februari 2006 @ 13:55:
[...]
$_POST is nog wel te doen.. elke link een form geven should work, right?
[...]

Als je toch voor $_POST gaat, kun je net zo goed het hele arsenaal ranzigheid uit de kast trekken : 1 form met een hidden input. Deze hidden kun je dan vullen en submitten met JavaScript.

[ Voor 51% gewijzigd door arieleks op 08-02-2006 14:06 ]

[Verwijderd]

Waarom zet je die gegevens niet tijdelijk in een ander tabel gekopeld aan een session id en dan wordt bij de laatste pagina de gegevens gekopieerd naar de goede tabel.

[Reinder83]

Ook al gebruik je een form (POST) dan kan je in de sourcecode altijd nog achterhalen waar de link heen verwijst, alleen zie je het dan niet direct in de statusbar.. oftewel je bereikt er niets mee.

ik vraagt me uberhaupt af waarom je het ID wilt hiden.. lijkt mij onlogisch?

[McKaamos]

Reinder83 schreef op woensdag 08 februari 2006 @ 14:21:
Ook al gebruik je een form (POST) dan kan je in de sourcecode altijd nog achterhalen waar de link heen verwijst, alleen zie je het dan niet direct in de statusbar.. oftewel je bereikt er niets mee.

ik vraagt me uberhaupt af waarom je het ID wilt hiden.. lijkt mij onlogisch?

voor mijn eigen site hoeft het ook niet, ik vroeg het me gewoon af.

maar stel dat ik het een keer nodig heb... het is gewoon een handig anti-deeplink techniekje imho...

Verwijderd schreef op woensdag 08 februari 2006 @ 14:20:
Waarom zet je die gegevens niet tijdelijk in een ander tabel gekopeld aan een session id en dan wordt bij de laatste pagina de gegevens gekopieerd naar de goede tabel.

Das idd wel een optie... maar voor een grote site lijkt me dat erg onhandig... gaat nogal wat database verwerking in zitten afaik, en als je een paar honderd bezoekers tegelijk hebt is dat niet bevorderlijk voor de snelheid.

[ Voor 32% gewijzigd door McKaamos op 08-02-2006 14:28 ]

[Bosmonster]

McKaamos schreef op woensdag 08 februari 2006 @ 14:27:
[...]


voor mijn eigen site hoeft het ook niet, ik vroeg het me gewoon af.

maar stel dat ik het een keer nodig heb... het is gewoon een handig anti-deeplink techniekje imho...

'handig'

Het zorgt ervoor dat je javascript en/of cookies nodig hebt en je browserfunctionaliteit (bookmarken, history (back/forward)) werken allemaal niet meer..

tis maar wat je 'handig' noemt

[ Voor 3% gewijzigd door Bosmonster op 08-02-2006 14:28 ]

[Verwijderd]

Ik zie echt het probleem niet... As said, ik zie hier in de url ook al in de URL een ID staan van het topic.

Als je gewoon checkt of het numeric is, kan hier helemaal geen SQL Injection plaatsvinden IMHO.

/Edit: waarom zou je geen deeplinking willen? Enige wanneer je volgens mij geen deeplinking wil is bij plaatjes en daar is met bv je .htaccess (oid) wel iets anders aan te doen.

[ Voor 31% gewijzigd door Verwijderd op 08-02-2006 14:30 ]

[McKaamos]

Bosmonster schreef op woensdag 08 februari 2006 @ 14:28:
[...]


'handig'

Het zorgt ervoor dat je javascript en/of cookies nodig hebt en je browserfunctionaliteit (bookmarken, history (back/forward)) werken allemaal niet meer..

tis maar wat je 'handig' noemt

$_POST heeft javascript en cookies nodig
en daarnaast, met $_POST werken browser controls nog wel.

[frickY]

Mensen die schreeuwen dat je het via cookies dawel sessies moet doen, moeten beter lezen.
Tenzij je het in javascript wilt doen, kun je geen cookie zetten op het moment dat er op een link wordt geklikt zonder een request naar je server.

Gebruik gewoon de ID's in je URL. Zodra je al is_numeric() over de ID's trekt is injection niet meer mogelijk (via die variabele).

[Verwijderd]

frickY schreef op woensdag 08 februari 2006 @ 14:32:
Gebruik gewoon de ID's in je URL. Zodra je al is_numeric() over de ID's trekt is injection niet meer mogelijk (via die variabele).

Idd, dat zei ik ook al... Waarom zo moeilijk doen en iets anders proberen te verzinnen? Deeplinking is wel op een andere manier te blokkeren

[Verwijderd]

is_numeric is een handige functie, maar niet nodig in dit geval. Ik zou gewoon de waarde uit de request casten naar een integer. Op die manier "controleer" je net zo goed de waarde. Is je request geen getal, dan wordt er dus een row opgehaald met 0 als id, en die bestaat waarschijnlijk niet. En niet bestaande id's moet je toch al afhandelen, dus scheelt dat ook weer wat onnodige code.

[Verwijderd]

@Cheatah: Zo kan het ook. Zo doe ik het ook idd met een forum waar ik voor dev... Werkt prima

[Bosmonster]

McKaamos schreef op woensdag 08 februari 2006 @ 14:30:
[...]


$_POST heeft javascript en cookies nodig
en daarnaast, met $_POST werken browser controls nog wel.

Als je gewone links met POST wilt gaan versturen heb je inderdaad javascript nodig om het formulier te vullen en te versturen.

En met POST werken back/forward niet meer, aangezien je dan bij iedere pagina de melding krijgt om POST variabelen opnieuw te versturen. Bookmarken werkt ook niet meer, aangezien die geen postdata opslaan.

[Verwijderd]

Bosmonster schreef op woensdag 08 februari 2006 @ 14:42:

En met POST werken back/forward niet meer, aangezien je dan bij iedere pagina de melding krijgt om POST variabelen opnieuw te versturen. Bookmarken werkt ook niet meer, aangezien die geen postdata opslaan.

POST requests zijn er dan eigenlijk ook alleen maar om requests te doen waarbij informatie van de gebruiker op de server wordt opgeslagen (en eventueel om requests mee te doen die dermate complex zijn dat je anders een te achterlijke URL krijgt).

[Janoz]

Navigeren middels post variabelen heeft wel javascript nodig. Tenzij je van elke link een submit button maakt natuurlijk.

Wanneer je je navigatie met POST variabelen oplost werken je standaard controls niet of niet goed. Zoals in de HTTP specs te lezen is is een pagina die middels post opgeroepen wordt niet idempotent is. De gevolgen hiervan zijn bijvoorbeeld dat je de pagina niet op kunt slaan in je bookmarks. Daarnaast krijg je, zodra je op back drukt, de vraag of IE de ingevulde gegevens nog een keer op moet sturen.

[.oisyn]

Verwijderd schreef op woensdag 08 februari 2006 @ 14:41:
is_numeric is een handige functie, maar niet nodig in dit geval. Ik zou gewoon de waarde uit de request casten naar een integer.

Ook het casten naar int is niet nodig in dit geval. Ik zou de db gewoon het werk laten doen (en natuurlijk wel je input escapen! maar dat moet je sowieso al doen), dan zou je in een later stadium ook nog over kunnen gaan op strings als primary keys zonder je code aan te passen (ik zou niet weten waarom je dat zou willen veranderen, maar dat terzijde).

[Verwijderd]

.oisyn schreef op woensdag 08 februari 2006 @ 14:55:

Ook het casten naar int is niet nodig in dit geval. Ik zou de db gewoon het werk laten doen (en natuurlijk wel je input escapen! maar dat moet je sowieso al doen), dan zou je in een later stadium ook nog over kunnen gaan op strings als primary keys zonder je code aan te passen (ik zou niet weten waarom je dat zou willen veranderen, maar dat terzijde).

Daar ben ik het op zich mee eens. Maar gezien de "normale gang van zaken" bij de meeste PHP scripters (en dat is overal mysql_query aanroepen door de code heen) is dat niet de meest aan te raden oplossing. Wel als je dat helemaal hebt dichtgetimmerd door bijvoorbeeld prepared statements te gebruiken bij queries.

[.oisyn]

"helemaal dichtgetimmerd" vind ik lichtelijk overdreven. Het lijkt me handig om aan te leren dat je altijd mysql_escape_string aanroept op je variabelen voordat je ze in de query insert.

[Bosmonster]

.oisyn schreef op woensdag 08 februari 2006 @ 15:44:
"helemaal dichtgetimmerd" vind ik lichtelijk overdreven. Het lijkt me handig om aan te leren dat je altijd mysql_escape_string aanroept op je variabelen voordat je ze in de query insert.

This function became deprecated, do not use this function. Instead, use mysql_real_escape_string().

[.oisyn]

Jammer dat die alleen niet bestaat pre 4.3