10 Java 보안 모범 사례

이 메모장 버전에서 우리는 소스 관리자와 개발자를 대상으로 하는 10가지 자바 안전 최적 실천을 중점적으로 소개할 것이다.대부분의 개발자들이 보안 인코딩이 중요하다는 것을 알고 있지만 안전성은 개발자들이 고려하는 첫 번째 일이 아니다.OWASP Top 10 vulnerabilities을 초기 기점으로 하여 10위권을 만들었습니다.이 메모에서 저는 Java Champion과 Manicode Security의 창시자인 Jim Manico와 합작했습니다.
그러므로 더 이상 설명할 필요가 없다. 나는 자랑스럽게 10 Java security best practices을 전시했다

1. 검색 매개 변수화를 사용하여 주입 방지

2017년 버전의 OWASP 10대 빈틈 중 주입은 그 해의 첫 번째 빈틈이 되었다.자바에서 전형적인 SQL 주입을 볼 때, sequel 조회의 매개 변수는 천진난만하게 조회의 정적 부분에 연결된다.다음은 Java에서 SQL이 안전하게 실행되지 않는 것입니다. 공격자는 이를 사용하여 더 많은 정보를 얻을 수 있습니다.

public void selectExample(String parameter) throws SQLException {
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);
   String query = "SELECT * FROM USERS WHERE lastname = " + parameter;
   Statement statement = connection.createStatement();
   ResultSet result = statement.executeQuery(query);

   printResult(result);
}

이 예제의 매개 변수가 '' OR 1=1과 유사하면 결과는 표의 모든 항목을 포함합니다.데이터베이스가 여러 개의 조회를 지원하고 파라미터가 ''; UPDATE USERS SET lastname=''이면 문제가 더욱 심각해질 수 있습니다.
Java에서 이러한 상황을 방지하기 위해서 우리는 사전 처리 문장을 사용하여 매개 변수화된 조회를 해야 한다.이것은 데이터베이스 조회를 만드는 유일한 방법일 것이다.전체 SQL 코드를 정의하고 나중에 질의에 매개 변수를 전달하면 코드를 쉽게 이해할 수 있습니다.가장 중요한 것은 SQL 코드와 파라미터 데이터를 구분함으로써 조회가 악성 입력에 납치되지 않는다는 것이다.

public void prepStatmentExample(String parameter) throws SQLException {
   Connection connection = DriverManager.getConnection(DB_URL, USER, PASS);
   String query = "SELECT * FROM USERS WHERE lastname = ?";
   PreparedStatement statement = connection.prepareStatement(query);
   statement.setString(1, parameter);
   System.out.println(statement);
   ResultSet result = statement.executeQuery();

   printResult(result);
}

위의 예시에서 입력은 형식 문자열에 연결되어 있기 때문에 조회 코드의 일부분이다.이러한 기술은 매개 변수의 입력이 SQL 코드를 방해하는 것을 방지할 수 있다.

2, OpenID를 사용하여 2FA 연결

신분 관리와 액세스 제어가 매우 어렵고 신분 검증이 중단되는 것이 데이터 유출의 원인이다.사실 이것은 OWASP 10대 빈틈 목록의 #2입니다.인증서를 작성할 때 암호의 안전한 저장, 강력한 암호화, 자격 증명 검색 등 여러 가지 고려 사항이 있습니다. 많은 경우 OpenID Connect와 같은 흥미로운 해결 방안을 사용하면 더욱 쉽고 안전합니다.OpenID Connect(OIDC)를 사용하면 웹 사이트 및 애플리케이션에서 사용자를 인증할 수 있습니다.이렇게 하면 암호 파일을 가지고 관리할 필요가 없다.OpenID Connect는 사용자 정보를 제공하는 OAuth 2.0 확장입니다.액세스 영패 외에 ID 영패와 /userinfo 노드가 추가되어 더 많은 정보를 얻을 수 있습니다.또한 엔드포인트 검색 기능과 동적 클라이언트 등록도 추가되었습니다.
Spring Security와 같은 라이브러리를 사용하여 OpenID Connect를 설정하는 것은 간단하면서도 일반적인 작업입니다.애플리케이션이 2FA(이중 요소 인증) 또는 MFA(다중 요소 인증)를 강제하여 시스템에 추가 보안 레이어를 추가해야 합니다.
Spring 부트 응용 프로그램에 oauth2 클라이언트와 Spring 보안 의존 항목을 추가하면 Google, Github, Okta와 같은 타사 클라이언트를 이용하여 OIDC를 처리할 수 있습니다.응용 프로그램을 만든 후, 응용 프로그램 설정에서 지정하는 방법으로 선택한 특정 클라이언트에 연결하기만 하면 됩니다.이것은 GitHub 또는 Okta 클라이언트 id와 클라이언트 기밀일 수 있습니다. 아래와 같습니다.
pom.xml

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
</dependency>

활용단어참조아마르

spring:
 security:
   oauth2:
     client:
         registration:
           github:
             client-id: 796b0e5403be4729ca01
             client-secret: f379318daa27502254a05e054361074180b840a9
           okta:
             client-id: 0oa1a4wascEpYu6yk358
             client-secret: hqxj7a9lVe_TudbS2boBW7AWwxTlZiHNrJxdc_Sk
             client-name: Okta
         provider:
           okta:
             issuer-uri: https://dev-844689.okta.com/oauth2/default

3. 알려진 빈틈을 찾기 위해 의존항을 스캔

