La etiqueta <exception> requiere que se defina un tipo de excepción. La ausencia de un atributo type o que esté vacío indica un controlador de excepciones superfluo o una omisión accidental. Si un desarrollador tenía la intención de controlar una excepción, pero olvidó definir el tipo de excepción, entonces la aplicación podría filtrar información confidencial sobre el sistema.
Ejemplo 1: La siguiente configuración omite el tipo de la etiqueta <exception>.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

Struts usa entradas de form-bean para asignar formularios HTML a acciones. Si el atributo name de una etiqueta <action> no se corresponde con el nombre de un elemento form-bean, la acción no se puede asignar e indica una definición superflua o un error tipográfico.

Ejemplo 1: La siguiente configuración no contiene una asignación 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>

Struts usa el nombre form-bean para asignar formularios HTML a acciones. Si un elemento form-bean no tiene un nombre, no se puede asignar a una acción e indica una definición superflua o un archivo Bean omitido por accidente.
Este es un ejemplo de un elemento form-bean apropiado:
Ejemplo 1: El siguiente elemento form-bean tiene un atributo name vacío.

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

Struts usa entradas de form-bean para asignar formularios HTML a acciones. Si un elemento form-bean no tiene un tipo, no se puede asignar a una acción.
Ejemplo 1: El siguiente elemento form-bean tiene un atributo type vacío.

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

Struts exige que las etiquetas <form-property> incluyan un atributo type. Struts lanzará una excepción al procesar un formulario que define un elemento form-property sin tipo.

Ejemplo 1: La siguiente configuración omite un tipo para la propiedad 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>

Una etiqueta <forward> debe tener los atributos name y path. Sin un nombre, el elemento forward nunca se utilizará.

Ejemplo 1: La siguiente etiqueta <forward> tiene un atributo name vacío.

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

Una etiqueta <forward> debe tener los atributos name y path. Es un error omitir una ruta de acceso o especificar una en blanco. Además, todas las rutas de acceso deben comenzar con el carácter "/".

Ejemplo 1: La siguiente etiqueta <forward> no tiene un atributo path.

    <forward name="success" />

Si dos formularios de validación tienen el mismo nombre, el validador Struts elige arbitrariamente uno de los formularios para usarlo para la validación de entrada y descarta el otro. Es posible que esta decisión no se corresponda con las expectativas del programador. Además, indica que la lógica de validación no se mantiene y puede indicar que existen otros errores de validación más sutiles.

Ejemplo 1: Dos formularios de validación con el mismo nombre.

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

Es de vital importancia que la lógica de validación se mantenga y se mantenga sincronizada con el resto de la aplicación. La entrada sin marcar es la causa principal de algunos de los problemas de seguridad de software peores y más comunes de la actualidad. Los ataques Cross-Site Scripting, SQL Injection y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la validación incorrecta o inexistente de entradas. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

El Validador Struts usa un método validate() de formulario para contrastar el contenido de las propiedades del formulario con las restricciones especificadas en el formulario de validación asociado. Esto significa que las clases siguientes tienen un método validate() que forma parte del marco de validación:

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

Si crea una clase que extiende una de estas clases y si su clase implementa lógica de validación personalizada reemplazando el método validate(), debe llamar super.validate() en su implementación de validate(). De no ser así, el marco de validación no podrá contrastar el contenido del formulario con un formulario de validación. Es decir, el marco de validación se deshabilitará para el formulario en cuestión.

Deshabilitar el marco de validación para un formulario expone a la aplicación a numerosos tipos de ataque. Las entradas no comprobadas son la causa principal de vulnerabilidades en secuencias entre sitios, control de procesos e inserción de SQL. Si bien las aplicaciones J2EE no suelen ser vulnerables a los ataques dirigidos a dañar la memoria, si una aplicación J2EE entra en contacto con código nativo que no comprueba los límites de matriz, un atacante puede ser capaz de aprovechar el error de validación de una entrada en la aplicación J2EE para lanzar un ataque de buffer overflow.

Para utilizar el validador Struts, un formulario debe ampliar uno de los siguientes:

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

Debe ampliar una de estas clases porque el validador Struts se vincula a su aplicación al implementar el método validate() en estas clases.

Los formularios derivados de las siguientes clases no pueden utilizar el validador Struts:

ActionForm
DynaActionForm

