fbpx
Kategorie
Bezpieczeństwo Publicystyka

Narodowy Bank Polski powinien porzucić protokół HTTP

Nie wierzę, że w 2023 muszę rozpoczynać artykuł następującym apelem: w interesie klientów i własnym, Narodowy Bank Polski powinien porzucić niebezpieczne protokoły sieciowe w swoich kanałach komunikacji elektronicznej. No dobra, mogę wierzyć lub nie wierzyć, to bez znaczenia. Niniejszy artykuł opiera się na faktach.

Faktem jest, że witryna WWW Narodowego Banku Polskiego nie gwarantuje bezpieczeństwa w zakresie integralności komunikacji. Faktem jest, że do danych serwowanych przez API (interfejs programistyczny) można dostać się za pomocą niezabezpieczonego protokołu HTTP. Faktem jest wreszcie, że wszystkie przykłady użycia owego API promują wariant komunikacji podatny na trywialnie prosty podsłuch i modyfikację zarówno żądań, jak i odpowiedzi.

Dwadzieścia lat temu metody komunikacji z serwerami WWW dzieliliśmy na „zwykłe” i bezpieczne. Przeglądarki internetowe wyróżniały tryb bezpieczny (gwarantujący poufność oraz integralność komunikacji) zieloną kłódką. Te czasy dawno za nami.

Dzisiaj bezpieczeństwo komunikacji jest stanem naturalnym zaś przeglądarki wyraźnie ostrzegają przed witrynami, które go nie zapewniają.

Przekonajmy się na własne oczy, jak wygląda takie ostrzeżenie (wszystkie poniższe zrzuty ekranu pozostają aktualne w dniu publikacji artykułu). Otworzyłem stronę http://api.nbp.pl/, możesz zrobić to samo klikając na link albo przepisując pełny URL do paska adresu. W przeglądarce Firefox zobaczyłem adres opatrzony przekreśloną kłódką:

Zbliżenie:

W przeglądarce Chrome adresowi strony towarzyszyła etykietka „Niezabezpieczona”

Zbliżenie:

Przewińmy tę stronę i przyjrzyjmy się przykładom. Wszystkie, co do ostatniej sztuki, zawierają adresy zaczynające się od protokołu „http://”. W dzisiejszych czasach przeglądarki porzuciły prezentację protokołów w pasku adresu, co nie oznacza, że same protokoły są pozbawione znaczenia.

Wykorzystajmy pierwszy przykład, otwórzmy adres http://api.nbp.pl/api/exchangerates/rates/a/chf/. W chwili pisania artykułu docelowy dokument wygląda tak:

Owszem, wszystkie powyższe strony mają swój zabezpieczony odpowiednik, ale to za mało!

Dlaczego protokół HTTP jest przestarzały?

Do tematu NBP wrócimy za chwilę, najpierw mały łyk historii. Gdy ćwierć wieku temu wymyślono język HTML, protokół HTTP i pisano pierwsze przeglądarki WWW, internet był zupełnie innym miejscem. Na całym świecie używało go kilkanaście milionów osób, w większości związanych ze środowiskiem akademickim albo mniej lub bardziej zorganizowanymi grupami pasjonatów. Wiele stosowanych dziś metod zabezpieczania ruchu sieciowego przed podsłuchem i modyfikacją nie zostało jeszcze wymyślonych. Przez pierwsze lata istnienia stron WWW, dane transmitowane były otwartym tekstem.

Gdy w sieci pojawiły się pierwsze sklepy i serwisy aukcyjne, jawność komunikacji zaczęła być problemem. Użytkownik podający w formularzu hasło albo numer karty kredytowej musiał ufać administratorowi swojej sieci lokalnej i operatorom sieci pośredniczących w transmisji danych – wszyscy oni mogli te dane przechwycić (np. podejrzeć numer karty) lub zmodyfikować (np. zmieniając adres dostawy).

Dodajmy, że przykłady zawiedzionego zaufania nie były rzadkością. Z wielką mocą nie zawsze przychodzi wielka odpowiedzialność. Administratorzy-dowcipnisie byli w stanie np. odwrócić „do góry nogami” wszystkie obrazki trafiające do przeglądarki. Nieetyczni dostawcy internetu wstrzykiwali do stron wczytywanych przez użytkowników dodatkową zawartość, np. bannery reklamowe albo okienka typu pop-up, też z reklamami. Do tego dochodziło przechwytywanie haseł, podszywanie się pod innych użytkowników, czytanie cudzej korespondencji itd.

