Trampas de Java: operadores bit a bit frente a booleanos

> "Trampa de Java": un patrón de error común que es fácil de implementar por accidente.

Una trampa de Java bastante sencilla en la que caer por accidente es: usar un operador bit a bit en lugar de un operador de comparación booleano.

Por ejemplo, un simple error de escritura puede hacer que escribas "&" cuando en realidad querías escribir "&&".

Una heurística común que aprendemos al revisar código es:

> "&" o "|" cuando se usan en una sentencia condicional probablemente no sean intencionados.

En esta entrada del blog, exploraremos esta heurística e identificaremos formas de detectar y corregir este problema de programación.

¿Cuál es el problema? Las operaciones bit a bit funcionan bien con booleanos

Usar operadores bit a bit con booleanos es perfectamente válido, por lo que Java no informará de un error de sintaxis.

Si construyo una prueba JUnit para explorar una tabla de verdad tanto para OR bit a bit (|) como para AND bit a bit (&), veremos que los resultados del operador bit a bit coinciden con la tabla de verdad. Dado esto, podríamos pensar que el uso de operadores bit a bit no es un problema.

Tabla de verdad AND

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

La prueba pasa; esto es Java perfectamente válido.

Tabla de verdad OR

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

Esta prueba también pasa, ¿por qué preferimos "&&" y "||"?

Las imágenes de las tablas de verdad se crearon utilizando la herramienta de tablas de verdad de web.standfor.edu.

Problema: Operación de cortocircuito

El verdadero problema es la diferencia de comportamiento entre los operadores a nivel de bits (&, |) y los operadores booleanos (&&, ||).

Un operador booleano es un operador de cortocircuito y solo evalúa lo estrictamente necesario.

p. ej.

if (args != null & args.length() > 23) {
    System.out.println(args);
}

En el código anterior, ambas condiciones booleanas se evaluarán porque se ha utilizado el operador a nivel de bits:

• args != null
• args.length() > 23

Esto deja mi código expuesto a una NullPointerException si args es nulo, ya que siempre realizaremos la comprobación de args.length, incluso cuando args sea nulo, porque ambas condiciones booleanas deben evaluarse.

Evaluación de cortocircuito de operadores booleanos

Cuando se utiliza &&, p. ej.

if (args != null && args.length() > 23) {
    System.out.println(args);
}

Tan pronto como sabemos que args != null se evalúa como falso, la evaluación de la expresión condicional se detiene.

No necesitamos evaluar el lado derecho.

Independientemente del resultado de la condición del lado derecho, el valor final de la expresión booleana será falso.

Pero esto nunca sucedería en código de producción

Es un error bastante fácil de cometer y no siempre es detectado por las herramientas de análisis estático.

Utilicé el siguiente Google Dork para ver si podía encontrar ejemplos públicos de este patrón:

filetype:java if "!=null & "
Esta búsqueda arrojó algo de código de Android en RootWindowContainer
isDocument = intent != null & intent.isDocument()

Este es el tipo de código que podría pasar una revisión, ya que a menudo usamos operadores a nivel de bits en sentencias de asignación para enmascarar valores. Pero en este caso, el resultado es el mismo que en el ejemplo de la sentencia if anterior. Si intent es nulo, se producirá una NullPointerException.

A menudo nos libramos de esta construcción porque solemos programar de forma defensiva y escribir código redundante. La comprobación != null bien podría ser redundante en la mayoría de los casos de uso.

Este es un error cometido por programadores en código de producción.

No sé qué tan actuales son los resultados de la búsqueda, pero cuando la realicé, obtuve resultados con código de: Google, Amazon, Apache... y mío.

Una solicitud de extracción (pull request) reciente en uno de mis proyectos de código abierto abordaba exactamente este error.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

Cómo encontrar esto

Cuando comprobé mi código de ejemplo en varios analizadores estáticos, ninguno detectó este código de autodestrucción oculto.

Como equipo en Secure Code Warrior, creamos y revisamos una receta de Sensei bastante sencilla que podría detectarlo.

Debido a que los operadores a nivel de bits son perfectamente válidos y se utilizan a menudo en asignaciones, nos centramos en el caso de uso de las sentencias if y el uso del operador & a nivel de bits para encontrar el código problemático.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

Esto utiliza una expresión regular para buscar " & " cuando se utiliza como expresión condicional, por ejemplo, en una sentencia if.

Para solucionarlo, volvimos a recurrir a las expresiones regulares. Esta vez utilizamos la función sed en el QuickFix para reemplazar globalmente el & en la expresión por &&.

availableFixes:
  - name: "Reemplazar el operador AND a nivel de bits por el operador AND lógico"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Notas finales

Esto cubre el uso indebido más común de un operador a nivel de bits, es decir, cuando en realidad se pretendía utilizar un operador booleano.

Existen otras situaciones en las que esto podría surgir, como en el ejemplo de asignación, pero al escribir recetas debemos intentar evitar la identificación de falsos positivos; de lo contrario, las recetas serán ignoradas o desactivadas. Creamos recetas para detectar las incidencias más comunes. A medida que Sensei evolucione, es muy probable que añadamos mayor especificidad a la funcionalidad de búsqueda para cubrir más condiciones de coincidencia.

En su forma actual, esta receta identificaría muchos de los casos de uso reales y, lo que es más importante, el que se informó en mi proyecto.

NOTA: Un buen número de "code warriors" contribuyeron a este ejemplo y a la revisión de la receta: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. Gracias por su ayuda.

---

Puedes instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego simplemente buscar "sensei secure code"

Tenemos una gran cantidad de código fuente y recetas para estas publicaciones de blog (incluida esta) en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior.

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei