Większość aplikacji korporacyjnych na co dzień korzysta z kryptografii — ale niewiele organizacji wie dokładnie gdzie i jak jest ona wykorzystywana.

Na przestrzeni lat rozwoju bazy kodu gromadzą przestarzałe biblioteki, nieaktualne algorytmy, zaszyte na stałe sekrety i niebezpieczne implementacje. Te ukryte problemy często pozostają niezauważone aż do audytu bezpieczeństwa, przeglądu zgodności lub — co gorsza — incydentu bezpieczeństwa.

Ten artykuł omawia dziesięć najczęstszych luk kryptograficznych występujących w oprogramowaniu korporacyjnym oraz wyjaśnia, jak zespoły inżynierskie mogą proaktywnie je identyfikować i usuwać.

Dlaczego luki kryptograficzne są trudne do wykrycia

W przeciwieństwie do SQL injection czy cross-site scripting, problemy kryptograficzne rzadko powodują widoczne błędy aplikacji.

Zamiast tego często pozostają ukryte w:

• Przestarzałych usługach
• Wewnętrznych bibliotekach
• Systemach uwierzytelniania
• Konfiguracjach TLS
• Bramach API
• Aplikacjach mobilnych
• Potokach CI/CD
• Zależnościach zewnętrznych

Duża organizacja może posiadać tysiące repozytoriów zawierających kod kryptograficzny napisany przez lata przez różne zespoły.

Bez automatycznego wykrywania te zagrożenia pozostają w dużej mierze niewidoczne.

1. Przestarzałe algorytmy kryptograficzne

Jednym z najczęstszych ustaleń podczas ocen bezpieczeństwa jest dalsze stosowanie algorytmów, które nie są już uznawane za bezpieczne.

Przykłady obejmują:

• MD5
• SHA-1
• DES
• RC4
• 3DES

Chociaż algorytmy te były kiedyś standardem branżowym, postępy w kryptoanalizie sprawiły, że wiele z nich nie nadaje się do nowoczesnych aplikacji.

Dlaczego to niebezpieczne

Atakujący mogą wykorzystać znane słabości, aby:

• Sfałszować podpisy cyfrowe
• Generować kolizje
• Odzyskać tekst jawny
• Obejść kontrole integralności

Zalecana poprawka

Zastąp przestarzałe algorytmy nowoczesnymi alternatywami, takimi jak:

• SHA-256 lub SHA-384
• AES-256
• Nowoczesne zestawy szyfrów TLS

2. Słabe rozmiary kluczy RSA

Wiele systemów korporacyjnych nadal polega na RSA-1024 lub nawet mniejszych kluczach.

Obecne zalecenia dotyczące bezpieczeństwa wymagają zwykle co najmniej RSA-2048, podczas gdy organizacje przygotowujące się do migracji postkwantowej zaczynają oceniać alternatywy odporne na ataki kwantowe.

Dlaczego to niebezpieczne

Mniejsze rozmiary kluczy zmniejszają nakład obliczeniowy potrzebny do ataku i mogą nie spełniać wymogów zgodności.

Zalecana poprawka

• Zaktualizuj do RSA-3072 lub silniejszego, tam gdzie to zasadne.
• Opracuj plan działania w kierunku algorytmów postkwantowych.

3. Zaszyte na stałe klucze kryptograficzne

Programiści czasami umieszczają klucze szyfrujące bezpośrednio w kodzie źródłowym dla wygody podczas rozwoju.

Przykłady obejmują:

private static final String SECRET_KEY = "my-secret-key";

Te sekrety często pozostają w produkcji długo po zakończeniu prac rozwojowych.

Dlaczego to niebezpieczne

Każdy z dostępem do repozytorium — lub ktokolwiek, kto zdobędzie wyciekły kod źródłowy — może natychmiast skompromitować zaszyfrowane dane.

Zalecana poprawka

Przechowuj sekrety w dedykowanych systemach zarządzania sekretami, takich jak:

• Cloud KMS
• HashiCorp Vault
• Azure Key Vault
• AWS Secrets Manager

4. Zaszyte na stałe wektory inicjalizujące (IV)

Tryby szyfrowania takie jak CBC i GCM wymagają unikalnych wektorów inicjalizujących.

Niestety programiści czasami ponownie wykorzystują statyczne IV.

Dlaczego to niebezpieczne

Powtarzające się IV znacząco osłabiają szyfrowanie i mogą ujawnić relacje tekstu jawnego.

Zalecana poprawka

Zawsze generuj kryptograficznie bezpieczne, losowe IV.

Nigdy nie wykorzystuj ich ponownie.

5. Słaba generacja liczb losowych

Nie wszystkie generatory liczb losowych nadają się do operacji kryptograficznych.

Słabe przykłady obejmują:

• rand()
• Math.random()
• przewidywalne ziarna (seedy)

Dlaczego to niebezpieczne

Słaba losowość może skompromitować:

• Tokeny sesji
• Linki do resetowania hasła
• Klucze API
• Klucze szyfrujące
• Sekrety podpisujące JWT

Zalecana poprawka

Zawsze używaj kryptograficznie bezpiecznych generatorów losowych dostarczanych przez Twoją platformę.

6. Niebezpieczne tryby szyfrowania

Algorytmy szyfrowania są tylko tak bezpieczne, jak tryb, w którym działają.

Jednym z najczęściej wykrywanych problemów jest stosowanie:

• AES-ECB

ECB ujawnia informacje strukturalne, ponieważ identyczne bloki tekstu jawnego dają identyczne bloki szyfrogramu.

Dlaczego to niebezpieczne

Atakujący mogą wywnioskować wzorce bez odszyfrowywania danych.

Zalecana poprawka

Używaj uwierzytelnionych trybów szyfrowania, takich jak:

• AES-GCM
• ChaCha20-Poly1305

7. Niewłaściwa walidacja certyfikatów

Aplikacje czasami wyłączają walidację certyfikatów TLS podczas testów — a kod przypadkowo trafia na produkcję.

Przykłady obejmują:

• Zaufanie do wszystkich certyfikatów
• Ignorowanie weryfikacji nazwy hosta
• Akceptowanie wygasłych certyfikatów

Dlaczego to niebezpieczne

Umożliwia to ataki typu Man-in-the-Middle.

Zalecana poprawka

Nigdy nie wyłączaj walidacji certyfikatów poza izolowanymi środowiskami deweloperskimi.

8. Nieaktualne biblioteki kryptograficzne

Wiele organizacji nadal korzysta z bibliotek wydanych wiele lat temu.

Te zależności mogą zawierać:

• Znane CVE
• Przestarzałe API
• Niewspierane algorytmy

Dlaczego to niebezpieczne

Nawet bezpieczny kod aplikacji staje się podatny, gdy jest zbudowany na nieaktualnych bibliotekach kryptograficznych.

Zalecana poprawka

Utrzymuj regularny proces aktualizacji zależności i monitoruj biuletyny bezpieczeństwa.

9. Niespójna kryptografia między usługami

Duże organizacje często pozwalają każdemu zespołowi wybrać własną strategię szyfrowania.

W efekcie różne usługi mogą korzystać z:

• Różnych algorytmów
• Różnych rozmiarów kluczy
• Różnych bibliotek
• Różnych polityk certyfikatów

Dlaczego to niebezpieczne

Niespójne bezpieczeństwo tworzy słabe ogniwa i znacząco komplikuje przyszłe migracje.

Zalecana poprawka

Ujednolić polityki kryptograficzne w zespołach inżynierskich.

10. Nieznane zasoby kryptograficzne

Być może największym ryzykiem nie jest konkretna luka — to po prostu niewiedza, gdzie kryptografia w ogóle występuje.

Wiele organizacji nie potrafi odpowiedzieć na pytania takie jak:

• Które repozytoria używają RSA?
• Gdzie zaimplementowano ECDSA?
• Które usługi nadal polegają na SHA-1?
• Które aplikacje zawierają osadzone certyfikaty?
• Które API generują klucze szyfrujące?

Bez widoczności zespoły bezpieczeństwa nie mogą skutecznie priorytetyzować działań naprawczych.

Zalecana poprawka

Stwórz kompletny inwentarz kryptograficzny w całej organizacji.

Automatyczne skanowanie może zidentyfikować:

• Algorytmy
• Klucze
• Certyfikaty
• Biblioteki
• Konfiguracje TLS
• Przestarzałe implementacje

Dlaczego ręczne przeglądy się nie skalują

Nowoczesne przedsiębiorstwa często zarządzają:

• Setkami inżynierów
• Tysiącami repozytoriów
• Milionami linii kodu
• Wieloma językami programowania
• Dekadami narosłego długu technicznego

Ręczne przeglądy kodu po prostu nie zapewniają pełnej widoczności użycia kryptografii.

Automatyczna analiza statyczna i narzędzia do wykrywania kryptografii są niezbędne do utrzymania bezpieczeństwa na dużą skalę.

Jak pomaga automatyczne wykrywanie kryptografii

Nowoczesne narzędzia skanujące mogą wykryć:

• Przestarzałe algorytmy

• Słabe rozmiary kluczy

• Osadzone certyfikaty

• Zaszyte na stałe klucze

• Biblioteki kryptograficzne

• Konfiguracje TLS

• Niebezpieczne tryby szyfrowania

• Problemy z walidacją certyfikatów

• Algorytmy podatne na ataki kwantowe

Daje to zespołom inżynierskim pełny obraz krajobrazu kryptograficznego i znacząco skraca czas usuwania problemów.

Przygotowanie do ery postkwantowej

Wiele dzisiejszych luk kryptograficznych zyskuje na znaczeniu w miarę jak organizacje przygotowują się do kryptografii postkwantowej.

Przed migracją do algorytmów takich jak ML-KEM czy ML-DSA organizacje muszą najpierw zrozumieć:

• Gdzie wykorzystywana jest kryptografia