header location met kenmerk?
Is het eigenlijk mogelijk om aan een header location iets mee te geven waardoor de aangeroepen pagina weet dat het een legitieme aanroep is?
Dus stel, pagina A is gemachtigd om pagina B aan te roepen via header(). Kun je nu vanuit pagina A iets meesturen waardoor pagina B weet dat pagina A hem heeft aangeroepen?
Oh ja, en dan zoek ik een "static" oplossing, dus zonder het gebruik van een database, cookies of sessions.
Gewijzigd op 25/07/2015 01:37:24 door Ozzie PHP
Code (php)
Edit: Uiteraard kun je dit niet gebruiken op de target van je redirect, omdat je daar geen headers mee zult krijgen. Je zult daar gebonden zijn aan een cookie, of het IP, waar het laatste niet handig is ivm mogelijke dubbele requests e.d.
Je zou ook een token kunnen berekenen op basis van de huidige tijd, al zal dit meer neerkomen op security through obscurity, waar ik zelf geen groot fan van ben.
Gewijzigd op 25/07/2015 03:50:03 door Ben van Velzen
Het idee is dus dat pagina B "ziet" dat hij is aangeroepen door pagina A. Zou het kunnen via een controle van de referer wellicht?
Dus Pagina A stuurt naar Pagina_B.php?token=3854734857v8irbge4r83f4bw4rv3489f
En Pagina B controleert of $_GET['token'] == '3854734857v8irbge4r83f4bw4rv3489f' ?
Op https://www.owasp.org/index.php/List_of_useful_HTTP_headers handige informatie.
X-AUTH-TOKEN doet precies dit, maar via een header().
Dus:
Pagina B:
Wellicht kan je ook dat X-AUTH-TOKEN veranderen naar O-ZZ-IE-TOKEN-GEHEIM....
Toevoeging op 25/07/2015 09:04:10:
Correctie: dat laatste werkt dus: http://zunflappie.nl/phphulp/pagina_a.php
Wellicht kan je via http://php.net/manual/en/features.http-auth.php wel zoiets regelen?
Toevoeging op 25/07/2015 09:29:06:
En via http://evertpot.com/223/ kan je lezen hoe je dit doet.
PS: mocht je pagina_a.php en pagina_b.php af hebben, wil je dat dan even posten? Ik kan het ook wel gebruiken ;)
Gewijzigd op 25/07/2015 09:16:23 door Eddy E
Dit dan vervolgens via HTTP zelf overbruggen klinkt... paradoxaal.
EDIT: de wens om vanuit A op B te kunnen "landen" klinkt als een vorm van applicatie-logica, er zal dus iets aan "geprogrammeerd" moeten worden, ik weet niet of je met HTTP alleen een soort van "valide klikpad" kunt definieren, hoe langer ik er over nadenk, hoe onwaarschijnlijker dit klinkt. Maar ik kan mij vergissen.
En dan de vraag: wil en moet je dit wel via HTTP zelf oplossen, of zijn er andere/makkelijkere manieren. Ik zou dan eerder voor de laatste variant gaan denk ik.
EDIT: en zelfs al krijg je dit voor elkaar, dan zal er ook een soort van afhandeling moeten zijn toch? Dan moet je toch al gebruik maken van een soortement van serverside scriptingtaal? :) Waarom dan niet direct? :)
Gewijzigd op 25/07/2015 11:28:57 door Thomas van den Heuvel
>> Wellicht kan je via http://php.net/manual/en/features.http-auth.php wel zoiets regelen?
Volgens mij gaat dit over het invoeren van een wachtwoord?
@Thomas:
Ik zal even uitleggen wat ik bedoel. Ik zat te denken om straks de klanten naar hun adminpanel te laten gaan (met header) door het typen van een subdomein, bijv. "adminpanel.mijndomein.nl". Ik wil dan dat ze via een header naar de "echte" (maar lastiger te onthouden) URL worden gestuurd, bijv. www.mijndomein.nl/admin/login.php. Ik wil echter dat ze deze URL niet rechtstreeks aanroepen of bookmarken. Het voordeel heirvan kan dan zijn dat als iemand het domein wil bruteforcen, dat deze URL simpelweg niet reageert, omdat ie niet is aangeroepen via "adminpanel.mijndomein.nl". Een ander voordeel is dat ik "www.mijndomein.nl/admin/login" kan wijzigen naar een andere URL als dat ooit nodig mocht zijn, zonder dat een klant daar last van heeft. Die blijft gewoon "adminpanel.mijndomein.nl" gebruiken.
Er hoeft vanaf het subdomein geen ingewikkelde code mee te worden gestuurd. Stel de domeinnaam is foo.nl dan zou adminpanel.foo.nl slechts iets simpels mee te hoeven sturen gebaseerd op de domeinnaam (bijv. "admin-foo.nl") waardoor "www.foo.nl/admin/login" weet dat hij is aangeroepen door het adminpanel subdomein.
Of je moet via dat WWW-AUTHEFICATION een wachtwoord moeten meegeven, en dat op pagina B moeten binnenkrijgen. Zo niet, dan kan je (met header() gewoon ergens anders heen sturen. Dat doet PHP trouwens.
Dus kan je net zo goed een ?token=838947347 meegeven.
Ozzie PHP op 25/07/2015 21:12:17:
Eddy, ik zie in die pagina A van jou wel een referer staan. Ik kan het zelf momenteel niet testen, maar als jij "headert" van pagina A naar pagina B, krijg jij dan op pagina B als referer pagina A binnen?
Nee.
Pagina_a.php =
Je belandt dus vanzelf op pagina_b.php en daar zie ik geen "pagina_a" staan.
Ook dat "123456" staat er niet bij.
Edit:
Met alles uit zit er geen verschil in.
Er is geen REFERER-ding aanwezig.
Met alles uit zit er geen verschil in.
Er is geen REFERER-ding aanwezig.
Gewijzigd op 26/07/2015 14:05:03 door Eddy E
Tja, dan weet ik ook zo gauw niet hoe ik dat moet oplossen :(
Ozzie PHP op 25/07/2015 01:35:50:
Zou je die vereiste durven laten vervallen? Oh ja, en dan zoek ik een "static" oplossing, dus zonder het gebruik van een database, cookies of sessions.
Mét een sessie wordt het namelijk allemaal een stuk makkelijker.
(Meer in het algemeen kun je je daarnaast nog afvragen waarom je geen sessies of databases zou mogen gebruiken als je hele serveromgeving toch al is ingericht op PHP en MySQL. Je hebt zeilen en een buitenboordmotor aan boord, maar je gaat toch liever roeien...?)
Dat begrijp ik. Punt is dat ik van een subdomein kom, dus dan wordt het ineens een wat lastiger verhaal. Daarom bij voorkeur niet via een sessie.
De gedachte is heel simpel. Pagina B moet "zien" dat hij is aangeroepen door pagina A (wat en subdomein is). Dus heel simpel:
sub.domein.nl roept www.domein.nl/foo aan en deze laatste "ziet" dat hij is aangeroepen door sub.domein.nl
Daarbij zou je dan ook nog als extra de sessie van A naar B kunnen meeverhuizen door een ?sid=... of een uniek token door te geven in de redirect-URL.
Klinkt goed, maar de moeilijkheid is dat de eerste aanroep vanaf een subdomein wordt gedaan. Het bestand wat daar wordt aangeroepen is dan niet gekoppeld aan een specifiek domein. Daarom wordt dat dynamisch verhaal te lastig. Wat jij voorstelt zou een mooie controle kunnen zijn, maar de vraag is dan hoe pagina A het IP-adres en de user-agent doorgeeft aan pagina B. Daar zit 'm de bottleneck.