[PHP] $_POST van buitenaf afschermen

[GewoonNico]

Hallo,

Ik heb net iets getest, en het blijkt dat als je op je pc een formuliertje maakt dat post naar een website, die website dat formuliertje gewoon herkent alsof het formulier op diezelfde site staat.

Ik wil voorkomen dat je met een zelf gemaakt html bestand iets kunt posten op mijn site. Mijn site mag dus alleen geposte formulieren accepteren die ook echt op mijn site staan.

Kan dit, en zo ja, hoe?

[Super_ik]

da kan met de refferer (oid) kijken waar t form vandaan komt

[Verwijderd]

De refferer checken?

PHP:

$_SERVER["HTTP_REFERER"]

[GewoonNico]

Hoe moet dit dan precies?

Ik heb op mijn site een pagina gemaakt en daarin staat

<?
echo("Referrer = ".$_SERVER["HTTP_REFERER"]." ");
?>

de pagina is
http://www.partypassion.net/?pid=test

Maar ik krijg geen output als ik iets post naar die pagina

[ Voor 118% gewijzigd door GewoonNico op 03-07-2003 17:45 ]

[Nvidiot]

de referer checken werkt, maar deze is ook zeer eenvoudig te faken

[Glimi]

Wat heb je zelf geprobeerd, opgezocht, ed. ed.
Er zijn echter verschillende mogelijkheden
• referrer check
• Gebruik een sessie voor authenticatie
• Check je variabelen serverside, zodat je je geen zorgen hoeft te maken over postings van buitenaf
ed.

[GewoonNico]

Sessies zijn al van sprake op mijn site.
En ik wil juist voorkomen dat ik alles serverside moet checken omdat ik veel formulieren gebruik en dus veel processorkracht ga gebruiken

Ik wil het via een referrer check doen, maar hoe werkt dit precies?

[Glimi]

Een referrercheck staat hierboven al beschreven.
Verder moet je je eerst gaan verdiepen hoe dat werkt voordat je een beslissing neemt over het al dan niet gebruiken.

[pietje63]

partypas schreef op 03 July 2003 @ 17:46:
Sessies zijn al van sprake op mijn site.
En ik wil juist voorkomen dat ik alles serverside moet checken omdat ik veel formulieren gebruik en dus veel processorkracht ga gebruiken

Ik wil het via een referrer check doen, maar hoe werkt dit precies?

referrer check werkt ook server side
ik denk dat een systeem met een simpele sessie controle toch beter/makkelijker werkt helemaal omdat je zegt dat die er al zijn

[GewoonNico]

ik denk dat ik dan toch maar server side beveilig.
Het kost me wel weer een hoop query's

PHP:

<?
    if (!mysql_num_rows(mysql_query("SELECT id FROM forum_forum WHERE status='open' AND id = '$_POST[forum]'"))) { $err .= "\n<li>Dit forum is gesloten!</li>"; }

    if ($user->status !== "normal" && $partylogin == true && !mysql_num_rows(mysql_query("SELECT id FROM forum_forum WHERE status='open' AND security='all' OR status='open' AND security='login' status='open' AND security='mod' ")))
        { 
        $err .= "\n<li>Je hebt geen toegang voor dit forum!</li>";
        }
    elseif($user->status == "normal" && $partylogin == true && !mysql_num_rows(mysql_query("SELECT id FROM forum_forum WHERE status='open' AND security='all' OR status='open' AND security='login'")))
        {
        $err .= "\n<li>Je hebt geen toegang voor dit forum!</li>";
        }
    elseif (!mysql_num_rows(mysql_query("SELECT id FROM forum_forum WHERE status='open' AND security='all'")))
        {
        $err .= "\n<li>Je hebt geen toegang voor dit forum!</li>";
        }

?>

[TRON]

Wat je kan doen is aan een form een identieke key meegeven, eej: sessie id's misschien?

Laat het geposte checken op de sessie sleutel. Indien de sleutel/key oid niet wordt meegestuurd steek je je middelvinger op naar het 'aangepaste' form.

[ Voor 30% gewijzigd door TRON op 03-07-2003 18:00 . Reden: (-34%) ]

[dusty]

SQL op lijn 4 in de geposte code heeft een fout .

en de geposte code slaat helemaal niet op serverside afhandelen van referers

[Gem1e]

die referer check is ook best waardeloos, aangezien die via een HTTP Header komt:

PHP:

header('Referer: Ver achterin de pruimentijd');

kan je best wel alles aan meegeven wat je wil

[Verwijderd]

Ok, en wat als jij nu bij het creeren van het form zegt:

PHP:

session_start();
$_SESSION["code"] = $mijnrandomcode;
header('Referer: $mijnrandomcode');

En op de volgende pagina, waar de $_POST waarden opgehaald worden:

PHP:

session_start();
if ($_SERVER["HTTP_REFERER"] != $_SESSION["code"])
{
      echo "Ga iemand anders plagen!";
}
else
{
      // Doe je ding
}

