Los errores y su tratamiento representan una clase de API. Los errores relacionados con el tratamiento de errores son tan comunes que se merecen una sección por sí mismos. Tal como sucede con los "abusos de la API", hay dos formas de presentar una vulnerabilidad de seguridad relacionada con los errores: la más común es tratar los errores inadecuadamente (o no llegar a hacerlo). La segunda es producir errores que dan demasiada información (a posibles atacantes) o que son difíciles de tratar.
+=
, pero está escrito como =+
, la operación sigue siendo válida. Sin embargo, en lugar de realizar la suma, reinicializa la variable.numberOne
. Sin embargo, el uso del operador =+
en realidad reinicializa la variable a 1.
uint numberOne = 1;
function alwaysOne() public {
numberOne =+ 1;
}
for
para reembolsar a todas las direcciones involucradas mediante el uso de send
llamada externa.
function refundAll() public {
for(uint x; x < refundAddresses.length; x++) {
require(refundAddresses[x].send(refunds[refundAddresses[x]]));
}
}
...
EXEC CICS
INGNORE CONDITION ERROR
END-EXEC.
...
doExchange()
.
try {
doExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
, el programa continuaría ejecutándose como si no hubiera ocurrido nada inusual. El programa no registra ninguna evidencia que aluda a la situación especial, lo que podría frustrar cualquier intento posterior de explicar el comportamiento del programa.DoExchange()
.
try {
DoExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.doExchange()
.
try {
doExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.doExchange()
.
try {
doExchange();
}
catch (exception $e) {
// this can never happen
}
RareException
se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.open()
.
try:
f = open('myfile.txt')
s = f.readline()
i = int(s.strip())
except:
# This will never happen
pass
RareException
se fuese a iniciar en algún momento, el programa seguiría ejecutándose como si no hubiese ocurrido nada inusual. El programa no registrará ninguna prueba que indique la situación especial, evitando potencialmente cualquier intento posterior de explicar el comportamiento del programa.
PROCEDURE do_it_all
IS
BEGIN
BEGIN
INSERT INTO table1 VALUES(...);
COMMIT;
EXCEPTION
WHEN OTHERS THEN NULL;
END;
END do_it_all;
Exception
, se pueden ocultar excepciones que requieran un tratamiento especial o que no se deberían obtener en este punto del programa. Si se obtiene una excepción demasiado amplia, básicamente hace fracasar el propósito de las excepciones tipificadas de .NET, y puede resultar particularmente peligroso si el programa se desarrolla y comienza a iniciar nuevos tipos de excepciones. Los nuevos tipos de excepciones quedarán desatendidas.
try {
DoExchange();
}
catch (IOException e) {
logger.Error("DoExchange failed", e);
}
catch (FormatException e) {
logger.Error("DoExchange failed", e);
}
catch (TimeoutException e) {
logger.Error("DoExchange failed", e);
}
try {
DoExchange();
}
catch (Exception e) {
logger.Error("DoExchange failed", e);
}
DoExchange()
para iniciar un nuevo tipo de excepción que debería tratarse de forma diferente, el amplio bloque catch evitará que el compilador señale la situación. Además, ahora el bloque catch nuevo tratará también excepciones de los tipos ApplicationException
y NullReferenceException
, lo cual no es el propósito del programador.Exception
, se pueden ocultar excepciones que requieran un tratamiento especial o que no se deberían obtener en este punto del programa. Si se obtiene una excepción demasiado amplia, básicamente hace fracasar el propósito de las excepciones tipificadas de Java, y puede resultar particularmente peligroso si el programa se desarrolla y comienza a iniciar nuevos tipos de excepciones. Los nuevos tipos de excepciones quedarán desatendidas.
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {
logger.error("doExchange failed", e);
}
catch (SQLException e) {
logger.error("doExchange failed", e);
}
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}
doExchange()
para iniciar un nuevo tipo de excepción que debería tratarse de forma diferente, el amplio bloque catch evitará que el compilador señale la situación. Es más, el nuevo bloque de filtrado ahora también administra las excepciones derivadas de RuntimeException
como ClassCastException
y NullPointerException
, que no es el propósito del programador.Exception
o Throwable
dificulta a los autores de llamada hacer un buen trabajo en cuanto al tratamiento y la recuperación de errores. El mecanismo de excepciones de Java se ha configurado para facilitar a los autores de llamada la anticipación de qué puede salir mal y escribir código para administrar cada circunstancia de excepción específica. Declarar que un método lance una forma genérica de excepción frustra este sistema.
public void doExchange()
throws IOException, InvocationTargetException,
SQLException {
...
}
public void doExchange()
throws Exception {
...
}
doExchange()
introduce un nuevo tipo de excepción que debería tratarse de forma diferente a las excepciones anteriores, no hay una forma fácil de exigir este requisito.