KWALIFIKACJA PGF4 - WRZESIEŃ 2014

PYTANIE NR 38.
Które z narzędzi należy wykorzystać do zapewnienia bezpieczeństwa transmisji danych protokołem HTTP w module zamawiania/opłacania w firmowym sklepie internetowym?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Bezpieczeństwo transmisji danych w sklepie WWW zapewnia szyfrowany kanał między przeglądarką a serwerem.
Mechanizmy SSL/TLS (w praktyce TLS) tworzą bezpieczne połączenie, chroniąc poufność i integralność danych w formularzach zamówienia i płatności. Pozostałe opcje nie zabezpieczają samego połączenia HTTP w czasie transmisji.

Pełne wyjaśnienie:

W module zamawiania i opłacania kluczowe jest, aby dane wpisywane przez klienta (np. dane logowania, adres, dane płatnicze) były chronione podczas przesyłania między przeglądarką a serwerem. Taką ochronę zapewnia zastosowanie szyfrowania warstwy transportowej, czyli połączenia realizowanego jako HTTPS (HTTP zestawione na kanale TLS).

Odpowiedź "Mechanizmy szyfrowania SSL i TLS." wskazuje właściwy kierunek: to właśnie protokół TLS (historycznie kojarzony także z nazwą SSL) zapewnia:

  • poufność – osoby trzecie nie odczytają treści przesyłanych formularzy, ciasteczek sesyjnych ani tokenów,
  • integralność – trudniej o niezauważoną modyfikację danych w tranzycie (np. podmianę numeru konta lub treści zamówienia),
  • uwierzytelnienie serwera – przeglądarka weryfikuje certyfikat, co ogranicza ryzyko podszycia się pod sklep.

Pozostałe propozycje nie spełniają celu pytania:

  • "Kwalifikowany podpis cyfrowy." służy głównie do potwierdzania tożsamości i podpisywania dokumentów/operacji, a nie do automatycznego szyfrowania całej komunikacji HTTP pomiędzy klientem i serwerem sklepu.
  • "Szyfrowanie PGP." jest typowo stosowane do szyfrowania wiadomości/plików (np. e-mail), a nie jako mechanizm zestawiania bezpiecznego kanału dla stron WWW i formularzy zakupowych w przeglądarce.
  • "Hasło przesłane klientowi automatycznie generowanym e-mailem." nie zabezpiecza transmisji HTTP. Co więcej, wysyłanie haseł e-mailem jest ryzykowne (przechwycenie, przechowywanie w skrzynce, brak kontroli nad kanałem), a bezpieczeństwo połączenia nadal zależy od użycia szyfrowanego kanału między przeglądarką a serwerem.

W praktyce egzaminacyjnej warto zapamiętać: gdy pytanie dotyczy ochrony danych w trakcie przesyłania w serwisie WWW, właściwą odpowiedzią jest zastosowanie szyfrowanego połączenia opartego o TLS (czyli HTTPS) oraz poprawnej konfiguracji certyfikatu po stronie serwera.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
TLS to protokół, który tworzy szyfrowany kanał między przeglądarką a serwerem. W sklepie internetowym chroni dane przesyłane w formularzach (logowanie, adres, płatność) przed podsłuchem i modyfikacją oraz pomaga potwierdzić, że łączysz się z właściwą domeną.
HTTP to protokół przesyłania treści WWW bez szyfrowania. HTTPS to praktyczna nazwa użycia HTTP przez szyfrowany kanał TLS. Innymi słowy: TLS zabezpiecza transport, a HTTP działa "w środku" tego bezpiecznego połączenia.
Hasło może chronić dostęp do konta, ale nie chroni treści przesyłanej po drodze. Jeśli połączenie nie jest szyfrowane, osoba podsłuchująca może przechwycić hasło lub dane sesji. Bez TLS ryzyko dotyczy także podmiany treści (np. danych zamówienia).
PGP najczęściej stosuje się do szyfrowania wiadomości e-mail i plików, a nie do zestawiania bezpiecznego kanału komunikacji WWW w przeglądarce. Dla formularzy sklepu internetowego standardem jest TLS/HTTPS, bo działa transparentnie dla użytkownika i całej sesji.
Podpis kwalifikowany służy do podpisania dokumentu lub oświadczenia woli i potwierdzenia tożsamości, ale nie tworzy szyfrowanego kanału dla całej komunikacji klient–serwer. Moduł płatności wymaga ochrony transmisji "na żywo", którą zapewnia TLS/HTTPS.
HTTPS powinien obejmować cały serwis, a co najmniej wszystkie miejsca, gdzie użytkownik podaje dane: logowanie, rejestracja, koszyk, formularz adresowy, płatność oraz panele administracyjne. W praktyce bezpieczniej jest używać HTTPS wszędzie, aby uniknąć "mieszanej" sesji.
Najprościej sprawdzić, czy adres zaczyna się od https:// i czy przeglądarka nie pokazuje ostrzeżeń o certyfikacie. Brak ostrzeżeń nie oznacza pełnego bezpieczeństwa aplikacji, ale potwierdza, że kanał transmisji jest szyfrowany i uwierzytelniony.
E-mail może zostać przechwycony, przekazany dalej lub pozostać w skrzynce na długo. To zwiększa ryzyko przejęcia konta. Dodatkowo wysłanie hasła nie zabezpiecza transmisji danych w sesji zakupowej. Lepszą praktyką jest reset hasła i zawsze szyfrowane połączenie TLS.
Certyfikat TLS pomaga przeglądarce potwierdzić tożsamość serwera (domeny) i nawiązać bezpieczne połączenie. Dzięki temu trudniej o podszycie się pod sklep. Certyfikat nie "naprawia" błędów aplikacji, ale jest podstawą zaufania do szyfrowanego kanału.
Częsty błąd to wybór rozwiązań do szyfrowania plików lub podpisywania dokumentów zamiast mechanizmu zabezpieczającego kanał połączenia. Warto zapamiętać: jeśli chodzi o transmisję w WWW, właściwa odpowiedź zwykle dotyczy TLS/HTTPS, a nie PGP czy podpisu.
info

Około 64% zdających odpowiada poprawnie na to pytanie. średnie

Według specjalistów z branży: "Pozostałe opcje nie zabezpieczają samego połączenia HTTP w czasie transmisji."

Źródła:

  • RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, IETF, August 2018
  • RFC 9110: HTTP Semantics, IETF, June 2022
  • OWASP Cheat Sheet Series: Transport Layer Protection Cheat Sheet, https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html - accessed 2026-03-05

Materiały:

  • Dokumentacja OWASP dotycząca ochrony transmisji (Transport Layer Protection)
  • Dokumentacja HTTP i TLS w formie RFC (dla zrozumienia pojęć i roli TLS)
  • Materiały szkoleniowe o podstawach HTTPS, certyfikatach i konfiguracji serwera WWW

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego