Dlatego pytania związane z bezpieczeństwem coraz częściej mogą pojawiać się również podczas rozmów technicznych.
Programista nie musi być specjalistą offensive security. Powinien jednak rozumieć, dlaczego samo sprawdzenie, czy użytkownik jest zalogowany, nie zawsze oznacza poprawną autoryzację, dlaczego walidacja wykonywana wyłącznie w przeglądarce nie chroni backendu i czemu pozornie niewielki błąd może stać się elementem większego scenariusza ataku.
W przypadku bardziej doświadczonych kandydatów rekruter może nie pytać:
„Co to jest Broken Access Control?”
Zamiast tego może przedstawić konkretny przypadek:
Użytkownik A jest poprawnie zalogowany i zna identyfikator dokumentu użytkownika B. Co powinien zrobić backend, aby uniemożliwić mu odczytanie tego dokumentu?
Takie pytanie sprawdza nie tylko znajomość definicji, ale przede wszystkim sposób myślenia o bezpieczeństwie aplikacji.
Poniżej znajduje się 15 zagadnień, które warto znać przed rozmową techniczną.
1. Czym różni się uwierzytelnianie od autoryzacji?
To jedno z najbardziej podstawowych, ale jednocześnie bardzo ważnych pytań.
Uwierzytelnianie — authentication odpowiada na pytanie:
Kim jesteś?
System może potwierdzić tożsamość użytkownika za pomocą:
loginu i hasła,
tokenu,
kodu jednorazowego,
certyfikatu,
klucza sprzętowego,
mechanizmu biometrycznego.
Autoryzacja — authorization odpowiada natomiast na pytanie:
Co wolno ci zrobić?
Użytkownik może być poprawnie uwierzytelniony, ale nadal nie powinien mieć dostępu do wszystkich danych i funkcji systemu.
Przykład:
Klient banku jest poprawnie zalogowany.
Nie oznacza to jednak, że może pobierać historię rachunku innego klienta.
Dobra odpowiedź na rozmowie może brzmieć:
Uwierzytelnianie potwierdza tożsamość użytkownika, natomiast autoryzacja sprawdza, czy ma on prawo wykonać konkretną operację na konkretnym zasobie.
To rozróżnienie jest podstawą wielu dalszych zagadnień bezpieczeństwa.
2. Co to jest Broken Access Control?
Broken Access Control oznacza nieprawidłowe egzekwowanie zasad dostępu do danych lub funkcji.
Wyobraźmy sobie endpoint:
GET /api/invoices/1042
Użytkownik posiada fakturę o identyfikatorze 1042.
Zmienia jednak adres na:
GET /api/invoices/1043
i otrzymuje dokument należący do innego klienta.
Problemem nie jest tutaj brak logowania.
Użytkownik może być poprawnie uwierzytelniony.
Problem polega na tym, że backend nie sprawdził, czy ma prawo do konkretnego dokumentu.
Dlatego kontrola dostępu powinna być realizowana po stronie serwera dla każdej operacji wymagającej uprawnień.
Nie wystarczy wiedzieć:
„Czy użytkownik jest zalogowany?”
Trzeba również odpowiedzieć:
„Czy ten konkretny użytkownik może wykonać tę konkretną operację na tym konkretnym obiekcie?”
3. Dlaczego ukrycie przycisku w frontendzie nie jest zabezpieczeniem?
Załóżmy, że aplikacja pokazuje przycisk:
„Usuń użytkownika”
wyłącznie administratorowi.
W interfejsie zwykłego użytkownika przycisku nie ma.
Czy to oznacza, że funkcja jest zabezpieczona?
Nie.
Jeżeli endpoint:
DELETE /api/users/123
nie sprawdza uprawnień po stronie backendu, użytkownik może wysłać żądanie samodzielnie.
Nie musi korzystać z interfejsu stworzonego przez developerów.
Może wykorzystać:
DevTools,
curl,
Postmana,
proxy przechwytujące ruch,
własny skrypt.
Frontend może ograniczać to, co użytkownik widzi.
Nie powinien jednak decydować o tym, co użytkownik może faktycznie zrobić.
Kontrola uprawnień musi odbywać się po stronie serwera.
4. Co to jest SQL Injection?
SQL Injection występuje wtedy, gdy dane kontrolowane przez użytkownika mogą wpłynąć na strukturę zapytania SQL.
Niebezpieczny przykład:
"SELECT * FROM users WHERE email = '" + email + "'"
Jeżeli wartość przesłana przez użytkownika zostaje bezpośrednio dołączona do zapytania, może pojawić się możliwość zmiany jego znaczenia.
Podstawową ochroną są między innymi:
parametryzowane zapytania,
prepared statements,
właściwie używane ORM-y,
ograniczenie uprawnień konta bazy danych.
Warto pamiętać, że ręczne blokowanie wybranych znaków zwykle nie jest właściwą strategią.
Bezpieczniejsze podejście polega na oddzieleniu:
danych
od
struktury zapytania.
5. Czym jest Cross-Site Scripting?
Cross-Site Scripting, czyli XSS, polega na doprowadzeniu do wykonania niebezpiecznego kodu w kontekście strony odwiedzanej przez użytkownika.
Może do tego dojść wtedy, gdy aplikacja pobiera dane kontrolowane przez użytkownika i umieszcza je w dokumencie HTML bez odpowiedniego zabezpieczenia.
Skutki mogą obejmować między innymi:
zmianę zawartości strony,
wykonywanie działań w kontekście użytkownika,
dostęp do informacji dostępnych dla skryptu,
phishing wewnątrz zaufanej aplikacji.
Ochrona zależy od konkretnego kontekstu.
Istotne są między innymi:
poprawne kodowanie danych wyjściowych,
unikanie niebezpiecznego wstawiania HTML,
odpowiednie wykorzystanie mechanizmów frameworka,
Content Security Policy.
Na rozmowie warto podkreślić, że zabezpieczenie przed XSS nie sprowadza się do jednej funkcji filtrującej dane.
6. Czym jest CSRF?
Cross-Site Request Forgery polega na wykorzystaniu faktu, że przeglądarka użytkownika posiada już aktywną sesję w danej aplikacji.
Atakujący próbuje doprowadzić do wysłania niepożądanego żądania w imieniu zalogowanego użytkownika.
Przykładowo może chodzić o:
zmianę adresu e-mail,
wykonanie określonej operacji,
modyfikację ustawień konta.
Mechanizmy ochronne mogą obejmować:
tokeny CSRF,
odpowiednie ustawienie SameSite dla cookies,
sprawdzanie pochodzenia żądania,
właściwy projekt API.
Warto przy tym zauważyć, że dokładne ryzyko zależy od sposobu uwierzytelniania aplikacji.
7. Jak powinno się przechowywać hasła?
Hasła nie powinny być przechowywane w bazie danych jako zwykły tekst.
Nie powinno się ich również zabezpieczać wyłącznie mechanizmem szyfrowania, który można później odwrócić.
Stosuje się funkcje przeznaczone specjalnie do hashowania haseł, na przykład:
Argon2,
bcrypt,
scrypt,
PBKDF2.
Istotne znaczenie mają również:
indywidualna sól,
odpowiedni koszt obliczeniowy,
możliwość zmiany parametrów wraz ze wzrostem mocy sprzętu.
Celem jest utrudnienie masowego odgadywania haseł w sytuacji, gdy baza danych zostanie przejęta.
8. Czy JWT jest bezpieczniejszy od klasycznej sesji?
To dobre pytanie, ponieważ nie ma tutaj prostej odpowiedzi:
„tak” albo „nie”.
JWT nie jest automatycznie bezpieczniejszy od sesji.
Jest innym sposobem przekazywania informacji dotyczących użytkownika i jego uprawnień.
Bezpieczeństwo zależy od implementacji.
W przypadku JWT trzeba zwrócić uwagę między innymi na:
sposób podpisywania tokenu,
weryfikację podpisu,
termin ważności,
issuer,audience,zakres uprawnień,
sposób przechowywania tokenu,
mechanizm odświeżania,
możliwość unieważnienia.
Warto również wiedzieć, że standardowy JWT nie musi być zaszyfrowany.
Podpis tokenu ma inne zadanie niż ukrywanie jego treści.
9. Co oznacza zasada least privilege?
Zasada najmniejszych uprawnień oznacza, że użytkownik, aplikacja lub proces powinny posiadać tylko taki zakres uprawnień, jaki jest rzeczywiście potrzebny.
Przykład:
Aplikacja potrzebuje:
odczytać rekord,
dodać rekord,
zmodyfikować rekord.
Nie oznacza to automatycznie, że jej konto w bazie danych powinno posiadać pełne uprawnienia administratora.
Ta sama zasada dotyczy:
użytkowników,
administratorów,
mikroserwisów,
kont technicznych,
systemów CI/CD.
Ograniczenie uprawnień zmniejsza potencjalne skutki błędu lub przejęcia konta.
10. Co to jest SSRF?
Server-Side Request Forgery występuje wtedy, gdy użytkownik może wpłynąć na adres zasobu pobieranego przez serwer.
Przykład:
Aplikacja posiada funkcję:
„Pobierz obraz z podanego adresu URL.”
Użytkownik zamiast publicznego obrazu podaje adres prowadzący do zasobu dostępnego wyłącznie z sieci wewnętrznej.
Jeżeli mechanizm nie jest odpowiednio zabezpieczony, serwer może zostać wykorzystany jako pośrednik.
Ochrona może obejmować między innymi:
ograniczenie dozwolonych hostów,
blokowanie prywatnych zakresów adresów,
kontrolę protokołów,
kontrolę przekierowań,
odpowiednią segmentację sieci.
Na rozmowie technicznej szczególnie dobrze wygląda odpowiedź pokazująca, że kandydat rozumie różnicę między żądaniem wykonywanym przez przeglądarkę a żądaniem wykonywanym bezpośrednio przez backend.
11. Dlaczego walidacja po stronie klienta nie wystarcza?
Frontend może sprawdzać:
wymagane pola,
format adresu e-mail,
minimalną długość,
zakres liczbowy.
Takie mechanizmy są bardzo przydatne dla UX.
Nie są jednak wystarczającym zabezpieczeniem.
Użytkownik może całkowicie pominąć frontend i wysłać żądanie bezpośrednio do API.
Dlatego wszystkie istotne ograniczenia muszą zostać zweryfikowane również po stronie serwera.
Można przyjąć prostą zasadę:
backend nie powinien ufać danym tylko dlatego, że zostały wcześniej sprawdzone w interfejsie użytkownika.
12. Co to jest rate limiting i po co się go stosuje?
Rate limiting ogranicza liczbę operacji wykonywanych przez określonego użytkownika, adres IP, token lub inny identyfikator w określonym czasie.
Może pomagać ograniczać między innymi:
brute force,
automatyczne zgadywanie kodów,
nadmierne użycie API,
masowe pobieranie danych,
część ataków przeciążeniowych.
Przykład:
Endpoint resetowania hasła pozwala na wpisanie sześciocyfrowego kodu.
Jeżeli można sprawdzić milion kodów bez żadnego ograniczenia, bezpieczeństwo mechanizmu będzie zupełnie inne niż w sytuacji, gdy liczba prób jest kontrolowana.
Rate limiting nie powinien być jednak jedynym zabezpieczeniem.
Najczęściej stanowi część większej strategii.
13. Jak bezpiecznie obsługiwać upload plików?
Upload plików jest jednym z miejsc wymagających szczególnej ostrożności.
Nie wystarczy sprawdzić, czy nazwa pliku kończy się na .jpg.
Warto kontrolować między innymi:
dopuszczalny typ pliku,
maksymalny rozmiar,
rzeczywistą zawartość,
nazwę pliku,
miejsce zapisu,
sposób późniejszego udostępniania,
możliwość wykonania przesłanego pliku.
Ważne jest również oddzielenie danych przesyłanych przez użytkowników od elementów aplikacji, które serwer może wykonywać jako kod.
14. Czym różni się skaner podatności od testu penetracyjnego?
To pytanie bardzo dobrze sprawdza praktyczne rozumienie bezpieczeństwa.
Automatyczny skaner może szybko:
analizować dużą liczbę zasobów,
wykrywać znane klasy podatności,
sprawdzać konfigurację,
wykrywać określone wersje podatnych komponentów.
Test penetracyjny ma inny cel.
Pentester może próbować:
zweryfikować, czy podatność rzeczywiście da się wykorzystać,
analizować różne role użytkowników,
sprawdzać logikę biznesową,
łączyć kilka słabości w jeden scenariusz,
określać potencjalny wpływ problemu.
Właśnie ten obszar jest jednym z głównych elementów działalności Pentestica jako firmy specjalizującej się w testach bezpieczeństwa aplikacji, API i infrastruktury.
Można więc powiedzieć:
skaner wskazuje potencjalny problem, a pentest próbuje ustalić, co faktycznie może zrobić z nim napastnik.
15. Jak developer powinien reagować na wykrytą podatność?
Podatność nie powinna być traktowana jako osobista porażka autora kodu.
Znacznie ważniejsze jest odpowiednie przeprowadzenie procesu naprawczego.
W praktyce może on wyglądać następująco:
potwierdzenie podatności,
zrozumienie jej przyczyny,
określenie wpływu,
przygotowanie poprawki,
wdrożenie testu regresyjnego,
ponowna weryfikacja po poprawce.
Jeżeli przyczyną problemu był błąd projektowy, warto przeanalizować również inne miejsca korzystające z podobnego mechanizmu.
Przykład:
Jeżeli jeden endpoint nie sprawdzał właściciela obiektu, nie należy automatycznie zakładać, że pozostałe endpointy robią to prawidłowo.
Jak odpowiadać na pytania dotyczące bezpieczeństwa?
Nie trzeba znać na pamięć wszystkich nazw podatności.
Znacznie ważniejsze jest pokazanie właściwego sposobu analizowania problemu.
Można posłużyć się prostym schematem.
Co kontroluje użytkownik?
Czy może zmieniać:
parametr,
identyfikator,
nagłówek,
treść żądania,
kolejność wykonywanych operacji?
Gdzie znajduje się granica zaufania?
Czy dane przechodzą:
z przeglądarki do API,
z API do bazy danych,
z jednej usługi do drugiej,
z publicznej sieci do środowiska wewnętrznego?
Co sprawdza backend?
Czy backend weryfikuje jedynie tożsamość?
Czy również uprawnienia do konkretnego zasobu?
Co stanie się, gdy użytkownik pominie przewidziany interfejs?
Czy operację można wykonać bezpośrednim żądaniem?
Jaki może być rezultat?
Czy potencjalnym skutkiem jest:
dostęp do cudzych danych,
modyfikacja informacji,
wykonanie nieautoryzowanej operacji,
eskalacja uprawnień,
przejęcie konta?
Takie rozumowanie często mówi rekruterowi więcej niż znajomość definicji słowo w słowo.
Bezpieczeństwo aplikacji nie jest już wyłącznie zadaniem działu security
Współczesny developer podejmuje każdego dnia decyzje, które mogą wpływać na bezpieczeństwo całego systemu.
Dotyczą one między innymi:
logowania,
autoryzacji,
API,
walidacji danych,
przechowywania informacji,
konfiguracji usług,
obsługi błędów,
komunikacji pomiędzy systemami,
zarządzania sekretami.
Dlatego bezpieczeństwo coraz częściej staje się częścią całego cyklu tworzenia oprogramowania, a nie jedynie kontrolą wykonywaną tuż przed wdrożeniem.
Wiedza pentestera i developera różni się zakresem, ale obie perspektywy uzupełniają się.
Developer najczęściej pyta:
„Jak użytkownik powinien korzystać z tej funkcji?”
Specjalista od testów bezpieczeństwa pyta:
„Co stanie się, jeśli użytkownik spróbuje zrobić coś zupełnie innego?”
I właśnie taka zmiana perspektywy może być szczególnie wartościowa podczas rozmowy technicznej.
Nie trzeba od razu zostać pentesterem.
Warto jednak nauczyć się patrzeć na własny kod również oczami osoby, która będzie próbowała znaleźć w nim nieprzewidzianą ścieżkę.
To podejście pomaga nie tylko lepiej odpowiadać na pytania rekrutacyjne.
Przede wszystkim pomaga tworzyć bezpieczniejsze aplikacje.
