Jak mogę chronić nazwę Użytkownika i hasło MySQL przed dekompilacją?

Nigdy nie wprowadzaj haseł do kodu. To zostało poruszone niedawno w Top 25 najbardziej niebezpiecznych błędów programistycznych :

Hard-kodowanie tajnego konta i hasło do oprogramowania jest niezwykle wygodne - dla wykwalifikowanych inżynierowie wsteczni. Jeśli hasło jest to samo w całym oprogramowaniu, wtedy każdy klient staje się wrażliwy kiedy to hasło nieuchronnie staje się znane. I dlatego, że jest mocno zakodowany, to ogromny ból do napraw.

Informacje o konfiguracji, w tym hasła, należy przechowywać w osobnym pliku, który aplikacja odczytuje podczas uruchamiania. Jest to jedyny prawdziwy sposób, aby zapobiec wyciekowi hasła w wyniku dekompilacji (nigdy nie Kompiluj go do pliku binarnego).

Aby uzyskać więcej informacji na temat tego częstego błędu, możesz przeczytać CWE-259 Artykuł . Artykuł zawiera dokładniejszą definicję, przykłady i wiele innych informacji na temat problem.

W Javie jednym z najprostszych sposobów na to 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);
  }

  // your code here
}

W powyższym kodzie można wywołać metodę setCredentials Po wyświetleniu okna dialogowego z zapytaniem o nazwę użytkownika i hasło. Kiedy musisz połączyć się z bazą danych, możesz po prostu użyć metod getUsername i getPassword, Aby pobrać zapisane wartości. Dane logowania nie będą zakodowane na twardo w Twoich binariach, więc dekompilacja nie będzie stanowić zagrożenia bezpieczeństwa.

Ważna uwaga: pliki preferencji są zwykłymi plikami tekstowymi XML. Upewnij się, że podejmiesz odpowiednie kroki, aby uniemożliwić nieautoryzowanym użytkownikom przeglądanie plików raw(uprawnienia UNIX, uprawnienia Windows itp.). W Linuksie przynajmniej nie jest to problemem, ponieważ wywołanie Preferences.userNodeForPackage spowoduje utworzenie pliku XML w katalogu domowym bieżącego użytkownika, który i tak nie jest czytelny dla innych użytkowników. W Windows, sytuacja może być inna.

Ważniejsze uwagi: w komentarzach tej odpowiedzi i innych było wiele dyskusji na temat właściwej architektury dla tej sytuacji. Oryginalne pytanie tak naprawdę nie wspomina o kontekście, w którym aplikacja jest używana, więc będę mówić o dwóch sytuacjach, które mogę myśleć. Pierwszy to przypadek, w którym osoba korzystająca z programu zna już (i jest uprawniona do znajomości) bazę danych poświadczenia. Drugi to przypadek, w którym ty, deweloper, próbujesz utrzymać dane uwierzytelniające bazy danych w tajemnicy przed osobą używającą programu.

Pierwszy przypadek: użytkownik jest upoważniony do znajomości danych logowania do bazy danych

W tym przypadku rozwiązanie, o którym wspomniałem powyżej, zadziała. Klasa Java Preference będzie przechowywać nazwę użytkownika i hasło w postaci zwykłego tekstu, ale plik preferencji będzie czytelny tylko dla uprawnionego użytkownika. Użytkownik może po prostu otworzyć preferencje Plik XML i odczytać poświadczenia logowania, ale nie jest to zagrożenie bezpieczeństwa, ponieważ użytkownik znał poświadczenia na początku.

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 znać dane logowania przed czas. Rozwiązanie, o którym wspomniałem powyżej, nie jest odpowiednie dla tego przypadku. Możesz zapisać 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, naprawdę nie ma dobrego sposobu, aby użyć tej sprawy w bezpieczny sposób.

Poprawny przypadek: użycie architektury wielowarstwowej

Poprawnym sposobem jest posiadanie środkowej warstwy pomiędzy serwerem bazy danych a aplikacją kliencką, która uwierzytelnia indywidualnych użytkowników i pozwala na wykonanie ograniczonego zestawu operacji. Każdy użytkownik miałby własne dane logowania, ale nie dla serwera bazy danych. Poświadczenia umożliwił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 mogłyby być przechowywane lokalnie w pliku preferencji bez żadnego zagrożenia bezpieczeństwa. To się nazywa trójwarstwowa Architektura (poziomy są twoim serwer bazy danych, serwer logiki biznesowej i aplikacja kliencka). Jest to bardziej złożone, ale tak naprawdę jest to najbezpieczniejszy sposób na tego typu rzeczy.

Podstawowa kolejność operacji to:

1. Klient uwierzytelnia się za pomocą warstwy logiki biznesowej przy użyciu osobistej nazwy użytkownika/hasła. 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.
2. jeśli uwierzytelnienie się powiedzie, klient wysyła żądanie do warstwa logiki biznesowej Prośba o informacje z bazy danych. Na przykład spis produktów. Zwróć uwagę, że żądanie klienta nie jest zapytaniem SQL; jest to zdalne wywołanie procedury, takie 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 być dezynfekowane, aby zapobiec SQL injection ataki.
3. warstwa logiki biznesowej wysyła listę zapasów z powrotem do aplikacji klienckiej.
4. klient wyświetla listę zapasów 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 o listę zapasów, a dopiero potem wykonuje zapytanie SQL.