Bezpieczeństwo internetowe i OWASP — błędy, których szukają atakujący

Każda aplikacja internetowa otwarta dla internetu jest testowana przez automatyczne narzędzia i ciekawe osoby przez całą dobę. Bezpieczeństwo nie jest zatem czymś, o czym myślisz, gdy strona jest gotowa — to sposób pisania kodu od pierwszego wiersza. Dobrym wytyczną jest OWASP (Open Worldwide Application Security Project), organizacja non-profit, która publikuje szeroko uznaną listę, OWASP Top 10, najistotniejszych zagrożeń bezpieczeństwa w aplikacjach internetowych. To nie jest prawo, ale wspólne pojęcie, na podstawie którego branża mówi.

Czerwona nić przez prawie wszystkie luki bezpieczeństwa w sieci web to zaufanie do danych pochodzących z zewnątrz. Wszystko, co pochodzi z przeglądarki — pola formularza, pasek adresu, parametry, pliki cookie, nagłówki — może być manipulowane. Atakujący niekoniecznie korzysta z twojego ładnego interfejsu użytkownika; wysyłają dane bezpośrednio do serwera. Dlatego wszystkie dane wejściowe muszą być zwalidowane i oczyszczone na serwerze, zanim zostaną użyte, zapisane lub wyświetlone ponownie. Walidacja na frontendu jest pomocą dla uczciwego użytkownika, nie obroną przed nieuczciwym.

Najczęstszym poważnym błędem jest to, że kontrolę dostępu można obejść: użytkownik może zobaczyć lub zmienić coś, czego nie powinien. Klasycznym przykładem jest możliwość zmiany identyfikatora w pasku adresu i zobaczenia danych innej osoby, ponieważ serwer nie sprawdza, czy zalogowany użytkownik faktycznie posiadł to. Zasadą jest, że każda pojedyncza akcja musi sprawdzić na serwerze, czy aktualny użytkownik ma prawo - nie wystarczy ukryć przycisk w interfejsie użytkownika. Załóż, że wszystko, co nie jest wyraźnie zaznaczone, jest otwarte.

Wstrzykiwanie występuje, gdy dane od użytkownika są interpretowane jako część komendy zamiast czystych danych. Klasycznym przypadkiem jest zapytanie do bazy danych, gdzie tekst użytkownika jest wstawiony bezpośrednio do zapytania, dzięki czemu atakujący może zmienić, co robi zapytanie. Obrona polega na oddzieleniu kodu od danych: użyj sparametryzowanych zapytań (zwanych również prepared statements), gdzie dane wejściowe użytkownika są zawsze traktowane jako wartość, nigdy jako komenda. Ta sama logika dotyczy wszędzie, gdzie dane wejściowe kończą się w komendzie — to jest princip, nie pojedynczy system, który powinieneś zrozumieć.

XSS pojawia się, gdy tekst atakującego jest pokazywany na stronie i uruchamiany jako kod w przeglądarce innego użytkownika — na przykład poprzez komentarz zawierający skrypt. Rezultatem może być to, że atakujący kradnie sesje lub handluje w imieniu ofiary. Obrona polega na traktowaniu wszystkich treści użytkownika jako tekstu, gdy jest wyświetlana: odpowiednio je ucieć, aby znaki były wyświetlane jako znaki, a nie wykonane. Używaj mechanizmów, które oferuje Twój framework do bezpiecznego drukowania, zamiast wstawiać surowy tekst bezpośrednio na stronę.

Lista grupuje powtarzające się zagrożenia w kategoriach. Nie musisz ich znać na pamięć, ale są dobrym podstawą sprawdzania, gdy przeglądasz aplikację.

Nigdy nie przechowuj haseł w tekście jawnym. Muszą być szyfrowane algorytmem zbudowanym do tego celu i celowo wolnym, oraz ze smakiem, aby jedno hasło nie dawało tego samego skrótu. Sesje muszą być chronione, aby nie mogły być kradzież lub zgadnięte, i sesja powinna wygasać i kończyć się przy wylogowaniu. Klucze dostępu, klucze API i inne tajemnice nigdy nie powinny być na frontendu lub w kontroli wersji — powinny być na serwerze, poza tym, co użytkownik może zobaczyć.

Żaden pojedynczy nawyk nie czyni aplikacji bezpieczną. To suma: walidacja na serwerze, kontrola dostępu na każdą akcję, rozdzielenie kodu od danych, wyświetlanie zawartości użytkownika jako tekstu, utrzymywanie zależności w aktualnym stanie, ochrona logowania i tajemnic, oraz wystarczająco dużo logowania, aby móc wykryć atak. Jeśli uczynimy je odruchowymi reakcjami, zamykamy większość dziur, przed którymi ostrzega lista OWASP — długo przed tym, zanim atakujący je znajdzie.

“Bezpieczne aplikacje internetowe nie są budowane przez dodanie bezpieczeństwa na koniec, ale poprzez niedowierzanie wszelkim danym wejściowym od pierwszej linii kodu.”

— Powszechna reguła nauczycielskiego bezpieczeństwa