Baza w sieci — aplikacja bazodanowa

🎯 Po co Ci to?

Poznane bazy stały na jednym komputerze. Ale prawdziwe systemy — sklep, bank, portal społecznościowy, ten system, w którym czytasz — mają bazę na serwerze w sieci, a korzystają z niej tysiące ludzi jednocześnie, przez przeglądarki i aplikacje na całym świecie. To rodzi pytania, których jednostanowiskowa baza nie znała: jak połączyć stronę WWW z bazą? co, gdy dwoje ludzi zmienia to samo naraz? jak nie dać się okraść z danych? Ta jednostka domyka dział, pokazując bazę w jej naturalnym, sieciowym środowisku — i spina wątki bezpieczeństwa, które w pełni rozwiniesz w dziale 16. Rozszerzona podstawa wymaga sieciowej aplikacji bazodanowej.

✅ Czego się nauczysz

Po tej jednostce potrafisz:

  • opisać architekturę klient–serwer aplikacji bazodanowej (przeglądarka → serwer → baza);
  • wyjaśnić, czemu jednoczesny dostęp wielu użytkowników wymaga ochrony (transakcje, blokady);
  • rozpoznać podstawowe zagrożenia bezpieczeństwa bazy w sieci (w tym wstrzyknięcie SQL).

🔁 Przypomnij sobie

Z 12.5: transakcje „wszystko albo nic", integralność; z 3.4 (SI, jeśli robiłeś): wejście od użytkownika bywa wrogie; z 9.5: sieć jako graf połączeń (architektura sieciowa — pełniej w dziale 14).

📘 Wyjaśnienie

Architektura klient–serwer. Sieciowa aplikacja bazodanowa ma zwykle trzy warstwy:

PRZEGLĄDARKA  →  SERWER APLIKACJI  →  BAZA DANYCH
(klient:        (logika: przyjmuje    (przechowuje
 formularz,      żądanie, sprawdza     dane, wykonuje
 przyciski)      uprawnienia,          zapytania SQL)
                 buduje zapytanie)

Klient (przeglądarka) nie rozmawia z bazą bezpośrednio — wysyła żądanie do serwera aplikacji, ten sprawdza uprawnienia, buduje zapytanie SQL, wykonuje je na bazie i odsyła wynik. Ta separacja jest kluczowa dla bezpieczeństwa: baza siedzi „w środku", niedostępna wprost z internetu; między nią a światem stoi serwer, który kontroluje, kto co może. (Rozpoznajesz warstwy? To ten sam pomysł co formularz oddzielający użytkownika od struktury z 12.3 — tu na skalę sieci.)

Wielu naraz — współbieżność. Jednostanowiskowa baza obsługiwała jedną operację na raz; sieciowa — tysiące jednocześnie. Rodzi to problem: dwoje ludzi rezerwuje ostatni bilet w tej samej milisekundzie. Oboje widzą „1 wolny", oboje klikają — sprzedano dwa bilety, których nie ma. Baza broni się blokadami i transakcjami (12.5): operacja „sprawdź dostępność i zarezerwuj" wykonuje się niepodzielnie, a druga osoba czeka ułamek sekundy i dostaje „brak miejsc". To ta sama groza współbieżności, którą sygnalizował burst uczniów w opisie tego systemu — bazy danych mają na nią sprawdzone od dekad mechanizmy. Bez nich każdy popularny serwis rozpadłby się przy pierwszym tłoku.

Bezpieczeństwo — baza jako cel. Baza w sieci to łakomy kąsek: zawiera dane, hasła, pieniądze. Główne zagrożenia (rozwinięte w dziale 16, tu w skrócie):

  • Wstrzyknięcie SQL (SQL injection) — klasyk. Jeśli serwer bezmyślnie wkleja tekst od użytkownika do zapytania, sprytnie spreparowany „login" może zmienić sens SQL i wyciągnąć całą bazę. Wpisujesz w pole loginu nie nazwisko, lecz fragment kodu SQL — i baza go wykonuje. Obrona: nigdy nie sklejaj zapytań z surowego wejścia — używa się zapytań parametryzowanych, które traktują wejście jako dane, nie jako kod (to dokładnie zasada z opisu tego systemu: „wszystko parametryzowane, zero SQL injection"). To najważniejsza zasada bezpieczeństwa baz w sieci.
  • Słabe uprawnienia — konto aplikacji z prawem do wszystkiego to katastrofa po włamaniu; daje się minimum potrzebne (zasada najmniejszych uprawnień).
  • Niezaszyfrowana transmisja/dane — hasła i dane wrażliwe szyfruje się w tranzycie (HTTPS — dział 5.7!) i często w spoczynku.

💭 Pomyśl: Formularz logowania buduje zapytanie tak: SELECT * FROM users WHERE login = '[to, co wpisał user]' AND haslo = '[hasło]'. Co się stanie, jeśli ktoś w pole login wpisze: admin' -- (gdzie -- zaczyna komentarz w SQL)?

Sprawdź odpowiedź

Zapytanie staje się: SELECT * FROM users WHERE login = 'admin' --' AND haslo = '...'. Komentarz -- wyłącza resztę linii, w tym sprawdzenie hasła! Baza zwróci rekord admina bez weryfikacji hasła — włamywacz zalogował się jako administrator, nie znając hasła. To jest wstrzyknięcie SQL w najczystszej postaci: wejście użytkownika zmieniło strukturę zapytania, bo zostało wklejone jako kod. Obrona (parametryzacja) traktuje admin' -- jako dosłowny login (którego nie ma), nie jako fragment SQL — i atak nie działa. Ta luka odpowiada za ogromną część historycznych wycieków danych; zrozumienie jej to pierwszy krok do pisania bezpiecznych aplikacji. Nigdy nie ufaj wejściu użytkownika (echo działu 1: dane od świata bywają wrogie).

⚠️ Uwaga, pułapka

„To tylko szkolny projekt, bezpieczeństwem zajmę się potem" — to droga do katastrofy. Luki bezpieczeństwa (jak SQL injection) najłatwiej zapobiec od początku (parametryzacja od pierwszej linijki kosztuje tyle samo co sklejanie), a najtrudniej załatać po fakcie w działającym systemie. Podobnie uprawnienia i szyfrowanie: wbudowane w projekt są tanie, doklejone później — drogie i dziurawe. Bezpieczeństwo to nie dodatek na koniec, lecz sposób budowania od pierwszego dnia — zasada, która wróci w dziale 16 i którą warto przyjąć już przy pierwszym własnym projekcie z bazą.

🛠️ Teraz Ty

Bez kodu — projekt na papierze: naszkicuj architekturę trzywarstwową dla prostego systemu (biblioteka szkolna albo sklepik): co robi przeglądarka, co serwer, co baza, jak płynie żądanie „wypożycz książkę". Wskaż jedno miejsce, gdzie grozi SQL injection, i opisz obronę. Zastanów się nad jednym scenariuszem współbieżności (dwoje wypożycza ostatni egzemplarz) i jak baza go rozwiąże.

📐 Definicje tej lekcji

  • Architektura klient–serwer — przeglądarka → serwer aplikacji → baza; baza niedostępna wprost, serwer kontroluje dostęp.
  • Współbieżność — jednoczesny dostęp wielu użytkowników; chroniona blokadami i transakcjami.
  • Wstrzyknięcie SQL — atak przez wklejenie kodu w wejście; obrona: zapytania parametryzowane (wejście jako dane, nie kod).

📌 Najważniejsze w pigułce

  • Sieciowa baza: trzy warstwy, baza „w środku", serwer aplikacji kontroluje dostęp.
  • Wielu użytkowników naraz wymaga transakcji i blokad — inaczej sprzedasz ostatni bilet dwa razy.
  • Nigdy nie sklejaj SQL z surowego wejścia (SQL injection); bezpieczeństwo buduje się od pierwszej linijki.

🎒 Zadania

  1. Wyjaśnij, czemu przeglądarka nie łączy się z bazą bezpośrednio, tylko przez serwer aplikacji. Jakie dwa problemy rozwiązuje ta warstwa pośrednia?
Wskazówka i odpowiedź

(1) Bezpieczeństwo: baza z hasłami i pieniędzmi nie może być wystawiona wprost do internetu — serwer stoi na straży, sprawdza uprawnienia, buduje bezpieczne (parametryzowane) zapytania; gdyby klient gadał z bazą wprost, każdy mógłby wysłać dowolny SQL. (2) Logika i kontrola: serwer egzekwuje reguły biznesowe (czy user może to zrobić? czy dane sensowne?), których baza sama nie zna. Warstwa pośrednia oddziela „co użytkownik chce" od „co baza fizycznie wykona" — jak formularz z 12.3, w skali sieci. Bez niej nie ma ani bezpieczeństwa, ani kontroli.

  1. Dwoje użytkowników jednocześnie zmienia opis tego samego produktu w sklepie. Opisz problem („zgubiona aktualizacja") i jak transakcje/blokady go rozwiązują.
Wskazówka i odpowiedź

Oboje wczytują opis, oboje edytują, oboje zapisują — druga zapisana wersja nadpisuje pierwszą, której zmiana „ginie" bez śladu (zgubiona aktualizacja). Rozwiązania: blokada (drugi czeka, aż pierwszy skończy) albo kontrola wersji (baza wykrywa, że rekord zmienił się od wczytania, i odrzuca zapis „na starym", każąc odświeżyć — rozpoznajesz mechanizm baseVersion/409 z opisu tego systemu?). Współbieżność bez ochrony cicho gubi dane; bazy mają na to sprawdzone wzorce, ale projektant musi je świadomie zastosować.

  1. Serwis przechowuje hasła użytkowników. Powinien trzymać je jawnie w bazie? Odwołaj się do działu 5.6 (haszowanie) i wyjaśnij, co baza powinna przechowywać zamiast hasła.
Wskazówka i odpowiedź

Nigdy jawnie! Baza (nawet dobrze chroniona) bywa wykradana — jawne hasła oznaczają katastrofę wszystkich kont (a ludzie używają tych samych haseł w wielu serwisach). Zamiast hasła przechowuje się jego hasz (5.6): przy logowaniu liczy się hasz podanego hasła i porównuje z zapisanym — zgadza się, wpuszczasz; a z samego hasza nie da się odtworzyć hasła. Dlatego „przypomnienie hasła" to zawsze reset (ustaw nowe), nigdy odesłanie starego — serwis go nie zna! (Dokładnie tak działa ten system: „nie przechowujemy hasła, tylko hasz; przypomnienie = reset".) Haszowanie z działu 5 chroni tu miliony kont — algorytmika i bezpieczeństwo spotykają się w praktyce.

🔍 Sprawdź, czy umiesz

  • Naszkicować architekturę trzywarstwową i rolę każdej warstwy.
  • Wyjaśnić, czemu współbieżność wymaga transakcji i blokad.
  • Opisać SQL injection i jego obronę oraz zasadę przechowywania haseł jako haszy.

Ucz się tej jednostki z asystentem