[PHP] Script mag alleen aangeroepen worden door server

[Rene59]

Allereerst, ik weet niet zeker of ik logisch bezig ben, da's ook aan jullie.

De situatie is als volgt:
- formulier op een PERL pagina wordt ingevoerd door gebruiker
- gebruiker klikt op submit
- gegevens worden verwerkt en er volgt een redirect

Nu wil ik tussen de gegevens verwerking (in het PERL script) en de redirect in een PHP script aanroepen (soort van counter).
Hoe kan ik er nou voor zorgen dat dit script alleen op deze manier werkt, en dus niet bijv. vanuit de adresbalk van de browser of een nep formulier van een bezoeker, die de counter voor de gek wil houden.
Er mag dus alleen geteld worden als het PERL script gepost wordt.

Oftewel, hoe check ik in het PHP script dat het aangeroepen is vanuit het juiste PERL script? Is dit überhaupt mogelijk, of is er een betere aanpak hiervoor?

[djluc]

Wat voor server gebruik je? Met htacces kun je zoiets namelijk vast wel doen.

[Evilbee]

zet in je formulier een verborgen veld en zet hier een bepaalde waarde in. En controleer dan of die het zelfde zijn.

Zelf gebruik ik hiervoor een md5 encryptie van het ipadres van de bezoeker.

[Rene59]

djluc: het is een apache server (linux)
Evilbee: hoe moet ik dat precies zien? zet je dan in dat hidden veld het ge-encrypte adres? zou je iets meer detail willen geven?

[Evilbee]

code:

<input type="hidden" name="string" value="<?=md5($_SERVER["REMOTE_ADDR"])?>">

En dan op de volgende pagina controleren of daar met md5($_SERVER["REMOTE_ADDR"]) ook weer het zelfde uitkomt.

Het is natuurlijk niet noodzakelijk om het adres met md5 te encypten, maar het is wel een goede beveiliging tegen mensen die je bron zitten te bekijken.

[ Voor 19% gewijzigd door Evilbee op 11-06-2003 21:54 ]

[curry684]

Evilbee schreef op 11 June 2003 @ 21:54:
En dan op de volgende pagina controleren of daar met md5($_SERVER["REMOTE_ADDR"]) ook weer het zelfde uitkomt.

Het is natuurlijk niet noodzakelijk om het adres met md5 te encypten, maar het is wel een goede beveiliging.

Sja MD5 voegt imho opinion niks toe omdat iemand die echt wil hacken daar ook wel een clientside implementatie van heeft. Je methode an sich is volgens mij wel de beste manier om het klaar te spelen.

[Erkens]

kan je niet in een cookie bijhouden wat de laatst bezochte page is (ok ook weer client side)

[Rene59]

Dat lijkt mij ook zo.
Je kan dan toch op een eigen server een "nep" formulier posten naar mijn script?

[Verwijderd]

Niks is te beveiligen, alles is te kraken.. controleer het anders met Referer en Sessie...

[curry684]

Verwijderd schreef op 11 June 2003 @ 22:01:
Niks is te beveiligen, alles is te kraken..

Onzin. Alles is te beveiligen, alles is te kraken. Dat is de klassieke paradox van beveiligingsmethodieken

[E-Vix]

wat dacht je er van om gewoon $HTTP_REFERER te controleren om te kijken of je wel van de juiste pagina af komt?

PHP:

if $HTTP_REFERER=="http://www.jouwsite.com/jouwscript.pl"
{
    blablabla; // hier dus de rest van de pagina
}
else {
    echo"Direct aanroepen van deze pagina is niet toegestaan";
}

[curry684]

E-Vix: net zo lek als de andere oplossingen. Referrer wordt vastgesteld adh HTTP-headers die optioneel door de client gestuurd mogen worden volgens HTTP-specs.

[Rene59]

Had ik ook al aan gedacht ja, maar met sommige browsers kun je zelfs de referer instellen, dus die valt ook af.

curry684: weet jij misschien een goede methode dan?

[curry684]

Als dat PHP-script perse vanaf een client getriggered moet worden niet. Als je 'm direct kunt triggeren op de server wel maja PHP is geloof ik tricky daarmee.

* curry684 weet veel van internet, systeembeheer, servers coden en zo, maar is enorme PHP-noob

[Glimi]

Kan het PHPscript niet gewoon het Perl script uitvoeren (welke buiten de webroot staat) en dan die output doorpipen naar de gebruiker?
Dan weet je het eig wel zeker

[Rene59]

curry684: ok, hoe zorg ik er dan voor dat alleen de server het script kan aanroepen? is dat op eoa manier te configureren met apache?

Glimi: da's helaas niet mogelijk in dit geval

[Erkens]

Rene59 schreef op 11 June 2003 @ 22:23:
Glimi: da's helaas niet mogelijk in dit geval

en dat omgekeerd dan?
je maakt een php script wat intern die perl aanroept en vervolgens die andere php?

[Apache]

Je kan mss een soort van exec() als in php doen in perl waarna je via de binary van php je count script aanroept.

Perl:

exec("/usr/bin/php -q /pad/naar/script.php");

En bypass je die hele client submit naar je php script.

[Rene59]

Goed idee! Alleen ik krijg een foutmelding:

Security Alert! PHP CGI cannot be accessed directly.
[...]

De beheerder van de server lief aankijken?

[Helox-in-a-box]

de referer tjekken waar hij vandaan komt.

[Erkens]

Helox-in-a-box schreef op 11 juni 2003 @ 23:10:
de referer tjekken waar hij vandaan komt.

ehm hij roept nu de php zelf aan, dus heb je geen referer

Rene59 schreef op 11 juni 2003 @ 22:58:
Goed idee! Alleen ik krijg een foutmelding:

Security Alert! PHP CGI cannot be accessed directly.
[...]

De beheerder van de server lief aankijken?

je zou eromheen kunnen proggen door een http request te doen vanuit je perl en dan een argument meegeven wat alleen jij weet ofzo

[ACM]

curry684 schreef op 11 June 2003 @ 21:55:
Sja MD5 voegt imho opinion niks toe omdat iemand die echt wil hacken daar ook wel een clientside implementatie van heeft. Je methode an sich is volgens mij wel de beste manier om het klaar te spelen.

't Voegt een zekere mate van onduidelijkheid toe, waardoor er iets minder snel te raden is hoe er gechecked wordt dat het zo aangeroepen wordt.

Als het niet heel erg is dat de php foutief aangeroepen wordt (maar het gewoon ongewenst is), dan is dat een van de makkelijkste manieren.

Als het absoluut voorkomen moet worden, dan zul je wellicht de functionaliteit van de php-file in de perlfile of andersom moeten verwerken (waarom uberhaupt twee losse pagina's, ook nog eens in verschillende talen?) of met serverside storage gaan spelen. Bijvoorbeeld door met perl in een temporary file of database een random key op te slaan en die uit te lezen in je php file.

Die kan je via een hidden-input file dan meesturen en als ie klopt, dan is er een zeer grote kans dat het allemaal netjes gegaan is
Evt kan je het remote-address er nog aan vast maken, hoewel er nog steeds proxies zijn die met meerdere ip's werken.

[Rene59]

ACM schreef op 11 juni 2003 @ 23:14:
[...]
(waarom uberhaupt twee losse pagina's, ook nog eens in verschillende talen?)

Mja, dat is omdat ik niet zo goed ben in Perl. Ik weet niet hoe ik mysql kan aansturen met Perl, dus vandaar dat ik voor deze omweg gekozen heb.

ACM schreef op 11 juni 2003 @ 23:14:
[...]
of met serverside storage gaan spelen. Bijvoorbeeld door met perl in een temporary file of database een random key op te slaan en die uit te lezen in je php file.
Die kan je via een hidden-input file dan meesturen en als ie klopt, dan is er een zeer grote kans dat het allemaal netjes gegaan is
Evt kan je het remote-address er nog aan vast maken, hoewel er nog steeds proxies zijn die met meerdere ip's werken.

Klinkt ook goed, wellicht dat ik dat nog probeer, maar het lijkt erop dat ik toch beter kan gaan leren hoe ik mysql aan kan sturen met Perl.

Bedankt voor de tips allemaal

[Shift]

PHP:

if($_SERVER['REMOTE_ADDR'] == "127.0.0.1")
{
         // Doe wat
} 
else 
{
          // doe andere dingen
}

[ACM]

Rene59 schreef op 11 June 2003 @ 23:18:
Klinkt ook goed, wellicht dat ik dat nog probeer, maar het lijkt erop dat ik toch beter kan gaan leren hoe ik mysql aan kan sturen met Perl.

Dat is vrij simpel hoor
Begin je zoektocht met keywords als 'DBI', 'DBD', (en perl en mysql natuurlijk) etc

Shift schreef op 11 juni 2003 @ 23:22:

Misschien volgende keer ook de topicstartmessage lezen ipv alleen de titel?

[ Voor 20% gewijzigd door ACM op 11-06-2003 23:31 ]