Los errores de Java: operadores bitwise frente a operadores booleanos
Los errores de Java: operadores bitwise frente a operadores booleanos
> «Java Gotcha»: un patrón de error común que es fácil de implementar accidentalmente.
Un truco de Java bastante simple en el que caer accidentalmente es: usar un operador bit a bit en lugar de un operador de comparación booleano.
Por ejemplo, un simple error de escritura puede resultar en escribir «&» cuando realmente querías escribir «&&».
Una heurística común que aprendemos al revisar el código es:
> «&» o «|» cuando se usan en una declaración condicional probablemente no sean intencionales.
En esta entrada del blog, exploraremos la heurística e identificaremos formas en las que podemos identificar y solucionar este problema de codificación.
¿Cuál es el problema? Las operaciones bit a bit funcionan bien con los valores booleanos
El uso de operadores bit a bit con booleanos es perfectamente válido, por lo que Java no notificará ningún error de sintaxis.
Si construyo una prueba JUnit para explorar una tabla de verdad tanto para Bitwise OR (|) como para Bitwise AND (&), veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. En vista de esto, podríamos pensar que el uso de operadores Bitwise no es un problema.
Y Tabla de la verdad
@Test
void BitwiseOperatorsAndTruthTable () {
Assertions.assertEquals (verdadero, verdadero y verdadero);
Assertions.assertEquals (falso, verdadero y falso);
Assertions.assertEquals (falso, falso y verdadero);
Assertions.assertEquals (falso, falso y falso);
}
La prueba pasa, esto es Java perfectamente válido.
O Tabla de la verdad
@Test
anular BitwiseOperatorSorTruthTable () {
Assertions.assertEquals (verdadero, verdadero | verdadero);
Assertions.assertEquals (verdadero, verdadero | falso);
Assertions.assertEquals (verdadero, falso | verdadero);
Assertions.assertEquals (falso, falso | falso);
}
Esta prueba también pasa, ¿por qué preferimos «&&'y «||'?
Las imágenes de la tabla de verdad se crearon utilizando el herramienta de tabla de la verdad de web.standfor.edu.
Problema: Funcionamiento en cortocircuito
El verdadero problema es la diferencia de comportamiento entre los operadores bitwise (&, |) y booleanos (&&, ||).
Un operador booleano es un operador de cortocircuito y solo evalúa lo necesario.
por ejemplo
si (args! = nulo & args.length () > 23) {
System.out.println (argumentos);
}
En el código anterior, se evaluarán ambas condiciones booleanas, porque se ha utilizado el operador Bitwise:
- argumentos! = nulo
- args.length () > 23
Esto deja mi código abierto a una NullPointerException si args es nulo porque siempre realizaremos la verificación de args.length, incluso cuando args sea nulo porque se deben evaluar ambas condiciones booleanas.
Evaluación de cortocircuitos de operadores booleanos
Cuando se usa un &&, p. ej.
si (args! = nulo && args.length () > 23) {
System.out.println (argumentos);
}
¡En cuanto sepamos que es un argumento! = null se evalúa como falso, la evaluación de la expresión de 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 sucedería en el código de producción
Este es un error bastante fácil de cometer y las herramientas de análisis estático no siempre lo detectan.
Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:
tipo de archivo: java si es «! =nulo &»
Esta búsqueda devolvió un código de Android en el RootWindowContainer
isDocument = intención! = nulo & intent.isDocument ()
Este es el tipo de código que puede pasar una revisión de código, ya que a menudo utilizamos operadores bit a bit en las sentencias de asignación para enmascarar los valores. Pero en este caso, el resultado es el mismo que en el ejemplo anterior de la sentencia if. Si la intención es alguna vez nula, se lanzará una NullPointerException.
Muy a menudo nos salimos con la nuestra con esta construcción porque a menudo codificamos a la defensiva y escribimos código redundante. ¡El cheque para! = null puede resultar redundante en la mayoría de los casos de uso.
Se trata de un error cometido por los programadores en el código de producción.
No sé qué tan actuales son los resultados de la búsqueda, pero cuando la ejecuté, aparecieron resultados con código de: Google, Amazon, Apache... y yo.
Un reciente solicitud de extracción en uno de mis proyectos de código abierto fue solucionar exactamente este error.
si (escriba! =nulo y escribe.trim () .length () >0) {
Aceptar MediaTypeDefinitionsList.add (type.trim ());
}
Cómo encontrar esto
Cuando comprobé mi código de muestra en algunos analizadores estáticos, ninguno de ellos detectó este código oculto de autodestrucción.
Como equipo de Secure Code Warrior, hemos creado y revisado una receta de Sensei bastante sencilla que podría responder a esta pregunta.
Como los operadores Bitwise son perfectamente válidos y se utilizan con frecuencia 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.
buscar:
expresión:
Cualquiera de:
- en:
condición: {}
valor:
Sensible a mayúsculas y minúsculas: falso
coincidencias: «.* & . *»
Esto usa una expresión regular para que coincida con "&» cuando se usa como expresión de condición, por ejemplo, en una sentencia if.
Para solucionarlo, volvimos a confiar en expresiones regulares. Esta vez, utilizamos la función sed del QuickFix para reemplazar globalmente el & de la expresión por &&.
Correcciones disponibles:
- nombre: «Reemplazar el operador AND bit a bit por el operador AND lógico»
acciones:
- reescribir:
a: «{{#sed}} s/&/&&/g, {{{.}}} {{/sed}}»
Notas finales
Esto cubre el uso indebido más común de un operador bit a bit, es decir, cuando realmente se pretendía utilizar un operador booleano.
Hay otras situaciones en las que esto podría surgir, por ejemplo, en el ejemplo de una tarea, pero al escribir recetas debemos intentar evitar la identificación de falsos positivos; de lo contrario, las recetas se ignorarán o se desactivarán. Creamos recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es muy posible que añadamos especificidad adicional a la función de búsqueda para cubrir más condiciones coincidentes.
En su forma actual, esta receta identificaría muchos de los casos de uso actuales, y lo más importante, el que se informó en mi proyecto.
NOTA: Unos pocos guerreros del código contribuyeron a este ejemplo y revisión de recetas: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet y Downey Robersscheuten. Gracias por tu ayuda.
---
Puede instalar Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, buscar «código seguro de sensei»
Tenemos muchos códigos fuente y recetas para estas entradas de blog (incluida esta) en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior.
https://github.com/securecodewarrior/sensei-blog-examples
En esta entrada de blog analizamos un error común de codificación en Java (usar un operador bit a bit en lugar de un operador condicional), el error al que hace que nuestro código sea vulnerable y cómo podemos usar Sensei para corregir y detectar el problema.
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Los errores de Java: operadores bitwise frente a operadores booleanos
> «Java Gotcha»: un patrón de error común que es fácil de implementar accidentalmente.
Un truco de Java bastante simple en el que caer accidentalmente es: usar un operador bit a bit en lugar de un operador de comparación booleano.
Por ejemplo, un simple error de escritura puede resultar en escribir «&» cuando realmente querías escribir «&&».
Una heurística común que aprendemos al revisar el código es:
> «&» o «|» cuando se usan en una declaración condicional probablemente no sean intencionales.
En esta entrada del blog, exploraremos la heurística e identificaremos formas en las que podemos identificar y solucionar este problema de codificación.
¿Cuál es el problema? Las operaciones bit a bit funcionan bien con los valores booleanos
El uso de operadores bit a bit con booleanos es perfectamente válido, por lo que Java no notificará ningún error de sintaxis.
Si construyo una prueba JUnit para explorar una tabla de verdad tanto para Bitwise OR (|) como para Bitwise AND (&), veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. En vista de esto, podríamos pensar que el uso de operadores Bitwise no es un problema.
Y Tabla de la verdad
@Test
void BitwiseOperatorsAndTruthTable () {
Assertions.assertEquals (verdadero, verdadero y verdadero);
Assertions.assertEquals (falso, verdadero y falso);
Assertions.assertEquals (falso, falso y verdadero);
Assertions.assertEquals (falso, falso y falso);
}
La prueba pasa, esto es Java perfectamente válido.
O Tabla de la verdad
@Test
anular BitwiseOperatorSorTruthTable () {
Assertions.assertEquals (verdadero, verdadero | verdadero);
Assertions.assertEquals (verdadero, verdadero | falso);
Assertions.assertEquals (verdadero, falso | verdadero);
Assertions.assertEquals (falso, falso | falso);
}
Esta prueba también pasa, ¿por qué preferimos «&&'y «||'?
Las imágenes de la tabla de verdad se crearon utilizando el herramienta de tabla de la verdad de web.standfor.edu.
Problema: Funcionamiento en cortocircuito
El verdadero problema es la diferencia de comportamiento entre los operadores bitwise (&, |) y booleanos (&&, ||).
Un operador booleano es un operador de cortocircuito y solo evalúa lo necesario.
por ejemplo
si (args! = nulo & args.length () > 23) {
System.out.println (argumentos);
}
En el código anterior, se evaluarán ambas condiciones booleanas, porque se ha utilizado el operador Bitwise:
- argumentos! = nulo
- args.length () > 23
Esto deja mi código abierto a una NullPointerException si args es nulo porque siempre realizaremos la verificación de args.length, incluso cuando args sea nulo porque se deben evaluar ambas condiciones booleanas.
Evaluación de cortocircuitos de operadores booleanos
Cuando se usa un &&, p. ej.
si (args! = nulo && args.length () > 23) {
System.out.println (argumentos);
}
¡En cuanto sepamos que es un argumento! = null se evalúa como falso, la evaluación de la expresión de 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 sucedería en el código de producción
Este es un error bastante fácil de cometer y las herramientas de análisis estático no siempre lo detectan.
Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:
tipo de archivo: java si es «! =nulo &»
Esta búsqueda devolvió un código de Android en el RootWindowContainer
isDocument = intención! = nulo & intent.isDocument ()
Este es el tipo de código que puede pasar una revisión de código, ya que a menudo utilizamos operadores bit a bit en las sentencias de asignación para enmascarar los valores. Pero en este caso, el resultado es el mismo que en el ejemplo anterior de la sentencia if. Si la intención es alguna vez nula, se lanzará una NullPointerException.
Muy a menudo nos salimos con la nuestra con esta construcción porque a menudo codificamos a la defensiva y escribimos código redundante. ¡El cheque para! = null puede resultar redundante en la mayoría de los casos de uso.
Se trata de un error cometido por los programadores en el código de producción.
No sé qué tan actuales son los resultados de la búsqueda, pero cuando la ejecuté, aparecieron resultados con código de: Google, Amazon, Apache... y yo.
Un reciente solicitud de extracción en uno de mis proyectos de código abierto fue solucionar exactamente este error.
si (escriba! =nulo y escribe.trim () .length () >0) {
Aceptar MediaTypeDefinitionsList.add (type.trim ());
}
Cómo encontrar esto
Cuando comprobé mi código de muestra en algunos analizadores estáticos, ninguno de ellos detectó este código oculto de autodestrucción.
Como equipo de Secure Code Warrior, hemos creado y revisado una receta de Sensei bastante sencilla que podría responder a esta pregunta.
Como los operadores Bitwise son perfectamente válidos y se utilizan con frecuencia 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.
buscar:
expresión:
Cualquiera de:
- en:
condición: {}
valor:
Sensible a mayúsculas y minúsculas: falso
coincidencias: «.* & . *»
Esto usa una expresión regular para que coincida con "&» cuando se usa como expresión de condición, por ejemplo, en una sentencia if.
Para solucionarlo, volvimos a confiar en expresiones regulares. Esta vez, utilizamos la función sed del QuickFix para reemplazar globalmente el & de la expresión por &&.
Correcciones disponibles:
- nombre: «Reemplazar el operador AND bit a bit por el operador AND lógico»
acciones:
- reescribir:
a: «{{#sed}} s/&/&&/g, {{{.}}} {{/sed}}»
Notas finales
Esto cubre el uso indebido más común de un operador bit a bit, es decir, cuando realmente se pretendía utilizar un operador booleano.
Hay otras situaciones en las que esto podría surgir, por ejemplo, en el ejemplo de una tarea, pero al escribir recetas debemos intentar evitar la identificación de falsos positivos; de lo contrario, las recetas se ignorarán o se desactivarán. Creamos recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es muy posible que añadamos especificidad adicional a la función de búsqueda para cubrir más condiciones coincidentes.
En su forma actual, esta receta identificaría muchos de los casos de uso actuales, y lo más importante, el que se informó en mi proyecto.
NOTA: Unos pocos guerreros del código contribuyeron a este ejemplo y revisión de recetas: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet y Downey Robersscheuten. Gracias por tu ayuda.
---
Puede instalar Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, buscar «código seguro de sensei»
Tenemos muchos códigos fuente y recetas para estas entradas de blog (incluida esta) en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior.
https://github.com/securecodewarrior/sensei-blog-examples
Los errores de Java: operadores bitwise frente a operadores booleanos
> «Java Gotcha»: un patrón de error común que es fácil de implementar accidentalmente.
Un truco de Java bastante simple en el que caer accidentalmente es: usar un operador bit a bit en lugar de un operador de comparación booleano.
Por ejemplo, un simple error de escritura puede resultar en escribir «&» cuando realmente querías escribir «&&».
Una heurística común que aprendemos al revisar el código es:
> «&» o «|» cuando se usan en una declaración condicional probablemente no sean intencionales.
En esta entrada del blog, exploraremos la heurística e identificaremos formas en las que podemos identificar y solucionar este problema de codificación.
¿Cuál es el problema? Las operaciones bit a bit funcionan bien con los valores booleanos
El uso de operadores bit a bit con booleanos es perfectamente válido, por lo que Java no notificará ningún error de sintaxis.
Si construyo una prueba JUnit para explorar una tabla de verdad tanto para Bitwise OR (|) como para Bitwise AND (&), veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. En vista de esto, podríamos pensar que el uso de operadores Bitwise no es un problema.
Y Tabla de la verdad
@Test
void BitwiseOperatorsAndTruthTable () {
Assertions.assertEquals (verdadero, verdadero y verdadero);
Assertions.assertEquals (falso, verdadero y falso);
Assertions.assertEquals (falso, falso y verdadero);
Assertions.assertEquals (falso, falso y falso);
}
La prueba pasa, esto es Java perfectamente válido.
O Tabla de la verdad
@Test
anular BitwiseOperatorSorTruthTable () {
Assertions.assertEquals (verdadero, verdadero | verdadero);
Assertions.assertEquals (verdadero, verdadero | falso);
Assertions.assertEquals (verdadero, falso | verdadero);
Assertions.assertEquals (falso, falso | falso);
}
Esta prueba también pasa, ¿por qué preferimos «&&'y «||'?
Las imágenes de la tabla de verdad se crearon utilizando el herramienta de tabla de la verdad de web.standfor.edu.
Problema: Funcionamiento en cortocircuito
El verdadero problema es la diferencia de comportamiento entre los operadores bitwise (&, |) y booleanos (&&, ||).
Un operador booleano es un operador de cortocircuito y solo evalúa lo necesario.
por ejemplo
si (args! = nulo & args.length () > 23) {
System.out.println (argumentos);
}
En el código anterior, se evaluarán ambas condiciones booleanas, porque se ha utilizado el operador Bitwise:
- argumentos! = nulo
- args.length () > 23
Esto deja mi código abierto a una NullPointerException si args es nulo porque siempre realizaremos la verificación de args.length, incluso cuando args sea nulo porque se deben evaluar ambas condiciones booleanas.
Evaluación de cortocircuitos de operadores booleanos
Cuando se usa un &&, p. ej.
si (args! = nulo && args.length () > 23) {
System.out.println (argumentos);
}
¡En cuanto sepamos que es un argumento! = null se evalúa como falso, la evaluación de la expresión de 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 sucedería en el código de producción
Este es un error bastante fácil de cometer y las herramientas de análisis estático no siempre lo detectan.
Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:
tipo de archivo: java si es «! =nulo &»
Esta búsqueda devolvió un código de Android en el RootWindowContainer
isDocument = intención! = nulo & intent.isDocument ()
Este es el tipo de código que puede pasar una revisión de código, ya que a menudo utilizamos operadores bit a bit en las sentencias de asignación para enmascarar los valores. Pero en este caso, el resultado es el mismo que en el ejemplo anterior de la sentencia if. Si la intención es alguna vez nula, se lanzará una NullPointerException.
Muy a menudo nos salimos con la nuestra con esta construcción porque a menudo codificamos a la defensiva y escribimos código redundante. ¡El cheque para! = null puede resultar redundante en la mayoría de los casos de uso.
Se trata de un error cometido por los programadores en el código de producción.
No sé qué tan actuales son los resultados de la búsqueda, pero cuando la ejecuté, aparecieron resultados con código de: Google, Amazon, Apache... y yo.
Un reciente solicitud de extracción en uno de mis proyectos de código abierto fue solucionar exactamente este error.
si (escriba! =nulo y escribe.trim () .length () >0) {
Aceptar MediaTypeDefinitionsList.add (type.trim ());
}
Cómo encontrar esto
Cuando comprobé mi código de muestra en algunos analizadores estáticos, ninguno de ellos detectó este código oculto de autodestrucción.
Como equipo de Secure Code Warrior, hemos creado y revisado una receta de Sensei bastante sencilla que podría responder a esta pregunta.
Como los operadores Bitwise son perfectamente válidos y se utilizan con frecuencia 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.
buscar:
expresión:
Cualquiera de:
- en:
condición: {}
valor:
Sensible a mayúsculas y minúsculas: falso
coincidencias: «.* & . *»
Esto usa una expresión regular para que coincida con "&» cuando se usa como expresión de condición, por ejemplo, en una sentencia if.
Para solucionarlo, volvimos a confiar en expresiones regulares. Esta vez, utilizamos la función sed del QuickFix para reemplazar globalmente el & de la expresión por &&.
Correcciones disponibles:
- nombre: «Reemplazar el operador AND bit a bit por el operador AND lógico»
acciones:
- reescribir:
a: «{{#sed}} s/&/&&/g, {{{.}}} {{/sed}}»
Notas finales
Esto cubre el uso indebido más común de un operador bit a bit, es decir, cuando realmente se pretendía utilizar un operador booleano.
Hay otras situaciones en las que esto podría surgir, por ejemplo, en el ejemplo de una tarea, pero al escribir recetas debemos intentar evitar la identificación de falsos positivos; de lo contrario, las recetas se ignorarán o se desactivarán. Creamos recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es muy posible que añadamos especificidad adicional a la función de búsqueda para cubrir más condiciones coincidentes.
En su forma actual, esta receta identificaría muchos de los casos de uso actuales, y lo más importante, el que se informó en mi proyecto.
NOTA: Unos pocos guerreros del código contribuyeron a este ejemplo y revisión de recetas: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet y Downey Robersscheuten. Gracias por tu ayuda.
---
Puede instalar Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, buscar «código seguro de sensei»
Tenemos muchos códigos fuente y recetas para estas entradas de blog (incluida esta) en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior.
https://github.com/securecodewarrior/sensei-blog-examples
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Los errores de Java: operadores bitwise frente a operadores booleanos
> «Java Gotcha»: un patrón de error común que es fácil de implementar accidentalmente.
Un truco de Java bastante simple en el que caer accidentalmente es: usar un operador bit a bit en lugar de un operador de comparación booleano.
Por ejemplo, un simple error de escritura puede resultar en escribir «&» cuando realmente querías escribir «&&».
Una heurística común que aprendemos al revisar el código es:
> «&» o «|» cuando se usan en una declaración condicional probablemente no sean intencionales.
En esta entrada del blog, exploraremos la heurística e identificaremos formas en las que podemos identificar y solucionar este problema de codificación.
¿Cuál es el problema? Las operaciones bit a bit funcionan bien con los valores booleanos
El uso de operadores bit a bit con booleanos es perfectamente válido, por lo que Java no notificará ningún error de sintaxis.
Si construyo una prueba JUnit para explorar una tabla de verdad tanto para Bitwise OR (|) como para Bitwise AND (&), veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. En vista de esto, podríamos pensar que el uso de operadores Bitwise no es un problema.
Y Tabla de la verdad
@Test
void BitwiseOperatorsAndTruthTable () {
Assertions.assertEquals (verdadero, verdadero y verdadero);
Assertions.assertEquals (falso, verdadero y falso);
Assertions.assertEquals (falso, falso y verdadero);
Assertions.assertEquals (falso, falso y falso);
}
La prueba pasa, esto es Java perfectamente válido.
O Tabla de la verdad
@Test
anular BitwiseOperatorSorTruthTable () {
Assertions.assertEquals (verdadero, verdadero | verdadero);
Assertions.assertEquals (verdadero, verdadero | falso);
Assertions.assertEquals (verdadero, falso | verdadero);
Assertions.assertEquals (falso, falso | falso);
}
Esta prueba también pasa, ¿por qué preferimos «&&'y «||'?
Las imágenes de la tabla de verdad se crearon utilizando el herramienta de tabla de la verdad de web.standfor.edu.
Problema: Funcionamiento en cortocircuito
El verdadero problema es la diferencia de comportamiento entre los operadores bitwise (&, |) y booleanos (&&, ||).
Un operador booleano es un operador de cortocircuito y solo evalúa lo necesario.
por ejemplo
si (args! = nulo & args.length () > 23) {
System.out.println (argumentos);
}
En el código anterior, se evaluarán ambas condiciones booleanas, porque se ha utilizado el operador Bitwise:
- argumentos! = nulo
- args.length () > 23
Esto deja mi código abierto a una NullPointerException si args es nulo porque siempre realizaremos la verificación de args.length, incluso cuando args sea nulo porque se deben evaluar ambas condiciones booleanas.
Evaluación de cortocircuitos de operadores booleanos
Cuando se usa un &&, p. ej.
si (args! = nulo && args.length () > 23) {
System.out.println (argumentos);
}
¡En cuanto sepamos que es un argumento! = null se evalúa como falso, la evaluación de la expresión de 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 sucedería en el código de producción
Este es un error bastante fácil de cometer y las herramientas de análisis estático no siempre lo detectan.
Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:
tipo de archivo: java si es «! =nulo &»
Esta búsqueda devolvió un código de Android en el RootWindowContainer
isDocument = intención! = nulo & intent.isDocument ()
Este es el tipo de código que puede pasar una revisión de código, ya que a menudo utilizamos operadores bit a bit en las sentencias de asignación para enmascarar los valores. Pero en este caso, el resultado es el mismo que en el ejemplo anterior de la sentencia if. Si la intención es alguna vez nula, se lanzará una NullPointerException.
Muy a menudo nos salimos con la nuestra con esta construcción porque a menudo codificamos a la defensiva y escribimos código redundante. ¡El cheque para! = null puede resultar redundante en la mayoría de los casos de uso.
Se trata de un error cometido por los programadores en el código de producción.
No sé qué tan actuales son los resultados de la búsqueda, pero cuando la ejecuté, aparecieron resultados con código de: Google, Amazon, Apache... y yo.
Un reciente solicitud de extracción en uno de mis proyectos de código abierto fue solucionar exactamente este error.
si (escriba! =nulo y escribe.trim () .length () >0) {
Aceptar MediaTypeDefinitionsList.add (type.trim ());
}
Cómo encontrar esto
Cuando comprobé mi código de muestra en algunos analizadores estáticos, ninguno de ellos detectó este código oculto de autodestrucción.
Como equipo de Secure Code Warrior, hemos creado y revisado una receta de Sensei bastante sencilla que podría responder a esta pregunta.
Como los operadores Bitwise son perfectamente válidos y se utilizan con frecuencia 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.
buscar:
expresión:
Cualquiera de:
- en:
condición: {}
valor:
Sensible a mayúsculas y minúsculas: falso
coincidencias: «.* & . *»
Esto usa una expresión regular para que coincida con "&» cuando se usa como expresión de condición, por ejemplo, en una sentencia if.
Para solucionarlo, volvimos a confiar en expresiones regulares. Esta vez, utilizamos la función sed del QuickFix para reemplazar globalmente el & de la expresión por &&.
Correcciones disponibles:
- nombre: «Reemplazar el operador AND bit a bit por el operador AND lógico»
acciones:
- reescribir:
a: «{{#sed}} s/&/&&/g, {{{.}}} {{/sed}}»
Notas finales
Esto cubre el uso indebido más común de un operador bit a bit, es decir, cuando realmente se pretendía utilizar un operador booleano.
Hay otras situaciones en las que esto podría surgir, por ejemplo, en el ejemplo de una tarea, pero al escribir recetas debemos intentar evitar la identificación de falsos positivos; de lo contrario, las recetas se ignorarán o se desactivarán. Creamos recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es muy posible que añadamos especificidad adicional a la función de búsqueda para cubrir más condiciones coincidentes.
En su forma actual, esta receta identificaría muchos de los casos de uso actuales, y lo más importante, el que se informó en mi proyecto.
NOTA: Unos pocos guerreros del código contribuyeron a este ejemplo y revisión de recetas: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet y Downey Robersscheuten. Gracias por tu ayuda.
---
Puede instalar Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, buscar «código seguro de sensei»
Tenemos muchos códigos fuente y recetas para estas entradas de blog (incluida esta) en el repositorio `sensei-blog-examples` de la cuenta de GitHub de Secure Code Warrior.
https://github.com/securecodewarrior/sensei-blog-examples
Tabla de contenido
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
