서명되지 않은 메시지의 모든 부분은 수신자가 수정을 눈치채지 못하는 사이에 가로채어 수정될 가능성이 있습니다. 서명이 없는 경우 수신자는 메시지 내용의 출처를 암호화 방식으로 확인할 수 없습니다.

다음 클라이언트 구성은 Axis 2에 서명되지 않은 요청을 보내도록 지시합니다.

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

보안 타임스탬프는 메시지 보안 데이터의 최근성을 나타냅니다. 공격자가 메시지를 가로채 나중에 다시 전송하는 경우 타임스탬프가 메시지가 오래되었음을 나타내므로 수신자가 재생 공격을 거부할 수 있습니다. 필요한 경우 타임스탬프에 보안 의미 체계의 유효 기간에 엄격한 제한을 두는 만료 속성을 포함할 수 있습니다.

공격자가 타임스탬프를 조작하는 것을 막으려면 타임스탬프를 서명해야 합니다. 서명된 타임스탬프가 없으면 공격자는 SOAP 메시지를 가로채서 타임스탬프를 수정하고 수신자가 모르는 사이에 메시지를 보낼 수 있습니다. 이러한 상황에서 공격자는 수신자를 속여 악의적인 메시지를 수락하도록 할 수 있습니다.

다음 Apache Axis 2 Rampart 구성은 <items> 태그에서 Timestamp 지시문을 생략하기 때문에 클라이언트가 요청을 타임스탬프와 함께 전송하지 않습니다.

<axisconfig name="AxisJava2.0">
...
   <parameter name="OutflowSecurity">
      <action>
        <items>Signature Encrypt</items>
...
</axisconfig>

WS-Security는 전송 프로토콜과 관계없이 엔드투엔드 메시지 무결성 및 기밀성을 제공하는 SOAP의 확장입니다. WS-Security가 사용되지 않는 경우 메시지의 무결성 및 기밀성은 전송 보안에 의존합니다. 서비스가 메시지를 다른 서비스로 릴레이하는 경우 메시지는 릴레이 지점 간에 사용되는 가장 약한 전송 메커니즘에 노출됩니다. WS-Security는 전송 보안 종속성을 없애고 메시지 자체에 보안을 구축합니다.

Apache Axis 2 구성 파일에 OutflowSecurity 매개 변수가 없으면 아웃바운드 메시지 보안이 활성화되지 않음을 나타냅니다.

PasswordText 암호 유형을 사용하면 실제 암호가 일반 텍스트로 전송되고 있음을 나타낼 수 있습니다. WS-Security UsernameToken 프로필에는 UsernameToken <Password> 태그로 전송된 텍스트가 실제 암호로 국한되지 않고 암호 파생물을 대신 포함할 수 있다고 나와 습니다. 그러나 개발자에게는 암호 파생물 대신 실제 암호를 보내는 것이 일반적입니다. 암호화되지 않은 암호 또는 암호 해시를 보내면 트래픽 스니퍼가 있는 모든 사람에게 자격 증명이 노출됩니다.

보안 타임스탬프는 메시지의 최근성을 나타냅니다. 공격자가 메시지를 가로채 나중에 다시 전송하는 경우 타임스탬프가 메시지가 오래되었음을 나타내므로 수신자가 재생 공격을 거부할 수 있습니다. 필요한 경우 타임스탬프에 보안 의미 체계의 유효 기간에 엄격한 제한을 두는 만료 속성을 포함할 수 있습니다.

공격자가 타임스탬프를 조작하는 것을 막으려면 타임스탬프를 서명해야 합니다. 서명된 타임스탬프가 없으면 공격자는 SOAP 메시지를 가로채서 타임스탬프를 수정하고 수신자가 모르는 사이에 메시지를 보낼 수 있습니다. 이러한 상황에서 공격자는 수신자를 속여서 악의적인 메시지를 수락하도록 할 수 있습니다.

다음 클라이언트 구성은 Axis 2에 서명되지 않은 타임스탬프를 수락하도록 지시합니다.

<axisconfig name="AxisJava2.0">
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

보안 타임스탬프는 메시지의 최근성을 나타냅니다. 공격자가 메시지를 가로채 나중에 다시 전송하는 경우 타임스탬프가 메시지가 오래되었음을 나타내므로 수신자가 재생 공격을 거부할 수 있습니다. 필요한 경우 타임스탬프에 보안 의미 체계의 유효 기간에 엄격한 제한을 두는 만료 속성을 포함할 수 있습니다.

공격자가 타임스탬프를 조작하는 것을 막으려면 타임스탬프를 서명해야 합니다. 서명된 타임스탬프가 없으면 공격자는 SOAP 메시지를 가로채서 타임스탬프를 수정하고 수신자가 모르는 사이에 메시지를 보낼 수 있습니다. 이러한 상황에서 공격자는 수신자를 속여서 악의적인 메시지를 수락하도록 할 수 있습니다.

다음 클라이언트 구성은 Axis 2에 서명되지 않은 타임스탬프를 보내도록 지시합니다.

<axisconfig name="AxisJava2.0">
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</axisconfig>

암호화되지 않은 채널을 통해 일반 텍스트 암호를 보내면 SOAP 메시지를 스니핑할 수 있는 공격자에게 자격 증명이 노출될 수 있습니다.

예제 1: 다음 Axis 2 클라이언트 구성은 UsernameToken(암호)을 사용합니다.

<axisconfig name="AxisJava2.0">
...
    <parameter name="OutflowSecurity">
      <action>
        <items>UsernameToken</items>
        <user>bob</user>
        <passwordCallbackClass>org.apache.rampart.samples.PWCBHandler</passwordCallbackClass>
        <passwordType>PasswordText</passwordType>
      </action>
    </parameter>
...
</axisconfig>

Rampart WS-Security 모듈이 활성화되어 있지 않습니다. WS-Security는 전송 프로토콜과 관계없이 엔드투엔드 메시지 무결성 및 기밀성을 제공하는 SOAP의 확장입니다. WS-Security가 사용되지 않는 경우 메시지의 무결성 및 기밀성은 전송 보안에 의존합니다. 서비스가 메시지를 다른 서비스로 릴레이하는 경우 메시지는 릴레이 지점 간에 사용되는 가장 약한 전송 메커니즘에 노출됩니다. WS-Security는 전송 보안 종속성을 제거하고 메시지 자체에 보안을 구축합니다.

서버 구성 파일에서 axis.development.system이 true로 설정되어 있으면 시스템이 개발 환경인 것처럼 동작합니다. SOAP 응답에서 시스템 또는 응용 프로그램에 대한 정보를 누출할 수 있는 스택 추적을 보냅니다.

axis.disableServiceList가 false로 설정되어 있으면 Apache Axis가 서블릿 루트에서 GET을 수행할 때 사용 가능한 서비스 목록을 반환합니다. 이 서비스 목록에는 공개적으로 액세스할 수 없는 것으로 표시되는 기능 목록이 포함될 수 있습니다.

PasswordText 암호 유형을 사용하면 실제 암호가 일반 텍스트로 전송되고 있음을 나타낼 수 있습니다. WS-Security UsernameToken 프로필에는 UsernameToken <Password> 태그로 전송된 텍스트가 실제 암호로 국한되지 않는다고 나와 습니다. 대신 암호 파생물이 여기에 포함될 수 있습니다. 그러나 개발자에게는 암호 파생물 대신 실제 암호를 보내는 것이 일반적입니다. 암호화되지 않은 암호 또는 암호 해시를 보내면 트래픽 스니퍼가 있는 모든 사람에게 자격 증명이 노출됩니다.

UsernameToken을 사용하는 서비스 공급자는 일반 텍스트로 보낸 암호를 수락할 수 있습니다. 암호화되지 않은 채널을 통해 일반 텍스트 암호를 보내면 SOAP 메시지를 스니핑할 수 있는 공격자에게 자격 증명이 노출될 수 있습니다.

예제 1: 다음 Axis 서비스 공급자 구성은 UsernameToken을 사용합니다.

<deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

PasswordText 암호 유형을 사용하면 실제 암호가 일반 텍스트로 전송되고 있음을 나타낼 수 있습니다. WS-Security UsernameToken 프로필에는 UsernameToken <Password> 태그로 전송된 텍스트가 실제 암호로 국한되지 않는다고 나와 습니다. 대신 암호 파생물이 여기에 포함될 수 있습니다. 그러나 개발자에게는 암호 파생물 대신 실제 암호를 보내는 것이 일반적입니다. 암호화되지 않은 암호 또는 암호 해시를 보내면 트래픽 스니퍼가 있는 모든 사람에게 자격 증명이 노출됩니다.

암호화되지 않은 채널을 통해 일반 텍스트 암호 또는 암호 해시를 보내면 SOAP 메시지를 스니핑할 수 있는 공격자에게 자격 증명이 노출될 수 있습니다.

예제 1: 다음 Axis 클라이언트 구성은 UsernameToken을 사용합니다.

<deployment xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
...
	<parameter name="action" value="UsernameToken"/>
...
</deployment>

Bean을 채우기 전에 Bean 속성 이름과 값을 확인해야 합니다. Bean 채우기 기능을 통해 개발자가 Bean 속성 또는 Nested 속성을 설정할 수 있습니다. 공격자는 이 기능을 활용하여 시스템 속성을 오버라이드하고 임의의 코드를 실행할 수 있는 특수 Bean 속성(예: class.classLoader)에 액세스할 수 있게 됩니다.

예제: 다음 코드는 속성 이름이나 값에 대한 적합한 확인 없이 사용자 제어 Bean 속성을 설정합니다.

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

Apache Ivy 자동 dependency 관리 시스템을 사용하면 dependency에 대해 특정 dependency를 나열하는 것 대신 동적 수정 버전이라고도 하는 버전 상태를 지정할 수 있습니다. 공격자가 dependency 리포지토리를 손상시키거나 build system을 속여 공격자의 제어 하에 리포지토리에서 dependency를 다운로드하도록 할 수 있는 경우, build system이 손상된 dependency를 자동으로 다운로드하고 실행하는 데에는 동적 수정 버전 지정자만 있으면 됩니다. 동적 수정 버전에는 보안 위험 외에도 code quality 면에서 다음과 같은 위험 요소도 있습니다. 동적 수정 버전은 소프트웨어에 사용되는 dependency를 개발하고 출시한 타사의 제어를 받아 소프트웨어의 보안성 및 안정성을 부여합니다.

빌드 시 Ivy는 리포지토리에 연결하고 나열된 상태와 일치하는 dependency를 검색하려고 합니다.

Ivy는 다음 동적 수정 버전 지정자를 받아 들입니다.

- latest.integration: dependency 모듈의 최신 수정 버전을 선택합니다.
- latest.[any status]: 최소한의 지정된 상태에서 dependency 모듈의 최신 수정 버전을 선택합니다. 예를 들어 latest.milestone은 중요 시점 또는 릴리스인 최신 버전을 선택하고 latest.release는 최신 릴리스만 선택합니다.
- +로 끝나는 모든 수정 버전: dependency 모듈의 최신 하위 수정 버전을 선택합니다. 예를 들어 수정 버전 1.0.3, 1.0.7 및 1.1.2에 dependency가 있는 경우 1.0.+로 지정된 수정 버전은 수정 버전 1.0.7을 선택합니다.
- 버전 범위: < 및 >와 같은 범위에 대한 수학적 표기법을 사용하여 버전 범위를 일치할 수 있습니다.

예제 1: 다음 구성 항목은 Ivy에 clover 구성 요소의 최신 릴리스 버전을 검색하도록 지시합니다.

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

리포지토리가 손상되면 공격자는 Ivy에 악의적인 버전의 dependency를 다운로드할 수 있는 동적 조건을 충족시키는 버전을 그대로 업로드할 수 있습니다.

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

개발자는 해당 URL에 의해 지정된 dependency를 검색하는 <get> 작업을 사용하여 Ant 대상의 외부 종속성을 지정합니다. 이 방법은 개발자가 각 외부 dependency를 소프트웨어 프로젝트에 포함된 아티팩트로 문서화하는 경우와 기능적으로는 동일하지만, 빌드가 수행되면 종속성의 검색 및 결합이 자동화되므로 더욱 바람직합니다.

예제: Ant build.xml 구성 파일에서 발췌한 다음 내용은 외부 dependency에 대한 일반적인 참조를 보여 줍니다.

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

두 가지 별개 유형의 공격 시나리오가 이들 시스템에 영향을 줍니다. 공격자는 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이 빌드 프로세스의 일부로 외부 종속성을 관리하는 데 사용되는 방법을 보여줍니다.

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);