Świat potrzebował sposobu na to, aby transmisja danych gwarantowała poufność (by wścibski operator nie mógł niczego podsłuchać) oraz integralność (by nie mógł modyfikować przesyłanych treści).

Dlaczego protokół HTTPS jest lepszy?

Podczas ewolucji przeglądarek i technologii za nimi stojących wymyślono szereg rozwiązań, które poufność lub integralność realizowały w sposób niedoskonały. Przełomem było opracowanie protokołu HTTPS, który bazował na szyfrowanych połączeniach SSL (potem TLS) oraz kryptografii klucza publicznego.

Operator serwera kupował certyfikat bezpieczeństwa powiązany z domeną, na której działał zabezpieczany serwis WWW. Certyfikaty sprzedawało kilkadziesiąt zaufanych instytucji i organizacji, które zobowiązane były do sprawdzenia, że nabywcą rzeczywiście jest osoba dysponująca ową domeną. Tu też mogły zdarzyć się nadużycia, ale na mniejsza skalę i znacznie rzadsze – zaś winowajcy wylatywali z listy zaufanych, co kończyło się ich szybkim bankructwem.

Przeglądarka działająca po stronie użytkownika mogła zaszyfrować żądanie wysyłane do serwera tzw. kluczem publicznym osadzonym w certyfikacie, dołączając dodatkowo unikalny sekret wymagany do szyfrowania komunikacji zwrotnej (w tym akapicie mocno upraszczamy cały ten proces). Urządzenia sieciowe pośredniczące w komunikacji nie miały więc wglądu w wysyłane treści, bo tylko właściciel certyfikatu dysponował kluczem prywatnym niezbędnym do rozszyfrowania żądania. Nie miały też wglądu w odpowiedzi wysyłane przez serwer – co w efekcie dawało pełną obustronną poufność transmisji.

Integralność zrobiła się sama, niejako przy okazji. Pośrednik transmisji nie może poznać ani zmodyfikować żądania, bo jest ono zaszyfrowane. Gdyby spróbował je podmienić (używając innego sekretu, bo przecież nie zna właściwego) i odesłać klientowi otrzymaną odpowiedź, przeglądarka klienta wykryje niezgodność sekretów, przerwie komunikację i podniesie alarm.

Scenariusz katastrofy

Nie trzeba chyba tłumaczyć, że informacje publikowane przez Narodowy Bank Polski mają fundamentalne znaczenie dla gospodarki, bilansu handlowego czy skłonności inwestorów do lokowania pieniędzy w Polsce. Gdyby środowiska finansistów i dziennikarzy uwierzyły (choćby na krótki moment) w fałszywe kursy walut albo zmiany stóp procentowych, na rynkach mógłby rozpętać się chaos, szkodliwy dla gospodarki oraz naruszający wiarygodność banku centralnego i całego kraju.

Oczywiście mało kto wchodzi na strony WWW, aby odczytać wartości kursów – robią to automaty przy użyciu wspomnianego wcześniej API. Bardzo wiele systemów finansowych samodzielnie reaguje na wahania rynków, np. zbyt duże zmiany kursów walut mogą wywołać autonomiczne zlecenia transakcji na giełdzie. Im większa zmiana – tym bardziej zdecydowana reakcja.

Wyobraźmy sobie teraz, że jakaś instytucja finansowa – zgodnie z dokumentacją API NBP – pobiera dane o kursach przez niezabezpieczony protokół HTTP. Jeśli atakujący włamie się na jakikolwiek komputer lub urządzenie sieciowe pośredniczące w takiej komunikacji, może w dowolnie wybranej chwili zacząć modyfikować przesyłane dane – np. określić kurs dolara na 10 zł a referencyjną stopę procentową na 20%. Odpalają automatyczne transakcje „sprzedaży po każdej cenie”, GPW nurkuje, wybucha panika.

