Jeżeli te katalogi, które wypisałeś są ścieżkami do osobnych kont użytkowników, na jednym serwerze, to kwestią zabezpieczenia ich powinien zająć się administrator serwera (tak, aby jeden użytkownik nie miał dostępu do folderu drugiego).

Kiedy jednak są to dwie ścieżki, na jednym koncie, sytuacja się komplikuje. Tak jak napisałeś, możesz pobawić się prawami dostępu, czy nawet .htaccess i przykładowo order deny,allow [...]. Problem w tym, że jeżeli ktoś uzyska dostęp do plików serwera poprzez jakiś dziurawy skrypt, to pobierając jakikolwiek inny plik PHP może w 99% przypadków bez problemu rozgryźć każde zabezpieczenie oparte stricte na tym języku. Chyba, że użyjesz jakiegoś szyfratora kodu w stylu ionCube, czy zaciemniacza takiego jak phpobfuscator. Ciut inaczej sprawa wyglądać będzie, jeżeli agresor nie będzie miał możliwość wylistowania, czy przejrzenia listy Twoich plików. Wtedy kluczową sprawą jest sam kod serwisu który może zostać zaatakowany. Wiadomo przecież, że jeżeli includeujemy pliki poprzez adresy typu index.php?page=test to łatwiej trafić, gdzie i w jakiej postaci znajduje się dany plik, niż chociażby, gdy wywołanie następuje jako index.php?page=1. Są to jednak kwestie pośrednie i zależne od sytuacji.

Dlatego uważam, że w tym konkretnym wypadku (pierwszym z wymienionych) przede wszystkim należy zabezpieczyć serwer od strony administracyjnej. A tu najlepiej jakby wypowiedział się na ten temat ktoś, kto zajmuje się tym na co dzień, a nie hobbistycznie, od święta jak ja :]

Pozdrawiam,
m1chu

Niestety na tym samym serwerze znajduje się Ich skrypt w katalogu:
/…/ichSkrypt

Jak się okazuje Ich skrypt jest podatny choćby na AFD. W ten sposób zawartość mojego skryptu przed światem stoi otworem.
Podejrzewam, że jeśli dobrze poustawiam chmody, skrypty nie będą mogły się czytać, a jedynie wykonywać (co nadal mi nie odpowiada).
Umieśćmy sobie na moim serwerze plik: /…/mojSkrypt/index.php, który będzie includował pozostałe skrypty. Aby zapewnić sobie, że skrypty nie są uruchamiane bezpośrednio (czy, że ktoś w przyszłości przenosząc mój skrypt nie zapomni poustawiać chmodów) dodajmy na początek skryptu w index.php:
define („TO_MOJ_SKRYPT”, true);
I w pliku skryptu właściwego (includowanego) w skrypt.php:
if (TO_MOJ_SKRYPT != true)
exit;
Faktycznie uruchomić mój skrypt bezpośrednio jest ciężko. No ale ktoś może skorzystać z Ich skryptu w sposób następujący:
1. Wgrać plik php do niezabezpieczonego katalogu:
/…/ichSkrypt/tmp/skrypt.php
o następującej zawartości:
define (‘TO_MOJ_SKRYPT’, true);
include ‘../../mojSkrypt/skrypt.php’;
W tym momencie bezpieczeństwo od strony PHP zupełnie leży. W takiej sytuacji pozostaje jedynie sprawdzanie czy $_SERVER['PHP_SELF'] (czy czegoś w tym stylu) jest ustawione na /…/mojSkrypt/index.php. No ale każdy przyzna, że taki wpis we wszystkich plikach includowanych jest kiepskim rozwiązaniem, bo aplikacja staje się nieprzenośna.
Może jednak jest jakiś inny, magiczny sposób na zabezpieczenie tego skryptu? Jeśli to, to jak zabezpieczyć serwer?

Pozdrawiam
Michał

Program po jakimś czasie rozmyślania nad sposobem podejścia do problemu napisany został dzisiaj – na szybko. To taka druga wersja alpha.

Atrybuty:
- skanowanie linka w poszukiwaniu RFI/LFI + Poison Null Byte
- posiada podstawowe zabezpieczenia przed wpisaniem niepoprawnych danych
- pozwala na wprowadzenie adresu shella
- pozwala na podanie (zakres 1 – 12) ilości wykonywanych pętli wzwyż w drzewie katalogów w poszukiwaniu LFI
- daje możliwość użycia proxy w postaci hosta bądź IP (różnie to działa, przy słabych serwerach pośredniczących kończy się niekiedy np. timeoutem)
- pozwala zapisać log wyników skanowania
- można użyć dwóch języków interfejsu – polskiego i angielskiego (tu za pewnie też znajdzie się trochę błędów spowodowanych pośpiechem, będą poprawione… mam nadzieję ;])
- itp.

Jest też wiele rzeczy do poprawki (bo nie zawsze błędy są wykrywane, a i kod nie jest zbyt optymalny ;D), dlatego zaglądajcie tu regularnie i aktualizujcie. Mam nadzieję, że znajdę chwilę na… dopieszczenie :]

Więcej informacji już niedługo pod pierwszym linkiem w tym komentarzu.