Skip to content

Latest commit

 

History

History
172 lines (100 loc) · 10.7 KB

secureheaders.polish.md

File metadata and controls

172 lines (100 loc) · 10.7 KB

Korzystanie z nagłówków związanych z bezpieczeństwem w celu zabezpieczenia aplikacji przed typowymi atakami



Wyjaśnienie jednym akapitem

Istnieją nagłówki związane z bezpieczeństwem, które służą do dalszego zabezpieczenia aplikacji. Najważniejsze nagłówki są wymienione poniżej. Możesz również odwiedzić witryny połączone na dole tej strony, aby uzyskać więcej informacji na ten temat. Możesz łatwo ustawić te nagłówki za pomocą modułu Helmet modułu dla express (Helmet for koa).



Spis treści



HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) to mechanizm polityki bezpieczeństwa sieci, który chroni strony internetowe przed protocol downgrade attacks oraz cookie hijacking. Pozwala serwerom internetowym zadeklarować, że przeglądarki internetowe (lub inne zgodne z nimi aplikacje klienckie) powinny z nim współpracować tylko przy użyciu secure HTTPS connections, oraz never przez niepewny protokół HTTP. Polityka HSTS jest implementowana przy użyciu nagłówka Strict-Transport-Security przez istniejące połączenie HTTPS.

Nagłówek Strict-Transport-Security akceptuje wartość 'max-age' w sekundach, aby powiadomić przeglądarkę, jak długo powinien uzyskiwać dostęp do witryny przy użyciu tylko HTTPS, oraz wartość „includeSubDomains”, aby zastosować regułę ścisłego transportu do wszystkich poddomeny witryny.

Przykład nagłówka - zasady HSTS włączone na tydzień, obejmują poddomeny

Strict-Transport-Security: max-age=2592000; includeSubDomains

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



Public Key Pinning dla HTTP (HPKP)

HTTP Public Key Pinning (HPKP) to mechanizm bezpieczeństwa umożliwiający stronom HTTPS opieranie się podszywaniu się pod osoby atakujące przy użyciu nieprawidłowo wydanych lub w inny sposób fałszywych certyfikatów SSL / TLS.

Serwer webowy HTTPS udostępnia listę skrótów kluczy publicznych, a przy kolejnych połączeniach klienci oczekują, że serwer użyje jednego lub więcej kluczy publicznych w swoim łańcuchu certyfikatów. Korzystając z tej funkcji ostrożnie, można znacznie zmniejszyć ryzyko ataków typu man-in-the-middle (MITM) i innych problemów z fałszywym uwierzytelnianiem użytkowników aplikacji bez ponoszenia nadmiernego ryzyka.

Przed wdrożeniem powinieneś najpierw zajrzeć do nagłówka Expect-CT, ze względu na jego zaawansowaną elastyczność odzyskiwania po błędnej konfiguracji i inne zalety.

Nagłówek klucza Public-Key-Pins przyjmuje 4 wartości, pin-sha256 wartość dodawania klucza publicznego certyfikatu, zaszyfrowana przy użyciu algorytmu SHA256, który można dodawać wiele razy dla różnych kluczy publicznych, wartość 'max-age', która informuje przeglądarkę, jak długo powinna stosować regułę, wartość „includeSubDomains” do zastosuj tę regułę do wszystkich subdomen i wartości report-uri, aby zgłosić niepowodzenia sprawdzania poprawności pinów dla podanego adresu URL.

Przykład nagłówka - zasady HPKP włączone na jeden tydzień, obejmują subdomeny, zgłaszają awarie do przykładowego adresu URL i zezwalają na dwa klucze publiczne

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=2592000; includeSubDomains

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



X-Frame-Options

Nagłówek X-Frame-Options zabezpiecza aplikację przed Clickjacking atakami, deklarując zasadę, czy aplikacja może być osadzona na innych (zewnętrznych) stronach za pomocą ramek.

X-Frame-Options pozwala na 3 parametry, parametr deny aby uniemożliwić osadzanie zasobu w ogóle, parametr sameorigin umożliwiający osadzanie zasobu na tym samym hoście / źródle oraz parametr allow-from określający host, na którym dozwolone jest osadzanie zasobu.

Przykład nagłówka - odmowa osadzenia aplikacji

X-Frame-Options: deny

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



X-XSS-Protection

Ten nagłówek umożliwia filtr Cross-site scripting w twojej przeglądarce.

