Cybersecurity i pentesting - podstawy

To kompendium służy do rozumienia ryzyka i bezpiecznego testowania własnych systemów. Nie zastępuje profesjonalnego audytu, ale pomaga rozpoznawać klasy podatności, budować threat model i czytać wyniki podstawowych narzędzi.

Powiązane tematy: Bezpieczeństwo aplikacji webowych, Linux permissions i bezpieczeństwo serwera, OAuth 2.0, OpenID Connect, JWT i sesje oraz HTTP, HTTPS i TLS.

1. Cel

To kompendium jest przeznaczone dla developera i osoby odpowiedzialnej za rozwiązania cyfrowe.

Celem nie jest zostanie pentesterem, lecz zrozumienie:

• podstaw bezpieczeństwa,
• typowych ataków,
• sposobu myślenia atakującego,
• metod testowania własnych systemów,
• podstawowych narzędzi bezpieczeństwa,
• dobrych praktyk.

Testy bezpieczeństwa wykonuj wyłącznie na systemach, do których masz uprawnienia.

2. CIA triad

Trzy podstawowe cele bezpieczeństwa:

Confidentiality

Poufność.

Dane widzą tylko uprawnione osoby.

Integrity

Integralność.

Dane nie są nieautoryzowanie modyfikowane.

Availability

Dostępność.

System działa wtedy, gdy jest potrzebny.

3. Threat model

Zanim zaczniesz zabezpieczać system, odpowiedz:

• co chronimy?
• przed kim?
• jakie są możliwe drogi ataku?
• jakie byłyby skutki?
• jakie zabezpieczenia już istnieją?

Przykład:

system:
panel administracyjny

zasoby:
dane klientów

zagrożenia:
kradzież konta administratora

wektory:
brute force
phishing
session theft

zabezpieczenia:
MFA
rate limit
HTTPS
session expiry

4. Attack surface

Powierzchnia ataku to wszystko, co może zostać wykorzystane:

• porty,
• API,
• formularze,
• panele administracyjne,
• konta,
• uploady,
• zależności,
• serwisy zewnętrzne.

Im mniej wystawiasz, tym lepiej.

5. Zasada least privilege

Każdy użytkownik i proces powinien mieć tylko niezbędne uprawnienia.

Dotyczy:

• systemu operacyjnego,
• bazy,
• API,
• kontenerów,
• CI/CD,
• kont cloud.

6. Defense in depth

Nie opieraj bezpieczeństwa na jednej warstwie.

Przykład:

firewall
 + SSH keys
 + MFA
 + aktualizacje
 + monitoring
 + backup

7. Authentication i authorization

Authentication:

kim jesteś?

Authorization:

co wolno ci zrobić?

To dwa różne problemy.

8. Hasła

Dobre praktyki:

• unikalne,
• długie,
• manager haseł,
• MFA,
• brak współdzielenia.

Serwer nie powinien przechowywać hasła plaintext.

Stosuje się bezpieczne funkcje haszujące, np.:

• Argon2id,
• bcrypt,
• scrypt.

9. MFA

MFA znacząco zmniejsza ryzyko przejęcia konta.

Przykłady:

• TOTP,
• hardware key,
• passkeys.

10. Aktualizacje

Duża część realnych ataków wykorzystuje stare podatności.

Regularnie aktualizuj:

• system,
• biblioteki,
• obrazy Docker,
• serwery WWW,
• CMS,
• firmware.

11. Backup

Backup to również element cybersecurity.

Dobre minimum:

• automatyczny,
• poza głównym serwerem,
• wersjonowany,
• testowany.

12. Szyfrowanie

At rest:

dysk
baza
backup

In transit:

TLS / HTTPS
SSH
VPN

13. OWASP Top 10

Developer powinien znać podstawowe klasy problemów:

• broken access control,
• security misconfiguration,
• software supply chain failures,
• cryptographic failures,
• injection,
• insecure design,
• authentication failures,
• software or data integrity failures,
• security logging and alerting failures,
• mishandling of exceptional conditions.

Powyższa lista odpowiada OWASP Top 10:2025. Nie chodzi o zapamiętanie nazw, lecz rozumienie problemu.

14. SQL Injection

Atak wykorzystuje niebezpieczne tworzenie zapytań SQL.

Zabezpieczenie:

• prepared statements,
• parametryzowane query,
• walidacja danych.

15. XSS

Atakujący próbuje uruchomić swój JavaScript w przeglądarce użytkownika.

Zabezpieczenie:

• escaping,
• bezpieczny templating,
• CSP,
• unikanie innerHTML.

16. CSRF

Atak wykorzystuje sesję zalogowanego użytkownika.

Ochrona:

• CSRF tokens,
• SameSite cookies,
• poprawne projektowanie API.

17. SSRF

Atakujący próbuje skłonić backend do wykonania requestu do niedozwolonego celu.

Ochrona:

• allowlist,
• ograniczenie ruchu sieciowego,
• walidacja adresów.

18. Broken access control

Przykład:

/user/123/invoice/99

Backend musi sprawdzić, czy użytkownik naprawdę ma dostęp do faktury 99.

19. Security headers

Przykładowe:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

20. Security testing

Dobre testowanie bezpieczeństwa obejmuje:

recon
 ↓
enumeration
 ↓
analysis
 ↓
validation
 ↓
report
 ↓
fix
 ↓
retest

21. Reconnaissance

W legalnym pentestingu recon oznacza poznawanie systemu.

Przykładowe pytania:

• jakie domeny istnieją?
• jakie usługi są wystawione?
• jakie technologie są używane?
• jaka jest wersja serwera?

22. Nmap

Nmap służy do analizy hostów i portów.

Przykład własnego hosta laboratoryjnego:

nmap 192.168.56.10

Wersje usług:

nmap -sV 192.168.56.10

System operacyjny można próbować rozpoznawać w kontrolowanym środowisku:

sudo nmap -O 192.168.56.10

23. Nikto

Nikto skanuje serwery WWW pod kątem typowych problemów.

Przykład laboratorium:

nikto -h http://192.168.56.10

Nie traktuj wyniku jako automatycznego dowodu podatności.

24. OWASP ZAP

ZAP to proxy i skaner bezpieczeństwa aplikacji WWW.

Może:

• przechwytywać requesty,
• analizować headers,
• wykrywać typowe problemy,
• skanować aplikację testową.

Dobry wybór dla developera.

25. Burp Suite

Burp Suite jest standardowym narzędziem web pentestingu.

Funkcje:

• proxy,
• repeater,
• decoder,
• scanner w wersjach posiadających tę funkcję,
• analiza request/response.

Najbardziej wartościowa funkcja do nauki:

przechwyć request
zmodyfikuj go
wyślij ponownie
obserwuj odpowiedź

26. BeEF

BeEF oznacza Browser Exploitation Framework.

Służy do badań bezpieczeństwa przeglądarek i aplikacji webowych w kontrolowanych laboratoriach.

Może demonstracyjnie pokazać skutki sytuacji, w której atakujący uzyska możliwość wykonywania kodu JavaScript w kontekście przeglądarki.

Dla developera ważniejsza jest lekcja:

XSS może prowadzić do przejęcia zachowania sesji użytkownika

niż samo operowanie frameworkiem.

BeEF najlepiej poznawać wyłącznie w odizolowanym labie.

27. Metasploit

Metasploit Framework służy do badań i testowania znanych podatności.

Developerowi wystarczy rozumieć:

• czym jest exploit,
• czym jest payload,
• czym jest module,
• czym jest session.

Nie jest potrzebny do codziennej pracy przy bezpiecznych aplikacjach.

28. Wireshark

Analizator ruchu sieciowego.

Pozwala oglądać:

• TCP,
• UDP,
• DNS,
• TLS,
• HTTP bez szyfrowania,
• różne protokoły sieciowe.

Przydatny przy troubleshootingu.

29. tcpdump

CLI:

sudo tcpdump -i any

Port:

sudo tcpdump -i any port 443

Host:

sudo tcpdump -i any host 192.168.1.20

30. Gobuster / ffuf

Narzędzia do enumeracji ścieżek i zasobów WWW.

W kontrolowanym labie mogą pomóc znaleźć:

/admin
/backup
/test

Lekcja dla developera:

• nie polegaj na „ukrytych URL-ach” jako zabezpieczeniu,
• usuń stare endpointy,
• zabezpieczaj każdy zasób autoryzacją.

31. curl

Jedno z najważniejszych narzędzi bezpieczeństwa developera.

Headers:

curl -I https://example.com

Verbose:

curl -v https://example.com

Custom header:

curl -H 'X-Test: 1' https://example.com

32. OpenSSL

Test TLS:

openssl s_client -connect example.com:443 -servername example.com

Pozwala obejrzeć:

• certyfikat,
• chain,
• handshake.

33. testssl.sh

Narzędzie do sprawdzania konfiguracji TLS.

Przydatne do własnych serwerów.

Sprawdza m.in.:

• protokoły,
• cipher suites,
• certyfikaty,
• znane problemy TLS.

34. Lynis

Audyt systemu Unix/Linux.

Przykład:

sudo lynis audit system

Zwraca rekomendacje dotyczące hardeningu.

35. Trivy

Skaner:

• obrazów Docker,
• filesystemów,
• dependencies,
• IaC.

Przykład własnego obrazu:

trivy image myapp:latest

36. Dependency scanning

Node:

npm audit

Go:

govulncheck ./...

Python:

pip-audit

37. Secret scanning

Warto sprawdzać repo pod kątem:

• API keys,
• tokenów,
• haseł,
• private keys.

Przykładowe narzędzia:

• Gitleaks,
• TruffleHog.

38. SAST

Static Application Security Testing.

Analizuje kod bez jego uruchamiania.

Przykłady:

• Semgrep,
• CodeQL,
• SonarQube.

39. DAST

Dynamic Application Security Testing.

