Dependency 관리를 지원하는 Java 개발 환경에는 다음과 같은 몇 가지 도구가 있습니다. Apache Ant 및 Apache Maven build system에는 종속성을 관리하는 데 도움을 주도록 특별히 설계된 기능이 포함되어 있으며, Apache Ivy는 dependency 관리자로서 개발되었습니다. 이러한 도구들은 동작에는 차이점이 있지만 빌드 시 빌드 프로세스에 지정된 외부의 종속성을 자동으로 다운로드하는 일반적인 기능은 공통적으로 가지고 있습니다. 따라서 개발자 B가 개발자 A와 동일한 방법으로 소프트웨어를 쉽게 빌드할 수 있습니다. 개발자들은 dependency 정보를 빌드 파일에 저장합니다. 즉, 각 개발자 및 빌드 엔지니어가 수동 dependency 관리 시 일어나는 dependency 관리 문제 없이 종속성을 얻고 코드를 컴파일하고 배치하는 일관된 방법을 가진다는 것을 의미합니다. 다음 예제는 Ivy, Ant 및 Maven이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

Ivy의 경우, 개발자는 종속성을 검색할 명시적인 URL을 나열하는 대신 dependency 이름과 버전을 지정하고 Ivy는 자체의 기본적인 구성에 의존하여 종속성을 검색하는 서버를 식별합니다. 따라서 일반적으로 사용되는 구성 요소의 경우에는 개발자가 dependency 위치를 확인하지 않아도 됩니다.

예제 1: Ivy ivy.xml 파일에서 발췌한 다음 내용은 개발자가 이름과 버전을 사용하여 여러 외부 종속성을 지정하는 방법을 보여 줍니다.

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 dependency를 호스팅하는 서버를 손상시키거나, dependency를 호스팅하는 서버의 호스트 이름에 대한 요청을 공격자에 의해 제어되는 시스템으로 리디렉션하도록 build system이사용하는 DNS 서버를 손상시킬 수 있습니다. 두 경우 모두, 공격자는 악의적인 버전의 dependency를 손상되지 않은 시스템에서 실행 중인 빌드에 삽입할 수 있는 능력을 얻게 됩니다.

Trojan dependency를 전달하는 데 사용되는 공격에 관계없이 이러한 경우에는 build system에서 악성 바이너리를 무조건 받고 빌드에 포함시킨다는 점이 공통 사항입니다. Build system은 일반적으로 외부 종속성이 아닌 내부적으로 개발된 코드에 초점을 맞춘 코드 검사 등의 악성 바이너리 및 기존 보안 메커니즘을 거부할 방법이 없으므로 이런 유형의 공격은 개발 환경 및 제품에 잠재적으로 퍼져 있는 것처럼 눈에 띄지 않게 진행될 가능성이 큽니다.

수동 빌드 프로세스에 손상된 dependency가 발생할 위험이 일부 있지만, 매번 외부 소스에서 dependency를 검색하는 자동화된 build system의 경향으로 인해 build system은 공격자에게 기회의 창이 증가된 새로운 환경에서 실행됩니다. 공격자가 빌드를 실행 중인 시스템을 손상시키는 데에는 dependency를 검색하는 여러 번 중 한 번만 dependency 서버 또는 DNS 서버만 손상시키기만 하면 됩니다.

Dependency 관리를 지원하는 Java 개발 환경에는 다음과 같은 몇 가지 도구가 있습니다. Apache Ant 및 Apache Maven build system에는 종속성을 관리하는 데 도움을 주도록 특별히 설계된 기능이 포함되어 있으며, Apache Ivy는 dependency 관리자로서 개발되었습니다. 이러한 도구들은 동작에는 차이점이 있지만 빌드 시 빌드 프로세스에 지정된 외부의 종속성을 자동으로 다운로드하는 일반적인 기능은 공통적으로 가지고 있습니다. 따라서 개발자 B가 개발자 A와 동일한 방법으로 소프트웨어를 쉽게 빌드할 수 있습니다. 개발자들은 dependency 정보를 빌드 파일에 저장합니다. 즉, 각 개발자 및 빌드 엔지니어가 수동 dependency 관리 시 일어나는 dependency 관리 문제 없이 종속성을 얻고 코드를 컴파일하고 배치하는 일관된 방법을 가진다는 것을 의미합니다. 다음 예제는 Ivy, Ant 및 Maven이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

Maven의 경우, 개발자는 종속성을 검색할 명시적인 URL을 나열하는 대신 dependency 이름과 버전을 지정하고 Maven은 자체의 기본적인 구성에 의존하여 종속성을 검색하는 서버를 식별합니다. 따라서 일반적으로 사용되는 구성 요소의 경우에는 개발자가 dependency 위치를 확인하지 않아도 됩니다.

예제 1: Maven pom.xml 파일에서 발췌한 다음 내용은 개발자가 이름과 버전을 사용하여 여러 외부 종속성을 지정하는 방법을 보여줍니다.

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 dependency를 호스팅하는 서버를 손상시키거나, dependency를 호스팅하는 서버의 호스트 이름에 대한 요청을 공격자에 의해 제어되는 시스템으로 리디렉션하도록 build system이사용하는 DNS 서버를 손상시킬 수 있습니다. 두 경우 모두, 공격자는 악의적인 버전의 dependency를 손상되지 않은 시스템에서 실행 중인 빌드에 삽입할 수 있는 능력을 얻게 됩니다.

Trojan dependency를 전달하는 데 사용되는 공격에 관계없이 이러한 경우에는 build system에서 악성 바이너리를 무조건 받고 빌드에 포함시킨다는 점이 공통 사항입니다. Build system은 일반적으로 외부 종속성이 아닌 내부적으로 개발된 코드에 초점을 맞춘 코드 검사 등의 악성 바이너리 및 기존 보안 메커니즘을 거부할 방법이 없으므로 이런 유형의 공격은 개발 환경 및 제품에 잠재적으로 퍼져 있는 것처럼 눈에 띄지 않게 진행될 가능성이 큽니다.

수동 빌드 프로세스에 손상된 dependency가 발생할 위험이 일부 있지만, 매번 외부 소스에서 dependency를 검색하는 자동화된 build system의 경향으로 인해 build system은 공격자에게 기회의 창이 크게 증가된 새로운 환경에서 실행됩니다. 공격자가 빌드를 실행 중인 시스템을 손상시키는 데에는 dependency를 검색하는 여러 번 중 한 번만 dependency 서버 또는 DNS 서버만 손상시키기만 하면 됩니다.

castor가 개체에 대한 잠금을 만든다 해도 개체를 읽거나 개체에 쓰지 못하도록 다른 스레드를 보호하지 못합니다. 또한 읽기 전용 쿼리는 기본 공유 모드와 비교하여 약 7배 더 빠릅니다.

예제 1: 다음 예는 쿼리 모드를 읽기 및 쓰기 접근 모두를 허용하는 SHARED로 지정합니다.

results = query.execute(Database.SHARED);

기본적으로 Castor는 공유 모드에서 쿼리를 실행합니다. 공유 모드에서는 읽기 및 쓰기 접근이 모두 가능하기 때문에 쿼리가 의도한 작업의 종류가 무엇인지 불분명합니다. 개체가 읽기 전용 컨텍스트에 사용될 경우, 공유된 접근은 불필요한 성능 오버헤드를 추가합니다.

예제 1: 다음 예는 쿼리 모드를 지정하지 않습니다.

results = query.execute();    //missing query mode

ClassLoader Manipulation을 통해 공격자는 기본 응용 프로그램 서버 설정에 액세스하고 이를 수정할 수 있습니다. Tomcat 8과 같은 특정 응용 프로그램 서버에서 공격자는 이러한 설정을 조정하여 웹 셸을 업로드하고 임의의 명령을 실행할 수 있습니다.

바이트 배열의 데이터를 String으로 변환할 때 해당되는 문자 집합 외부의 데이터가 어떻게 변환되는지는 지정되지 않습니다. 따라서 데이터가 손실되거나, 적절한 보안 대책을 따르기 위해 이진 데이터가 필요할 때 보안 수준이 낮아질 수 있습니다.

예제 1: 다음 코드는 해시를 만들기 위해 데이터를 String으로 변환합니다.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

파일 크기가 BUFSIZE보다 작다고 가정할 때 myFile의 정보를 기본 문자 집합과 같이 인코딩하면 이 코드는 문제 없이 작동합니다. 그러나 이 파일이 다른 인코딩을 사용하거나 이진 파일인 경우에는 정보가 손실됩니다. 그러면 결과로 생성되는 SHA 해시의 안정성이 떨어질 수 있으며, 충돌이 발생하기가 훨씬 쉬워집니다. 특히 기본 문자 집합 외부의 모든 데이터가 물음표 등의 같은 값으로 표현되는 경우에는 더욱 그러합니다.

notify()에 대한 호출로 활성화될 스레드를 지정할 방법은 없습니다.

예제 1: 다음 코드에서, notifyJob()은 notify()을 호출합니다.

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

이 경우 개발자는 wait()를 호출하는 스레드를 활성화시킬 생각이겠지만 notify()는 의도한 것과는 다른 스레드를 통지할 수 있습니다.