암호를 코드에 하드 코딩하지 마십시오. 이것은 최근 가장 위험한 프로그래밍 실수 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);
}
}
위의 코드 setCredentials에서 사용자 이름과 암호를 묻는 대화 상자를 표시 한 후 메서드를 호출 할 수 있습니다. 데이터베이스에 연결해야하는 경우 getUsername및 getPassword메서드를 사용 하여 저장된 값을 검색 할 수 있습니다 . 로그인 자격 증명은 바이너리에 하드 코딩되지 않으므로 디 컴파일로 인해 보안 위험이 발생하지 않습니다.
중요 참고 : 환경 설정 파일은 일반 텍스트 XML 파일입니다. 권한이없는 사용자가 원시 파일 (UNIX 권한, Windows 권한 등)을 보지 못하도록 적절한 조치를 취해야합니다. Linux에서는 적어도 이것은 문제가되지 않습니다.을 호출 Preferences.userNodeForPackage하면 현재 사용자의 홈 디렉토리에 XML 파일이 생성되므로 다른 사용자가 읽을 수 없습니다. Windows에서는 상황이 다를 수 있습니다.
더 중요한 참고 사항 : 이 답변에 대한 의견과이 상황에 대한 올바른 아키텍처가 무엇인지에 대한 다른 의견에서 많은 논의가있었습니다. 원래 질문은 응용 프로그램이 사용되는 컨텍스트를 실제로 언급하지 않으므로 생각할 수있는 두 가지 상황에 대해 이야기하겠습니다. 첫 번째는 프로그램을 사용하는 사람이 이미 데이터베이스 자격 증명을 알고 있고 알 권한이있는 경우입니다. 두 번째는 개발자 인 귀하가 프로그램을 사용하는 사람으로부터 데이터베이스 자격 증명을 비밀로 유지하려는 경우입니다.
첫 번째 경우 : 사용자는 데이터베이스 로그인 자격 증명을 알 수있는 권한이 있습니다.
이 경우 위에서 언급 한 솔루션이 작동합니다. Java Preference클래스는 사용자 이름과 암호를 일반 텍스트로 저장하지만 기본 설정 파일은 인증 된 사용자 만 읽을 수 있습니다. 사용자는 기본 설정 XML 파일을 열고 로그인 자격 증명을 읽을 수 있지만 사용자가 시작할 자격 증명을 알고 있었기 때문에 보안 위험이 없습니다.
두 번째 사례 : 사용자에게 로그인 자격 증명을 숨기려고
이것은 더 복잡한 경우입니다. 사용자는 로그인 자격 증명을 몰라도 데이터베이스에 액세스해야합니다. 이 경우 응용 프로그램을 실행하는 사용자는 데이터베이스에 직접 액세스 할 수 있으므로 프로그램이 로그인 자격 증명을 미리 알아야합니다. 위에서 언급 한 솔루션은이 경우에 적합하지 않습니다. 데이터베이스 로그인 자격 증명을 기본 설정 파일에 저장할 수 있지만 사용자는 소유자가되므로 해당 파일을 읽을 수 있습니다. 사실,이 경우를 안전하게 사용하는 좋은 방법은 없습니다.
올바른 사례 : 다중 계층 아키텍처 사용
이를 수행하는 올바른 방법은 데이터베이스 서버와 클라이언트 애플리케이션 사이에 개별 사용자를 인증하고 제한된 작업 집합을 수행 할 수있는 중간 계층을 갖는 것입니다. 각 사용자는 자신의 로그인 자격 증명을 가지지 만 데이터베이스 서버에 대해서는 그렇지 않습니다. 자격 증명은 중간 계층 (비즈니스 논리 계층)에 대한 액세스를 허용하며 각 사용자마다 다릅니다.
모든 사용자는 보안 위험없이 기본 설정 파일에 로컬로 저장할 수있는 고유 한 사용자 이름과 암호를 갖게됩니다. 이를 3 계층 아키텍처 라고합니다 (계층은 데이터베이스 서버, 비즈니스 논리 서버 및 클라이언트 응용 프로그램 임). 더 복잡하지만 실제로 이런 종류의 작업을 수행하는 가장 안전한 방법입니다.
기본 작업 순서는 다음과 같습니다.
- 클라이언트는 사용자의 개인 사용자 이름 / 암호를 사용하여 비즈니스 논리 계층으로 인증합니다. 사용자 이름과 암호는 사용자에게 알려져 있으며 어떤 방식 으로든 데이터베이스 로그인 자격 증명과 관련이 없습니다.
- 인증이 성공하면 클라이언트는 데이터베이스에서 일부 정보를 요청하는 비즈니스 논리 계층에 요청을 보냅니다. 예를 들어, 제품 재고. 클라이언트의 요청은 SQL 쿼리가 아닙니다. .NET과 같은 원격 프로 시저 호출
getInventoryList입니다.
- 비즈니스 논리 계층은 데이터베이스에 연결하고 요청 된 정보를 검색합니다. 비즈니스 로직 계층은 사용자의 요청에 따라 보안 SQL 쿼리를 구성하는 역할을합니다. SQL 인젝션 공격을 방지하려면 SQL 쿼리에 대한 모든 매개 변수를 삭제해야합니다.
- 비즈니스 논리 계층은 인벤토리 목록을 클라이언트 응용 프로그램으로 다시 보냅니다.
- 클라이언트는 사용자에게 인벤토리 목록을 표시합니다.
전체 프로세스 에서 클라이언트 애플리케이션은 데이터베이스에 직접 연결되지 않습니다 . 비즈니스 논리 계층은 인증 된 사용자로부터 요청을 수신하고 인벤토리 목록에 대한 클라이언트의 요청을 처리 한 다음 SQL 쿼리 만 실행합니다.