[java] 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에서는 상황이 다를 수 있습니다.

더 중요한 참고 사항 : 이 답변에 대한 의견과이 상황에 대한 올바른 아키텍처가 무엇인지에 대한 다른 의견에서 많은 논의가있었습니다. 원래 질문은 응용 프로그램이 사용되는 컨텍스트를 실제로 언급하지 않으므로 생각할 수있는 두 가지 상황에 대해 이야기하겠습니다. 첫 번째는 프로그램을 사용하는 사람이 이미 데이터베이스 자격 증명을 알고 있고 알 권한이있는 경우입니다. 두 번째는 개발자 인 귀하가 프로그램을 사용하는 사람으로부터 데이터베이스 자격 증명을 비밀로 유지하려는 경우입니다.

첫 번째 경우 : 사용자는 데이터베이스 로그인 자격 증명을 알 수있는 권한이 있습니다.

이 경우 위에서 언급 한 솔루션이 작동합니다. Java Preference클래스는 사용자 이름과 암호를 일반 텍스트로 저장하지만 기본 설정 파일은 인증 된 사용자 만 읽을 수 있습니다. 사용자는 기본 설정 XML 파일을 열고 로그인 자격 증명을 읽을 수 있지만 사용자가 시작할 자격 증명을 알고 있었기 때문에 보안 위험이 없습니다.

두 번째 사례 : 사용자에게 로그인 자격 증명을 숨기려고

이것은 더 복잡한 경우입니다. 사용자는 로그인 자격 증명을 몰라도 데이터베이스에 액세스해야합니다. 이 경우 응용 프로그램을 실행하는 사용자는 데이터베이스에 직접 액세스 할 수 있으므로 프로그램이 로그인 자격 증명을 미리 알아야합니다. 위에서 언급 한 솔루션은이 경우에 적합하지 않습니다. 데이터베이스 로그인 자격 증명을 기본 설정 파일에 저장할 수 있지만 사용자는 소유자가되므로 해당 파일을 읽을 수 있습니다. 사실,이 경우를 안전하게 사용하는 좋은 방법은 없습니다.

올바른 사례 : 다중 계층 아키텍처 사용

이를 수행하는 올바른 방법은 데이터베이스 서버와 클라이언트 애플리케이션 사이에 개별 사용자를 인증하고 제한된 작업 집합을 수행 할 수있는 중간 계층을 갖는 것입니다. 각 사용자는 자신의 로그인 자격 증명을 가지지 만 데이터베이스 서버에 대해서는 그렇지 않습니다. 자격 증명은 중간 계층 (비즈니스 논리 계층)에 대한 액세스를 허용하며 각 사용자마다 다릅니다.

모든 사용자는 보안 위험없이 기본 설정 파일에 로컬로 저장할 수있는 고유 한 사용자 이름과 암호를 갖게됩니다. 이를 3 계층 아키텍처 라고합니다 (계층은 데이터베이스 서버, 비즈니스 논리 서버 및 클라이언트 응용 프로그램 임). 더 복잡하지만 실제로 이런 종류의 작업을 수행하는 가장 안전한 방법입니다.

기본 작업 순서는 다음과 같습니다.

1. 클라이언트는 사용자의 개인 사용자 이름 / 암호를 사용하여 비즈니스 논리 계층으로 인증합니다. 사용자 이름과 암호는 사용자에게 알려져 있으며 어떤 방식 으로든 데이터베이스 로그인 자격 증명과 관련이 없습니다.
2. 인증이 성공하면 클라이언트는 데이터베이스에서 일부 정보를 요청하는 비즈니스 논리 계층에 요청을 보냅니다. 예를 들어, 제품 재고. 클라이언트의 요청은 SQL 쿼리가 아닙니다. .NET과 같은 원격 프로 시저 호출 getInventoryList입니다.
3. 비즈니스 논리 계층은 데이터베이스에 연결하고 요청 된 정보를 검색합니다. 비즈니스 로직 계층은 사용자의 요청에 따라 보안 SQL 쿼리를 구성하는 역할을합니다. SQL 인젝션 공격을 방지하려면 SQL 쿼리에 대한 모든 매개 변수를 삭제해야합니다.
4. 비즈니스 논리 계층은 인벤토리 목록을 클라이언트 응용 프로그램으로 다시 보냅니다.
5. 클라이언트는 사용자에게 인벤토리 목록을 표시합니다.

전체 프로세스 에서 클라이언트 애플리케이션은 데이터베이스에 직접 연결되지 않습니다 . 비즈니스 논리 계층은 인증 된 사용자로부터 요청을 수신하고 인벤토리 목록에 대한 클라이언트의 요청을 처리 한 다음 SQL 쿼리 만 실행합니다.