Dzisiaj taka mało przyjemna sprawa :/ Jakiś czas temu pewna osoba dostała maila, którego można by streścić słowami: “wasza aplikacja jest dziurawa, mam hasła do bazy, proponuje 150zł i wykonam odpowiednie poprawki bezpieczeństwa”. Śliska sprawa tym bardziej, że napisała to osoba udzielająca się na polskim forum Kohany, notabene także czytelnik tego bloga ;) Nie chce tego komentować, za to proponuje lekturę wpisu Vagli. Skupmy się na samym problemie.

Problem dotyczy frameworka KohanaPHP od wersji (chyba 2.2) w której dodano internal cache w konfiguracji. Internal cache to solidny kop wydajnościowy uzyskiwany poprzez zbuforowanie na ustalony okres czasu całej konfiguracji frameworka oraz wszystkich ścieżek dostępu. Zserializowane tablice są zapisywane w formie tekstowej w katalogu /application/cache/. Nie jestem teraz w stanie stwierdzić czy złą konstrukcję .htaccess posiadała oficjalna paczka z tego czasu czy to jest kwestia indywidualnych zmian. Ważne jest abyście sprawdzili swoje poprzednie produkcje i mieli to na uwadze zestawiając nowe (jednocześnie zmieniając .htaccess standardowo dostarczany z frameworkiem). W każdym razie zestawienie inne niż kierowanie wszystkiego (z pominięciem np. css/img/js itp.) na index.php może spowodować to, że ów katalog z cache będzie swobodnie dostępny z poziomu przeglądarki, a tym samym dostęp do loginu/hasła do bazy danych stoi otworem ;)

ps. to też jeden z powodów dla którego zawsze sugeruję przenoszenie katalogów z aplikacją i frameworkiem POZA katalog główny (tzw. webroot) dostępny na zewnątrz. W Kohanie jest to bardzo proste do uzyskania: edytujemy plik index.php zmieniając $kohana_application, $kohana_modules i $kohana_system na odpowiednie ścieżki (np. "../enginemojejstrony/application").