Как мога да защитя MySQL потребителско име и парола от декомпилиране?

Никога не въвеждайте твърди пароли във вашия код. Това беше повдигнато наскоро в Топ 25 най-опасни програмни грешки :

Твърдо кодирането на таен акаунт и парола във вашия софтуер е изключително удобно - за квалифицирани инженери по обратния път. Ако паролата е една и съща в целия ви софтуер, тогава всеки клиент става уязвим, когато тази парола неизбежно стане известна. И тъй като е твърдо кодиран, е огромна болка за поправяне.

Трябва да съхранявате информация за конфигурацията, включително пароли, в отделен файл, който приложението чете при стартиране. Това е единственият реален начин да предотвратите изтичане на паролата в резултат на декомпилиране (никога не я компилирайте в двоичен файл като начало).

За повече информация относно тази често срещана грешка можете да прочетете статията за CWE-259 . Статията съдържа по-задълбочено определение, примери и много друга информация за проблема.

В Java един от най-лесните начини да направите това е да използвате класа Preferences. Той е проектиран да съхранява всички видове програмни настройки, някои от които могат да включват потребителско име и парола.

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
}

В горния код можете да извикате setCredentials метод, след като се покаже диалогов прозорец със запитване за потребителско име и парола. Когато трябва да се свържете с базата данни, можете просто да използвате getUsername и getPassword методи за извличане на съхранените стойности. Идентификационните данни за вход няма да бъдат твърдо кодирани във вашите двоични файлове, така че декомпилирането няма да представлява риск за сигурността.

Важна забележка: Файловете с предпочитания са просто текстови XML файлове. Уверете се, че сте предприели подходящи стъпки, за да предотвратите неоторизирани потребители да преглеждат необработените файлове (UNIX разрешения, Windows разрешения и т.н.). В Linux поне това не е проблем, защото извикването на Preferences.userNodeForPackage ще създаде XML файла в домашната директория на текущия потребител, който така или иначе не може да се чете от други потребители. В Windows ситуацията може да е различна.

Още важни бележки: Имаше много дискусии в коментарите на този отговор и други относно това каква е правилната архитектура за тази ситуация. Първоначалният въпрос всъщност не споменава контекста, в който се използва приложението, така че ще говоря за двете ситуации, за които се сещам. Първият е случаят, в който лицето, използващо програмата, вече знае (и е упълномощено да знае) идентификационните данни на базата данни. Вторият е случаят, в който вие, разработчикът, се опитвате да запазите идентификационните данни на базата данни в тайна от лицето, използващо програмата.

Първи случай:Потребителят е упълномощен да знае идентификационните данни за вход в базата данни

В този случай решението, което споменах по-горе, ще работи. Preference на Java class ще съхранява потребителското име и паролата в обикновен текст, но файлът с предпочитания ще бъде четим само от оторизирания потребител. Потребителят може просто да отвори XML файла с предпочитанията и да прочете идентификационните данни за вход, но това не е риск за сигурността, тъй като потребителят е знаел идентификационните данни отначало.

Втори случай:Опит да се скрият идентификационните данни за вход от потребителя

Това е по-сложният случай:потребителят не трябва да знае идентификационните данни за вход, но все пак има нужда от достъп до базата данни. В този случай потребителят, изпълняващ приложението, има директен достъп до базата данни, което означава, че програмата трябва да знае идентификационните данни за вход преди време. Решението, което споменах по-горе, не е подходящо за този случай. Можете да съхранявате идентификационните данни за вход в базата данни във файл с предпочитания, но потребителят ще може да прочете този файл, тъй като той ще бъде собственикът. Всъщност няма добър начин да използвате този калъф по сигурен начин.

Правилен случай:Използване на многостепенна архитектура

Правилният начин да го направите е да имате среден слой, между сървъра на базата данни и клиентското ви приложение, който удостоверява отделните потребители и позволява извършването на ограничен набор от операции. Всеки потребител ще има свои собствени идентификационни данни за влизане, но не и за сървъра на базата данни. Идентификационните данни ще позволят достъп до средния слой (нивото на бизнес логиката) и биха били различни за всеки потребител.

Всеки потребител ще има собствено потребителско име и парола, които могат да се съхраняват локално във файл с предпочитания без никакъв риск за сигурността. Това се нарича тристепенна архитектура (нивата са вашият сървър на база данни, сървър на бизнес логика и клиентско приложение). Това е по-сложно, но наистина е най-сигурният начин за извършване на подобни неща.

Основният ред на операции е:

Клиентът се удостоверява с ниво на бизнес логика, като използва личното потребителско име/парола на потребителя. Потребителското име и паролата са известни на потребителя и не са свързани по никакъв начин с идентификационните данни за вход в базата данни.
Ако удостоверяването е успешно, клиентът отправя заявка към нивото на бизнес логиката, като иска информация от базата данни. Например инвентаризация на продукти. Имайте предвид, че заявката на клиента не е SQL заявка; това е отдалечено извикване на процедура като getInventoryList .
Нивото на бизнес логиката се свързва с базата данни и извлича исканата информация. Нивото на бизнес логиката отговаря за формиране на защитена SQL заявка въз основа на заявката на потребителя. Всички параметри на SQL заявката трябва да бъдат дезинфекцирани, за да се предотвратят атаки с инжектиране на SQL.
Нивото на бизнес логиката изпраща списъка с инвентара обратно на клиентското приложение.
Клиентът показва списъка с инвентара на потребителя.

Имайте предвид, че в целия процес клиентското приложение никога не се свързва директно с базата данни . Нивото на бизнес логиката получава заявка от удостоверен потребител, обработва заявката на клиента за инвентарен списък и едва след това изпълнява SQL заявка.