응용 프로그램이 몇 개의 직접 의존 항목을 사용했는지 모를 수도 있습니다.응용 프로그램이 얼마나 많은 전달 의존 항목을 사용했는지 모를 수도 있습니다.의존성이 전체 응용 프로그램의 대부분을 차지하지만 이것은 통상적으로 옳다.공격자들은 악의적인 공격자에게 많은 피해자를 제공하기 때문에 개원 의존항을 겨냥하고 있다.응용 프로그램의 전체 의존 관계 트리에 알려진 빈틈이 없는지 확인하는 것이 중요하다.
Snyk 테스트 응용 프로그램 구축 부품은 이미 알고 있는 빈틈이 있는 의존 항목을 표시합니다.이것은 응용 프로그램에서 대시보드로 사용되는 패키지에 존재하는 빈틈 목록을 제공합니다.
또한 원본 코드 저장소에 대한 요청을 통해 보안 문제를 해결하는 버전을 업그레이드하거나 패치를 제공하는 것을 권장합니다.Snyk는 또한 향후 저장소에서 요청되는 모든 요청이 자동으로 테스트될 수 있도록 (Webhook을 통해) 환경을 보호함으로써 새로운 빈틈이 발생하지 않도록 합니다.
Snyk는 웹 UI와 CLI를 통해 사용할 수 있기 때문에 CI 환경과 통합하여 설정된 한도값을 초과하는 심각한 빈틈이 있을 때 구축을 중단할 수 있도록 설정할 수 있습니다.
Snyk for free을 개원 프로젝트나 매달 테스트 수량이 제한된 개인 프로젝트에 사용합니다.

4. 민감한 데이터 조심

고객의 개인 데이터나 신용카드 번호 같은 민감한 데이터를 노출하는 것은 유해할 수 있다.하지만 이보다 더 미묘한 상황이라도 해롭다.예를 들어 다른 호출에서 유일한 식별자를 사용하여 다른 데이터를 검색할 수 있다면 시스템에서 유일한 식별자의 노출은 유해하다.
우선, 응용 프로그램의 설계를 자세히 연구하고 데이터가 정말 필요한지 확인해야 합니다.이외에도 로그 기록, 자동 완성, 전송 등을 통해 민감한 데이터가 노출되지 않도록 하십시오.
민감한 데이터가 로그에 나타나는 것을 방지하는 간단한 방법은 영역 실체를 정리하는 toString() 방법이다.이렇게 하면 의외로 민감한 필드를 인쇄하지 않을 것이다.프로젝트 Lombok을 사용하여 toString() 방법을 생성하려면 @ToString.Exclude을 사용하여 필드가 toString()의 출력의 일부가 되는 것을 방지하십시오.
또 외부에 데이터를 공개할 때는 조심해야 한다.예를 들어 시스템에 모든 사용자 이름을 표시하는 끝이 있는 경우 내부 고유 식별자를 표시할 필요가 없습니다.이 유일한 식별자는 다른 단점을 사용하여 더 민감한 정보를 사용자에게 연결하는 데 사용할 수 있다.만약 잭슨을 사용하여 POJO를 JSON으로 서열화하고 반서열화하면 @JsonIgnore과 @JsonIgnoreProperties을 사용하여 이러한 속성이 서열화되거나 반서열화되는 것을 방지하십시오.
민감한 데이터를 다른 서비스로 전송하려면 적절한 암호화를 하고 연결이 HTTPS와 같은 보안을 유지하십시오.

5. 모든 입력 정리

다중 사이트 스크립트(XSS)는 JavaScript 응용 프로그램에 주로 사용되는 알려진 문제입니다.그러나 Java도 피할 수 없습니다.XSS는 원격으로 실행되는 JavaScript 코드의 주입에 불과합니다.OWASP에 따르면 XSS 방지 규칙 #0은 "허용된 위치에 있지 않으면 신뢰할 수 없는 데이터를 삽입하지 마십시오."입니다. 이 방면의 기본 해결 방안은 신뢰할 수 없는 데이터를 최대한 방지하고 데이터를 사용하기 전에 모든 다른 내용을 정리하는 것입니다.좋은 출발점은 OWASP Java 인코딩 라이브러리입니다. 많은 인코더를 제공합니다.

<dependency>
   <groupId>org.owasp.encoder</groupId>
   <artifactId>encoder</artifactId>
   <version>1.2.2</version>
</dependency>

String untrusted = "<script> alert(1); </script>";
System.out.println(Encode.forHtml(untrusted));

// output: <script> alert(1); </script>

사용자의 텍스트 입력을 정리하는 것은 뚜렷한 문제이다.그러나 자신의 데이터베이스라도 데이터베이스에서 검색한 데이터는 어떻습니까?만약 데이터베이스가 파괴된다면, 누군가가 데이터베이스 필드나 문서에 악성 텍스트를 심었다면, 어떻게 해야 합니까?
또한 전송된 파일을 주의하십시오.압축 파일의 경로를 정리하지 않았기 때문에, 많은 라이브러리에 Zip-slip 빈틈이 존재합니다.경로가 ../../../../foo.xy인 파일을 포함하는 Zip 파일을 추출하고 임의의 파일을 덮어쓸 수 있습니다.XSS 공격은 아니지만 모든 입력을 정리해야 하는 이유를 설명하는 좋은 예입니다.모든 입력은 악의적일 수 있으므로 상응하여 정리해야 한다.
이것은 단지 내 10위권 중의 5위권일 뿐이다.
다음 5시에 대해 더 알고 싶으세요?
Read more ...