<?php
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include ltrim($_SERVER["REQUEST_URI"], "/")
: http_response_code(404);
?>
Apache kunt niet mijnGeheimScript.php vindt (404) -> proxy.php is niet verzoekt vanuit externe dus geen $_POST | $_GET | $_REQUEST variable(s) zijn gecreëerd :( maar wel draaid mijnGeheimScript.php
Security through obscurity lijkt mij niet de weg om te gaan. Waarom mag men niet weten dat het PHP-scripts betreft? In nieuwere webservers/PHP-versies kun je er volgens mij voor zorgen dat er geen informatie naar buiten gaat over typen en versies.
Daarnaast zou je je applicatie kunnen laten werken via één voordeur (single point of entry): index.php. Deze zet je in je webdir, de rest van je PHP-code kun je buiten je webdirectory houden.
Waarom wil je je php scripts buiten de docroot houden? Voor configuratiebestanden is dat logisch, voor de rest niet echt. En nu zie je wat voor problemen je jezelf op de hals haalt.
?
Onbekende gebruiker
04-01-2017 23:53
Thomas van den Heuvel op 04/01/2017 19:20:06
Security through obscurity lijkt mij niet de weg om te gaan.
Dit is 't niet. Beveiligd is 't.
Thomas van den Heuvel op 04/01/2017 19:20:06
In nieuwere webservers/PHP-versies kun je er volgens mij voor zorgen dat er geen informatie naar buiten gaat over typen en versies.
Link / bewijs, AUB?
Thomas van den Heuvel op 04/01/2017 19:20:06
Daarnaast zou je je applicatie kunnen laten werken via één voordeur (single point of entry): index.php. Deze zet je in je webdir, de rest van je PHP-code kun je buiten je webdirectory houden.
Hoe dan weet je welke script moeten draaien (en met welke query string)?
- In PHP kan je de headers met de PHP-versie afschermen met de 'expose_php' directive op 0.
- Voor Apache en zijn versienummertjes kan dit met:
ServerSignature Off
ServerTokens Prod
- En met Nginx kan dit met:
server_tokens off;
Verder ontgaat mij nog steeds het exacte nut waarom je een proxy wilt bouwen? Je kan toch een AJAX-script bouwen die classes/methods/functies aanroept welke (zoals eigenlijk hoort) netjes buiten de webroot staan?
?
Onbekende gebruiker
04-01-2017 23:59
Ben van Velzen op 04/01/2017 19:20:28
En nu zie je wat voor problemen je jezelf op de hals haalt.
[quote="Thomas van den Heuvel op 04/01/2017 19:20:06"]
Daarnaast zou je je applicatie kunnen laten werken via één voordeur (single point of entry): index.php. Deze zet je in je webdir, de rest van je PHP-code kun je buiten je webdirectory houden.
Hoe dan weet je welke script moeten draaien (en met welke query string)?
[/quote]
Daar had ik al o.a in een ander topic al een oplossing voor gepost.
[quote="Thomas van den Heuvel op 04/01/2017 19:20:06"]
Security through obscurity lijkt mij niet de weg om te gaan.
Dit is 't niet. Beveiligd is 't.
[/quote]
Uhm. Nee? Ik kan me een partij brakke code schrijven, en die vervolgens buiten de webdir plaatsen en via index.php aanroepen. Hoe is dat veiliger?
Daarnaast, zelfs als je rauwe php-bestanden door een of andere fout zou kunnen downloaden, dan is er echt meer aan de hand? Klinkt meer als hosting die steken laat vallen dan.
Je kunt dit soort discussies tot in het absurde voeren natuurlijk, met als eindconclusie dat niets veilig is. Dat is echter niet erg praktisch dus je zult tot op zekere hoogte aannames moeten doen. Het lijkt mij echter vaker het geval dat brakke code een boosdoener is dan webservers die hele rare dingen doen.
>> Hoe dan weet je welke script moeten draaien (en met welke query string)?
Die informatie kun je halen uit de $_SERVER super-global array.
Ik zou zeggen: pak een eenvoudig PHP framework zoals bijvoorbeeld CakePHP. Daar heb je een hoop profijt van.
?
Onbekende gebruiker
05-01-2017 16:14
gewijzigd op 05-01-2017 16:18
Uhh, alleen als de HTTP GET methode was gebruikte (en deze zijn AJAX POST met Content-Type: application/x-www-form-urlencoded en multipart/form-data met GEEN query string).