Oczywiście objaśnienie sytuacji będzie rolą dziennikarzy. Jak sprawić, aby cała redakcja zobaczyła na stronie NBP podane wyżej kursy walut i stopy procentowe? Umożliwi to atak znany pod nazwą zatruwanie DNS (DNS cache poisoning), skutkujący przekierowaniem żądań do danej strony na inną, podstawioną maszynę. Wyobraźmy więc sobie, że branżowi dziennikarze dostają mailem lub komunikatorem informację o krachu – z dramatycznym screenshotem i linkiem do newsa w domenie nbp.pl (link prowadzi do strony serwowanej przez HTTP, na co mało kto zwróci uwagę). Dziennikarze rzucą się na stronę NBP i odnajdą tam potwierdzenie dramatycznych informacji!

Może się tak zdarzyć, ponieważ…

Witryna nbp.pl też ma wady

Całkiem możliwe, że po wejściu na stronę http://nbp.pl nastąpi w twojej przeglądarce przekierowanie na wersję serwowaną przez HTTPS. Niestety – gdy piszę te słowa, dzieje się to dopiero na poziomie aplikacji, która trafia do przeglądarki przez niezaszyfrowany protokół HTTP. Nawet wówczas jednak ręczne dostawienie znaków „http://” na początku adresu sprawia, że przekierowanie przestaje działać i dostajemy taki obrazek:

W takim stanie rzeczy, jak powyżej, zawartość strony może zostać podmieniona w locie na kilka różnych sposobów. Gdy zatruwanie DNS zadziała na poziomie całej sieci lokalnej, fałszywe informacje wyświetlą się na wszystkich komputerach w całej redakcji (i na tych telefonach, które korzystają z redakcyjnego Wi-Fi).

Jak sprawdzić, czy problem jest aktualny? Otwórz wiersz poleceń i wydaj komendę curl -I http://nbp.pl. Jeśli w odpowiedzi zobaczysz HTTP/1.1 200 OK, nadal mamy do czynienia z podatnością. Wartością oczekiwaną byłoby HTTP/1.1 301 Moved Permanently.

Jak zapobiec katastrofie?

Cel jest prosty – chcemy mieć pewność, że w każdej sytuacji informacje pobierane z serwerów NBP są przesyłane w sposób poufny oraz integralny. Każda próba naruszenia bezpieczeństwa transmisji musi zostać wykryta i zakończyć się przerwaniem komunikacji.

Innymi słowy – na poziomie przeglądarki internetowej próba fałszerstwa powinna skończyć się takim alarmem, jaki symulowany jest na tej stronie:

To właśnie dlatego nie widujemy ataków opisanych wyżej w praktyce – takiemu scenariuszowi potrafilibyśmy zapobiec. Z nieznanych przyczyn NBP tego nie robi. Aby zmierzać w stronę pełnego bezpieczeństwa, bank powinien podjąć następujące działania:

Krok 1 – odejście od HTTP

Jeśli chodzi o API – krótka piłka. Dostęp przez HTTP powinien zostać wyłączony a dokumentacja zaktualizowana. Coś komuś zepsujemy? Trudno. Jeśli ów ktoś był na tyle nieogarnięty, by korzystać z nieszyfrowanej komunikacji, nagłe wyłączenie usługi i tak będzie niskim wymiarem kary.

Zasoby dostępne przez WWW to temat nieco bardziej delikatny, nie chcielibyśmy nieprzemyślanymi ruchami odciąć użytkowników od witryny banku ani zepsuć istniejących linków przychodzących. Dobrą praktyką będzie automatyczne i bezwarunkowe przekierowanie do zabezpieczonej wersji witryny na poziomie protokołu (status odpowiedzi HTTP „301 Moved Permanently”). Przeglądarki pomogą, bo same z siebie podnoszą bezpieczeństwo na wiele sposobów – np. domyślnie stosując połączenia HTTPS wszędzie tam, gdzie użytkownik nie podał protokołu.

Krok 2 – wdrożenie HSTS

Nie chcemy, aby wybór między protokołami HTTP i HTTPS zależał od użytkownika. Naszym celem jest sto procent bezpiecznego ruchu. Okazuje się, że istnieje na to prosty sposób – witryna docelowa powinna odsyłać w każdej odpowiedzi nagłówek HSTS (HTTP Strict Transport Security). Już przy pierwszym połączeniu przeglądarka użytkownika dowie się, że na odwiedzanej stronie HTTPS jest obowiązkowy. Od tej chwili jakakolwiek próba nawiązania nieszyfrowanego połączenia HTTP zostanie automatycznie zastąpiona szyfrowanym połączeniem HTTPS.

Wystarczy więc, że dziennikarz choć raz odwiedził witrynę NBP w przeszłości, by wyeliminować ryzyka związane z zatruciem DNS. Udany atak tego typu sprawi, że docelowa strona będzie przez pewien czas nieosiągalna, jednak nie zobaczymy na ekranie sfałszowanej strony z podstawioną zawartością.

W przypadku API całą robotę zrobi TLS i kryptografia klucza publicznego. Gdy wszystkie żądania będą korzystały z HTTPS, to HSTS ani pomoże, ani zaszkodzi.

Jak sprawdzić, czy problem jest aktualny? Otwórz wiersz poleceń i wydaj komendę curl -I https://nbp.pl. Jeśli w odpowiedzi nie zobaczysz nagłówka Strict-Transport-Security, nadal mamy do czynienia z podatnością.

konfiguracja oprogramowania Imperva Incapsula
(źródło)

Czytelnik-eksperymentator zauważy, że witryna NBP używa oprogramowania Imperva Incapsula. Aktywacja nagłówków HSTS sprowadza się tam do kliknięcia jednego checkboxa w panelu konfiguracyjnym a opcja ta pojawiła się w… marcu 2016.

Krok 3 – lista preload HSTS

Uważny czytelnik zauważył, że nagłówek HSTS zadziała dopiero po pierwszym udanym połączeniu z docelowym serwerem. Nadal więc narażamy się na ryzyko wpadki, jeśli pierwsze połączenie będzie nieszyfrowane i zostanie przejęte przez atakującego. Taki scenariusz ataku jest na szczęście bardzo mało prawdopodobny. Czy da się zredukować go do zera? Da się!

Z pomocą przychodzi lista „HSTS preload” czyli spis domen, których właściciele życzą sobie bezwarunkowego podbijania komunikacji do bezpiecznego protokołu HTTPS. Lista zawiera obecnie 118 tysięcy domen, z czego ponad 900 ma końcówkę PL.

zrzut ekranu stąd

Czy Narodowy Bank Polski będzie skłonny dotrzeć aż tutaj? Wątpliwe, na liście HSTS preload nie znalazłem ani jednego polskiego banku – i na dobrą sprawę nie wiem, dlaczego. Może ktoś znający przyczyny zechce podać je w komentarzu?

Z ciekawostek – na liście HSTS preload znajduje się 40 domen najwyższego poziomu, wśród nich *.dev, *.bank, *.google czy kontrowersyjna domena *.zip. Do stron o takiej końcówce adresu żadna przeglądarka nie wyśle nigdy ani jednego żądania HTTP.

„Nie wszystkie witryny potrzebują HTTPS”

Gdy skrytykowałem praktyki NBP w social mediach, kilka osób zarzuciło mi wyolbrzymianie problemu. Argumentacja była taka: skoro witryna banku jest jedynie stroną informacyjną i nie podajemy na niej żadnych haseł, to HTTPS jest niepotrzebny.

Przekonanie, że na poufność i bezpieczeństwo przesyłane treści muszą „zasłużyć”, jest błędne. Po pierwsze: w opisywanej sytuacji możliwy jest dostęp przez HTTP nie tylko do strony WWW, lecz także do API. Po drugie: bezpieczeństwo nic nie kosztuje. Certyfikaty HTTPS są od lat dostępne za darmo a koszty serwowania wersji niezabezpieczonej i zabezpieczonej są takie same. Po trzecie: przez HTTPS strona załaduje się szybciej i sprawniej (sprawdzisz to tutaj). Zoptymalizowane protokoły HTTP/2 oraz HTTP/3 działają jedynie w oparciu o bezpieczną komunikację HTTPS.

Serwowanie witryny przez niezabezpieczony protokół HTTP nie ma żadnych zalet. Do największych wad należy zaś… obniżenie pozycji w wynikach wyszukiwania Google. Co z tego jednak, bank centralny nie ma konkurencji na żadnym rynku.

Telemetria Mozilli (a dokładniej – Firefoxa w wersji nightly) pokazuje, że bezpieczna komunikacja stanowi 89% całości ruchu obsługiwanego przez tę przeglądarkę.

Dane z połowy 2022 zgromadzone na blogu Scotta Helme pokazują, że przeszło 70% spośród miliona najpopularniejszych stron WWW dokonuje automatycznego przekierowania na wersję HTTPS. Gwałtowny wzrost w latach 2016-2019 zawdzięczamy przede wszystkim darmowym certyfikatom HTTPS dostępnym na stronie letsencrypt.org.

Telemetria Chrome wskazuje, że ponad 95% czasu pracy tej przeglądarki na platformach Windows i MacOS użytkownicy spędzają w witrynach serwowanych przez HTTPS.

Niezabezpieczony HTTP kontra niezabezpieczone Wi-Fi

Dygresja. Mniej biegli w protokołach sieciowych czytelnicy mogą poczuć się zdezorientowani – dlaczego narzekam na stronę NBP serwowaną przez HTTP a jednocześnie stoję na stanowisku, że korzystanie z publicznego Wi-Fi jest bezpieczne?

Odpowiedź jest nieoczywista, lecz mimo wszystko prosta. Protokół HTTPS gwarantuje poufność i integralność na całej trasie pakietów podróżujących między komputerem a serwerem – nawet wówczas, gdy korzystamy z publicznego Wi-Fi. Sytuacja odwrotna – „gołe” HTTP przez bezpieczne Wi-Fi – to ochrona poufności i integralności transmisji jedynie pomiędzy komputerem a punktem dostępowym. Nie wiemy, co dzieje się dalej.

Co na to Narodowy Bank Polski?

19 maja 2023 prezes NBP powiedział: „Narodowy Bank Polski zawsze należał do najbardziej zaawansowanych technologicznie banków centralnych, potwierdza to również niedawna nagroda dla NBP ze strony międzynarodowego, eksperckiego gremium Central Banking Awards” (źródło: Youtube). Nie podzielam tego optymizmu – moim zdaniem opisana seria zaniedbań jest kompromitująca.

Przypomnienie dla nowych czytelników – choć niniejszy blogasek ukazuje się jedynie w postaci elektronicznej, to jest czasopismem wpisanym do rejestru dzienników i czasopism (numer Rej Pr 3727, sygnatura akt I Ns Rej. Pr 10/20). Jako redaktor naczelny czasopisma Informatyk Zakładowy, 21 maja 2023 wysłałem do NBP następujące pytania:

  1. Witryna NBP jest dostępna przez protokoły HTTPS oraz nieszyfrowany HTTP. Czy Bank akceptuje ryzyko wynikające z ataków man-in-the-middle oraz DNS Cache Poisoning, możliwych do zrealizowania wobec użytkowników otwierających witrynę http://www.nbp.pl?
  2. Dlaczego Bank nie stosuje przekierowań HTTP 301 ani nagłówków HSTS pozwalających na redukcję owego ryzyka?
  3. Wszystkie przykłady użycia API na stronie http://api.nbp.pl/ zawierają żądania HTTP. Czy Bank akceptuje ryzyko wynikające z ataków man-in-the-middle oraz DNS Cache Poisoning możliwych do zrealizowania podczas użycia przykładowych żądań do API?
  4. Jaki procent zapytań kierowanych do API realizowanych jest poprzez nieszyfrowany protokół HTTP?

Do dnia publikacji tekstu nie otrzymałem żadnej odpowiedzi. Jeśli kiedykolwiek nadejdzie, artykuł zostanie uzupełniony.



O autorze: zawodowy programista od 2003 roku, pasjonat bezpieczeństwa informatycznego. Rozwijał systemy finansowe dla NBP, tworzył i weryfikował zabezpieczenia bankowych aplikacji mobilnych, brał udział w pracach nad grą Angry Birds i wyszukiwarką internetową Microsoft Bing.

17 odpowiedzi na “Narodowy Bank Polski powinien porzucić protokół HTTP”

Straszliwie mieszasz.
Po pierwsze, nie ma „protokołu HTTPS”. Jest komunikacja protokołem HTTP odbywająca się kanałem szyfrowanym TLS.
Po drugie, jak najbardziej można wyobrazić sobie realizację poufności i integralności bez uciekania się do szyfrowanego kanału komunikacji (patrz np. Xmlsec).
Po trzecie – użycie HTTPS zapewnia co najwyżej integralność i poufność do zakończenia TLS, a niekoniecznie do źródła danych w połączeniu (ważne rozróżnienie kiedy TLS jest obsługiwany np. przez rev-proxy przed właściwym serwerem.
Po czwarte – samo w sobie użycie TLS, jeśli nie weryfikujemy świadomie certyfikatu drugiej strony jest psu na budę (naprawdę bezkrytycznie uwierzyłbyś certyfikatowi NBP wystawionemu przez chińskie, czy rosyjskie CA?).
Po piąte – argument o pozycjonowaniu w góglu jest raczej argumentem przeciwko samozwańczemu „regulatorowi internetu”.

ad 1) to prawda, ale Twoja wersja to niewygodne osiem słów zamiast jednego – efektywnie oznaczającego to samo
ad 2) to prawda, ale co miałoby z tego wynikać?
ad 3) to prawda, ale co z tego, skoro terminacja połączenia TLS z definicji będzie miała miejsce w infrastrukturze kontrolowanej przez drugą stronę komunikacji?
ad 4) to prawda, ale nie unieważnia ona tezy artykułu
ad 5) a to już opinia

Ad 1) No niestety. Brak precyzji sugeruje, że nie wiesz o czym piszesz. Albo, co gorsza, utrwalasz w publiczności takie paskudne uproszczenia i obniżasz poziom.
Ad 2) i 4) łącznie – Tyle, że ani sam w sobie TLS nie powoduje magicznie, że łączność jest bezpieczna, ani jego brak nie czyni jej niebezpieczną istotna jest całość. I warto to rozumieć. Inaczej tworzą się niebezpieczne mity, takie jak ten o kłódce w przeglądarce.
Owszem, TLS jest po prostu sposobem powszechnym i najłatwiej sobie poradzić w ten sposób, ale to zupełnie inna sprawa niż „nie ma TLS, wszyscy zginiemy!”
ad 3) No… niekoniecznie. Są różne zespoły w ramach jednego podmiotu, bywają różne podmioty swiadczące usługi na rzecz innych podmiotów. Warto mieć świadomość, że TLS może „kończyć się wcześniej”.
ad 5) To Ty to przytaczasz jako „argument”. Warto zresztą zwrócić uwagę, że TLS powoduje, że bez dekrypcji „po drodze” nie da się np. cache’ować (kurczę, nie ma na to dobrego słowa po polsku) staticów. A, no i nie zgodzę się, że serwowanie treści z TLS-em i bez nie daje różnicy w kosztach. Jedna rzecz to oczywiście same certyfikaty (bo jak zaproponujesz postawienie enbepu na let’s encrypcie wyśmieję Cię po całości), ale to nie jest aż taki gigantyczny koszt (powiedzmy, że 1300zł netto za EV z Certum można przełknąć, ale jak musisz tego więcej mieć, może już zacząć boleć), ale druga rzecz to jednak szyfrowanie nie jest obojętne obciążeniowo. Owszem, jak masz wordpressa, na którego wchodzą trzy osoby dziennie, tego nie widać, ale jak masz tysiące połączeń na sekundę, już wygląda to trochę inaczej (chociaż pewnie w tej skali już masz zupełnie inną architekturę, TLS lub jego brak może decydować np. czy Twoja kilkuletnia F5, czy inny Netscaler jeszcze sobie da radę, czy już nie).
Swoją drogą, to całe szyfrowanie i tak idzie szczekać w prawie wszystkich większych firmach, gdzie masz inspekcję TLS na wyjściu na świat, do tego pewnie z połowa antywirusów robi to samo na poziomie klienckich windowsów.
Bezpieczeństwo jest naprawdę troszkę bardziej skomplikowane niż Ci się wydaje. A kluczowym pytaniem jest zawsze przed czym chcemy się zabezpieczyć. W przypadku „zwykłej” strony banku, pewnie po prostu dobrą praktyką faktycznie byłoby dla świętego spokoju przekierowanie na https. Bo czemu nie. Ale jego brak nie jest żadnym wielkim problemem – to nie jest serwis transakcyjny, do którego logują się użytkownicy. Co do API, pytanie co to za API, co z niego dostajemy, czy w ogóle wymaga uwierzytelniania, jaka jest „istotność” danych, które dostajemy itd.

Tu mamy konkretne API. Jeśli ktoś po drodze zmieni kurs waluty, to można mieć problemy – podejmując złą decyzję albo wysyłając błędną deklarację podatkową.

Tak, spodziewałem się takiego komentarza.
Żeby się zabezpieczyć przed taką sytuacją, musielibyśmy mieć możliwość pobrania podpisanego, znakowanego czasem, dokumentu, a nie samo zabezpieczenie kanału komunikacyjnego. To są dwie różne rzeczy. Zabezpieczenie kanału w żaden sposób nie zabezpiecza przed choćby błędnym działaniem oprogramowania po drugiej stronie.

Co do zasady nie istnieje coś takiego jak pełne bezpieczeństwo. Zawsze się znajdzie jakaś dziura. Bezpieczeństwo to zawsze analiza ryzyka. Natomiast mając gołe HTTP na pewno bezpieczeństwo danych jest o wiele, wiele mniejsze niż z HTTPS. Tak że chyba sam się trochę nie znasz panie Nazwa ;]

„Bezpieczeństwo jest naprawdę troszkę bardziej skomplikowane niż Ci się wydaje. A kluczowym pytaniem jest zawsze przed czym chcemy się zabezpieczyć.”
W moim tekście postuluję eliminację istniejących podatności na MITM oraz DNS spoofing. Bezpieczeństwo to proces, który dobrze zacząć od identyfikacji słabych punktów. Ty wspominasz o Xmlsec, więc odpowiedz na pytanie: bardziej prawdopodobne jest trafienie na lewy cert wystawiony przez wrogie CA czy pominięcie weryfikacji podpisu XML po stronie klienta?

Obstawiam, że źródło problemu to nie NBP. Skoro API dostępne jest również z HTTPS, to HTTP zostało w formie kompatybilności wstecznej. Jakby od jutra mieli wyłączyć HTTP, to pewnie z tego powodu byłaby panika, bo wiele archaicznych systemów do przetwarzania danych u wielu podmiotów by przestała działać. Niejedno już widziałem i dla mnie, jako sieciowca, to najbardziej prawdopodobny scenariusz.
Twój scenariusz jest jak najbardziej możliwy, ale myślę, że modyfikacja treści przez mitm byłaby najmniejszym zmartwieniem, jakby ktoś to faktycznie gdzieś po drodze go zrobił. Atak realny, ale większą finansową szkodę zrobi imho wyłączenie HTTP.

Myślę, że to prawdopodobne niestety. Na nbp mają włączone TLS 1.2 i 1.3 (czyli powiedzmy nowe w uproszczeniu), więc mógłby być problem z np. z Windows XP… A wbrew pozorom w sektorze publicznym Windows XP jeszcze istnieje, a nawet IE istnieje. Pewnie się znajdą jeszcze takie aplikacje, które używają Java 1.6, które z tego co pamiętam TLS 1.2 nie obsługuje w ogóle (JDK 1.7 obsługuje już, chociaż nie domyślnie).

No tak też mi się wydaje, że ten artykuł trzeba pokazać wszystkim instytucjom finansowym na całym świecie i zapytać, czy korzystają jeszcze z api wystawionego po http i czy ich klienci nie stracą oszczędności całego życia, bo trzeba go przekierować 301 na https.
Już niejeden się przejechał na podbiciu TLS do wersji 1.2, a co dopiero wymuszenie szyfrowania.

Strona npb.pl stoi na WordPress, w dodatku miejscami średnio skonfigurowanym:

O ile samo użycie WP nie jest niczym złym, tym bardziej, że stron to tylko wizytówka, to niechlujne %%sitename%% w zestawieniu z „Konstytucją PR” wygląda jakby niepoważnie.

Zaś co do użycia HTTP w API – nic nie stoi na przeszkodzie, by korzystać z HTTPS. A developerom będzie łatwiej debug zrobić tcpdumpem przy nieszyfrowanej wersji! 😉

Niestety fragment nagłówków został wycięty, zapewne za sprawą nawiasów, zatem bez nich:
meta property=”og:title” content=”%%sitename%%” /
meta property=”og:description” content=”Narodowy Bank Polski jest bankiem centralnym Rzeczypospolitej Polskiej. NBP, zgodnie z Konstytucją RP, odpowiada za wartość polskiego pieniądza.” /

Trochę taka sprawa jak: a co jak dziewczyna Cię zdradza? Załóż jej szyfrowany protokół, to Cię nie okłamie gdy zapytasz, czy Cię kocha 😉

gównoburza. starsze wersje nie będą działać a i dla programistów wygodniej pracować. tam żadne tajne dane nie są udostępniane. one sa wrecz publicznie dostępne. Wiec gownoburza.

Gdy zaczynałem czytać artykuł też skłaniałem się raczej ku „szukaniu problemu na siłę”. Niemniej jednak, argument z modyfikacją zwrotek z API w locie ma sens i odpowiednio ukierunkowany ma szansę narobić szkód więc 👍 za nagłośnienie tematu.

Bardziej mnie natomiast martwi to, że komuś w NBP nie chciało się poświęcić jednego dnia (zakładając, że robiłby to pierwszy raz w życiu) na ogarnięcie aspektów opisanych w artykule. Boję się wiedzieć jakie kwiatki są w części, której przeciętny Kowalski nie widzi.

A co w tym niebezpiecznego, poza tym, że przeglądarki się czepiają i blokują taką stronę (bardzo denerwujące, swoją drogą)? Czasami nie da się pobrać apletu Javy, bo przeglądarka krzyczy, że to zagrożenie.

Fajny wpis, generalnie to też jestem za HTTPS i pewnie większość czytających też, tylko, że nie wszędzie się da, albo nie da się szybko:)
Parę myśli do fragmentu: „Serwowanie witryny przez niezabezpieczony protokół HTTP nie ma żadnych zalet. Do największych wad należy zaś… obniżenie pozycji w wynikach wyszukiwania Google. ”
1) Swego czasu rozgorzała ciekawa dyskusja na temat SSL i jego braku, tam się też parę ciekawych wątków i argumentów przewinęło:
https://sekurak.pl/ransomware-w-placowce-medycznej-w-otwocku-objete-incydentem-dane-pacjentow-z-5-lat-w-tym-dane-kontaktowe-wyniki-badan-dokumentacja-medyczna/
ktoś napisał „W takim przypadku jedyna zaleta jest tak że Twój ISP musi się spocić żeby prześledzić po jakich stronach łazisz. Inny zalet nie widzę. ”
2) Ten system (czyli wcześniejsza wersja algorytmu Google) oceniał, czy strony są bezpieczne, czyli czy korzystają z protokołu HTTPS.
Google usunęło go z listy wycofanych systemów, prawdopodobnie ze względu na fakt, że większość stron już korzysta z tego protokołu, a kwestie bezpieczeństwa są ważne, ale nie mają już tak dużego wpływu na pozycjonowanie.
https://www.ministerstworeklamy.pl/blog/nowosci-z-branzy/powazna-zmiana-w-seo-czy-uderzy-w-twoja-strone/
3) Generalnie, to większość stron w Polsce opartych ma HTTSP: https://cyberfolks.pl/blog/wersje-wordpress-w-polsce-w-maju-2023/
więc dane pokrywają się z danymi od Scotta.
Wizerunkowo… no cóż, NBP traci, ale patrząc na strony powiatów i gmin (2825 JST)
https://dane.gov.pl/pl/dataset/2009,dane-teleadresowe-jst-w-polsce/resource/45174/table
to nie wszystkie mają HTTPS, więc analizując np. w https://httpstatus.io zbliżymy się do ok 70%.
4) Na pewno NBP i inni admini mają cały czas pełne ręce roboty i trochę do nadrobienia – na punkty 34 do 65 przegrywa z Twoją stroną:
https://internet.nl/site/informatykzakladowy.pl/2130669/
PS.
Hmmm, która strona bezpieczników w Polsce jest najlepiej zabezpieczona? 😉 Ktoś taką widział? parę z gov.pl miało powyżej 80 pkt w internet.nl, ale faktycznie na liście HTST trochę mało tych polskich.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *