Doorsturen $_POST variable
Zo...
JS -> AJAX post met URI 'mijnGeheimScript.php' -> LAMP -> (document_root)/.htaccess ->
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
RewriteEngine on
RewriteCond %{REQUEST_URI} -d
RewriteRule "^/$" "/start_pagina.html"
<IfModule mod_php5.c>
php_value include_path "../assets/PHP"
ErrorDocument 404 /proxy.php
</IfModule>
RewriteCond %{REQUEST_URI} -d
RewriteRule "^/$" "/start_pagina.html"
<IfModule mod_php5.c>
php_value include_path "../assets/PHP"
ErrorDocument 404 /proxy.php
</IfModule>
En proxy.php:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include ltrim($_SERVER["REQUEST_URI"], "/")
: http_response_code(404);
?>
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
.../assets/PHP/.htaccess ->
Ideeën?
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.
Thomas van den Heuvel op 04/01/2017 19:20:06:
Dit is 't niet. Beveiligd is 't.Security through obscurity lijkt mij niet de weg om te gaan.
Thomas van den Heuvel op 04/01/2017 19:20:06:
Link / bewijs, AUB?In nieuwere webservers/PHP-versies kun je er volgens mij voor zorgen dat er geen informatie naar buiten gaat over typen en versies.
Thomas van den Heuvel op 04/01/2017 19:20:06:
Hoe dan weet je welke script moeten draaien (en met welke query string)?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.
- Voor Apache en zijn versienummertjes kan dit met:
- En met Nginx kan dit met:
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?
Gewijzigd op 05/01/2017 00:00:49 door - Ariën -
Ben van Velzen op 04/01/2017 19:20:28:
Sorry, maar verwijten is niet behulpzaam :(En nu zie je wat voor problemen je jezelf op de hals haalt.
Max Hopper op 04/01/2017 23:53:55:
Thomas van den Heuvel op 04/01/2017 19:20:06:
Hoe dan weet je welke script moeten draaien (en met welke query string)?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.
Daar had ik al o.a in een ander topic al een oplossing voor gepost.
Gewijzigd op 05/01/2017 00:04:43 door - Ariën -
Max Hopper op 04/01/2017 23:53:55:
Thomas van den Heuvel op 04/01/2017 19:20:06:
Dit is 't niet. Beveiligd is 't.Security through obscurity lijkt mij niet de weg om te gaan.
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.
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
RewriteEngine on
RewriteCond %{REQUEST_URI} -d
RewriteRule \.php$ /proxy.php [end]
<IfModule mod_php5.c>
php_value include_path "../assets/PHP"
</IfModule>
RewriteCond %{REQUEST_URI} -d
RewriteRule \.php$ /proxy.php [end]
<IfModule mod_php5.c>
php_value include_path "../assets/PHP"
</IfModule>
Nu is de hele bol super globals in de BESCHERMDE script zijn verkrijgbaar.
<full_disclosure>
inhout van ../assets/PHP/.htaccess:
</full_disclosure>
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.
Edit:
Het is niet nodig om het voorlaatste bericht te quoten. Daarom heb ik deze verwijderd.
Gewijzigd op 05/01/2017 16:18:53 door - Ariën -
Single Point entry:
Code (php)
1
2
3
4
2
3
4
http://example.com/ ====> [.htaccess] ===> http://example.com/index.php/
http://example.com/about ====> [.htaccess] ===> http://example.com/index.php/about
http://example.com/contact ====> [.htaccess] ===> http://example.com/index.php/contact
http://example.com/contact/confirmation ====> [.htaccess] ===> http://example.com/index.php/contact/confirmation
http://example.com/about ====> [.htaccess] ===> http://example.com/index.php/about
http://example.com/contact ====> [.htaccess] ===> http://example.com/index.php/contact
http://example.com/contact/confirmation ====> [.htaccess] ===> http://example.com/index.php/contact/confirmation
Zoals je hierboven in het schema kunt lezen worden alle url's doorgestuurd naar index.php, het enigste php bestand in je webroot.
In dit index.php bestand doe je slechts een paar kleine simpele dingetjes. Alle andere php bestanden staan buiten je webroot.
Het heeft niets te maken met POST of GET of AJAX.
Een framework biedt je alles waar je nu om roept in dit draadje
onder andere:
- single point entry
- clean url's
- directory structuur
- tal van additional modules voor allerlei doeleinden
- een schat aan libraries
Toevoeging op 05/01/2017 16:31:06:
GOOGLE ook eens op MVC...
'gewoon' URL verzoek (Chrome Inspector):
Request URL:https://acer-ubuntu:4443/WM_3.html
Request Method:GET
Status Code:200 OK
Remote Address:192.168.2.11:4443
'gewoon' AJAX verzoek vanuit WM_3.html (Javascript):
Request URL:https://acer-ubuntu:4443/validateAccountName.php
Request Method:POST
Status Code:204 No Content
Remote Address:192.168.2.11:4443
Accept:*/*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-GB,en;q=0.8,nl;q=0.6,de;q=0.4,it;q=0.2
Connection:keep-alive
Content-Length:16
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
DNT:1
Host:acer-ubuntu:4443
Origin:https://acer-ubuntu:4443
Referer:https://acer-ubuntu:4443/WM_3.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
X-Requested-With:XMLHttpRequest
En nu, pakt 'proxy.php' de URI en 'include()' de gevraagd script.
Maar er is een verschil tussen afgeschermde mappen IN of hoger dan je WEBROOT en bestanden BUITEN je webroot he?
Stel je webroot is:
/var/www/example.com/public_html (Je index.php is dus: /var/www/example.com/public_html/index.php)
Dan is dit een voorbeeld van een afgeschermde map:
/var/www/example.com/public_html/php ( in de php map staat dan een .htaccess met de inhoud 'Deny from all')
En dit is een voorbeeld van een map buiten je webroot:
/var/www/example.com/private (Hier kun je met het http protocol zowiezo niet komen)
https://acer-ubuntu:4443/validateAccountName.php de script moet in DOCUMENT_ROOT liggen... ONBEVEILIGD.
'Deny from all'? Waar? In {DOCUMENT_ROOT}/.htaccess? De AJAX verzoek aan de script krijgt HTTP 403 (en gewoone URL verzoeken, ook).
Stel je dat scripts liggen in {DOCUMENT_ROOT}/PHP/ met een .htaccess inhout 'Deny from all'. Nu krijgt de verzoek HTTP 404. Of je de pad vanuit de Javascript aanpassen tot '/PHP/validateAccountName.php' is de AJAX verzoek: https://acer-ubuntu:4443/PHP/validateAccountName.php en krijgt de verzoek HTTP 403.
Toegang te scripts, wat liggen buiten DOCUMENT_ROOT door een script (proxy.php) dat woont in DOCUMENT_ROOT krijgt HTP 200.
Met een URL zoals: 'Deny from all'? Waar? In {DOCUMENT_ROOT}/.htaccess? De AJAX verzoek aan de script krijgt HTTP 403 (en gewoone URL verzoeken, ook).
Stel je dat scripts liggen in {DOCUMENT_ROOT}/PHP/ met een .htaccess inhout 'Deny from all'. Nu krijgt de verzoek HTTP 404. Of je de pad vanuit de Javascript aanpassen tot '/PHP/validateAccountName.php' is de AJAX verzoek: https://acer-ubuntu:4443/PHP/validateAccountName.php en krijgt de verzoek HTTP 403.
Toegang te scripts, wat liggen buiten DOCUMENT_ROOT door een script (proxy.php) dat woont in DOCUMENT_ROOT krijgt HTP 200.
Waar loop je tegenaan (oorspronkelijke bericht: je mist superglobals)? Heb je een concrete vraag?
Wie heeft je in hemelsnaam verteld dat een andere aanpak "onveilig" zou zijn? Kun je ook uitleggen waarom het onveilig zou zijn? Indien het gaat om het voorkomen van rechtstreekse aanroepen van bepaalde scripts: daar zijn ook andere, en wellicht makkelijkere, oplossingen voor.
En, ik wil graag andere, makkelijkere oplossingen te horen.
Doel: nul data lekkage
Je kunt de internetkabel uit je server trekken, dan heb je geen lekkage meer ;-)
Wat ik bedoel te zeggen:
Natuurlijk wil je bepaalde gegevens niet laten lekken maar wat jij doet is heel je huis met rolluiken beveiligen behalve de garagedeur welke je vervolgens vergeet in het slot te draaien.
Mag ik vragen wat die proxy.php doet. Krijg altijd een beetje de smaak van illegale praktijken in mijn mond van het woord proxy. En als dat niet het geval is wil je misschien vertellen wat je wel wilt gaan maken?
Max Hopper op 04/01/2017 17:30:59:
En proxy.php:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?php
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include basename($_SERVER["REQUEST_URI"])
: http_response_code(404);
?>
preg_match("~.php$~", $_SERVER["REQUEST_URI"])
? include basename($_SERVER["REQUEST_URI"])
: http_response_code(404);
?>
(maakte 't pad 'agnostisch')