Nigdy nie wpisuj haseł na stałe do swojego kodu. Niedawno pojawiło się to na liście 25 najbardziej niebezpiecznych błędów w programowaniu :
Zakodowanie na stałe tajnego konta i hasła w oprogramowaniu jest niezwykle wygodne - dla wykwalifikowanych inżynierów wstecz. Jeśli hasło jest takie samo we wszystkich programach, każdy klient staje się podatny na ataki, gdy hasło nieuchronnie staje się znane. A ponieważ jest zakodowany na stałe, naprawienie go jest ogromnym problemem.
Informacje konfiguracyjne, w tym hasła, należy przechowywać w oddzielnym pliku, który aplikacja odczytuje podczas uruchamiania. To jedyny prawdziwy sposób, aby zapobiec wyciekowi hasła w wyniku dekompilacji (nigdy nie kompiluj go do pliku binarnego na początek).
Więcej informacji na temat tego częstego błędu można znaleźć w artykule CWE-259 . Artykuł zawiera dokładniejszą definicję, przykłady i wiele innych informacji na temat problemu.
W Javie jednym z najłatwiejszych sposobów jest użycie klasy Preferences. Jest przeznaczony do przechowywania wszelkiego rodzaju ustawień programu, z których niektóre mogą zawierać nazwę użytkownika i hasło.
import java.util.prefs.Preferences;
public class DemoApplication {
Preferences preferences =
Preferences.userNodeForPackage(DemoApplication.class);
public void setCredentials(String username, String password) {
preferences.put("db_username", username);
preferences.put("db_password", password);
}
public String getUsername() {
return preferences.get("db_username", null);
}
public String getPassword() {
return preferences.get("db_password", null);
}
}
W powyższym kodzie możesz wywołać setCredentialsmetodę po wyświetleniu okna dialogowego z pytaniem o nazwę użytkownika i hasło. Gdy potrzebujesz połączyć się z bazą danych, możesz po prostu użyć metod getUsernamei getPassword, aby pobrać zapisane wartości. Dane logowania nie zostaną zakodowane na stałe w Twoich plikach binarnych, więc dekompilacja nie będzie stanowić zagrożenia dla bezpieczeństwa.
Ważna uwaga: Pliki preferencji to zwykłe pliki tekstowe XML. Upewnij się, że podejmujesz odpowiednie kroki, aby uniemożliwić nieautoryzowanym użytkownikom przeglądanie plików surowych (uprawnienia UNIX, uprawnienia systemu Windows itp.). Przynajmniej w Linuksie nie stanowi to problemu, ponieważ wywołanie Preferences.userNodeForPackagespowoduje utworzenie pliku XML w katalogu domowym bieżącego użytkownika, który i tak jest nieczytelny dla innych użytkowników. W systemie Windows sytuacja może wyglądać inaczej.
Więcej ważnych uwag: W komentarzach do tej odpowiedzi i innych było wiele dyskusji na temat prawidłowej architektury w tej sytuacji. Oryginalne pytanie tak naprawdę nie wspomina o kontekście, w którym aplikacja jest używana, więc opowiem o dwóch sytuacjach, które przychodzą mi do głowy. Pierwszy to przypadek, w którym osoba korzystająca z programu już zna (i ma prawo znać) dane uwierzytelniające do bazy danych. Drugi to przypadek, w którym programista próbuje ukryć dane uwierzytelniające bazy danych przed osobą korzystającą z programu.
Pierwszy przypadek: użytkownik jest upoważniony do poznania danych logowania do bazy danych
W takim przypadku sprawdzi się rozwiązanie, o którym wspomniałem powyżej. PreferenceKlasa Java będzie przechowywać nazwę użytkownika i hasło w postaci zwykłego tekstu, ale plik preferencji będzie mógł odczytać tylko upoważniony użytkownik. Użytkownik może po prostu otworzyć plik XML preferencji i odczytać dane logowania, ale nie stanowi to zagrożenia dla bezpieczeństwa, ponieważ na początku znał dane uwierzytelniające.
Drugi przypadek: próba ukrycia danych logowania przed użytkownikiem
Jest to bardziej skomplikowany przypadek: użytkownik nie powinien znać danych logowania, ale nadal potrzebuje dostępu do bazy danych. W takim przypadku użytkownik uruchamiający aplikację ma bezpośredni dostęp do bazy danych, co oznacza, że program musi wcześniej znać dane logowania. Rozwiązanie, o którym wspomniałem powyżej, nie jest odpowiednie w tym przypadku. Możesz przechowywać dane logowania do bazy danych w pliku preferencji, ale użytkownik będzie mógł odczytać ten plik, ponieważ będzie właścicielem. W rzeczywistości nie ma dobrego sposobu na bezpieczne korzystanie z tego przypadku.
Prawidłowy przypadek: użycie architektury wielowarstwowej
Prawidłowym sposobem na to jest utworzenie warstwy pośredniej między serwerem bazy danych a aplikacją kliencką, która uwierzytelnia poszczególnych użytkowników i umożliwia wykonanie ograniczonego zestawu operacji. Każdy użytkownik miałby własne poświadczenia logowania, ale nie do serwera bazy danych. Poświadczenia umożliwiałyby dostęp do warstwy środkowej (warstwy logiki biznesowej) i byłyby różne dla każdego użytkownika.
Każdy użytkownik miałby własną nazwę użytkownika i hasło, które można przechowywać lokalnie w pliku preferencji bez żadnego zagrożenia bezpieczeństwa. Nazywa się to architekturą trójwarstwową (warstwy to serwer bazy danych, serwer logiki biznesowej i aplikacja kliencka). Jest to bardziej złożone, ale naprawdę jest to najbezpieczniejszy sposób zrobienia tego rodzaju rzeczy.
Podstawowa kolejność operacji to:
- Klient jest uwierzytelniany za pomocą warstwy logiki biznesowej przy użyciu osobistej nazwy użytkownika / hasła użytkownika. Nazwa użytkownika i hasło są znane użytkownikowi i nie są w żaden sposób powiązane z danymi logowania do bazy danych.
- Jeśli uwierzytelnianie powiedzie się, klient wysyła żądanie do warstwy logiki biznesowej z prośbą o podanie pewnych informacji z bazy danych. Na przykład spis produktów. Zwróć uwagę, że żądanie klienta nie jest zapytaniem SQL; jest to zdalne wywołanie procedury, takiej jak
getInventoryList.
- Warstwa logiki biznesowej łączy się z bazą danych i pobiera żądane informacje. Warstwa logiki biznesowej odpowiada za tworzenie bezpiecznego zapytania SQL na podstawie żądania użytkownika. Wszelkie parametry zapytania SQL powinny zostać oczyszczone, aby zapobiec atakom polegającym na iniekcji SQL.
- Warstwa logiki biznesowej wysyła listę zapasów z powrotem do aplikacji klienckiej.
- Klient wyświetla listę inwentarza użytkownikowi.
Zauważ, że w całym procesie aplikacja kliencka nigdy nie łączy się bezpośrednio z bazą danych . Warstwa logiki biznesowej otrzymuje żądanie od uwierzytelnionego użytkownika, przetwarza żądanie klienta dotyczące listy zapasów, a dopiero potem wykonuje zapytanie SQL.