Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor detecte la modificación. Sin una firma, un receptor no puede verificar criptográficamente el origen del contenido del mensaje.

La siguiente configuración del cliente indica a Axis 2 que envíe solicitudes sin firmar:

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

Una marca de tiempo de seguridad indica la actualidad de los datos de seguridad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante podría interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración de Apache Axis 2 Rampart omite la directiva Timestamp de la etiqueta <items>, por lo que el cliente no envía solicitudes con marcas de tiempo.

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

WS-Security es una extensión de SOAP que proporciona integridad y confidencialidad de los mensajes de un extremo a otro, independientemente del protocolo de transporte. Cuando no se utiliza WS-Security, la integridad y confidencialidad de los mensajes dependen de la seguridad del transporte. Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. WS-Security elimina la dependencia de la seguridad del transporte y crea seguridad en el propio mensaje.

La ausencia de un parámetro OutflowSecurity en el archivo de configuración de Apache Axis 2 indica que la seguridad de los mensajes entrantes no está habilitada.

Usar un tipo de contraseña de PasswordText podría ser una indicación de que las contraseñas reales se transmiten en texto sin formato. El perfil de UsernameToken de WS-Security indica que el texto enviado en la etiqueta <Password> de UsernameToken no se limita a contraseñas reales, sino que puede contener derivadas de contraseñas. Sin embargo, es común que los desarrolladores envíen contraseñas reales en lugar de derivadas de contraseñas. El envío de contraseñas no cifradas o incluso hash de contraseñas expone las credenciales a cualquiera que tenga un rastreador de tráfico.

Una marca de tiempo de seguridad indica la actualidad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración del cliente indica a Axis 2 que acepte marcas de tiempo sin firmar:

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

Una marca de tiempo de seguridad indica la actualidad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración del cliente indica a Axis 2 que envíe marcas de tiempo sin firmar:

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

El envío de contraseñas de texto sin formato a través de un canal no cifrado puede exponer la credencial a los atacantes que pueden examinar el mensaje SOAP.

Ejemplo 1: La siguiente configuración del cliente Axis 2 utiliza un UsernameToken (una contraseña):

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

El módulo Rampart WS-Security no está habilitado. WS-Security es una extensión de SOAP que proporciona integridad y confidencialidad de los mensajes de un extremo a otro, independientemente del protocolo de transporte. Cuando no se utiliza WS-Security, la integridad y confidencialidad de los mensajes dependen de la seguridad del transporte. Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. WS-Security elimina la dependencia de la seguridad del transporte y crea seguridad en el propio mensaje.

Cuando axis.development.system se establece en true en el archivo de configuración del servidor, el sistema se comporta como si fuera un entorno de desarrollo. Envía seguimientos de pila en respuestas SOAP que pueden filtrar información sobre el sistema o la aplicación.

Cuando axis.disableServiceList se establece en false, Apache Axis devolverá una lista de servicios disponibles cuando se realice una operación GET en una raíz de servlet. La lista de servicios puede contener una lista de características que muestran que no son de acceso público.

Usar un tipo de contraseña de PasswordText podría ser una indicación de que las contraseñas reales se transmiten en texto sin formato. El perfil de UsernameToken de WS-Security indica que el texto enviado en la etiqueta<Password> de UsernameToken no se limita a ser contraseñas reales. Pueden ser derivados de contraseña. Sin embargo, es común que los desarrolladores envíen contraseñas reales en lugar de derivadas de contraseñas. El envío de contraseñas no cifradas o incluso hash de contraseñas expone las credenciales a cualquiera que tenga un rastreador de tráfico.

Los proveedores de servicios que utilizan UsernameToken pueden aceptar contraseñas enviadas en texto sin formato. El envío de contraseñas de texto sin formato a través de un canal no cifrado puede exponer la credencial a los atacantes que pueden examinar el mensaje SOAP.

Ejemplo 1: La siguiente configuración del proveedor de servicio Axis utiliza el UsernameToken:

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

Usar un tipo de contraseña de PasswordText podría ser una indicación de que las contraseñas reales se transmiten en texto sin formato. El perfil de UsernameToken de WS-Security indica que el texto enviado en la etiqueta<Password> de UsernameToken no se limita a ser contraseñas reales. Pueden ser derivados de contraseña. Sin embargo, es común que los desarrolladores envíen contraseñas reales en lugar de derivadas de contraseñas. El envío de contraseñas no cifradas o incluso hash de contraseñas expone las credenciales a cualquiera que tenga un rastreador de tráfico.

El envío de contraseñas de texto sin formato o hash de contraseñas a través de un canal no cifrado puede exponer la credencial a los atacantes que puedan examinar el mensaje SOAP.

Ejemplo 1: La siguiente configuración del cliente Axis utiliza el UsernameToken:

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

Los nombres y los valores de las propiedades bean tienen que validarse antes de rellenar cualquier bean. Las funciones de relleno bean permiten a los desarrolladores establecer una propiedad bean o una propiedad anidada. Un atacante puede aprovechar esta funcionalidad para acceder a propiedades bean especiales, como class.classLoader, que le permitirá sobrescribir propiedades del sistema y ejecutar potencialmente código arbitrario.

Ejemplo: el código siguiente establece una propiedad bean controlada por el usuario sin validación adecuada del nombre o valor de la propiedad:

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

El sistema de administración de dependencias automatizado Apache Ivy permite a los usuarios especificar un estado de versión, conocido como revisión dinámica, para una dependencia en lugar de enumerar la específica. Si un atacante puede comprometer el repositorio de dependencias o engañar al sistema de compilación para que descargue dependencias de un repositorio bajo su control, entonces un especificador de revisión dinámica puede ser todo lo que haga falta para que el sistema de compilación descargue y ejecute silenciosamente la dependencia comprometida. Aparte de los riesgos de seguridad, las revisiones dinámicas también introducen un elemento de riesgo en el frente de la calidad del código: Las revisiones dinámicas colocan la seguridad y la estabilidad de su software bajo el control de terceros que desarrollan y liberan las dependencias que utiliza su software.

En el momento de la compilación, Ivy se conecta al repositorio e intenta recuperar una dependencia que coincida con el estado indicado.

Ivy acepta los siguientes especificadores de revisión dinámica:

- latest.integration: selecciona la última revisión del módulo de dependencias.
- latest.[any status]: selecciona la última revisión del módulo de dependencias con al menos el estado especificado. Por ejemplo, latest.milestone seleccionará la última versión que sea un hito o un lanzamiento, y latest.release solo seleccionará el último lanzamiento.
- Cualquier revisión que termine en +: selecciona la última subrevisión del módulo de dependencias. Por ejemplo, si la dependencia existe en las revisiones 1.0.3, 1.0.7 y 1.1.2, una revisión especificada como 1.0.+ seleccionará la revisión 1.0.7.
- Intervalos de versiones: la notación matemática para intervalos, como <y>, se puede utilizar para hacer coincidir un intervalo de versiones.

Ejemplo 1: La siguiente entrada de configuración indica a Ivy que recupere la última versión de lanzamiento del componente clover:

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

Si el repositorio está comprometido, un atacante podría simplemente cargar una versión que cumpla con los criterios dinámicos para hacer que Ivy descargue una versión malintencionada de la dependencia.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

Los desarrolladores especifican las dependencias externas en un destino de Ant mediante una tarea <get>, que recupera la dependencia especificada por la dirección URL correspondiente. Este enfoque es funcionalmente equivalente al escenario en el que un desarrollador documenta cada dependencia externa como un artefacto incluido en el proyecto de software, pero es más deseable porque automatiza la recuperación e incorporación de las dependencias cuando se realiza una compilación.

Ejemplo: El siguiente extracto de un archivo de configuración build.xml de Ant muestra una referencia típica a una dependencia externa:

<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"/>

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Ivy, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias, e Ivy se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo ivy.xml de Ivy muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

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

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Existen varias herramientas dentro del mundo del desarrollo de Java que facilitan la administración de dependencias: tanto Apache Ant como Apache Maven son sistemas de compilación que incluyen funcionalidad específicamente diseñada para facilitar la administración de dependencias, y Apache Ivy está diseñado expresamente como administrador de dependencias. Aunque existen diferencias en su comportamiento, estas herramientas comparten la funcionalidad común de descargar de forma automática dependencias externas especificadas en el proceso de compilación en tiempo de compilación. Así, resulta mucho más sencillo para un desarrollador B compilar software de la misma forma que un desarrollador A. Los desarrolladores simplemente almacenan información de dependencias en el archivo de compilación, lo que significa que cada desarrollador e ingeniero de compilación tiene una forma consistente de obtener dependencias, compilar el código y llevar a cabo la implementación sin las complicaciones de la administración de dependencias que supone la administración manual. En los siguientes ejemplos, se ilustra cómo Ivy, Ant y Maven se pueden utilizar para administrar dependencias externas como parte de un proceso de compilación.

En Maven, en lugar de enumerar las direcciones URL explícitas de las que recuperar las dependencias, los desarrolladores especifican los nombres y las versiones de las dependencias y Maven se basa en su configuración subyacente para identificar los servidores de los que recuperar las dependencias. Para los componentes de uso común, esta medida evita que el desarrollador tenga que investigar las ubicaciones de las dependencias.

Ejemplo 1: El siguiente extracto de un archivo pom.xml de Maven muestra cómo un desarrollador puede especificar múltiples dependencias externas usando su nombre y versión:

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

Dos tipos distintos de escenarios de ataque afectan a estos sistemas: Un atacante podría comprometer el servidor que hospeda la dependencia o el servidor DNS que utiliza la máquina de compilación para redirigir las solicitudes de nombre de host del servidor que hospeda la dependencia a una máquina controlada por el atacante. Ambos escenarios dan lugar a que el atacante consiga inyectar una versión malintencionada de una dependencia en una compilación que se ejecuta en una máquina no comprometida.

Independientemente del vector de ataque utilizado para entregar la dependencia de troyano, estos escenarios comparten el elemento común de que el sistema de compilación acepta ciegamente el archivo binario malintencionado y lo incluye en la compilación. Dado que el sistema de compilación no tiene ningún recurso para rechazar el binario malintencionado y que los mecanismos de seguridad existentes, como la revisión del código, suelen centrarse en el código desarrollado internamente y no en las dependencias externas, este tipo de ataque tiene un gran potencial para pasar desapercibido a medida que se extiende por el entorno de desarrollo y, potencialmente, a producción.

Aunque existe cierto riesgo de que se introduzca una dependencia comprometida en un proceso de compilación manual, la tendencia de los sistemas de compilación automatizados a recuperar la dependencia de un origen externo cada vez que el sistema de compilación se ejecuta en un nuevo entorno aumenta enormemente la ventana de oportunidad para un atacante. Un atacante solo necesita comprometer el servidor de dependencias o el servidor DNS durante una de las muchas veces que se recupera la dependencia para comprometer la máquina en la que se está produciendo la compilación.

Incluso aunque Castor cree un bloqueo en un objeto, eso no impide que otros subprocesos lean o escriban en él. Las consultas de solo lectura son también unas siete veces más rápidas en comparación con el modo compartido predeterminado.

Ejemplo 1: el ejemplo siguiente especifica el modo de consulta como SHARED, que permite tener acceso de lectura y escritura.

results = query.execute(Database.SHARED);