O Struts usa entradas form-bean para mapear formulários HTML para ações. Se o atributo name em uma tag <action> não corresponde ao nome de uma form-bean , a ação não pode ser mapeada e indica uma definição supérflua ou um erro tipográfico.

Exemplo 1: A configuração a seguir não contém um mapeamento para bean2 .

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

O Struts usa o nome form-bean para mapear formulários HTML para ações. Se uma form-bean não tem um nome, não pode ser mapeado para uma ação e indica uma definição supérflua ou uma bean omitida acidentalmente.
Aqui está um exemplo adequado de form-bean:
Exemplo 1: A seguinte form-bean tem um atributo de name vazio.

<form-beans>
  <form-bean name="" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

O Struts usa entradas form-bean para mapear formulários HTML para ações. Se uma form-bean não tem um tipo, não pode ser mapeada para uma ação.
Exemplo 1: A seguinte form-bean tem um atributo de type vazio.

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

O Struts exige que as tags <form-property> incluam um atributo type. O Struts lançará uma exceção ao processar um formulário que define uma form-property sem tipo.

Exemplo 1: A seguinte configuração omite um tipo para a propriedade name.

<form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
  <form-property name="name" />
  <form-property name="password" type="java.lang.String" />
</form-bean>

Uma tag <forward> deve ter os atributos name e path. Sem um nome, forward nunca será usado.

Exemplo 1: A seguinte tag <forward> tem um atributo de name vazio.

    <forward name="" path="/results.jsp"/>

Uma tag <forward> deve ter os atributos name e path. É um erro omitir um caminho ou especificar um caminho em branco. Além disso, todos os caminhos devem começar com o caractere "/".

Exemplo 1: A seguinte tag <forward> tem um atributo de path ausente.

    <forward name="success" />

Se a opção display_errors estiver habilitada, os erros são exibidos na Web, o que pode mostrar possíveis vulnerabilidades para um invasor. Por exemplo, uma mensagem de erro de banco de dados pode revelar que o aplicativo é vulnerável a um ataque de SQL Injection. Outras mensagens de erro podem revelar pistas mais indiretas sobre o sistema.

Se a opção expose_php estiver habilitada, todas as respostas produzidas pelo interpretador PHP incluirão a versão do PHP instalada no sistema host. Armado com a versão do PHP em execução no servidor remoto, um invasor pode enumerar as explorações conhecidas contra o sistema, o que pode reduzir extremamente o custo de preparação de um ataque bem-sucedido.

Um serviço que não autentica seus clientes permite acesso a todos os visitantes.

Um serviço que não autentica seus clientes permite acesso a todos os visitantes.

Os serviços do Windows Communication Framework (WCF) podem ser configurados para expor informações de depuração. As informações de depuração não devem ser usadas em ambientes de produção. A tag <serviceDebug> define se o recurso de informações de depuração está habilitado para um serviço WCF.



Se o atributo includeExceptionDetailInFaults estiver definido como true , as informações de exceção do aplicativo serão retornadas aos clientes. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Exemplo: O seguinte arquivo de configuração inclui a tag <serviceDebug>:

<configuration>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceDebug includeExceptionDetailInFaults="True" httpHelpPageEnabled="True"/>
...

Se o WCF estiver configurado para não lançar uma exceção quando não puder gravar em um log de auditoria, o programa não será notificado sobre a falha e a auditoria de eventos de segurança críticos pode não ocorrer.

Exemplo 1: O elemento <behavior/> do arquivo de configuração WCF a seguir instrui o WCF a não notificar o aplicativo quando o WCF não grava em um log de auditoria.

<behaviors>
   <serviceBehaviors>
      <behavior name="NewBehavior">
         <serviceSecurityAudit auditLogLocation="Application"
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success"
             messageAuthenticationAuditLevel="Success" />
      </behavior>
   </serviceBehaviors>
</behaviors>

O Windows Communication Foundation (WCF) oferece a capacidade de registrar tentativas de autenticação bem-sucedidas e/ou malsucedidas. O registro de tentativas de autenticação malsucedidas pode alertar os administradores sobre possíveis ataques de força bruta. Da mesma forma, o registro de eventos de autenticação bem-sucedidos pode fornecer uma trilha de auditoria útil quando uma conta legítima é comprometida.

Serviços WCF podem ser configurados para expor metadados. Metadados fornecem informações detalhadas sobre descrições de serviços e não devem ser transmitidos em ambientes de produção. As propriedades HttpGetEnabled / HttpsGetEnabled da classe ServiceMetaData definem se um serviço vai expor os metadados.
Exemplo 1: O código a seguir instrui o WCF a transmitir os metadados de um serviço.

    ServiceMetadataBehavior smb = new ServiceMetadataBehavior();
    smb.HttpGetEnabled = true;
    smb.HttpGetUrl = new Uri(EndPointAddress);
    Host.Description.Behaviors.Add(smb);

Se a autenticação não for usada para se conectar a uma fila MSMQ usada para entregar uma mensagem a outro programa, um invasor poderá enviar uma mensagem anônima mal-intencionada.

Exemplo 1: O elemento <netMsmqBinding/> do arquivo de configuração WCF a seguir instrui o WCF a desabilitar a autenticação ao se conectar a uma fila MSMQ para a distribuição de mensagens.

    <bindings>
      <netMsmqBinding>
        <binding>
          <security>
            <transport msmqAuthenticationMode="None" />
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>

Programas que transmitem mensagens sem segurança de transporte ou de mensagem não podem garantir a integridade ou confidencialidade das mensagens. Quando uma associação de segurança WCF é definida como None, os dois tipos de segurança de transporte e de mensagem são desabilitados.

Exemplo 1: O código a seguir define o modo de segurança como None de uma Associação HTTP Básica WCF referente a um Serviço Widget fictício.

BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;

ServiceHost serviceHost = new ServiceHost(typeof(Widget), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Widget), binding, new URI("ExposureAddress"));

A tag <serviceMetadata> ativa o recurso de publicação de metadados. Os metadados do serviço podem conter informações confidenciais que não devem ser acessíveis ao público.

O Windows Communication Foundation (WCF) oferece a capacidade de regulas as solicitações de serviço. Permitir muitas solicitações do cliente pode inundar um sistema e esgotar seus recursos. Por outro lado, permitir apenas um pequeno número de solicitações a um serviço pode impedir que usuários legítimos usem o serviço. Cada serviço deve ser ajustado e configurado individualmente para permitir a quantidade apropriada de recursos.

A segurança de transporte especifica que a confidencialidade, a integridade e a autenticação são fornecidas por mecanismos de camada de transporte (como o HTTPS). Ao usar um transporte como o HTTPS, esse modo tem a vantagem de ser eficiente em termos de desempenho e bem compreendido por causa do seu predomínio na Internet. A desvantagem é que esse tipo de segurança é aplicado separadamente em cada salto no caminho de comunicação, tornando a comunicação suscetível a um ataque MITM (man-in-the-middle). O WCF oferece dois outros modos de segurança de transferência, ambos preferíveis: mensagem e transporte com credencial de mensagem. A segurança de mensagens usa a especificação WS-Security para garantir a confidencialidade, a integridade e a autenticação em nível de mensagem. Isso fornece segurança ponta-a-ponta e flexibilidade nos métodos de transporte. No entanto, o desempenho é reduzido.

O método final, transporte com credencial de mensagem, é um híbrido de transporte e método. A segurança da mensagem é usada para autenticar o cliente, e a segurança de transporte é usada para autenticar o servidor e fornecer confidencialidade e integridade. É quase tão eficiente quanto a pura segurança de transporte.

Quando um cliente chama um serviço WCF específico, o WCF fornece vários esquemas de autorização que verificam se o chamador tem permissão para executar o método de serviço no servidor. Se controles de autorização não estiverem habilitados para serviços WCF, um usuário autenticado poderá conseguir a escalação de privilégios.

Exemplo 1: O seguinte código instrui o WCF a não verificar o nível de autorização do cliente ao executar o serviço:

    ServiceHost myServiceHost = new ServiceHost(typeof(Calculator), baseUri);
    ServiceAuthorizationBehavior myServiceBehavior =
    myServiceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
    myServiceBehavior.PrincipalPermissionMode =
        PrincipalPermissionMode.None;