Pièges Java - Opérateurs bit à bit et opérateurs booléens
Pièges Java - Opérateurs bit à bit et opérateurs booléens
« Java Gotcha » - un modèle d'erreur courant qui peut facilement être mis en œuvre de manière inattendue.
Un problème Java relativement simple qui peut survenir de manière inattendue est l'utilisation d'opérateurs bit à bit au lieu d'opérateurs de comparaison booléens.
Par exemple, lorsque vous souhaitez réellement saisir « && », une simple erreur de frappe peut entraîner la saisie de « & ».
Les heuristiques courantes que nous avons apprises lors de la révision du code sont les suivantes :
L'utilisation de « & » ou « | » dans les conditions peut ne pas être intentionnelle.
Dans cet article de blog, nous examinerons les approches heuristiques et déterminerons les méthodes permettant d'identifier et de corriger ce problème de codage.
Quel est le problème ? L'utilisation des opérations booléennes permet d'effectuer correctement les opérations bit à bit.
L'utilisation d'opérateurs bit à bit avec des valeurs booléennes est tout à fait valide, par conséquent Java ne signalera pas d'erreur de syntaxe.
Si je construis un test JUnit pour explorer les tables de vérité des opérateurs bit à bit OU (|) et ET (&), nous constaterons que les résultats des opérateurs bit à bit correspondent aux tables de vérité. Compte tenu de cela, nous pourrions conclure que l'utilisation des opérateurs bit à bit ne pose aucun problème.
ET Tableau des vérités
@Test
void Opérateurs bit à bit et TruthTable () {
assertions.asserteQuals（vrai, vrai et vrai）；
assertions.asserteQuals（faux, vrai et faux）；
assertions.asserteQuals（faux, faux et vrai）；
assertions.asserteQuals（faux, faux et faux）；
}
Le test a été réussi, il s'agit de Java entièrement fonctionnel.
Tableau des vérités
@Test
void Opérateur bit à bit ou table de vérité () {
assertions.asserteQuals（vrai, vrai | vrai）；
assertions.asserteQuals（vrai, vrai | faux）；
assertions.asserteQuals（vrai, faux | vrai）；
assertions.asserteQuals（faux, faux | faux）；
}
Ce test a également été réussi. Pourquoi préférons-nous « && » et « || » ?
Le tableau de vérité est une image créée à l'aide de l'outil de tableau de vérité. outil de tableau de vérité à partir de web.standfor.edu.
Question : Opération de court-circuit
Le véritable problème réside dans la différence de comportement entre les opérateurs bit à bit (&, |) et les opérateurs booléens (&&, ||).
Les opérateurs booléens sont des opérateurs de court-circuit et ne sont évalués que lorsque cela est nécessaire.
Par exemple
if (args!= null & args.length () > 23) {
system.out.println (args);
}
Dans le code ci-dessus, les deux conditions booléennes seront évaluées, car l'opérateur bit à bit est utilisé :
- args ! = valeur nulle
- args.length () > 23
Si args est vide, cela expose mon code à un risque de NullPointerException, car même si le paramètre est vide, nous continuerons à vérifier args.length, car les deux conditions booléennes doivent être évaluées.
Évaluation de court-circuit des opérateurs booléens
Lorsque vous utilisez &&, par exemple
if (args!= null && args.length () > 23) {
system.out.println (args);
}
Dès lors que nous savons que args != null, le résultat du calcul est faux et l'expression conditionnelle cesse d'être évaluée.
Nous n'avons pas besoin d'évaluer la partie droite.
Quelle que soit la valeur de la condition de droite, la valeur finale de l'expression booléenne sera fausse.
Cependant, cela ne se produira jamais dans le code de production.
Il s'agit d'une erreur fréquente, mais les outils d'analyse statique ne la commettent pas systématiquement.
J'ai utilisé Google Dork pour vérifier s'il était possible de trouver des exemples publics de ce modèle :
Type de fichier : java if « !=null & »
Cette recherche a permis de retrouver dans rootwindowContainer du code provenant d'Android
isDocument = intent != null & intent.isDocument ()
Ce code pourrait passer le contrôle de code, car nous utilisons souvent des opérateurs bit à bit dans les instructions d'affectation pour masquer les valeurs. Cependant, dans ce cas, le résultat est identique à celui de l'exemple d'instruction if ci-dessus. Si l'intention est toujours vide, une exception NullPointerException sera levée.
Nous avons tendance à contourner cette structure en recourant fréquemment au codage défensif et en écrivant du code redondant. La vérification « != null » est probablement superflue dans la plupart des cas d'utilisation.
Il s'agit d'une erreur commise par un programmeur dans le code de production.
Je ne sais pas si les résultats de recherche sont récents, mais lorsque j'effectue une recherche, les résultats proviennent de Google, Amazon, Apache... et de moi-même.
La dernière demande de tirage dans l'un de mes projets open source visait précisément à résoudre cette erreur.
if (键入!=null & type.trim () .length () >0) {
AcceptMediatypeDefinitionsList.add (type.trim ());
}
Comment trouver ceci
Lorsque j'ai examiné mon exemple de code dans plusieurs analyseurs statiques, aucun d'entre eux n'a détecté ce code autodestructeur caché.
En tant Secure Code Warrior , nous avons élaboré et examiné une Sensei relativement simple Sensei de résoudre ce problème.
Étant donné que les opérateurs bit à bit sont pleinement efficaces et fréquemment utilisés pour l'affectation, nous avons examiné de manière approfondie les cas d'utilisation des instructions if et l'utilisation de Bitwise & afin d'identifier le code problématique.
搜索:
表情：
AnyOF：
-在：
条件：{}
价值：
区分大小写：假
匹配：“.* &。*”
Lorsqu'il est utilisé comme expression conditionnelle, il utilise une expression régulière pour correspondre à « & ». Par exemple, dans une instruction if.
Pour résoudre ce problème, nous nous appuyons à nouveau sur les expressions régulières. Cette fois-ci, nous utilisons la fonction sed de QuickFix pour remplacer globalement tous les & par && dans l'expression.
Correctif disponible :
- Nom : « Remplacer l'opérateur AND bit à bit par l'opérateur AND logique »
Action :
- Réécriture :
Remplacer par : « {{#sed}} s/&/&&&g,{{{.}}} {{/sed}} »
Note de fin
Ceci couvre les cas les plus courants d'utilisation abusive des opérateurs bit à bit, c'est-à-dire lorsque l'on utilise en réalité des opérateurs booléens.
Dans d'autres cas, cela peut se produire, par exemple dans des exemples de tâches, mais lors de la rédaction de recettes, nous devons éviter autant que possible les faux positifs, sinon les recettes seront ignorées ou désactivées. Nous créons des recettes pour correspondre aux cas les plus courants. À mesure que Sensei évolue, nous ajouterons probablement des spécificités supplémentaires à la fonction de recherche afin de couvrir davantage de conditions de correspondance.
Dans sa forme actuelle, cette formule reconnaîtra de nombreux cas d'utilisation pratiques, et surtoutcelui présenté dans mon projet.
Remarque : plusieurs contributeurs ont apporté leur expertise en matière de code à cet exemple et à la révision de la recette : Charlie Erikson, Matthew Carley, Robin Clairhout, Bryson Axe, Nathan Desmet et Donny Robershoten. Nous vous remercions pour votre aide.
---
Vous pouvez installer Sensei à partir d'IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Sensei «sensei
Dans le référentiel «sensei » du compte Secure Code Warrior de Secure Code Warrior , nous avons rassemblé le code source et les recettes de nombreux articles de blog, y compris celui-ci.
https://github.com/securecodewarrior/sensei-blog-examples
Dans cet article de blog, nous examinerons une erreur courante dans le codage Java (l'utilisation d'opérateurs bit à bit au lieu d'opérateurs conditionnels), les vulnérabilités qu'elle introduit dans notre code et comment utiliser Sensei corriger et détecter ce problème.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Pièges Java - Opérateurs bit à bit et opérateurs booléens
« Java Gotcha » - un modèle d'erreur courant qui peut facilement être mis en œuvre de manière inattendue.
Un problème Java relativement simple qui peut survenir de manière inattendue est l'utilisation d'opérateurs bit à bit au lieu d'opérateurs de comparaison booléens.
Par exemple, lorsque vous souhaitez réellement saisir « && », une simple erreur de frappe peut entraîner la saisie de « & ».
Les heuristiques courantes que nous avons apprises lors de la révision du code sont les suivantes :
L'utilisation de « & » ou « | » dans les conditions peut ne pas être intentionnelle.
Dans cet article de blog, nous examinerons les approches heuristiques et déterminerons les méthodes permettant d'identifier et de corriger ce problème de codage.
Quel est le problème ? L'utilisation des opérations booléennes permet d'effectuer correctement les opérations bit à bit.
L'utilisation d'opérateurs bit à bit avec des valeurs booléennes est tout à fait valide, par conséquent Java ne signalera pas d'erreur de syntaxe.
Si je construis un test JUnit pour explorer les tables de vérité des opérateurs bit à bit OU (|) et ET (&), nous constaterons que les résultats des opérateurs bit à bit correspondent aux tables de vérité. Compte tenu de cela, nous pourrions conclure que l'utilisation des opérateurs bit à bit ne pose aucun problème.
ET Tableau des vérités
@Test
void Opérateurs bit à bit et TruthTable () {
assertions.asserteQuals（vrai, vrai et vrai）；
assertions.asserteQuals（faux, vrai et faux）；
assertions.asserteQuals（faux, faux et vrai）；
assertions.asserteQuals（faux, faux et faux）；
}
Le test a été réussi, il s'agit de Java entièrement fonctionnel.
Tableau des vérités
@Test
void Opérateur bit à bit ou table de vérité () {
assertions.asserteQuals（vrai, vrai | vrai）；
assertions.asserteQuals（vrai, vrai | faux）；
assertions.asserteQuals（vrai, faux | vrai）；
assertions.asserteQuals（faux, faux | faux）；
}
Ce test a également été réussi. Pourquoi préférons-nous « && » et « || » ?
Le tableau de vérité est une image créée à l'aide de l'outil de tableau de vérité. outil de tableau de vérité à partir de web.standfor.edu.
Question : Opération de court-circuit
Le véritable problème réside dans la différence de comportement entre les opérateurs bit à bit (&, |) et les opérateurs booléens (&&, ||).
Les opérateurs booléens sont des opérateurs de court-circuit et ne sont évalués que lorsque cela est nécessaire.
Par exemple
if (args!= null & args.length () > 23) {
system.out.println (args);
}
Dans le code ci-dessus, les deux conditions booléennes seront évaluées, car l'opérateur bit à bit est utilisé :
- args ! = valeur nulle
- args.length () > 23
Si args est vide, cela expose mon code à un risque de NullPointerException, car même si le paramètre est vide, nous continuerons à vérifier args.length, car les deux conditions booléennes doivent être évaluées.
Évaluation de court-circuit des opérateurs booléens
Lorsque vous utilisez &&, par exemple
if (args!= null && args.length () > 23) {
system.out.println (args);
}
Dès lors que nous savons que args != null, le résultat du calcul est faux et l'expression conditionnelle cesse d'être évaluée.
Nous n'avons pas besoin d'évaluer la partie droite.
Quelle que soit la valeur de la condition de droite, la valeur finale de l'expression booléenne sera fausse.
Cependant, cela ne se produira jamais dans le code de production.
Il s'agit d'une erreur fréquente, mais les outils d'analyse statique ne la commettent pas systématiquement.
J'ai utilisé Google Dork pour vérifier s'il était possible de trouver des exemples publics de ce modèle :
Type de fichier : java if « !=null & »
Cette recherche a permis de retrouver dans rootwindowContainer du code provenant d'Android
isDocument = intent != null & intent.isDocument ()
Ce code pourrait passer le contrôle de code, car nous utilisons souvent des opérateurs bit à bit dans les instructions d'affectation pour masquer les valeurs. Cependant, dans ce cas, le résultat est identique à celui de l'exemple d'instruction if ci-dessus. Si l'intention est toujours vide, une exception NullPointerException sera levée.
Nous avons tendance à contourner cette structure en recourant fréquemment au codage défensif et en écrivant du code redondant. La vérification « != null » est probablement superflue dans la plupart des cas d'utilisation.
Il s'agit d'une erreur commise par un programmeur dans le code de production.
Je ne sais pas si les résultats de recherche sont récents, mais lorsque j'effectue une recherche, les résultats proviennent de Google, Amazon, Apache... et de moi-même.
La dernière demande de tirage dans l'un de mes projets open source visait précisément à résoudre cette erreur.
if (键入!=null & type.trim () .length () >0) {
AcceptMediatypeDefinitionsList.add (type.trim ());
}
Comment trouver ceci
Lorsque j'ai examiné mon exemple de code dans plusieurs analyseurs statiques, aucun d'entre eux n'a détecté ce code autodestructeur caché.
En tant Secure Code Warrior , nous avons élaboré et examiné une Sensei relativement simple Sensei de résoudre ce problème.
Étant donné que les opérateurs bit à bit sont pleinement efficaces et fréquemment utilisés pour l'affectation, nous avons examiné de manière approfondie les cas d'utilisation des instructions if et l'utilisation de Bitwise & afin d'identifier le code problématique.
搜索:
表情：
AnyOF：
-在：
条件：{}
价值：
区分大小写：假
匹配：“.* &。*”
Lorsqu'il est utilisé comme expression conditionnelle, il utilise une expression régulière pour correspondre à « & ». Par exemple, dans une instruction if.
Pour résoudre ce problème, nous nous appuyons à nouveau sur les expressions régulières. Cette fois-ci, nous utilisons la fonction sed de QuickFix pour remplacer globalement tous les & par && dans l'expression.
Correctif disponible :
- Nom : « Remplacer l'opérateur AND bit à bit par l'opérateur AND logique »
Action :
- Réécriture :
Remplacer par : « {{#sed}} s/&/&&&g,{{{.}}} {{/sed}} »
Note de fin
Ceci couvre les cas les plus courants d'utilisation abusive des opérateurs bit à bit, c'est-à-dire lorsque l'on utilise en réalité des opérateurs booléens.
Dans d'autres cas, cela peut se produire, par exemple dans des exemples de tâches, mais lors de la rédaction de recettes, nous devons éviter autant que possible les faux positifs, sinon les recettes seront ignorées ou désactivées. Nous créons des recettes pour correspondre aux cas les plus courants. À mesure que Sensei évolue, nous ajouterons probablement des spécificités supplémentaires à la fonction de recherche afin de couvrir davantage de conditions de correspondance.
Dans sa forme actuelle, cette formule reconnaîtra de nombreux cas d'utilisation pratiques, et surtoutcelui présenté dans mon projet.
Remarque : plusieurs contributeurs ont apporté leur expertise en matière de code à cet exemple et à la révision de la recette : Charlie Erikson, Matthew Carley, Robin Clairhout, Bryson Axe, Nathan Desmet et Donny Robershoten. Nous vous remercions pour votre aide.
---
Vous pouvez installer Sensei à partir d'IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Sensei «sensei
Dans le référentiel «sensei » du compte Secure Code Warrior de Secure Code Warrior , nous avons rassemblé le code source et les recettes de nombreux articles de blog, y compris celui-ci.
https://github.com/securecodewarrior/sensei-blog-examples
Pièges Java - Opérateurs bit à bit et opérateurs booléens
« Java Gotcha » - un modèle d'erreur courant qui peut facilement être mis en œuvre de manière inattendue.
Un problème Java relativement simple qui peut survenir de manière inattendue est l'utilisation d'opérateurs bit à bit au lieu d'opérateurs de comparaison booléens.
Par exemple, lorsque vous souhaitez réellement saisir « && », une simple erreur de frappe peut entraîner la saisie de « & ».
Les heuristiques courantes que nous avons apprises lors de la révision du code sont les suivantes :
L'utilisation de « & » ou « | » dans les conditions peut ne pas être intentionnelle.
Dans cet article de blog, nous examinerons les approches heuristiques et déterminerons les méthodes permettant d'identifier et de corriger ce problème de codage.
Quel est le problème ? L'utilisation des opérations booléennes permet d'effectuer correctement les opérations bit à bit.
L'utilisation d'opérateurs bit à bit avec des valeurs booléennes est tout à fait valide, par conséquent Java ne signalera pas d'erreur de syntaxe.
Si je construis un test JUnit pour explorer les tables de vérité des opérateurs bit à bit OU (|) et ET (&), nous constaterons que les résultats des opérateurs bit à bit correspondent aux tables de vérité. Compte tenu de cela, nous pourrions conclure que l'utilisation des opérateurs bit à bit ne pose aucun problème.
ET Tableau des vérités
@Test
void Opérateurs bit à bit et TruthTable () {
assertions.asserteQuals（vrai, vrai et vrai）；
assertions.asserteQuals（faux, vrai et faux）；
assertions.asserteQuals（faux, faux et vrai）；
assertions.asserteQuals（faux, faux et faux）；
}
Le test a été réussi, il s'agit de Java entièrement fonctionnel.
Tableau des vérités
@Test
void Opérateur bit à bit ou table de vérité () {
assertions.asserteQuals（vrai, vrai | vrai）；
assertions.asserteQuals（vrai, vrai | faux）；
assertions.asserteQuals（vrai, faux | vrai）；
assertions.asserteQuals（faux, faux | faux）；
}
Ce test a également été réussi. Pourquoi préférons-nous « && » et « || » ?
Le tableau de vérité est une image créée à l'aide de l'outil de tableau de vérité. outil de tableau de vérité à partir de web.standfor.edu.
Question : Opération de court-circuit
Le véritable problème réside dans la différence de comportement entre les opérateurs bit à bit (&, |) et les opérateurs booléens (&&, ||).
Les opérateurs booléens sont des opérateurs de court-circuit et ne sont évalués que lorsque cela est nécessaire.
Par exemple
if (args!= null & args.length () > 23) {
system.out.println (args);
}
Dans le code ci-dessus, les deux conditions booléennes seront évaluées, car l'opérateur bit à bit est utilisé :
- args ! = valeur nulle
- args.length () > 23
Si args est vide, cela expose mon code à un risque de NullPointerException, car même si le paramètre est vide, nous continuerons à vérifier args.length, car les deux conditions booléennes doivent être évaluées.
Évaluation de court-circuit des opérateurs booléens
Lorsque vous utilisez &&, par exemple
if (args!= null && args.length () > 23) {
system.out.println (args);
}
Dès lors que nous savons que args != null, le résultat du calcul est faux et l'expression conditionnelle cesse d'être évaluée.
Nous n'avons pas besoin d'évaluer la partie droite.
Quelle que soit la valeur de la condition de droite, la valeur finale de l'expression booléenne sera fausse.
Cependant, cela ne se produira jamais dans le code de production.
Il s'agit d'une erreur fréquente, mais les outils d'analyse statique ne la commettent pas systématiquement.
J'ai utilisé Google Dork pour vérifier s'il était possible de trouver des exemples publics de ce modèle :
Type de fichier : java if « !=null & »
Cette recherche a permis de retrouver dans rootwindowContainer du code provenant d'Android
isDocument = intent != null & intent.isDocument ()
Ce code pourrait passer le contrôle de code, car nous utilisons souvent des opérateurs bit à bit dans les instructions d'affectation pour masquer les valeurs. Cependant, dans ce cas, le résultat est identique à celui de l'exemple d'instruction if ci-dessus. Si l'intention est toujours vide, une exception NullPointerException sera levée.
Nous avons tendance à contourner cette structure en recourant fréquemment au codage défensif et en écrivant du code redondant. La vérification « != null » est probablement superflue dans la plupart des cas d'utilisation.
Il s'agit d'une erreur commise par un programmeur dans le code de production.
Je ne sais pas si les résultats de recherche sont récents, mais lorsque j'effectue une recherche, les résultats proviennent de Google, Amazon, Apache... et de moi-même.
La dernière demande de tirage dans l'un de mes projets open source visait précisément à résoudre cette erreur.
if (键入!=null & type.trim () .length () >0) {
AcceptMediatypeDefinitionsList.add (type.trim ());
}
Comment trouver ceci
Lorsque j'ai examiné mon exemple de code dans plusieurs analyseurs statiques, aucun d'entre eux n'a détecté ce code autodestructeur caché.
En tant Secure Code Warrior , nous avons élaboré et examiné une Sensei relativement simple Sensei de résoudre ce problème.
Étant donné que les opérateurs bit à bit sont pleinement efficaces et fréquemment utilisés pour l'affectation, nous avons examiné de manière approfondie les cas d'utilisation des instructions if et l'utilisation de Bitwise & afin d'identifier le code problématique.
搜索:
表情：
AnyOF：
-在：
条件：{}
价值：
区分大小写：假
匹配：“.* &。*”
Lorsqu'il est utilisé comme expression conditionnelle, il utilise une expression régulière pour correspondre à « & ». Par exemple, dans une instruction if.
Pour résoudre ce problème, nous nous appuyons à nouveau sur les expressions régulières. Cette fois-ci, nous utilisons la fonction sed de QuickFix pour remplacer globalement tous les & par && dans l'expression.
Correctif disponible :
- Nom : « Remplacer l'opérateur AND bit à bit par l'opérateur AND logique »
Action :
- Réécriture :
Remplacer par : « {{#sed}} s/&/&&&g,{{{.}}} {{/sed}} »
Note de fin
Ceci couvre les cas les plus courants d'utilisation abusive des opérateurs bit à bit, c'est-à-dire lorsque l'on utilise en réalité des opérateurs booléens.
Dans d'autres cas, cela peut se produire, par exemple dans des exemples de tâches, mais lors de la rédaction de recettes, nous devons éviter autant que possible les faux positifs, sinon les recettes seront ignorées ou désactivées. Nous créons des recettes pour correspondre aux cas les plus courants. À mesure que Sensei évolue, nous ajouterons probablement des spécificités supplémentaires à la fonction de recherche afin de couvrir davantage de conditions de correspondance.
Dans sa forme actuelle, cette formule reconnaîtra de nombreux cas d'utilisation pratiques, et surtoutcelui présenté dans mon projet.
Remarque : plusieurs contributeurs ont apporté leur expertise en matière de code à cet exemple et à la révision de la recette : Charlie Erikson, Matthew Carley, Robin Clairhout, Bryson Axe, Nathan Desmet et Donny Robershoten. Nous vous remercions pour votre aide.
---
Vous pouvez installer Sensei à partir d'IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Sensei «sensei
Dans le référentiel «sensei » du compte Secure Code Warrior de Secure Code Warrior , nous avons rassemblé le code source et les recettes de nombreux articles de blog, y compris celui-ci.
https://github.com/securecodewarrior/sensei-blog-examples
Veuillez cliquer sur le lien ci-dessous pour télécharger le PDF de cette ressource.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez consulter le rapport.Veuillez réserver une démonstration.
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Pièges Java - Opérateurs bit à bit et opérateurs booléens
« Java Gotcha » - un modèle d'erreur courant qui peut facilement être mis en œuvre de manière inattendue.
Un problème Java relativement simple qui peut survenir de manière inattendue est l'utilisation d'opérateurs bit à bit au lieu d'opérateurs de comparaison booléens.
Par exemple, lorsque vous souhaitez réellement saisir « && », une simple erreur de frappe peut entraîner la saisie de « & ».
Les heuristiques courantes que nous avons apprises lors de la révision du code sont les suivantes :
L'utilisation de « & » ou « | » dans les conditions peut ne pas être intentionnelle.
Dans cet article de blog, nous examinerons les approches heuristiques et déterminerons les méthodes permettant d'identifier et de corriger ce problème de codage.
Quel est le problème ? L'utilisation des opérations booléennes permet d'effectuer correctement les opérations bit à bit.
L'utilisation d'opérateurs bit à bit avec des valeurs booléennes est tout à fait valide, par conséquent Java ne signalera pas d'erreur de syntaxe.
Si je construis un test JUnit pour explorer les tables de vérité des opérateurs bit à bit OU (|) et ET (&), nous constaterons que les résultats des opérateurs bit à bit correspondent aux tables de vérité. Compte tenu de cela, nous pourrions conclure que l'utilisation des opérateurs bit à bit ne pose aucun problème.
ET Tableau des vérités
@Test
void Opérateurs bit à bit et TruthTable () {
assertions.asserteQuals（vrai, vrai et vrai）；
assertions.asserteQuals（faux, vrai et faux）；
assertions.asserteQuals（faux, faux et vrai）；
assertions.asserteQuals（faux, faux et faux）；
}
Le test a été réussi, il s'agit de Java entièrement fonctionnel.
Tableau des vérités
@Test
void Opérateur bit à bit ou table de vérité () {
assertions.asserteQuals（vrai, vrai | vrai）；
assertions.asserteQuals（vrai, vrai | faux）；
assertions.asserteQuals（vrai, faux | vrai）；
assertions.asserteQuals（faux, faux | faux）；
}
Ce test a également été réussi. Pourquoi préférons-nous « && » et « || » ?
Le tableau de vérité est une image créée à l'aide de l'outil de tableau de vérité. outil de tableau de vérité à partir de web.standfor.edu.
Question : Opération de court-circuit
Le véritable problème réside dans la différence de comportement entre les opérateurs bit à bit (&, |) et les opérateurs booléens (&&, ||).
Les opérateurs booléens sont des opérateurs de court-circuit et ne sont évalués que lorsque cela est nécessaire.
Par exemple
if (args!= null & args.length () > 23) {
system.out.println (args);
}
Dans le code ci-dessus, les deux conditions booléennes seront évaluées, car l'opérateur bit à bit est utilisé :
- args ! = valeur nulle
- args.length () > 23
Si args est vide, cela expose mon code à un risque de NullPointerException, car même si le paramètre est vide, nous continuerons à vérifier args.length, car les deux conditions booléennes doivent être évaluées.
Évaluation de court-circuit des opérateurs booléens
Lorsque vous utilisez &&, par exemple
if (args!= null && args.length () > 23) {
system.out.println (args);
}
Dès lors que nous savons que args != null, le résultat du calcul est faux et l'expression conditionnelle cesse d'être évaluée.
Nous n'avons pas besoin d'évaluer la partie droite.
Quelle que soit la valeur de la condition de droite, la valeur finale de l'expression booléenne sera fausse.
Cependant, cela ne se produira jamais dans le code de production.
Il s'agit d'une erreur fréquente, mais les outils d'analyse statique ne la commettent pas systématiquement.
J'ai utilisé Google Dork pour vérifier s'il était possible de trouver des exemples publics de ce modèle :
Type de fichier : java if « !=null & »
Cette recherche a permis de retrouver dans rootwindowContainer du code provenant d'Android
isDocument = intent != null & intent.isDocument ()
Ce code pourrait passer le contrôle de code, car nous utilisons souvent des opérateurs bit à bit dans les instructions d'affectation pour masquer les valeurs. Cependant, dans ce cas, le résultat est identique à celui de l'exemple d'instruction if ci-dessus. Si l'intention est toujours vide, une exception NullPointerException sera levée.
Nous avons tendance à contourner cette structure en recourant fréquemment au codage défensif et en écrivant du code redondant. La vérification « != null » est probablement superflue dans la plupart des cas d'utilisation.
Il s'agit d'une erreur commise par un programmeur dans le code de production.
Je ne sais pas si les résultats de recherche sont récents, mais lorsque j'effectue une recherche, les résultats proviennent de Google, Amazon, Apache... et de moi-même.
La dernière demande de tirage dans l'un de mes projets open source visait précisément à résoudre cette erreur.
if (键入!=null & type.trim () .length () >0) {
AcceptMediatypeDefinitionsList.add (type.trim ());
}
Comment trouver ceci
Lorsque j'ai examiné mon exemple de code dans plusieurs analyseurs statiques, aucun d'entre eux n'a détecté ce code autodestructeur caché.
En tant Secure Code Warrior , nous avons élaboré et examiné une Sensei relativement simple Sensei de résoudre ce problème.
Étant donné que les opérateurs bit à bit sont pleinement efficaces et fréquemment utilisés pour l'affectation, nous avons examiné de manière approfondie les cas d'utilisation des instructions if et l'utilisation de Bitwise & afin d'identifier le code problématique.
搜索:
表情：
AnyOF：
-在：
条件：{}
价值：
区分大小写：假
匹配：“.* &。*”
Lorsqu'il est utilisé comme expression conditionnelle, il utilise une expression régulière pour correspondre à « & ». Par exemple, dans une instruction if.
Pour résoudre ce problème, nous nous appuyons à nouveau sur les expressions régulières. Cette fois-ci, nous utilisons la fonction sed de QuickFix pour remplacer globalement tous les & par && dans l'expression.
Correctif disponible :
- Nom : « Remplacer l'opérateur AND bit à bit par l'opérateur AND logique »
Action :
- Réécriture :
Remplacer par : « {{#sed}} s/&/&&&g,{{{.}}} {{/sed}} »
Note de fin
Ceci couvre les cas les plus courants d'utilisation abusive des opérateurs bit à bit, c'est-à-dire lorsque l'on utilise en réalité des opérateurs booléens.
Dans d'autres cas, cela peut se produire, par exemple dans des exemples de tâches, mais lors de la rédaction de recettes, nous devons éviter autant que possible les faux positifs, sinon les recettes seront ignorées ou désactivées. Nous créons des recettes pour correspondre aux cas les plus courants. À mesure que Sensei évolue, nous ajouterons probablement des spécificités supplémentaires à la fonction de recherche afin de couvrir davantage de conditions de correspondance.
Dans sa forme actuelle, cette formule reconnaîtra de nombreux cas d'utilisation pratiques, et surtoutcelui présenté dans mon projet.
Remarque : plusieurs contributeurs ont apporté leur expertise en matière de code à cet exemple et à la révision de la recette : Charlie Erikson, Matthew Carley, Robin Clairhout, Bryson Axe, Nathan Desmet et Donny Robershoten. Nous vous remercions pour votre aide.
---
Vous pouvez installer Sensei à partir d'IntelliJ en utilisant « Préférences\Plugins » (Mac) ou « Paramètres\Plugins » (Windows), Sensei «sensei
Dans le référentiel «sensei » du compte Secure Code Warrior de Secure Code Warrior , nous avons rassemblé le code source et les recettes de nombreux articles de blog, y compris celui-ci.
https://github.com/securecodewarrior/sensei-blog-examples
Table des matières
Alan Richardson a plus de vingt ans d'expérience professionnelle dans le domaine des technologies de l'information. Il a travaillé en tant que développeur et à tous les niveaux de la hiérarchie des tests, du testeur au responsable des tests. Responsable des relations avec les développeurs à l'adresse Secure Code Warrior, il travaille directement avec les équipes pour améliorer le développement de codes sécurisés de qualité. Alan est l'auteur de quatre livres, dont "Dear Evil Tester" et "Java For Testers". Alan a également créé une formation en ligne courses pour aider les gens à apprendre les tests techniques sur le Web et Selenium WebDriver avec Java. Alan publie ses écrits et ses vidéos de formation sur SeleniumSimplified.com, EvilTester.com, JavaForTesters.com et CompendiumDev.co.uk.
Secure Code Warrior peut aider votre organisation à sécuriser le code tout au long du cycle de vie du développement logiciel et à instaurer une culture qui accorde la priorité à la cybersécurité. Que vous soyez responsable de la sécurité des applications, développeur, directeur de la sécurité de l'information ou tout autre professionnel concerné par la sécurité, nous pouvons aider votre organisation à réduire les risques liés au code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Formation sur les codes de sécurité : thèmes et contenu
Notre contenu de pointe évolue constamment pour s'adapter au paysage changeant du développement logiciel, tout en tenant compte de votre rôle. Les sujets abordés couvrent tout, de l'IA à l'injection XQuery, et s'adressent à divers postes, des architectes et ingénieurs aux chefs de produit et responsables de l'assurance qualité. Découvrez un aperçu par thème et par rôle de ce que notre catalogue de contenu a à offrir.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : la mission AI pour vaincre le boss est désormais disponible sur demande.
Cybermon 2025 : la campagne « Vaincre le boss » est désormais disponible toute l'année dans SCW. La guerre de sécurité avancée de l'IA/LLM tribale, le renforcement de l'IA de sécurité à grande échelle.
Interprétation de la loi sur la résilience des réseaux : que signifie la sécurité par le biais de la conception et du développement de logiciels ?
Comprenez les exigences de la loi européenne sur la résilience des réseaux (CRA), à qui elle s'applique et comment les équipes d'ingénierie peuvent s'y préparer grâce à des pratiques de conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facteur déterminant 1 : des critères de réussite clairs et mesurables
Le catalyseur n° 1 constitue le premier volet de notre série en dix parties consacrée aux facteurs de réussite. Il démontre comment relier la sécurité du code aux résultats opérationnels, tels que la réduction des risques et l'accélération de la maturité des programmes à long terme.
