2008-12-29 13 views
5

Acabo de instalar el complemento FindBugs para Eclipse, con la esperanza de que me ayude a encontrar vulnerabilidades de inyección SQL en mi código. Sin embargo, no parece estar encontrando nada, ni siquiera cuando me puse deliberadamente algunos enFindbugs no encuentra potencial vulnerabilidad de inyección SQL

En los siguientes ejemplos se supone staticFinalBaseQuery se declara como sigue:.

pública final de cuerda estática staticFinalBaseQuery = "SELECT foo DE tabla donde id = '";

y asume userInputfilterString es un argumento para el método que envuelve los fragmentos de ejemplo. Viene directamente de la entrada del usuario y no se desinfecta.

Por ejemplo, el siguiente fragmento no se disparará una advertencia:

String query = staticFinalBaseQuery + userInputfilterString; 
pstmt = dbConnection.prepareStatement(query); 

Dónde staticFinalBaseQuery es una cadena static final, y userInputfilterString es una cadena directa de la entrada del usuario, disponible sólo en tiempo de ejecución, no se ha borrado del todo . Claramente, esta es una vulnerabilidad.

Espero que se active la advertencia "A prepared statement is generated from a nonconstant String".

El siguiente fragmento también no causa una advertencia (no es sorprendente, ya que las formas compiladas de estos son probablemente idénticos):

pstmt = dbConnection.prepareStatement(staticFinalBaseQuery + userInputfilterString); 

Sin embargo, esto causará una advertencia:

pstmt = dbConnection.prepareStatement(staticFinalBaseQuery + userInputfilterString + "'"); 

Si agrego una cadena vacía o un espacio, no se activa ninguna advertencia.

Entonces, mi pregunta es, ¿cómo puedo obtener FindBugs para disparar en mi primer ejemplo? También tengo curiosidad por ¿por qué el primero no causa una advertencia, pero el último sí?

¡Gracias de antemano!

EDIT: I submitted a bug al sistema de seguimiento de errores FindBugs, ya que parece que esto podría ser un error. Sin embargo, si alguien tiene algún consejo, me encantaría escucharlos.

+0

Tal vez deberías reportar esto como un error para la gente de FindBugs? –

+0

Sí, quizás debería. Pensé que tal vez solo lo estaba usando mal. Si ese es el caso, es posible que deseen actualizar la documentación. – pkaeding

+0

¿Puedes publicar cómo se inicializan staticFinalBaseQuery y userInputfilterString exactamente? –

Respuesta

2

Aquí es difícil distinguir entre código seguro y código inseguro. Claro, userInputfilterString puede ser inseguro, pero es imposible determinarlo en tiempo de compilación. Sin embargo, el carácter de comillas simples en una concatenación de cadenas es un signo revelador del uso de código inyectable. Es por eso que FindBugs se activa en la línea que contiene este carácter, pero no en la línea con la mera concatenación de cadenas.

Básicamente, esto no es un error, sino una limitación de cuánto puede hacer el software para comprobar la inyección de SQL. Como la cadena puede contener cualquier cosa (es decir, podría tener la concatenación vulnerable en otra función) es imposible que la herramienta determine con la certeza de que existe un problema.

+0

Acabo de editar la pregunta para indicar qué comprobación esperaba que FindBugs se activara, y por qué pensé que debería mostrar mis fragmentos como un posible error. – pkaeding

+0

Principalmente estoy de acuerdo con esta respuesta, pero definitivamente hay una concatenación no constante que ocurre en la llamada para preparar el estado, por lo que yo también esperaría que se active el cheque. –

1

No creo que PMD o Checkstyle lo atrapen tampoco, pero puede intentarlo (utilizo los 3 de forma regular, buenas herramientas para usar).

EDIT: PMD era el enlace correcto, pero me llamó findbugs ... findbugs en el cerebro supongo ...

Cuestiones relacionadas