Bezpieczeństwo aplikacji webowych — SQL Injection, XSS, CSRF, testy penetracyjne i DevSecOps

Poniżej masz praktyczny i uporządkowany przewodnik po najważniejszych zagrożeniach aplikacji webowych (SQLi, XSS, CSRF), metodach testowania (pentesty, SAST/DAST) oraz jak wpleść bezpieczeństwo na stałe w proces wytwarzania oprogramowania (DevSecOps). Skupiam się na przyczynach, demonstracjach (krótkie przykłady), oraz skutecznych technikach zapobiegania i narzędziach — tak, byś mógł szybko zastosować to w praktyce.

1. Zasady ogólne bezpieczeństwa weba

• Zasada najmniejszych uprawnień — komponenty i konta mają tylko te prawa, które są niezbędne.
• Walidacja po stronie serwera — klient może być zmodyfikowany, więc walidacja frontendu to tylko UX, nie zabezpieczenie.
• Fail securely — w razie błędu nie ujawniaj stack trace, konfiguracji ani tajnych danych.
• Logowanie i monitoring — loguj podejrzane zdarzenia (bez ujawniania sekretów) i monitoruj je centralnie.
• Aktualizacje i dependency scanning — podatności w bibliotekach to częsty wektor ataku.

2. SQL Injection (SQLi)

Co to jest

SQL Injection to technika wstrzyknięcia złośliwego kodu SQL przez wejścia aplikacji, pozwalająca na odczyt, modyfikację lub usunięcie danych, a czasem uruchomienie komend systemowych (w zależności od bazy i konfiguracji).

Przykład podatnego kodu (PHP, stare podejście)

// podatne na SQLi
$user = $_GET['user'];
$sql = "SELECT * FROM users WHERE username = '$user'"; 
$result = $db->query($sql);

Jeśli user = admin' OR '1'='1, zapytanie zwróci wszystkie wiersze.

Zabezpieczenia / Mitigacje

1. Parametryzowane zapytania / Prepared Statements — używaj mechanizmów DB drivera.
   • PHP (PDO):

     $stmt = $pdo->prepare('SELECT * FROM users WHERE username = ?');
     $stmt->execute([$user]);
     

2. ORM — używanie sprawdzonych ORM (np. Hibernate, Sequelize, Doctrine) minimalizuje ryzyko, ale uwaga na raw queries.
3. Whitelist walidacja — dopuszczalne wartości (np. typy, formaty) zamiast blacklist.
4. Ogranicz uprawnienia bazy — konto aplikacji powinno mieć minimalne prawa (SELECT/INSERT itd.). Nie używaj konta dbo/sys.
5. WAF / zapory aplikacyjne — przydatne dodatkowo (np. ModSecurity) ale nie zastąpią poprawnego kodu.
6. Least privilege i separacja danych — szyfrowanie wrażliwych pól (np. PII) i maskowanie wyników.

Testowanie SQLi

• Narzędzia: sqlmap, manualne testy, Burp Suite Intruder.
• Sprawdzaj miejsca: pola formularzy, nagłówki (User-Agent), cookies, parametry URL.

3. Cross-Site Scripting (XSS)

Typy XSS

1. Stored (persistent) — złośliwy skrypt zapisany w bazie i serwowany innym użytkownikom. Najgroźniejszy.
2. Reflected (non-persistent) — payload od razu odbijany w odpowiedzi (np. w parametrach GET).
3. DOM-based — podatność po stronie klienta — skrypt modyfikuje DOM z wejściem użytkownika bez sanitacji.

Przykład podatności (reflected)

<!-- serwer zwraca parametr name bez sanitacji -->
Hello, <?php echo $_GET['name']; ?>!

Jeśli name=<script>alert(1)</script>, skrypt wykona się w przeglądarce.

Mitigacje / Obrona

1. Output encoding / escaping — escape dla kontekstu: HTML, attribute, JavaScript, URL, CSS. Używaj bibliotek templatingowych, które domyślnie escapują (np. Mustache, Twig, Razor).
2. Content Security Policy (CSP) — ogranicza skąd mogą być ładowane skrypty i inne zasoby; użyteczny jako dodatkowa warstwa. Nawet script-src 'self' + nonces może poważnie ograniczyć XSS.
3. HTTPOnly i Secure cookies — HttpOnly zapobiega odczytowi ciasteczek przez JS (co utrudnia kradzież sesji).
4. Sanityzacja danych wejściowych — dozwolone formaty, długości, regexpy; ale escaping przy wyjściu jest kluczowy.
5. Unikaj eval()/innerHTML — zwłaszcza z danymi z zewnątrz.

Testowanie XSS

• Narzędzia: Burp Suite, OWASP ZAP, ręczne payloady (np. "><script>alert(1)</script>), DOM inspection, CSP testing.

4. Cross-Site Request Forgery (CSRF)

Co to jest

CSRF to atak, który wykorzystuje zaufanie aplikacji do przeglądarki zalogowanego użytkownika — złośliwa strona może spowodować, że przeglądarka wykona działanie (POST/GET) w imieniu użytkownika (np. przelew, zmiana hasła).

Mitigacje

1. CSRF tokens (synchronizer token pattern) — unikalny, trudny do przewidzenia token wysyłany w formularzach i weryfikowany po stronie serwera.
2. SameSite cookies — ustaw SameSite=Lax lub SameSite=Strict (Lax jest często kompromisem dla funkcjonalności).
3. CORS — prawidłowa konfiguracja Cross-Origin Resource Sharing ogranicza, które domeny mogą wykonywać żądania z przeglądarki (szczególnie przy credentials).
4. Double Submit Cookie — token w ciasteczku i w body; serwer porównuje.
5. Weryfikacja Referer/Origin — sprawdzanie nagłówka Origin/Referer (nie zawsze w 100% pewne, ale pomocne).

HTML example (token)

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="{{csrf_token}}">
  <!-- ... -->
</form>

Serwer sprawdza zgodność csrf_token z wartością przechowywaną w sesji.

5. Testy penetracyjne aplikacji webowych (pentesty)

Cele pentestu

• Odkryć luki (SQLi, XSS, auth bypass, IDOR, SSRF itd.)
• Ocenić ryzyko i potencjalny wpływ
• Zaproponować poprawki i rekomendacje

Typy testów

• Black-box — bez wiedzy o systemie (symuluje zewnętrznego atakującego).
• White-box — pełna wiedza (kody źródłowe, konfiguracje).
• Gray-box — częściowa wiedza (np. konto użytkownika).

Proces pentestu (skrócony)

1. Discovery: inwentaryzacja URL, subdomen, API, endpoints (nmap, whatweb, directory brute forcing).
2. Mapping: identyfikacja parametrów, punktów wejścia, auth flows.
3. Vulnerability scanning: automaty (OWASP ZAP, Nikto), ale nie polegaj tylko na nich.
4. Manual exploitation: SQLi, XSS, auth bypass, IDOR, SSRF, file upload.
5. Post-exploitation: eskalacja, pivot, exfiltration (z symulacją).
6. Raportowanie: CVSS, kroki reproducible, rekomendacje naprawcze.

Narzędzia (przydatne)

• Burp Suite (Professional -> dużo funkcji; Community też pomocna), OWASP ZAP
• sqlmap, Nikto, wpscan (WordPress), nmap
• ffuf/dirbuster/gobuster (fuzzing katalogów)
• Amass, Subfinder (subdomain enumeration)
• Metasploit (w określonych scenariuszach)
• Postman / Insomnia (testowanie API)

6. DevSecOps — wplecenie bezpieczeństwa w CI/CD

Celem DevSecOps jest przesunięcie bezpieczeństwa „w lewo” (shift-left) — wykrywanie i zapobieganie problemom już na etapie developmentu.

Kluczowe praktyki

1. SAST (Static Application Security Testing) — analiza kodu źródłowego (np. SonarQube, Semgrep, Brakeman, Bandit). Wykrywa wzorce podatne na SQLi, XSS, brak walidacji.
2. DAST (Dynamic Application Security Testing) — skan aplikacji działającej (OWASP ZAP, Burp).
3. SCA (Software Composition Analysis) — skan zależności pod kątem znanych CVE (Snyk, Dependabot, OSS Index, Whitesource).
4. IaC Security — skanowanie Terraform/CloudFormation/Helm (tfsec, checkov) przed deployem.
5. Secret scanning — wykrywanie sekretów w repozytoriach (git-secrets, truffleHog).
6. Secured CI/CD pipelines — ogranicz dostęp do pipeline, podpisy artefaktów, skany image’ów kontenerów (Clair, Trivy).
7. Automatyczne testy bezpieczeństwa — integracja SAST/DAST/SCA w pipeline jako zadania, gating (blokada deployu przy krytycznych lukach).
8. Threat modeling — regularnie wykonuj threat modeling (STRIDE, PASTA) podczas tworzenia designu.
9. Runtime protection / RASP / WAF — monitorowanie i ochrona podczas działania (runtime application self-protection, Web Application Firewall).
10. Blue/Green, Canary deploys + monitoring — szybkie wycofanie zmian i obserwacja telemetrii bezpieczeństwa.

Przykładowy CI workflow (skrót)

• Commit -> unit tests -> SAST (Semgrep) -> build -> SCA (Snyk) -> container scan (Trivy) -> push image -> deploy to staging -> DAST (OWASP ZAP baseline) -> manual review -> deploy to prod.

7. Najczęściej spotykane dodatkowe luki i tematy

• Insecure Direct Object References (IDOR) — brak autoryzacji przy dostępie do zasobów (np. /files/1234).
• Server-Side Request Forgery (SSRF) — serwer wykonuje żądania do zewnętrznych/internal usług.
• Insecure deserialization — wykonanie złośliwych obiektów deserializowanych po stronie serwera.
• File upload vulnerabilities — umożliwiają upload webshelli; waliduj typy i trzymać pliki poza katalogiem wykonywalnym.
• Authentication & session management — złe przechowywanie haseł (bez bcrypt/argon2), słabe resetowanie haseł, przewidywalne session IDs.

8. Praktyczne checklisty (do szybkiej weryfikacji)

Dev / Code review checklist (krótkie)

• Używane są prepared statements dla zapytań DB?
• Escape output dla kontekstu (HTML, JS, attributes)?
• CSRF tokeny w formach zmieniających stan?
• Walidacja i sanityzacja danych wejściowych po stronie serwera?
• Brak wycieków poufnych w logach?
• Hasła/hasełki zabezpieczone Argon2/Bcrypt/PBKDF2?
• Zależności zaktualizowane i bez krytycznych CVE?

Pentest quick checklist

• Testy SQLi, XSS (all inputs), CSRF, IDOR, SSRF, insecure file upload, auth bypass.
• Sprawdź nagłówki bezpieczeństwa: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security.
• Test sesji: HttpOnly, Secure, SameSite, expiry.
• Test rate limiting, brute force protection.

9. Narzędzia rekomendowane (skrót)

• SAST: Semgrep, SonarQube, Bandit, Checkmarx
• SCA: Snyk, Dependabot, OWASP Dependency-Check
• DAST / pentesting: Burp Suite, OWASP ZAP, sqlmap, Nikto
• Container/IaC: Trivy, Clair, Checkov, tfsec
• Runtime / WAF: ModSecurity, OWASP CRS, Cloud WAF (Cloudflare, AWS WAF)
• Monitoring / SIEM: ELK, Splunk, CrowdStrike, Falco (Runtime for containers)

10. Rekomendacje i dobre praktyki podsumowujące

1. Shift-left — bezpieczeństwo w fazie projektowania i developmentu.
2. Defense-in-depth — nie polegaj na jednej warstwie (CSP + escaping + WAF + monitoring).
3. Automatyzacja testów i skanów — CI/CD to miejsce na SAST/SCA/DAST.
4. Regularne pentesty i bug bounty — zewnętrzna ocena uzupełnia wewnętrzne testy.
5. Edukacja zespołu — szkolenia secure coding, code review, threat modeling.

Polecane wpisy

Przewodnik Zabezpieczeń systemu Windows 8 oraz Windows 8.1

Przewodnik przedstawia funkcjonalności, zwiększające poziom zabezpieczeń systemów Windows 8, zawiera instrukcje i rekomendacje, które pomogą wzmocnić poziom zabezpieczenia komputerów stacjonarnych Czytaj dalej

Ataki CSRF – czym są i jak się przed nimi chronić

Ataki CSRF – czym są i jak się przed nimi chronić CSRF (Cross-Site Request Forgery) to rodzaj ataku na aplikacje Czytaj dalej