Security

Wyloguj użytkownika z aplikacji opartej na sesjach, a serwer zapomni o nim przy następnym żądaniu. Wyloguj go z aplikacji opartej na JWT i, jeśli nie zbudowałeś dodatkowego mechanizmu, token, który trzyma, zostaje ważny aż do wygaśnięcia. Ta różnica jest prawdziwą decyzją stojącą za “JWT vs sesja”. Reszta z niej wynika. Co faktycznie przechowuje sesja Sesja trzyma stan użytkownika na serwerze, a przeglądarce przekazuje tylko klucz do wyszukania. Użytkownik loguje się hasłem. Serwer tworzy rekord sesji (ID użytkownika, role, co tylko potrzebne) i zapisuje go w pamięci, w bazie danych albo w Redis, indeksowany losowym ID sesji. Serwer wysyła ten ID do przeglądarki jako cookie, oznaczone HttpOnly, żeby JavaScript po stronie klienta nie mógł go odczytać. Przy każdym żądaniu przeglądarka automatycznie odsyła cookie. Serwer szuka ID w store i pobiera dane sesji. Cookie nie niesie żadnej informacji o użytkowniku, tylko nieprzejrzysty ciąg, który serwer rozwiązuje przy każdym żądaniu. Usuń rekord w store i sesja znika przy następnym żądaniu, na każdym urządzeniu. ...

Endpoint logowania odsyła JWT, a Ty masz trzy miejsca, w których możesz go trzymać: cookie, localStorage albo sessionStorage. Wybierzesz źle i albo błąd XSS wyniesie token na zewnątrz, albo token nigdy nie dotrze do Twojego API. Wszystkie trzy mechanizmy przechowują stringi w przeglądarce. Różnią się tym, kto może je odczytać, jak długo żyją i czy serwer w ogóle je widzi. Czym różnią się localStorage, sessionStorage i cookies localStorage i sessionStorage to ten sam interfejs, Storage: setItem, getItem, removeItem, clear, klucze i wartości w postaci stringów. Różnica leży w czasie życia. localStorage przetrwa zamknięcie przeglądarki i restart komputera, i zostaje tam, dopóki coś go nie wyczyści. Safari jest wyjątkiem: z włączonym tracking prevention usuwa dane zapisane przez skrypt dla strony, z którą użytkownik nie miał kontaktu od siedmiu dni. sessionStorage należy do jednej karty i umiera, gdy ta karta się zamyka. Wpisz ten sam adres w drugiej karcie i dostaniesz nowy, pusty sessionStorage — tylko opcja “Duplikuj kartę” kopiuje go dalej. ...

Twój frontend działa na http://localhost:5173, API na http://localhost:4000, a zapytanie fetch, które bez problemu działało w Postmanie, w przeglądarce kończy się ścianą czerwonego tekstu: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Całkiem możliwe, że twój serwer obsłużył to zapytanie i zwrócił 200. Przeglądarka po prostu odmówiła przekazania odpowiedzi do twojego JavaScriptu. Ta odmowa to same-origin policy. CORS to sposób, w jaki serwer mówi przeglądarce, żeby złagodziła tę zasadę dla konkretnych stron. Każda poprawka poniżej sprowadza się do jednego nagłówka odpowiedzi, którego przeglądarka nie dostała. ...

Jak dostać się do bazy danych, która nasłuchuje tylko na localhost? Instancja Postgres na zdalnym serwerze celowo wiąże się z 127.0.0.1. Nic w sieci nie może jej dosięgnąć, tylko procesy działające na tej samej maszynie. Twój laptop nie jest tą maszyną, więc psql -h remote-server -p 5432 kończy się błędem, zanim w ogóle dojdzie do uwierzytelnienia. Otwarcie tego portu na świat przekreślałoby sens trzymania bazy na loopbacku. Chcesz na chwilę pożyczyć widok, jaki zdalna maszyna ma na 127.0.0.1, z własnego terminala. W momencie logowania SSH ma już otwarte, szyfrowane i uwierzytelnione połączenie między dwiema maszynami. Port forwarding wykorzystuje to połączenie do przesyłania ruchu spoza twojej powłoki. ...

Co TLS naprawdę chroni w połączeniu HTTPS Otwórz stronę przez zwykłe http:// w sieci, której nie kontrolujesz, na lotnisku albo na routerze w kawiarni, a wszystko, co wysyłasz, leci jako czytelny tekst. Ścieżka URL, ciasteczka, pola formularza, hasło w POST-cie logowania: każdy w tej sieci ze snifferem pakietów odczyta to w locie. TLS, Transport Layer Security, to protokół, który to blokuje. Siedzi między TCP a protokołem aplikacji, więc zanim HTTP zacznie w ogóle mówić, połączenie jest już zaszyfrowane i powiązane ze zweryfikowaną tożsamością serwera. HTTPS to po prostu HTTP puszczony przez takie połączenie zamiast przez zwykłe. ...

Gdzie kończą zmienne środowiskowe kontenera Uruchamiasz kontener poleceniem -e DB_PASSWORD=hunter2 i sprawdzasz go docker inspect: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] Hasło leży tam jawnym tekstem, czytelne dla każdego z dostępem do socketa Docker, dla docker exec api env i dla każdego procesu działającego w kontenerze. To nie jest błąd — dokładnie do tego służą zmienne środowiskowe. Problem pojawia się, gdy używasz ich do wartości, które nigdy nie powinny być aż tak widoczne. ...