CompTIA SY0-701: Bezpieczeństwo aplikacji i webowe — Przewodnik do nauki

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Część CompTIA Security+ SY0-701 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów CompTIA, albo rozwiąż testy na czas na ExamRoll.io.

Współczesne aplikacje znajdują się na styku logiki biznesowej, wrażliwych danych i niezaufanych danych wejściowych od użytkownika. Ponieważ frontendy webowe i mobilne są wystawione na cały internet, stanowią jedną z największych i najczęściej wykorzystywanych powierzchni ataku w każdym przedsiębiorstwie. Ich obrona wymaga warstwowych zabezpieczeń, które zaczynają się od sposobu pisania kodu, a kończą na ochronie w czasie wykonania, weryfikacji integralności i ciągłym testowaniu.

Ataki typu Injection

Ataki typu injection (wstrzykiwania) pozostają archetypową podatnością webową. Występują, gdy aplikacja łączy niezaufane dane wejściowe z poleceniem dla interpretera — zapytaniem SQL, poleceniem powłoki, filtrem LDAP, parserem XML czy silnikiem szablonów — bez odpowiedniego oddzielenia kodu od danych. W ataku SQL injection (SQLi) atakujący manipuluje zapytaniem w taki sposób, aby baza danych wykonała logikę kontrolowaną przez niego. Klasyczny podatny wzorzec w PHP wygląda następująco:

$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";

Przesłanie admin' OR '1'='1 przekształca zapytanie w tautologię, która zwraca wszystkie wiersze. Bardziej zaawansowane warianty obejmują ekstrakcję danych opartą na operatorze UNION (' UNION SELECT credit_card FROM payments--), ślepą inferencję opartą na wartościach logicznych (Boolean) lub na czasie (' AND SLEEP(5)--) oraz eksfiltrację danych metodą out-of-band poprzez wywołania zwrotne DNS. Ostatecznym rozwiązaniem są zapytania sparametryzowane lub prepared statements, które wysyłają szablon zapytania i jego parametry do bazy danych jako oddzielne struktury:

cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))

Atak command injection działa według tego samego wzorca, ale jest wymierzony w powłokę systemu operacyjnego. Kod taki jak os.system("ping " + host) pozwala atakującemu na przesłanie 8.8.8.8; cat /etc/passwd i wykonanie dowolnych poleceń. Rozwiązanie problemu wymaga całkowitego unikania wywoływania powłoki, używania API, które akceptują tablice argumentów (subprocess.run(["ping", host], shell=False)), oraz stosowania rygorystycznej walidacji w oparciu o listę dozwolonych wartości (allow-list) dla każdej wartości, która musi trafić do powłoki.

Cross-Site Scripting i CSRF

Cross-site scripting (XSS) to wstrzyknięcie złośliwego skryptu na strony renderowane przez zaufaną aplikację, co powoduje, że przeglądarka ofiary wykonuje kod atakującego w ramach tej samej domeny (origin). Reflected XSS (odbity) polega na odbiciu payloadu od podatnego parametru; stored XSS (przechowywany) utrwala payload w bazie danych i dostarcza go każdemu, kto wyświetli stronę; DOM-based XSS zachodzi w całości w kodzie JavaScript po stronie klienta, który zapisuje niezaufane dane do innerHTML, document.write lub podobnych „ujść” (sinks). Konsekwencje sięgają od przejęcia sesji i keyloggingu po pełne przejęcie konta poprzez wymuszone akcje.

Cross-site request forgery (CSRF) to odrębny, ale uzupełniający się atak. Wykorzystuje on automatyczne dołączanie plików cookie przez przeglądarkę, aby nakłonić uwierzytelnionego użytkownika do wysłania niechcianego żądania — na przykład ukryty formularz na złośliwej stronie, który wysyła żądanie POST do bank.com/transfer. Zabezpieczenia obejmują tokeny synchronizujące (losowe wartości na sesję, osadzone w formularzach i weryfikowane po stronie serwera), atrybut SameSite=Lax lub SameSite=Strict dla plików cookie oraz wymaganie ponownego uwierzytelnienia przy wrażliwych akcjach. XSS i CSRF są często mylone, ale XSS wykonuje kod w przeglądarce ofiary, podczas gdy CSRF jedynie powoduje, że przeglądarka wysyła żądanie; co istotne, udany atak XSS może obejść większość zabezpieczeń przed CSRF.

Bezpieczne programowanie: Walidacja danych wejściowych a kodowanie danych wyjściowych

Te dwa mechanizmy kontrolne są często mylone, a jednak rozwiązują różne problemy. Walidacja danych wejściowych (input validation) zapewnia, że dane są zgodne z oczekiwaną strukturą — długość, typ, zestaw znaków, zakres, format — zanim aplikacja zacznie na nich operować. Powinna odbywać się po stronie serwera, w miarę możliwości z użyciem list dozwolonych (allow-lists) (^[A-Za-z0-9_]{3,20}$ dla nazwy użytkownika). Walidacja po stronie klienta za pomocą JavaScript jest jedynie funkcją poprawiającą użyteczność; można ją ominąć za pomocą dowolnego proxy HTTP i nigdy nie może stanowić granicy bezpieczeństwa.

