A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte configuração de cliente do Apache Axis 2 Rampart não requer que mensagens de entrada sejam criptografadas, pois a tag <items> não contém uma diretiva Encrypt:

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem a modificação ser detectada pelo destinatário. Sem uma assinatura, um receptor não pode verificar criptograficamente a origem do conteúdo da mensagem.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar solicitações não assinadas:

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

Um carimbo de data/hora de segurança indica a atualização dos dados de segurança de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor pode interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor pode induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do Rampart do Apache Axis 2 omite a diretiva Timestamp da tag <items>, então o cliente não envia solicitações com carimbos de data/hora.

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

WS-Security é uma extensão do SOAP que fornece integridade e confidencialidade da mensagem de ponta a ponta, independentemente do protocolo de transporte. Quando o WS-Security não é usado, as mensagens contam com a segurança do transporte para integridade e confidencialidade. Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O WS-Security elimina a dependência de segurança de transporte e desenvolve a segurança na mensagem em si.

A ausência de um parâmetro OutflowSecurity no arquivo de configuração do Apache Axis 2 indica que a segurança da mensagem enviada não está ativada.

Usar um tipo de senha PasswordText pode ser uma indicação de que as senhas reais estão sendo transmitidas em texto simples. O perfil UsernameToken do WS-Security afirma que o texto enviado na tag UsernameToken <Password> não se limita a senhas reais, mas pode conter derivados de senha. No entanto, é comum que os desenvolvedores enviem senhas reais em vez de derivados de senha. O envio de senhas não criptografadas ou até mesmo hashes de senha expõe as credenciais a qualquer pessoa com um detector de tráfego.

Um carimbo de data/hora de segurança indica a atualização de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar carimbos de data/hora sem assinatura:

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

Um carimbo de data/hora de segurança indica a atualização de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar carimbos de data/hora sem assinatura:

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

O envio de senhas de texto simples por meio de um canal não criptografado pode expor a credencial a invasores que podem detectar a mensagem SOAP.

Exemplo 1: A seguinte configuração de cliente Axis 2 usa UsernameToken (uma senha):

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

O módulo Rampart WS-Security não está ativado. WS-Security é uma extensão do SOAP que fornece integridade e confidencialidade da mensagem de ponta a ponta, independentemente do protocolo de transporte. Quando o WS-Security não é usado, a mensagem conta com a segurança do transporte para integridade e confidencialidade. Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O WS-Security elimina a dependência de segurança do transporte e desenvolve a segurança na mensagem em si.

Quando axis.development.system estiver definido como true no arquivo de configuração do servidor, o sistema se comporta como se fosse um ambiente de desenvolvimento. Ele envia rastreamentos de pilha em respostas SOAP que podem vazar informações sobre o sistema ou aplicativo.

Quando axis.disableServiceList está configurado como false, o Apache Axis retornará uma lista de serviços disponíveis quando um GET for executado em uma raiz de servlet. A lista de serviços pode conter uma lista de recursos que mostram não serem acessíveis publicamente.

Usar um tipo de senha PasswordText pode ser uma indicação de que as senhas reais estão sendo transmitidas em texto simples. O perfil WS-Security UsernameToken afirma que o texto enviado na tag UsernameToken <Password> não se limita a ser senhas reais. Em vez disso, eles podem ser derivados de senha. No entanto, é comum que os desenvolvedores enviem senhas reais em vez de derivados de senha. O envio de senhas não criptografadas ou até mesmo hashes de senha expõe as credenciais a qualquer pessoa com um detector de tráfego.

Os provedores de serviços que usam o UsernameToken podem aceitar senhas enviadas em texto simples. O envio de senhas de texto simples por meio de um canal não criptografado pode expor a credencial a invasores que podem detectar a mensagem SOAP.

Exemplo 1: A seguinte configuração de provedor de serviços Axis usa o UsernameToken:

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

Usar um tipo de senha PasswordText pode ser uma indicação de que as senhas reais estão sendo transmitidas em texto simples. O perfil WS-Security UsernameToken afirma que o texto enviado na tag UsernameToken <Password> não se limita a ser senhas reais. Em vez disso, eles podem ser derivados de senha. No entanto, é comum que os desenvolvedores enviem senhas reais em vez de derivados de senha. O envio de senhas não criptografadas ou até mesmo hashes de senha expõe as credenciais a qualquer pessoa com um detector de tráfego.

Enviar senhas de texto simples ou hashes de senhas por meio de um canal não criptografado pode expor a credencial a invasores que podem detectar a mensagem SOAP.

Exemplo 1: A seguinte configuração de cliente Axis usa o UsernameToken:

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

Nomes e valores de propriedades de bean precisam ser validados antes do preenchimento de qualquer bean. Funções de preenchimento de beans permitem que os desenvolvedores definam uma propriedade de bean ou uma propriedade aninhada. Os invasores podem utilizar essa funcionalidade para acessar propriedades especiais de beans, como class.classLoader, o que permitirá que ele substitua as propriedades do sistema e potencialmente execute código arbitrário.

Exemplo 1: O código a seguir define uma propriedade de bean controlada pelo usuário sem a devida validação do nome da propriedade ou do valor:

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

O sistema de gerenciamento de dependência automatizado Apache Ivy permite que os usuários especifiquem um status de versão para uma dependência em vez de listar o específico, o que é conhecido como revisão dinâmica. Se um invasor for capaz de comprometer o repositório de dependências ou enganar o sistema de compilação para baixar as dependências de um repositório sob controle do invasor, um especificador de revisão dinâmica pode ser tudo o que é necessário para o sistema de compilação baixar e executar silenciosamente a dependência comprometida. Além dos riscos de segurança, as revisões dinâmicas também introduzem um elemento de risco na frente da qualidade do código: As revisões dinâmicas colocam a segurança e a estabilidade de seu software sob o controle de terceiros que desenvolvem e lançam as dependências que seu software usa.

No momento da compilação, o Ivy se conecta ao repositório e tenta recuperar uma dependência que corresponda ao status listado.

O Ivy aceita os seguintes especificadores de revisão dinâmica:

- latest.integration: Seleciona a revisão mais recente do módulo de dependência.
- latest.[any status]: Seleciona a revisão mais recente do módulo de dependência com o status especificado, no mínimo. Por exemplo, latest.milestone selecionará a versão mais recente que seja um marco ou um lançamento, e latest.release selecionará apenas a versão mais recente.
- Qualquer revisão que termine em +: Seleciona a última sub-revisão do módulo de dependência. Por exemplo, se a dependência existe nas revisões 1.0.3, 1.0.7 e 1.1.2, uma revisão especificada como 1.0.+ selecionará a revisão 1.0.7.
- Intervalos de versão: A notação matemática para intervalos, como < e >, pode ser usada para corresponder a um intervalo de versões.

Exemplo 1: A seguinte entrada de configuração instrui o Ivy a recuperar a versão de lançamento mais recente do componente clover:

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

se o repositório estiver comprometido, um invasor pode simplesmente fazer upload de uma versão que atenda aos critérios dinâmicos e fazer com que o Ivy baixe uma versão mal-intencionada da dependência.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

Os desenvolvedores especificam dependências externas em um destino Ant usando uma tarefa <get>, que recupera a dependência especificada pelo URL correspondente. Essa abordagem é funcionalmente equivalente ao cenário em que um desenvolvedor documenta cada dependência externa como um artefato incluído no projeto de software, mas é mais desejável porque automatiza a recuperação e incorporação das dependências quando um build é executado.

Exemplo 1: O seguinte trecho de um arquivo de configuração Ant build.xml mostra uma referência típica a uma dependência 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"/>

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de uma dependência comprometida ser introduzida em um processo de build manual, a tendência dos sistemas de build automatizados de recuperar a dependência de uma fonte externa cada vez que o sistema de compilação é executado em um novo ambiente aumenta muito a janela de oportunidade para um atacante. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

No Ivy, em vez de listar URLs explícitos dos quais recuperar as dependências, os desenvolvedores especificam os nomes e versões das dependências e o Ivy conta com sua configuração subjacente para identificar os servidores dos quais recuperar as dependências. Para componentes comumente usados, isso evita que o desenvolvedor tenha que pesquisar locais de dependência.

Exemplo 1: O trecho a seguir de um arquivo ivy.xml do Ivy mostra como um desenvolvedor pode especificar várias dependências externas usando seu nome e versão:

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

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de introduzir uma dependência comprometida em um processo de compilação manual, a tendência dos sistemas de compilação automatizados de recuperar a dependência de uma fonte externa sempre que o sistema de compilação for executado em um novo ambiente aumenta a janela de oportunidade para um invasor. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.

No universo de desenvolvimento Java, existem várias ferramentas para auxiliar no gerenciamento de dependências: os sistemas de compilação Apache Ant e Apache Maven incluem ambos uma funcionalidade projetada especificamente para ajudar a gerenciar dependências, enquanto o Apache Ivy foi desenvolvido explicitamente como um gerenciador de dependências. Embora existam diferenças em seus comportamentos, essas ferramentas compartilham a funcionalidade comum de baixar automaticamente as dependências externas especificadas no processo de compilação em tempo de compilação. Isso torna mais fácil para o desenvolvedor B construir softwares da mesma maneira que o desenvolvedor A. Os desenvolvedores apenas armazenam informações de dependências no arquivo de compilação, o que significa que cada desenvolvedor e engenheiro de compilação tem uma maneira consistente de obter dependências, compilar o código e implantá-lo sem os aborrecimentos envolvidos no gerenciamento de dependências manual. Os exemplos a seguir ilustram como o Ivy, o Ant e o Maven podem ser usados para gerenciar dependências externas como parte de um processo de compilação.

No Maven, em vez de listar URLs explícitos dos quais recuperar as dependências, os desenvolvedores especificam os nomes e versões das dependências e o Maven conta com sua configuração subjacente para identificar os servidores dos quais recuperar as dependências. Para componentes comumente usados, isso evita que o desenvolvedor tenha que pesquisar locais de dependência.

Exemplo 1: O trecho a seguir de um arquivo pom.xml do Maven mostra como um desenvolvedor pode especificar várias dependências externas usando seu nome e versão:

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

Dois tipos distintos de cenários de ataque afetam esses sistemas: Um invasor pode comprometer o servidor que hospeda a dependência ou comprometer o servidor DNS que a máquina de build usa para redirecionar as solicitações de nome de host do servidor que hospeda a dependência para uma máquina controlada pelo invasor. Ambos os cenários resultam no invasor conquistando a capacidade de injetar uma versão mal-intencionada de uma dependência em um build em execução em uma máquina não comprometida de outra forma.

Independentemente do vetor de ataque usado para entregar a dependência Trojan, esses cenários compartilham o elemento comum de que o sistema de build aceita cegamente o binário mal-intencionado e o inclui no build. Como o sistema de build não tem recursos para rejeitar o binário mal-intencionado e os mecanismos de segurança existentes, como revisão de código, geralmente se concentram em códigos desenvolvidos internamente em vez de dependências externas, esse tipo de ataque tem uma grande possibilidade de passar despercebido à medida que se espalha pelo ambiente de desenvolvimento e possivelmente de produção.

Embora haja algum risco de uma dependência comprometida ser introduzida em um processo de build manual, a tendência dos sistemas de build automatizados de recuperar a dependência de uma fonte externa cada vez que o sistema de compilação é executado em um novo ambiente aumenta muito a janela de oportunidade para um atacante. Um invasor precisa apenas comprometer o servidor de dependência ou o servidor DNS durante uma das muitas vezes em que a dependência é recuperada para comprometer a máquina na qual o build está ocorrendo.