Audyt bezpieczeństwa aplikacji PHP: co sprawdzamy, zanim będzie za późno
Większość wycieków w małych i średnich firmach dotyczy starych paneli PHP, o których „wszyscy wiedzą, że działa”. Audyt nie jest oskarżeniem programisty — to lista ryzyk, które da się zamknąć, zanim ktoś je wykorzysta.
Typowy scenariusz: firma ma panel od 2016 roku. Logują się handlowcy, księgowość i czasem stażysta. Hasło administratora jest w mailu. PHP na serwerze ma kilka wersji wstecze. Nikt nie wie, czy są kopie z ostatniego tygodnia. To nie jest zaniedbanie złośliwe — to zwykły dług techniczny. Dopóki nikt nie wejdzie, wszystko „działa”.
Co obejmuje audyt w GESOFT
1. Aplikacja
- Logowanie: brute-force, reset hasła, sesje, czy da się ominąć uprawnienia znając URL.
- Formularze i API: SQL injection, XSS, CSRF, upload plików (czy da się wgrać skrypt).
- Tajemnice w kodzie: hasła do bazy, klucze API, dump-y w publicznym katalogu.
- Uprawnienia ról: czy handlowiec widzi dane, których nie powinien.
- Logi: czy da się odtworzyć, kto usunął rekord.
2. Zależności i wersje
Sprawdzamy wersję PHP, Laravela (albo innego frameworka) i paczek Composer/npm pod kątem znanych CVE. Stary Laravel 5.x albo PHP 7.2 to dziś otwarte drzwi — nawet jeśli kod biznesowy jest „w porządku”.
3. Serwer i wdrożenie
- Czy katalog .env i Git nie są publiczne.
- Czy działa HTTPS, czy da się wejść przez HTTP i wysłać hasło otwartym tekstem.
- Uprawnienia plików, dostęp SSH, firewall, osobny użytkownik bazy z minimalnymi prawami.
- Kopie zapasowe: czy istnieją, czy są poza serwerem, czy ktoś próbował je odtworzyć.
Naprawiać czy pisać od nowa?
Nie każda stara aplikacja zasługuje na rewrite. Jeśli logika biznesowa jest jasna, a dziury da się załatać (aktualizacja PHP, Laravel, logowanie, nagłówki, kopie) — łatamy. Przepisujemy, gdy:
- Framework jest porzucony albo kod to „PHP w jednym pliku” bez testów i bez dokumentacji.
- Nikt nie jest w stanie bezpiecznie dodać nowej funkcji.
- Wymagania RODO (role, usuwanie danych, zgody) wymagają przebudowy modelu danych.
- Koszt kolejnych łatek zbliża się do kosztu nowej, utrzymywalnej wersji.
Nowy system stawiamy na Laravelu i przenosimy dane. Stary panel może działać równolegle przez okres przejściowy.
Jak wygląda współpraca
Potrzebujemy dostępu do kodu (Git albo archiwum) i — do części serwerowej — konta z ograniczonymi uprawnieniami albo rozmowy z administratorem. Podpisujemy NDA. Raport oddajemy w ustalonym terminie, zwykle w ciągu kilku dni roboczych dla typowego panelu.
Jeśli „działa, ale się boisz” — to dobry moment na audyt, nie na dzień po ataku. Napisz, jaki system chcesz sprawdzić. Powiemy, czy wystarczy przegląd, czy od razu plan naprawy.
Opisz projekt