zaszyte w kodzie hasło

Zaszyte w kodzie hasło (hardcoded credentials) to hasło, klucz kryptograficzny albo token umieszczony na stałe w kodzie lub konfiguracji produktu. MITRE opisuje tę słabość jako CWE-798: produkt zawiera zaszyte w kodzie dane uwierzytelniające, takie jak hasło albo klucz kryptograficzny ^[1]. Takie hasło jest zwykle identyczne we wszystkich instalacjach i administrator nie może go zmienić ^[1]. W zestawieniu CWE Top 25 za 2024 rok słabość zajęła 22. miejsce ^[5].

Jak działa

Hasło wpisane w kod trafia do każdej kopii programu: do paczki instalacyjnej, repozytorium, kopii zapasowych i na dyski klientów. Kto zdobędzie jedną kopię, zna hasło wszystkich. Wystarczy dekompilacja aplikacji, przejrzenie skryptu albo odczyt pamięci procesu. MITRE ostrzega, że przy zaszytych hasłach jest niemal pewne, że złośliwi użytkownicy uzyskają dostęp do danego konta ^[1].

MITRE wyróżnia dwa kierunki ^[1].

Wariant przychodzący przypomina domyślne hasło, ale jest groźniejszy: domyślne hasło można zmienić, a zaszytego nie. Wariant wychodzący oznacza, że sekret, który miał chronić serwer, jest rozsyłany do każdego klienta.

Schemat poniżej pokazuje typową drogę od kodu do nadużycia.

RYS. 1Droga zaszytego hasła do atakującego

W WordPressie

WordPress przechowuje dane dostępowe do bazy w pliku wp-config.php, a nie w kodzie rdzenia. Każda instalacja ma własne hasło, więc nie jest to CWE-798 w ścisłym sensie. Plik wymaga jednak ochrony. Dokumentacja zaleca, by tylko właściciel i serwer WWW mogli go odczytać, co zwykle oznacza uprawnienia plików 400 albo 440, oraz dopuszcza przeniesienie go katalog wyżej, poza katalog publiczny ^[6]; szerzej w haśle utwardzanie pliku wp-config.php.

Ten sam plik może przechowywać dane do aktualizacji przez FTP lub SSH: stałe FTP_USER i FTP_PASS ^[7]. Nie wolno ich kopiować do repozytorium razem z kodem motywu. Dokumentacja opisuje też stałą WP_ENVIRONMENT_TYPE, którą można ustawić zmienną środowiskową PHP ^[7]; ten sam mechanizm pozwala trzymać różne ustawienia dla środowiska produkcyjnego i testowego.

Prawdziwe zaszyte hasła pojawiają się we wtyczkach i motywach:

• klucz API usługi zewnętrznej wpisany w plik PHP wtyczki i rozesłany do wszystkich użytkowników;
• „serwisowe” konto albo hasło pozwalające autorowi wejść do panelu, które w praktyce jest tylną furtką (backdoor);
• dane dostępowe do serwera aktualizacji zaszyte w kodzie, co otwiera drogę do ataku na łańcuch dostaw (supply chain attack).

Taki błąd jest szczególnym przypadkiem podatności we wtyczce i zwykle nie da się go usunąć bez nowej wersji od autora.

Zagrożenia i skutki

Skutkiem jest obejście kontroli dostępu. MITRE zwraca uwagę, że skoro wszystkie instalacje mają te same dane, możliwe są masowe ataki, na przykład robaki ^[1]. Wśród skutków wymienia też ujawnienie danych i wykonanie nieautoryzowanego kodu ^[1].

Jeśli zaszyte hasło daje dostęp do bazy z wysokimi uprawnieniami, skutki obejmują wyciek danych i eskalację uprawnień, a czasem wykonanie poleceń systemowych na serwerze ^[2]. Jeśli daje prawo zapisu na serwerze aktualizacji, atakujący może rozesłać złośliwe oprogramowanie wszystkim klientom producenta ^[3].

Jak się bronić

MITRE zaleca przechowywanie danych uwierzytelniających poza kodem, w silnie chronionym, zaszyfrowanym pliku konfiguracyjnym albo bazie ^[1]. Dla kont przychodzących zaleca tryb „pierwszego logowania”, w którym użytkownik ustawia własne, silne hasło, oraz przechowywanie haseł jako jednokierunkowych skrótów z losową solą ^[1].

OWASP zwraca uwagę, że w wielu organizacjach sekrety są zaszyte w kodzie jawnym tekstem i porozrzucane po plikach konfiguracyjnych ^[4]. Zaleca centralne zarządzanie sekretami: przechowywanie, wydawanie, audyt i rotację w jednym miejscu ^[4]. Przy tym przestrzega, że zmienne środowiskowe są zwykle dostępne dla wszystkich procesów i mogą trafić do logów albo zrzutów pamięci ^[4].

Wykrywanie powinno działać przed zapisaniem zmiany. OWASP zaleca wyłapywanie sekretów w edytorze albo haczykiem przed zatwierdzeniem zmiany (pre-commit hook) ^[4]. Usunięcie sekretu z repozytorium może wymagać przepisania historii gita ^[4].

Gdy sekret wycieknie, samo usunięcie go z kodu nie wystarczy. OWASP zaleca natychmiastowe unieważnienie ujawnionego klucza, a potem jego wymianę ^[4]; zob. rotacja kluczy. Regularna rotacja sprawia, że skradzione dane działają tylko przez krótki czas ^[4].

Historia i przykłady

MITRE wśród przykładów CWE-798 wymienia CVE-2010-2772: zaszyte dane uwierzytelniające w systemie SCADA, wykorzystane przez robaka Stuxnet ^[1].

CERT Polska 14 maja 2026 roku opublikował informację o podatnościach w programie Comarch ERP Optima ^[2]. W CVE-2025-68421 klient programu wykorzystuje zaszyte w kodzie hasło użytkownika bazy danych, którego nie można zmienić; zdalny atakujący może dzięki niemu uzyskać dostęp do bazy z podniesionymi uprawnieniami, w tym wykonywać polecenia systemowe na serwerze ^[2]. Poprawkę zawiera wersja 2026.4 ^[2].

Niebezpiecznik w październiku 2025 roku opisał podatności w programie FARA do obsługi parafii ^[3]. Analiza zdekompilowanej aplikacji ujawniła zaszyte dane dostępowe do serwera FTP producenta z prawem zapisu oraz uniwersalne hasła do lokalnych baz SQLite, takie same u każdego klienta ^[3]. Podatność otrzymała numer CVE-2025-4049, a w wersji 5.0.80.35 producent zastąpił stałe hasła hasłami generowanymi dla każdej instalacji na podstawie numeru seryjnego maszyny ^[3].