Testuje działającą aplikację.

Przykłady:

• OWASP ZAP,
• Burp Scanner,
• Nikto.

40. SCA

Software Composition Analysis.

Sprawdza zależności i znane CVE.

Przykłady:

• Dependabot,
• Renovate,
• Trivy,
• Snyk.

41. CVE i CVSS

CVE:

identyfikator znanej podatności

CVSS:

ocena jej potencjalnej istotności

Nie każda wysoka wartość CVSS oznacza, że dana aplikacja jest realnie podatna.

Liczy się:

• konfiguracja,
• ekspozycja,
• wersja,
• sposób użycia.

42. Pentest a vulnerability scan

Vulnerability scan:

automatyczne szukanie znanych problemów

Pentest:

manualna analiza + weryfikacja podatności + ocena ryzyka

Skaner nie zastępuje pentestera.

43. Laboratorium

Najlepszy sposób nauki to własne środowisko.

Można używać celowo podatnych aplikacji:

• OWASP Juice Shop,
• WebGoat,
• DVWA,
• Metasploitable.

Uruchamiaj je w izolowanej sieci lokalnej.

44. Przykładowy lab

VirtualBox / KVM
      |
      +-- Kali / Debian tools
      |
      +-- OWASP Juice Shop
      |
      +-- DVWA

Sieć:

host-only / internal network

Bez publicznego wystawiania podatnych maszyn.

45. Kali Linux

Kali zawiera wiele narzędzi bezpieczeństwa.

Nie jest magicznym systemem „do hackowania”.

To Debian z gotowym zestawem narzędzi.

Do nauki możesz równie dobrze używać zwykłego Debiana i instalować tylko potrzebne programy.

46. Podstawowy workflow testu własnej aplikacji

1. Sprawdź porty:

nmap HOST

2. Sprawdź TLS.

3. Obejrzyj headers.

4. Przejdź aplikację przez proxy ZAP/Burp.

5. Sprawdź auth i authorization.

6. Sprawdź inputy.

7. Przeskanuj dependencies.

8. Przeskanuj obraz Docker.

9. Przejrzyj logi.

10. Zapisz wyniki.

47. Raport z pentestu

Dobry raport zawiera:

nazwa podatności
opis
wpływ
warunki wystąpienia
dowód
ryzyko
rekomendacja
status poprawki

48. Severity

Możesz stosować:

Critical
High
Medium
Low
Informational

Ale oceniaj realny wpływ, a nie tylko wynik skanera.

49. Retest

Po poprawce:

fix
 ↓
retest

Bez retestu nie masz pewności, że problem zniknął.

50. Logging i monitoring

Bezpieczeństwo to również możliwość wykrycia incydentu.

Loguj:

• nieudane logowania,
• zmiany uprawnień,
• błędy auth,
• podejrzane requesty,
• zdarzenia administracyjne.

51. Incident response - minimum

Jeśli coś podejrzewasz:

1. zachowaj logi,
2. ogranicz dostęp,
3. zmień sekrety,
4. sprawdź zakres problemu,
5. usuń przyczynę,
6. odtwórz z bezpiecznego źródła,
7. monitoruj.

52. Dobre praktyki developera

• HTTPS wszędzie,
• parametryzowane SQL,
• bezpieczne cookies,
• sekrety poza repo,
• regularne aktualizacje,
• dependency scanning,
• minimalne permissions,
• brak publicznej bazy,
• firewall,
• backup,
• health checks,
• monitoring,
• code review.

53. Minimalny zestaw narzędzi

Developer:

curl
nmap
OWASP ZAP lub Burp
Trivy
govulncheck / npm audit / pip-audit
Gitleaks
Wireshark lub tcpdump
openssl

Pentest lab:

Burp Suite
OWASP ZAP
Nmap
Nikto
ffuf / Gobuster
Metasploit
BeEF
Wireshark

54. Czego nie robić

Nie testuj:

• cudzych serwerów,
• produkcyjnych usług bez zgody,
• infrastruktury firmy bez autoryzacji,
• przypadkowych adresów IP.

Nawet „tylko skanowanie” może być traktowane jako działanie niepożądane.

55. Najważniejszy mindset

Cybersecurity nie polega na „hakowaniu”.

Polega na zadawaniu pytań:

Co może pójść źle?
Jak ktoś mógłby to wykorzystać?
Jak to wykryję?
Jak ograniczę skutki?
Jak szybko to naprawię?

56. Co powinieneś umieć

Po opanowaniu tego kompendium powinieneś:

• znać podstawowe klasy podatności,
• rozumieć attack surface,
• znać podstawy pentest methodology,
• rozumieć role narzędzi takich jak Nmap, ZAP, Burp, BeEF i Metasploit,
• zbudować bezpieczne laboratorium,
• testować własną aplikację,
• analizować zależności i obrazy,
• rozumieć raport z pentestu,
• stosować podstawowy hardening i monitoring.

Oficjalne źródła

• OWASP Top 10:2025: https://top10.owasp.org/2025/
• OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/