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").