Kodowanie danych wyjściowych (output encoding) zapewnia, że dane są bezpiecznie renderowane w dowolnym kontekście, w którym się znajdą. Ten sam ciąg znaków, który jest całkowicie poprawnymi danymi wejściowymi, może wymagać różnego traktowania w zależności od tego, gdzie trafi: kontekst ciała dokumentu HTML wymaga kodowania encji HTML (< → <), kontekst atrybutu wymaga kodowania dla atrybutów w cudzysłowach, kontekst JavaScript wymaga escapowania w formacie \xHH, a adresy URL wymagają kodowania procentowego (percent-encoding). Nazwa użytkownika taka jak O'Brien jest prawidłowymi danymi wejściowymi, ale musi zostać zakodowana jako O'Brien podczas umieszczania jej w kodzie HTML. Walidacja danych wejściowych nie może zastąpić kodowania danych wyjściowych, a kodowanie nie zastąpi walidacji — rozwiązują one różne problemy na różnych etapach cyklu życia danych.

Dodatkowe zabezpieczenia obejmują nagłówki Content Security Policy (CSP) w celu ograniczenia źródeł skryptów, flagi HttpOnly i Secure na sesyjnych plikach cookie oraz sparametryzowane API na każdej granicy zaufania.

WAF-y i zabezpieczenia przesyłania plików

Zapora sieciowa dla aplikacji webowych (web application firewall, WAF) inspekcjonuje ruch HTTP i blokuje żądania pasujące do znanych złośliwych wzorców — sygnatury SQLi, payloady XSS, sekwencje path traversal, anomalie protokołu. Wdrażany jako odwrotne proxy (reverse proxy) (ModSecurity z OWASP Core Rule Set, AWS WAF, Cloudflare, F5), zapewnia cenne wirtualne łatanie (virtual patching), gdy podatność zostanie odkryta, zanim kod zostanie naprawiony. WAF jest jednak mechanizmem kompensacyjnym, a nie substytutem bezpiecznego programowania. Zaawansowani atakujący rutynowo omijają WAF-y poprzez sztuczki z kodowaniem, zanieczyszczanie parametrów HTTP (HTTP parameter pollution) i fragmentację payloadu.

Przesyłanie plików zasługuje na szczególną uwagę, ponieważ łączy niezaufaną treść z przechowywaniem po stronie serwera i, często, z jej wykonywaniem. Zabezpieczenia obejmują walidowanie typu pliku poprzez inspekcję jego magicznych bajtów (magic bytes) zamiast ufania rozszerzeniu lub nagłówkowi Content-Type, przechowywanie przesłanych plików poza głównym katalogiem serwera WWW (web root), zmianę nazw plików na identyfikatory generowane przez serwer (co zapobiega atakom directory traversal poprzez spreparowane nazwy plików), skanowanie programem antywirusowym przed zapisaniem oraz serwowanie treści przesłanych przez użytkowników z oddzielnej domeny, aby zapobiec wykonaniu skryptów w ramach tej samej domeny (same-origin).

Praktyczny scenariusz: Atak SQL Injection prowadzący do pełnego przejęcia bazy danych

Punkt końcowy (endpoint) wyszukiwania produktów w firmie z branży handlowej akceptował parametr category, który był bezpośrednio dołączany (konkatenowany) do zapytania SQL bez uprzedniej sanityzacji. Badacz bezpieczeństwa odkrył, że przesłanie wartości ' UNION SELECT table_name,null,null FROM information_schema.tables-- zwracało w odpowiedzi listę wszystkich tabel z bazy danych. Kolejne zapytania pozwoliły na wyodrębnienie tabeli customers, co dało w wyniku 1,2 miliona rekordów zawierających imiona i nazwiska, adresy e-mail oraz hasła haszowane za pomocą bcrypt. Atakujący odkrył również procedurę składowaną, którą można było wywołać poprzez SQL injection w celu zapisania plików w głównym katalogu serwera WWW (web root), co umożliwiło wdrożenie webshella i pełne przejęcie serwera. Podatność istniała od trzech lat i została przeoczona w dwóch poprzednich testach penetracyjnych, ponieważ testerzy sprawdzali jedynie formularz logowania, a nie punkt końcowy wyszukiwania. Wniosek: testowanie pod kątem ataków injection musi obejmować każdy parametr w każdym punkcie końcowym, a nie tylko oczywiste ścieżki uwierzytelniania.

← Reagowanie na incydenty · Wszystkie domeny · Bezpieczeństwo chmury →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →