Buduję fundamenty backendu juz-ide — kontekst konta, logowanie, rejestracja. Przy okazji przeglądam wszystko co mam w kodzie odpowiedzialnym za zabezpieczenie danych i widzę coś, co nie powinno tam być od dawna.
Co znalazłem i dlaczego to był problem
Wyobraź sobie zamek do drzwi, który wygląda solidnie — solidna obudowa, gruba stal. Ale producent zdecydował, że każdy egzemplarz tego zamka używa tego samego klucza. Kupujesz zamek w sklepie, dostajesz klucz, i… twój sąsiad z tym samym modelem ma identyczny klucz do swoich drzwi. Twój też pasuje do jego mieszkania.
Mniej więcej tak działało zabezpieczenie, które miałem w kodzie.
Problem sprowadzał się do jednego: użyta funkcja była z grupy, którą dokumentacja Node.js wprost oznacza jako wycofaną i odradza w nowym kodzie. Stary, naiwny sposób — taki, jaki wkleja się z pierwszego lepszego przykładu z internetu — zamiast aktualnego standardu z wbudowanym sprawdzaniem integralności danych.
Miałem ten kod w projekcie i nie wiedziałem. Wziąłem przykład z internetu, sprawdziłem że działa — i poszedłem dalej.
Co zrobiłem zamiast
Zamieniłem na aktualny standard — taki z wbudowanym sprawdzaniem, czy dane nie zostały po drodze zmienione, i z porządnym zabezpieczeniem hasła. Sama zmiana kodu była prosta. Zmienił się też format zaszyfrowanych danych — i tu zadziałał komfort wczesnego etapu: wszystkie dane były lokalne i testowe, bez ani jednego prawdziwego użytkownika. Mogłem je po prostu przebudować na nowy format, bez obawy, że komuś coś zniknie.
Gdyby aplikacja miała już użytkowników, taka zmiana formatu szyfrowania byłaby poważną, ryzykowną operacją — tu była zwykłym porządkiem.
Lekcja
Kryptografia starzeje się. Mechanizm, który był bezpieczny według standardów sprzed lat, dziś może być wycofany — a dokumentacja Twojego środowiska mówi to wprost. Problem nie w tym, że ktoś popełnił błąd; problem w tym, że kod żyje długo, a standardy się zmieniają.
Dobra zasada: jak wchodzisz w obszar zabezpieczeń, nie ufaj starym przykładom z internetu. Sprawdzaj dokumentację swojego środowiska pod kątem ostrzeżeń o wycofanych funkcjach. Szukaj aktualnych rekomendacji — na przykład ze strony OWASP, która prowadzi listę aktualnych zaleceń kryptograficznych.
I sprawdzaj cały kod, nie tylko to co właśnie zmieniasz.
Kilka tygodni później, przy pracach wokół RODO, ta sama klasa błędu — przestarzałe zabezpieczenie w innym miejscu — wróciła. Ten post to pierwsza połowa historii. Naprawienie jednego miejsca nie znaczy przeglądu całości.