Gotchas de Java - Operadores Bitwise vs Boolean

> "Java Gotcha" - un patrón de error común que es fácil de implementar accidentalmente.

Un Gotcha de Java bastante sencillo en el que se puede caer accidentalmente es: utilizar un operador Bitwise en lugar de un operador de Comparación Booleana.

Por ejemplo, un simple error tipográfico puede hacer que se escriba "&" cuando en realidad se quería escribir "&&".

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

> "&" o "|" cuando se utiliza en una declaración condicional probablemente no se pretende.

En esta entrada del blog, exploraremos la heurística e identificaremos las formas en que podemos identificar y solucionar este problema de codificación.

¿Cuál es el problema? Las operaciones Bitwise funcionan bien con los booleanos

El uso de operadores Bitwise 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 para ambos operadores Bitwise OR (|) y Bitwise AND (&) entonces veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. Dado esto, podríamos pensar que el uso de los operadores Bitwise 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 de 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 la tabla de verdad se crearon con la herramienta herramienta de tabla de verdad de web.standfor.edu.

Problema: Funcionamiento en cortocircuito

El verdadero problema es la diferencia de comportamiento entre los operadores Bitwise (&, |) y Boolean (&&, ||).

Un operador booleano es un operador de cortocircuito y sólo evalúa lo necesario.

Por ejemplo

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

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

Esto deja mi código abierto a una NullPointerException si args es null porque siempre realizaremos la comprobación de args.length, incluso cuando args es null porque ambas condiciones booleanas tienen que ser evaluadas.

Operadores booleanos Evaluación de cortocircuitos

Cuando se utiliza un &&, por ejemplo

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

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

No necesitamos evaluar el lado derecho.

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

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

Este 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 algún ejemplo público de este patrón:

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

Este es el tipo de código que podría pasar una revisión de código porque a menudo usamos operadores Bitwise en las sentencias de asignación para enmascarar valores. Pero en este caso, el resultado es el mismo que el ejemplo de la sentencia if anterior. Si la intención es alguna vez nula, entonces se lanzará una NullPointerException.

Muy a menudo nos libramos de esta construcción porque solemos codificar a la defensiva y escribir código redundante. La comprobación de != null puede ser redundante en la mayoría de los casos de uso.

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

No sé cómo de actuales son los resultados de la búsqueda, pero cuando ejecuté la búsqueda había resultados de vuelta con código de: Google, Amazon, Apache... y yo.

Un reciente pull request en uno de mis proyectos de código abierto fue para solucionar exactamente este error.

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

Cómo encontrarlo

Cuando comprobé mi código de muestra en unos cuantos analizadores estáticos, ninguno de ellos detectó este código de autodestrucción oculto.

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

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

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

Utiliza una expresión regular para que coincida con " & " cuando se utiliza como expresión de condición, por ejemplo, en una sentencia if.

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

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Notas finales

Esto cubre el uso erróneo más común de un operador Bitwise, es decir, cuando se pretendía un operador Booleano.

Hay otras situaciones en las que esto podría surgir, por ejemplo, el ejemplo de la asignación, pero al escribir las recetas tenemos que intentar evitar la identificación falsa-positiva, de lo contrario las recetas serán ignoradas o desactivadas. Construimos las recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es posible que añadamos más especificidad a la función de búsqueda para cubrir más condiciones de coincidencia.

En su forma actual, esta receta identificaría muchos de los casos de uso en vivo, y lo más importante, el que fue reportado en mi proyecto.

NOTA: Unos cuantos guerreros del código han contribuido 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 "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"

Tenemos un montón de código fuente y recetas para estas entradas del blog (incluyendo 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