Eludir el marco de validación de un formulario expone a la aplicación a numerosos tipos de ataques. La entrada no verificada es la causa principal de vulnerabilidades como Cross-Site Scripting, el control de procesos y SQL Injection. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Omitir la validación incluso para un solo campo de entrada puede facilitar a los atacantes el margen de maniobra que necesitan.

La entrada sin marcar es la causa principal de algunos de los problemas de seguridad de software peores y más comunes de la actualidad. Los ataques Cross-Site Scripting, SQL Injection y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la validación incorrecta o inexistente de entradas. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Algunas aplicaciones utilizan el mismo ActionForm para más de un propósito. En situaciones como esta, es posible que haya campos que no se utilicen en algunas asignaciones de acción. Es fundamental que los campos sin utilizar también se validen. Preferiblemente, los campos sin usar se deben limitar de manera que solo puedan estar vacíos o sin definir. Si los campos sin usar no se validan, la lógica de negocios compartida en una acción podría permitir a los atacantes anular las comprobaciones de validación que se llevan a cabo para otros usos del formulario.

La entrada no comprobada es la principal causa de vulnerabilidades en las aplicaciones J2EE. La entrada no verificada puede generar numerosas vulnerabilidades, incluidas Cross-Site Scripting, control de procesos e SQL injection. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Para prevenir estos ataques, use el validador Struts para comprobar toda la entrada del programa antes de que la aplicación la procese. Utilice Fortify Static Code Analyzer para asegurarse de que no haya agujeros en la configuración del validador Struts.

Los ejemplos de usos del validador incluyen la verificación para garantizar que:

- Los campos de números de teléfono contengan solo caracteres válidos en los números de teléfono

- Los valores booleanos sean solo "T" o "F"

- Las cadenas sin formato tengan una longitud y una composición razonables

Struts usa entradas de form-bean para asignar formularios HTML a acciones. Si el elemento <action-mappings> del archivo de configuración de Struts no contiene una entrada que se corresponda con un formulario de acción pertinente definido a través de una etiqueta <form-bean>, es posible que la lógica de la aplicación no esté actualizada.

Ejemplo 1: La siguiente configuración no contiene una asignación para bean2.

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean1" />
  <form-bean name="bean2" type="coreservlets.UserFormBean2" />
</form-beans>

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

Es fácil para los desarrolladores olvidarse de actualizar la lógica de validación cuando eliminan o cambian el nombre de las asignaciones de formularios de acción. Una indicación de que la lógica de validación no se mantiene correctamente es la presencia de un formulario de validación no utilizado.

Si una asignación de formulario de acción de Struts especifica un formulario, debe tener un formulario de validación definido en el validador Struts. Si una asignación de formulario de acción no tiene un formulario de validación definido, dicha asignación podría ser vulnerable a una serie de ataques que dependen de una entrada no verificada.

La entrada sin marcar es la causa principal de algunos de los problemas de seguridad de software peores y más comunes de la actualidad. Los ataques Cross-Site Scripting, SQL Injection y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la validación incorrecta o inexistente de entradas. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Una acción o un formulario pueden realizar la validación de otras formas, pero el validador Struts facilita una manera excelente de verificar que todas las entradas reciban al menos un nivel básico de verificación. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Una asignación de formulario de acción nunca debe deshabilitar la validación. La deshabilitación de la validación desactiva el validador Struts, así como cualquier lógica de validación personalizada realizada por el formulario.

Ejemplo 1: Una asignación de formulario de acción que deshabilita la validación.

<action path="/download"
type="com.website.d2.action.DownloadAction"
name="downloadForm"
scope="request"
input=".download"
validate="false">
</action>

La deshabilitación de la validación expone esta acción a numerosos tipos de ataques. La entrada no verificada es la causa principal de vulnerabilidades como Cross-Site Scripting, el control de procesos y SQL Injection. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Es fácil para los desarrolladores olvidar actualizar la lógica de validación cuando realizan cambios en una clase de ActionForm. Una indicación de que la lógica de validación no se mantiene correctamente son las inconsistencias entre el formulario de acción y el formulario de validación.

Ejemplo 1.a: Un formulario de acción con dos campos.

    public class DateRangeForm extends ValidatorForm {
    String startDate, endDate;
    public void setStartDate(String startDate) {
        this.startDate = startDate;
    }
    public void setEndDate(String endDate) {
        this.endDate = endDate;
    }
}

El ejemplo 1.a muestra un formulario de acción que tiene dos campos: startDate y endDate.

Ejemplo 1.b: Un formulario de validación con un tercer campo.

<form name="DateRangeForm">
    <field property="startDate" depends="date">
        <arg0 key="start.date"/>
    </field>
    <field property="endDate" depends="date">
         <arg0 key="end.date"/>
    </field>
    <field property="scale" depends="integer">
         <arg0 key="range.scale"/>
    </field>
</form>

El ejemplo 1.b presenta un formulario de validación para el formulario de acción. El formulario de validación presenta un tercer campo: scale. La presencia del tercer campo sugiere que DateRangeForm se modificó sin tener en cuenta la validación.

Es de vital importancia que la lógica de validación se mantenga y se mantenga sincronizada con el resto de la aplicación. La entrada sin marcar es la causa principal de algunos de los problemas de seguridad de software peores y más comunes de la actualidad. Los ataques Cross-Site Scripting, SQL Injection y las vulnerabilidades detectadas en el control de los procesos tienen todos su origen en la validación incorrecta o inexistente de entradas. Aunque las aplicaciones J2EE no suelen ser susceptibles a ataques de corrupción de memoria, si una aplicación J2EE interactúa con código nativo que no comprueba límites de matriz, un atacante puede usar un error de validación de entrada en la aplicación J2EE para lanzar un ataque de desbordamiento de búfer.

Los campos del sistema ABAP siempre están disponibles en los programas ABAP. El sistema de tiempo de ejecución los rellena según el contexto después de iniciar un programa, después de enviar una pantalla y después de cambiar el modo interno. Entonces pueden usarse en programas para consultar el estado del sistema. Los campos del sistema son variables pero siempre deben tratarse como si fueran constantes y de solo lectura. Cambiar sus valores puede provocar la pérdida de información importante necesaria para que el programa fluya. Solo algunas de ellas están para que se cambien en los programas ABAP de los clientes.


Cambiar valores de los campos del sistema que comunican información específica en tiempo de ejecución al programa ABAP podría provocar una interrupción o un comportamiento inesperado del programa ABAP.

Se produce una pérdida de información cuando los datos del sistema o la información de depuración abandonan el programa a través de una secuencia de salida o de una función de registro.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:

try {
    ...
} catch (Exception e) {
    e.printStackTrace();
}

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o exponer ante un usuario remoto. Por ejemplo, con los mecanismos de scripts es sencillo redirigir la información de salida de un "Error típico" o una "Salida estándar" a un archivo o a otro programa. De forma alternativa, el sistema que ejecuta el programa podría tener un mecanismo de registro remoto, como un servidor como "syslog", que envía los registros a un dispositivo remoto. Durante este proceso, no existe forma alguna de saber dónde se puede terminar mostrando esta información.

En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los autores de aplicaciones deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo.

Ejemplo 2: El siguiente código difunde el seguimiento de pila de una excepción detectada a todos los destinatarios de Android registrados.

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

Se trata de otra situación específica de las plataformas móviles. La mayoría de los dispositivos móviles ahora implementa un protocolo de transmisión de datos en proximidad (NFC) para compartir rápidamente la información entre dispositivos utilizando la comunicación de radio. Funciona cuando se colocan dispositivos cerca los unos de los otros o tocándose. Aunque el campo de la comunicación de NFC está limitado a unos pocos centímetros, sí son posibles las escuchas, la modificación de datos y otros tipos de ataques, ya que NFC por sí solo no es garantía de una comunicación segura.

Ejemplo 3: la plataforma Android tiene compatibilidad con NFC. El código siguiente crea un mensaje que se inserta en otro dispositivo dentro del campo de alcance.

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

Un mensaje con formato de intercambio de datos NFC (NDEF) contiene datos escritos, un URI o una carga de aplicación personalizada. Si el mensaje contiene información sobre la aplicación, como su nombre, el tipo MIME o la versión de software del dispositivo, esta información se podría filtrar a una persona que esté escuchando.

Se produce una pérdida de información cuando los datos del sistema o la información de depuración abandonan el programa a través de una secuencia de salida o de una función de registro.



Cuando se establece en true ,axis.enableListQuery se habilita la lista de Web Service Deployment Descriptor (WSDD). Esta característica expone la configuración actual del sistema que contiene información confidencial como la contraseña del servicio de administración.