자바 함정 - 비트 연산자 또는 부울 연산자

« Java Gotcha » - 실수로 구현하기 쉬운 일반적인 오류 패턴.

자바에서 실수로 빠지기 쉬운 함정 중 하나는 다음과 같습니다: 부울 비교 연산자 대신 비트 연산자를 사용하는 것입니다.

예를 들어, 단순한 입력 오류로 인해 실제로 "&&"를 입력하려던 의도와 달리 "&"가 기록될 수 있습니다.

코드 검토 시 배우는 일반적인 휴리스틱은 다음과 같습니다:

조건문에서 사용된 « & » 또는 « | »는 아마도 의도된 것이 아닐 것입니다.

이 블로그 글에서는 휴리스틱을 탐구하고, 이 코딩 문제를 식별하고 해결하는 방법을 알아보겠습니다.

문제가 무엇인가요? 비트 단위 연산은 부울 값과 함께 정상적으로 작동합니다.

부울 값에 비트 연산자를 사용하는 것은 완전히 유효합니다. 따라서 Java는 구문 오류를 발생시키지 않습니다.

비트 연산자(Bitwise OR(|) 및 비트 연산자(Bitwise AND(&))에 대한 진리값 표를 각각 탐색하기 위해 JUnit 테스트를 작성하면, 비트 연산자의 출력이 진리값 표와 일치함을 확인할 수 있습니다. 이를 고려할 때 비트 연산자 사용이 문제가 되지 않는다고 생각할 수 있습니다.

ET 진리표

@Test
annulez BitwiseOperatorsAndTruthTable () {
assertions.assertEquals (vrai, vrai et vrai) ;
Assertions.assertEquals (faux, vrai et faux) ;
Assertions.assertEquals (faux, faux et vrai) ;
Assertions.assertEquals (faux, faux et faux) ;
}

테스트는 성공했습니다. 이는 완벽하게 유효한 자바 코드입니다.

또는 진실 표

@Test
annulez BitwiseOperatorsorTruthTable () {
assertions.assertEquals (vrai, vrai | vrai) ;
Assertions.assertEquals (vrai, vrai | faux) ;
Assertions.assertEquals (vrai, faux | vrai) ;
Assertions.assertEquals (faux, faux | faux) ;
}

이 테스트도 통과합니다. 그런데 왜 '&&'와 '||'를 선호할까요?

진리표 도구는 진리표 생성 도구 를 사용하여 생성되었습니다. web.standfor.edu에서 제공되는

문제: 단락 상태에서의 작동

진정한 문제는 비트 연산자(&, |)와 부울 연산자(&&, ||) 간의 동작 차이입니다.

부울 연산자는 필요한 부분만 평가하는 단락 평가 연산자입니다.

예를 들어

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

위의 코드에서 비트 연산자가 사용되었기 때문에 두 부울 조건이 모두 평가됩니다:

• 쓰레기! = 쓸모없음
• args.length() > 23

이 코드는 args가 null일 경우 NullPointerException이 발생할 수 있습니다. args가 null인 경우에도 args.length 검사를 수행하기 때문입니다. 두 개의 부울 조건이 모두 평가되어야 하기 때문입니다.

부울 연산자에 의한 단락 회로 평가

&&가 사용될 때, 예를 들어

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

이를 알게 되는 즉시, Args! = null은 조건 표현식 평가가 중단될 때 False 값을 반환합니다.

우리가 오른쪽을 평가할 필요는 없습니다.

오른쪽 조건의 결과가 무엇이든, 부울 표현식의 최종 값은 거짓이 될 것이다.

그러나 이는 생산 코드에서는 절대 발생하지 않을 것입니다.

이는 상당히 쉽게 저지를 수 있는 오류이며 정적 분석 도구로 항상 탐지되는 것은 아닙니다.

다음과 같은 Google Dork를 사용하여 이 모델의 공개된 예시를 찾을 수 있는지 확인했습니다:

파일 유형: java 시 « ! =null & »
이 검색으로 RootWindowContainer에서 Android 코드를 복구했습니다
IsDocument = intention ! = null 및 Intent.isDocument ()

이 코드는 코드 리뷰를 통과할 수 있는 유형입니다. 값을 숨기기 위해 할당 문에서 비트 연산자를 자주 사용하기 때문입니다. 하지만 이 경우 결과는 위 if 문 예제와 동일합니다. 의도가 null이라면 NullPointerException 예외가 발생합니다.

매우 자주, 우리는 방어적으로 코딩하고 중복 코드를 작성하기 때문에 이 구조로 넘어가는 경우가 많습니다. 대부분의 사용 사례에서 ! = null 검사는 중복일 수 있습니다.

이는 프로그래머들이 생산 코드에서 저지른 오류입니다.

검색 결과가 최신 상태인지는 모르겠지만, 제가 실행했을 때는 Google, Amazon, Apache... 그리고 제 코드가 포함된 결과가 반환되었습니다.

최근 제 오픈소스 프로젝트 중 하나에 대한 추출 요청은 정확히 이 오류를 수정하기 위한 것이었습니다.

si (tapez ! =null et tapez .trim () .length () >0) {
AcceptMediaTypeDefinitionsList.add (type.trim ()) ;
}

어떻게 찾을 수 있나요?

몇 가지 정적 분석기에서 내 코드 예제를 확인했을 때, 그중 어느 것도 이 숨겨진 자가 파괴 코드를 감지하지 못했습니다.

Secure Code Warrior 팀으로서, 우리는 이 문제에 대응할 수 있는 Sensei 간단한 Sensei 레시피를 작성하고 검토했습니다.

비트 연산자는 완벽히 유효하며 할당문에서 자주 사용되므로, 우리는 if 문 사용 사례와 비트wise & 연산자 활용에 집중하여 문제 코드를 찾아냈습니다.

recherche :
expression :
N'importe lequel des :
- dans :
état : {}
valeur :
CaseSensitive : faux
correspond à : « .* » et . * »

이것은 조건식(예: if 문)으로 사용될 때 '&'에 일치하도록 정규 표현식을 사용합니다.

이 문제를 해결하기 위해 우리는 다시 정규 표현식을 활용했습니다. 이번에는 QuickFix의 sed 기능을 사용하여 표현식 내의 &를 &&로 일괄 교체하십시오.

Correctifs disponibles :
- nom : « Remplacer l'opérateur AND au niveau du bit par l'opérateur ET logique »
actions :
- réécrire :
à : « {{#sed}} s/&/&&/g, {{{.}}} {{/sed}} »

후기

이는 비트 연산자의 가장 흔한 오용 사례를 다루며, 즉 실제로 부울 연산자가 의도된 경우를 의미합니다.

다른 상황에서는, 예를 들어 할당 예시에서 발생할 수 있지만, 레시피 작성 시에는 오탐지(false positive)를 피해야 합니다. 그렇지 않으면 레시피가 무시되거나 비활성화될 수 있습니다. 우리는 가장 일반적인 이벤트에 해당하는 레시피를 개발합니다. Sensei 발전함에 따라 검색 기능에 추가적인 특이성을 부여하여 더 많은 조건을 포괄할 수 있도록 할 수 있습니다.

현재 형태로 이 레시피는 수많은 기존 사용 사례를 식별할 수 있으며, 가장 중요한 것은 제 프로젝트에서 보고된 사례입니다.

참고: 이 예시와 레시피 검토에는 다수의 코드 전문가들이 기여했습니다: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. 도움 주셔서 감사합니다.

---

Sensei 설치하려면 Mac의 경우 "환경설정 \ 플러그인", Windows의 경우 "설정 \ 플러그인"으로 이동한 후 "Sensei Code"를 검색하세요.

Secure Code Warrior GitHub 계정의sensei 저장소에는 이 블로그 글(본문 포함)을 위한 많은 소스 코드와 레시피가 있습니다.

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

Sensei 대해 더 알아보기