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").
Osobie czytającej tego bloga proponuję sobie przypomnieć podobną sytuację w home.pl i panów którzy chcieli też kasę za ‘pomoc w znalezieniu dziury’ etc – to raczej nie jest dobry pomysł.
Spojrzałem właśnie na dzieła Xanna i katalog /cache jest dostępny z poziomu przeglądarki tak jak napisałeś. Tyle, że tam nie ma chyba cachowania, bo inaczej swl by nie działał. Czyli ogólnie nie powinienem się tym przejmować?
@Paweł: jeżeli nie ma tam (a webcities chyba stoi na wcześniejszej wersji) żadnych plików to i nie ma czego obejrzeć. Nie mniej dla świętego spokoju powinno się blokować bezpośredni dostęp do katalogów /system, /modules, /application.
Ok, dzięki nrm, w wolnej chwili poprawię swoje spamy.
Pingback: Z notatnika webmasterki » Blog Archive » Co trzeba wiedzieć, żeby zacząć pracę z frameworkiem Kohana
O ile samo znalezienie dziury i wskazanie jej właścicielowi jest jeszcze do zaakceptowania (choć z drugiej strony – ciekawe jak zareagowałby sąsiad, gdybyś do niego przyszedł i powiedział: „Pana drzwi da się otworzyć śrubokrętem” – jeden podziękuje i zmieni zamek, a drugi…), o tyle chęć – „wymuszenie” (bo tak brzmią słowa z początku wiadomości) pieniędzy za „poprawę” jest już karygodna (karalna).
Druga sprawa – czy hasło do bazy danych cokolwiek daje? Wszystko zależy od konfiguracji bazy danych – ale żaden porządny admin, nie daje user@’%’. (nie znam kohanaPHP, wiec zakładam, że dostęp tylko do tego uzyskał „klakier”).
Marcinie, ujawnione hasło do bazy danych jest poważnym zagrożeniem dopiero wtedy, gdy na serwerze dostępne jest narzędzie typu phpMyAdmin.
Te skrypty są dostępne publicznie na prawie wszystkich serwerach. Wymyśliłem sobie teraz szybko czterech „hostingodawców” i wpisałem ich domenę wraz z suffiksem /phpmyadmin. U dwóch pokazało się okno logowania.
Cóż.. masz rację, nie przyszło mi do głowy (nie zastanawiałem się nad tym zbyt długo jednakże, pisząc wówczas), że phpmyadmin jest dostępny publicznie
Fakt faktem, w wielu przypadkach można łatwo znaleźć phpmyadmina, choć nie zawsze jest na prostej ścieżce (vide home.pl, gdzie dodatkowo trzeba znać nazwę użytkownika).
Niestety ale w kohanie nie można przenieść katalogów frameworka poza katalog główny. Domyślnie w pliku htaccess jest wpis, który blokuje dostęp do katalogów frameworka.
@snap można. nie jest prawdą co piszesz. testowane wielokrotnie. a co ma domyśny htaccess to koto to tam obchodzi