Lijkt me redelijk veilig...als je gewoon een random int pakt.
(wat natuurlijk ook gewoon met sessies kan, hoeft niet eens met referer)

[ Voor 41% gewijzigd door Verwijderd op 03-07-2003 19:05 ]

[Bosmonster]

Wat je ook kunt doen is in je formulieren een hidden value schrijven met een random ID. Deze zet je ook in de sessie en je checkt ze samen weer in het POST. Komt in principe op hetzelfde neer als slindenau, maar dan zonder de headers aan te passen aan dingen waar ze niet voor bedoeld zijn

[GewoonNico]

Ja,

Maar als nu iemand naar die page gaat, bijvoorbeeld formposten.php (dan wordt er een sessie aangemaakt, of in een hidden field de random waarde) Dan opent die gast de bron, past wat dingen aan, bijvoorbeeld "maxlength=111111111" en slaat hem lokaal op (dus sessie en hidden value zijn er nog altijd)
en post hem dan... dan is zijn die beveiligingen eigenlijk voor niks want dan heb er niks aan... toch?

[RM-rf]

partypas schreef op 04 July 2003 @ 10:16:
Ja,

Maar als nu iemand naar die page gaat, bijvoorbeeld formposten.php (dan wordt er een sessie aangemaakt, of in een hidden field de random waarde) Dan opent die gast de bron, past wat dingen aan, bijvoorbeeld "maxlength=111111111" en slaat hem lokaal op (dus sessie en hidden value zijn er nog altijd)
en post hem dan... dan is zijn die beveiligingen eigenlijk voor niks want dan heb er niks aan... toch?

welkom op het internet?

die onveiligheid zul je altijd hebben, http is een stateless protocoll en dus weet je nauwelijks wat de referrer van een request is, deze kan namelijk domweg gefaked worden (zelfs al zou je de refferrer checken ben je niet veilig).

essentieel is dus dat je altijd de waardes serverside checked, zelfs al heb je clientside form-validatie, doe dit nogmaals serverside, en daarmee is de enige mogelijkheid dat maxlength niet groter word: wil je essentiele authenticatie koppelen aan een bezoeker, gebruik dan een sessie met een korte timeout (en eventueel gekoppeld aan een IP).

Maar laat nooit de veiligheid afhangen van het feit of de gebruiker niet waardes aanpast buiten veilige normen, dit moet serverside na de submit gecontroleerd worden.

[Verwijderd]

Maxlength staat daar sowieso los van volgens mij

Stel dat diegene het random ID aanpast, en via een lokaal opgeslagen versie het formulier submit, dan komen het radom ID van Sessie en Formulier niet overeen .. waar jij dus server side op kan checken. (en dan een foutmelding geeft ofzo)

[satyriasis]

Maar waarom wil je dat beveiligen dan? ik zie heel eerlijk gezegd het nut er niet van in. ik ben op het moment ook met inlog scripts en zo bezig. waarom zou je willen blokkeren dat gebruikers van andere sites kunnen inloggen? wat maakt dat uit dan?

[ Voor 8% gewijzigd door satyriasis op 04-07-2003 11:29 ]

[Breuls]

Een referer is een header die de client naar de server stuurt. Een header(); gaat van de server naar de client, dus een

PHP:

header('Referer: blaat')

is nogal onzin.

[RM-rf]

Breuls schreef op 04 juli 2003 @ 11:42:
Een referer is een header die de client naar de server stuurt. Een header(); gaat van de server naar de client, dus een

PHP:

header('Referer: blaat')

is nogal onzin.

dat is inderdaad onzin, maar met php is wel doodeenvoudig een fake http-req (GET of POST) te simuleren, met een vervalse referrer:
http://de.php.net/manual/en/function.curl-setopt.php

CURLOPT_REFERER: Pass a string containing the "referer" header to be used in an HTTP request.

de enige methode om zulk misbruik te ondervangen is mbv extra variabelen te controleren of de vorige pagina ook werkelijk opgevraagd is door deze client (dus een sessie, eventueel gecombineerd met een IP)

overigens is zelfs als de pagina werkelijk van jouw eigen server afkomt nog steeds grapjes uit te halen, bv dmv:

code:

javascript:document.forms['inlogform'].elements['maxlength_value'].value = '1111111'

in te typen in de lokatiebalk van je browser, de refferrer blijft gelijk, maar je maxlength variabele is aangepast, zelfs al zou hij hidden zijn

[MBV]

Je zal gewoon moeten controleren of de goeie waardes worden gegeven, en nooit in een php-var een link zetten naar een hdd-locatie bijvoorbeeld
Je kan met java o.i.d. wel beveiligen, en als het echt belangrijk is kan je https gebruiken. Maar of dat de bedoeling is...

Een simpelere beveiliging is te kijken hoelang het duurt tussen het kijken naar 1e pagina, en het versturen van het form. In 5 minuten kan je niet zo'n php-script in elkaar knutselen, maar wel een form invullen.

[ Voor 29% gewijzigd door MBV op 04-07-2003 12:07 ]

[GewoonNico]

Oke, bedankt voor alle reacties

Ik ga al mijn forms aanpassen zodat ze ook serverside checken

[Verwijderd]

Kun je niet instellen dat er partypassion.net in de refferer-domein moet komen?
<?
$_SERVER["HTTP_REFERER"]
?>
Dat dus alles van http://xxx.partypassion.net/ ge-accepteerd wordt?
Misschien werkt http://partypassion.net.mijnpagina.nl dan ook, maar dat weten anderen toch niet.

Ik heb zo weleens dingen aangepast die ik niet mocht aanpassen. (Bij Trouble-Tickets in Members.Area) Het stelde weinig voor, maar het kon door dit aan te passen: <textarea name="demo" cols="60" rows="6" tabindex="5" readonly>

[eborn]

Verwijderd schreef op 06 juli 2003 @ 19:44:
Kun je niet instellen dat er partypassion.net in de refferer-domein moet komen?
<?
$_SERVER["HTTP_REFERER"]
?>
Dat dus alles van http://xxx.partypassion.net/ ge-accepteerd wordt?

Zoals eerder gezegd: dat is een mogelijkheid. Maar dit is enorm makkelijk te omzeilen, dus je moet hierbij niet denken dat het een echte beveiliging is. Elke persoon met een beetje verstand van Internet kan die header aanpassen zodat je ook vanaf een lokaal adres een geldige referrer hebt.

[Verwijderd]

Wat je zou kunnen doen, is een soort van 'hash'-tabel in je database maken. Bij het laden van het form wordt dan in deze tabel een record weggeschreven met de tijd en een random hash. In je form zet je vervolgens deze random hash als hidden field en deze stuur je mee. Aangekomen bij het verwerken check je of deze random hash in combinatie met de tijd (range van een uur ofzo) klopt en aan de hand daarvan geef je groen licht voor de verwerking. Wanneer de post dan correct uitgevoerd is kun je hierna het record ook weer verwijderen.

[GewoonNico]

Als je dat met die hash zou doen, en je copieerd de preciese html copieer je ook het hidden field mee dus dat werkt denk ik ook niet

[Roa]

satyriasis schreef op 04 July 2003 @ 11:28:
Maar waarom wil je dat beveiligen dan? ik zie heel eerlijk gezegd het nut er niet van in. ik ben op het moment ook met inlog scripts en zo bezig. waarom zou je willen blokkeren dat gebruikers van andere sites kunnen inloggen? wat maakt dat uit dan?

Amen, wat maakt het uit als iemand een ander form gebruikt? Het gaat er toch om wat er met de ingevoerde data gebeurd, niet welk form gebruikt is. Door een form lokaal op te slaan kan je nl niet inloggen onder iemand anders account ofzo...

Wat nog zou kunnen is de url opvragen in het script dat je form afhandelt en kijken of dat overéén komt met wat zou moeten (heb de laatste paar posts niet gelezen, als het er al bijstaat, sorry)

[The_Eternal]

alles wat je binnenkrijgt via de headers is ook met gemak na te bootsen door simpelweg je eigen HTTP headers te sturen dus kan je hier in principe allemaal niks mee.
het enige wat 'echt veilig' zou moeten zijn is HTTPS. je kan het wel een STUK moeilijker maken door gebruik te maken van een sessie. maar uiteindelijk is het gewoon onveilig, wat via de webbrowser kan, kan je ook via een script nabootsen. zo simpel is het

[Verwijderd]

The_Eternal schreef op 28 juli 2003 @ 18:39:
alles wat je binnenkrijgt via de headers is ook met gemak na te bootsen door simpelweg je eigen HTTP headers te sturen dus kan je hier in principe allemaal niks mee.
het enige wat 'echt veilig' zou moeten zijn is HTTPS. je kan het wel een STUK moeilijker maken door gebruik te maken van een sessie. maar uiteindelijk is het gewoon onveilig, wat via de webbrowser kan, kan je ook via een script nabootsen. zo simpel is het

Zo simpel is het niet. De issue is niet wat iemand zelf kan posten, maar wat hij een ander kan laten posten. Denk daar maar eens goed over na.

[The_Eternal]

cheatah, het gaat er toch om dat hij een formulier op z'n site wil beveiligen voor een post van een site van buitenaf. Een normaal formuliertje is met gemak af te vangen door een combinatie van referer en een sessie (bij het weergeven van het formulier een session var op een random waarde zetten en die als GET var of invisible veld op te geven, en die bij de post van het formulier bekijken of die overeenkomt met de sessie). Maar uiteindelijk kan iemand die via een script in WIL loggen er altijd op inloggen (maar met alleen html is dit dan niet meer mogelijk).

[Gilles]

Ik vraag me af waarom je deze beveiliging wilt toepassen. Zorg gewoon dat je alle input correct afvangt en dan zie ik het probleem niet. Als het bijvoorbeeld gaat over verplichte velden checken met javascript, zorg dan ook dat het ook door php gecontroleerd wordt. Zou je de redenen wat verder kunnen verduidelijken?