Przyjmuje 4 parametry, 0 do wyłączania filtra, 1 w celu włączenia filtra i włączenia automatycznej dezynfekcji strony, mode=block aby włączyć filtr i zapobiec renderowaniu strony w przypadku wykrycia ataku XSS (ten parametr należy dodać do 1 za pomocą średnika, a report = <domainToReport> aby zgłosić naruszenie (ten parametr należy dodać na '1').

Przykład nagłówka - Włącz ochronę XSS i zgłoś naruszenia na przykładowy adres URL

X-XSS-Protection: 1; report=http://example.com/xss-report

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj OWASP Secure Headers Project



X-Content-Type-Options

Ustawienie tego nagłówka uniemożliwi przeglądarce interpretowanie plików jako czegoś innego niż zadeklarowany przez typ zawartości w nagłówkach HTTP.

Przykład nagłówka - Disallow Content sniffing

X-Content-Type-Options: nosniff

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



Referrer-Policy

Nagłówek Referrer-Policy HTTP określa, które informacje o odsyłaczach wysyłane w nagłówku 'Referer' powinny być dołączane do żądań.

Przyjmuje 8 parametrów, no-referrer parametr, aby usunąć nagłówek Referer całkowicie, no-referrer-when-downgrade aby usunąć nagłówek Referer gdy zejście w dół na przykład HTTPS -> HTTP, parametr origin aby wysłać źródło hosta (host root) jako odnośnik only, parametr origin-when-cross-origin aby wysłać origin URL pozostając na tym samym origin i wysłać host origin only when inaczej, parametr same-origin aby wysyłać informacje o stronie odsyłającej tylko w przypadku pochodzenia z tej samej witryny i pomijać żądania dotyczące różnych źródeł, parametr strict-origin aby zachować nagłówek Referer tylko na tym samym poziomie bezpieczeństwa (HTTPS -> HTTPS) i pominąć go w mniej bezpiecznym miejscu docelowym, parametr strict-origin-when-cross-origin aby wysłać pełny adres URL strony odsyłającej do miejsca docelowego tego samego pochodzenia - źródła only do miejsca docelowego pochodzącego z innego źródła w same poziom bezpieczeństwa i brak strony odsyłającej w mniej bezpiecznym miejscu docelowym pochodzącym z innego źródła oraz parametr 'unsafe-url', aby wysłać pełne strony odsyłające do miejsc docelowych tego samego lub innego źródła.

Przykład nagłówka - Całkowite usunięcie nagłówka Referer

Referrer-Policy: no-referrer

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



Expect-CT

Nagłówek Expect-CT jest używany przez serwer do wskazania, że przeglądarki powinny oceniać połączenia z hostem emitującym nagłówek pod kątem zgodności z Przejrzystość certyfikatu.

Nagłówek akceptuje 3 parametry, parametr „report-uri” do podania adresu URL do zgłoszenia awarii Expect-CT, parametr „enforce” sygnalizujący przeglądarce, że należy narzucić (a nie tylko zgłaszać) przejrzystość certyfikatu i odmawiać przyszłych połączeń naruszając Certificate Transparency oraz parametr „max-age” określający liczbę sekund, w których przeglądarka traktuje hosta jako znanego hosta Expect-CT.

Przykład nagłówka - Narzuć przejrzystość certyfikatu przez tydzień i zgłoś do przykładowego adresu URL

Expect-CT: max-age=2592000, enforce, report-uri="https://example.com/report-cert-transparency"

🔗 Czytaj OWASP Secure Headers Project



Content-Security-Policy

Nagłówek odpowiedzi HTTP Content-Security-Policy pozwala kontrolować zasoby, które agent użytkownika może załadować dla danej strony. Z kilkoma wyjątkami zasady obejmują przede wszystkim określenie pochodzenia serwera i punktów końcowych skryptu. Pomaga to chronić się przed cross-site scripting attacks (XSS).

Przykład nagłówka - Włącz CSP i wykonuj tylko skrypty z tego samego źródła

Content-Security-Policy: script-src 'self'

Istnieje wiele zasad włączonych za pomocą Content-Security-Policy, które można znaleźć na poniższych stronach.

🔗 Czytaj OWASP Secure Headers Project

🔗 Czytaj MDN web docs



Dodatkowe zasoby

🔗 OWASP Secure Headers Project

🔗 Node.js Security Checklist (RisingStack)