OWASP API 상위 10위권의 대부분의 취약점과 달리 부적절한 자산 관리는 코딩 결함에 특별히 중심을 두지 않습니다. 대신 이 취약점은 더 새롭고 안전한 버전으로 대체되어야 하는 오래된 API를 오래 동안 제자리에 유지할 수 있는 인간 또는 관리 문제에 가까울 수 있습니다. 또한 아직 개발 중인 API가 위협에 완전히 강화되기 전에 프로덕션 환경에 노출되는 경우에도 발생할 수 있습니다.

이 취약점은 마이크로 서비스 및 클라우드 컴퓨팅의 출현으로 인해 관리하기가 특히 어렵습니다. 이러한 환경에서는 일시적인 필요를 충족시키기 위해 새로운 서비스가 신속하게 스폰된 다음 잊어버렸고 결코 폐기되지 않을 수 있습니다. 이전 API가 프로덕션 환경에 연결되어 있으면 전체 네트워크를 위험에 빠뜨릴 수 있습니다.

이 보안 버그에 게임 챌린지를 시도하고 싶으신가요? 경기장으로 들어오세요: [여기에서 시작]

부적절한 자산 관리 결함이 API에 어떤 영향을 미칩니까?

부적절한 자산 관리 결함은 현대의 산물입니다. 비즈니스 속도로 이동하는 조직은 때때로 매일 수백 또는 수천 개의 서비스와 마이크로 서비스를 스핀업할 수 있습니다. 이 작업은 종종 수반되는 문서를 작성하거나 관련 API가 사용되는 것, 필요한 기간 또는 그 중요도에 대한 설명 없이 신속하게 수행됩니다. 이렇게 하면 시간이 지남에 따라 길들여질 수 없는 API 스프롤이 생성될 수 있으며, 특히 API가 얼마나 오래 존재할 수 있는지 를 정의하는 담요 정책이 없는 경우 더욱 그렇다.

이러한 환경에서일부 API가 손실되거나 잊혀지거나 폐기되지 않을 가능성이 큽분입니다.

정상적인 프로세스 이외의 새로운 서비스를 만들 수 있는 권한이 있는 사용자도 때때로 비난할 수 있습니다. 예를 들어 마케팅 그룹은 제품 출시와 같은 예정된 이벤트를 지원하는 데 도움이 되는 서비스를 만든 다음 이벤트가 완료된 후에는 다시 중단하지 않을 수 있습니다. 나중에 해당 서비스와 관련 API를 보는 사람은 왜 존재하는지 전혀 알지 못할 수 있으며 문서가 없으면 수수께끼로 남을 수 있습니다. 그들은 생산 환경에서 이러한 API를 제거하거나 그들이 얼마나 중요한지 또는 무엇을 하는지 전혀 알지 못하기 때문에 더 새로운 버전으로 업그레이드하는 것이 불편할 수 있습니다.

프레임워크의 API 보안이 시간이 지남에 따라 향상되므로 취약점이 위험해집니다. 연구원은 취약점을 발견하거나 점점 더 인기 있는 유형의 공격을 막기 위해 추가 보안을 추가할 수 있습니다. 이전 API는 업그레이드하지 않는 한 이러한 공격에 취약할 수 있으므로 해커는 종종 해당 API를 검색하거나 자동화된 도구를 사용하여 이를 검색합니다.

OWASP에서 제공하는 실제 예제에서 회사는 중요한 결함을 패치하기 위해 사용자 데이터베이스를 검색하는 데 사용되는 API를 업그레이드했습니다. 그러나 그들은 실수로 기존의 API를 제자리에 두드했습니다.

공격자는 새 API의 위치가 api.criticalservice.com/v2)와 같다는 것을 발견했습니다. URL을 (api.criticalservice.com/v1)로 대체하여 이전 API를 알려진 취약점으로 사용할 수 있었습니다. 이것은 궁극적으로 1 억 명 이상의 사용자의 개인 기록을 노출.

부적절한 자산 관리 결함 제거

사용자 환경에서 부적절한 자산 관리 결함을 제거하는 유일한 방법은 모든 API, 사용 및 버전에 대한 엄격한 인벤토리를 유지하는 것입니다. 이는 기존 API의 인벤토리로 시작하여 프로덕션 또는 개발과 같이 배포해야 하는 환경, 네트워크에 액세스할 수 있어야 하는 사용자 및 버전과 같은 요인에 중점을 두어야 합니다.

완료되면 작성된 새 API 또는 서비스에 문서가 자동으로 추가되는 프로세스를 구현해야 합니다. 여기에는 속도 제한, 요청 및 응답 처리 방법, 연결할 수 있는 엔드포인트, 적용되는 관련 정책, 나중에 감사하는 데 필요한 기타 모든 것을 포함하여 API의 모든 측면이 포함되어야 합니다. 또한 비생산 API 또는 프로덕션 환경에서 개발 환경의 API를 사용하지 않아야 합니다. 또한 자동 폐기를 방지하기 위해 소유자가 계속 사용해야 하는 API에 시간 제한을 추가하는 것도 고려해 보십시오.

활성 API의 새 버전을 사용할 수 있게 될 때마다 위험을 수행하십시오. assessment 업그레이드해야 하는지, 생산 환경의 방해를 피하기 위해 해당 프로세스가 어떻게 수행되어야 하는지 확인합니다. 새 API로 마이그레이션한 후 이전 API를 환경에서 완전히 제거합니다.

이러한 모든 작업을 수행하면 부적절한 자산 관리 취약점이 조직, 사용자 또는 네트워크에 해를 끼치지 않도록 할 수 있습니다. 체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

‍

이전 블로그 게시물은 자바 고차 "비트 와이즈 대 부울 연산자"를 설명했다.

• 자바 고차스 - 비트 와이즈 대 부울 연산자

우리는이의 변형을 추가하고, 다른 자바 고타스는 "도전 "도전이라는 재미있는 작은 퀴즈에 추가 Sensei ".

• scw.typeform.com/to/rgw7q7OE

위의 블로그 게시물을 읽으셨다면 적어도 하나의 질문을 에이스로 할 수 있는 좋은 위치에 있을 것입니다.

그러나 친구가하지 않을 수도 있으므로 퀴즈 재미를 발견하면 그들과 공유하고 점수가 있는지 확인할 수 있습니다.

우리는 단지 당신을 퀴즈하고 싶지 않기 때문에. 우리는 지식을 교육하고 명문화하는 데 도움이 되는 데 사용하려고 합니다. 따라서 문제에 대한 실행 가능한 코드 예제와 솔루션이 있는 Github 리포지토리를 만들었습니다.

• github.com/SecureCodeWarrior/challenge-the- sensei

이것은 Sensei 활성화된 리포지토리.

리포지토리를 복제하여 IntelliJ에 로드할 때 Secure Code Warrior Sensei IntelliJ 플러그인 설치, 다음 자동으로 당신이 가지고 있음을 볼 수 있습니다 . sensei 폴더를 로드하고 Sensei 조리법.

IDE에서 코드를 탐색할 때 IntelliJ가 코드에 오류가 있음을 알리는 메시지가 표시되며 코드에서 gotcha를 쉽게 볼 수 있습니다.

• 강조 표시된 코드 위로 마우스를 가져가면 오류에 대해 알리는 프롬프트가 표시됩니다.
• 컨텍스트 작업 표시 키 사용: alt+enter(Windows) 옵션+입력(macOS) 코드를 수정할 수 있는 QuickFix를 사용할 수 있습니다.

Sensei 조리법은 다음을 위해 추가되었습니다.

• 비트 와이즈 연산자
• 분할 IP 주소
• 어설션 순서

우리는 미래에 코드의 나머지 부분을 커버하기 위해 더 많은 조리법과 더 설명 텍스트를 추가하고 있습니다 ... 그러나 코드를 살펴보고 오류를 직접 발견하지 못하게하십시오.

그리고 퀴즈를 시도하고 기억 "도전 Sensei "

자바 고차스 - 비트 와이즈 대 부울 연산자

> "자바 고차"- 실수로 구현하기 쉬운 일반적인 실수 패턴.

부울 비교 연산자 대신 Bitwise 연산자 사용: 실수로 빠지게 되는 매우 간단한 Java Gotcha.

예를 들어 간단한 오용은 "&"를 실제로 쓰려는 의미일 때 "&"를 작성하게 될 수 있습니다.

코드를 검토할 때 학습하는 일반적인 추론은 다음과 입니다.

조건부 문에 사용될 때 "&" 또는 "|"> 의도되지 않았을 것입니다.

이 블로그 게시물에서는 추론을 탐구하고 이 코딩 문제를 식별하고 해결할 수 있는 방법을 식별합니다.

문제가 뭔가요? Bitwise 작업은 부울과 잘 작동합니다.

Booleans와 Bitwise 연산자 사용이 완벽하게 유효하므로 Java는 구문 오류를 보고하지 않습니다.

Bitwise OR (|)과 Bitwise AND (&)에 대한 진실 테이블을 탐색하기 위해 JUnit 테스트를 구성하면 Bitwise 운영자의 출력이 진실 표와 일치하는 것을 볼 수 있습니다. 이를 감안할 때 Bitwise 운영자의 사용은 문제가 아니라고 생각할 수 있습니다.

그리고 진실 테이블

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

테스트가 통과, 이것은 완벽하게 유효한 자바입니다.

또는 진실 표

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

이 테스트는 또한 통과, 왜 우리는 선호합니까 "&'와 "||"?

진실 테이블 이미지는 web.standfor.edu 진실 테이블 도구를 사용하여 만들어졌습니다.

문제: 단락 작동

진짜 문제는 Bitwise (&, |)와 부울 (&, ||) 운영자 사이의 행동의 차이입니다.

부울 연산자는 단락 연산자이며 필요한 만큼만 평가합니다.

예를 들어.

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

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

• 아르그 != null
• args.length () > 23

이것은 args가 항상 args.length에 대한 검사를 수행하기 때문에 nullPointerException에 내 코드를 열어 둡니다.

부울 연산자 단락 평가

예를 들어 & 사용시

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

args!= null이 조건 표현식 평가가 중지되는 것을 잘못 평가한다는 것을 알자마자.

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

오른쪽 조건의 결과가 어떻든 간에 부울 표현의 최종 값은 거짓입니다.

그러나 프로덕션 코드에서는 이런 일이 일어나지 않을 것입니다.

이것은 매우 쉬운 실수이며 항상 정적 분석 도구에 의해 포착되지는 않습니다.

나는이 패턴의 공개 예를 찾을 수 있는지 확인하기 위해 다음과 같은 Google Dork를 사용했습니다.

파일 유형:자바 경우 "!=null & "
이 검색은 루트윈도우 컨테이너에서 안드로이드에서 일부 코드를 다시 가져
isDocument = 의도!= null 및 의도.isDocument()

할당 문에서 Bitwise 연산자(Bitwise operators)를 사용하여 값을 마스크하기 때문에 코드 검토를 전달할 수 있는 코드 유형입니다. 그러나 이 경우 결과는 위의 if 문 예제와 동일합니다. 의도가 null이면 NullPointer예외가 throw됩니다.

종종 방어적으로 코딩하고 중복 코드를 작성하기 때문에 이 구문에서 벗어나는 경우가 많습니다. 대부분의 사용 사례에서 != null에 대한 검사가 중복될 수 있습니다.

이는 프로덕션 코드의 프로그래머가 오류한 오류입니다.

검색에 대한 결과가 얼마나 현재인지 는 모르겠지만 검색을 실행했을 때 Google, Amazon, Apache ... 그리고 나.

오픈 소스 프로젝트 중 하나에 대한 최근 풀 요청은 이 오류를 정확하게 해결하는 것이었습니다.

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

이 것을 찾는 방법

몇 가지 정적 분석기에서 샘플 코드를 확인했을 때, 그 중 어느 것도 이 숨겨진 자폭 코드를 선택하지 않았습니다.

팀으로서 Secure Code Warrior , 우리는 만들고 매우 간단한 검토 Sensei 이 것을 선택할 수있는 조리법.

Bitwise 연산자는 완벽하게 유효하고 종종 할당에 사용되기 때문에 우리는 문제가있는 코드를 찾기 위해 문의 의 사용 사례및 Bitwise & 사용에 초점을 맞춥니다.

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

이렇게 하면 조건 표현식으로 사용될 때 "&" 일치하는 정규 식을 사용합니다. 예를 들어 if 문에서.

이를 해결하기 위해 우리는 다시 정규 식에 의존했습니다. 이번에는 QuickFix의 sed 함수를 사용하여 표현식의 및 표현식을 &로 전 세계적으로 대체합니다.

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

끝 노트

이는 Bitwise 연산자의 가장 일반적인 오용(예: 부울 연산자가 실제로 의도한 경우)을 다룹니다.

과제 예제와 같은 다른 상황이 있지만 레시피를 작성할 때 는 잘못된 긍정 식별을 피해야 하므로 그렇지 않으면 조리법이 무시되거나 꺼집니다. 우리는 가장 일반적인 발생에 맞게 조리법을 구축 할 수 있습니다. 만큼 Sensei 더 많은 일치 조건을 커버하기 위해 검색 기능에 추가 특이성을 추가할 수 있습니다.

현재의 형태로, 이 조리법은 라이브 사용 사례의 많은 식별 것, 그리고 가장 중요한 것은,내 프로젝트에보고 된 하나.

참고 : 찰리 에릭센, 마티유 칼리, 로빈 클레어하우트, 브라이센 Ackx, 네이선 데스멧, 다우니 로버슈텐 - 공정한 몇 코드 전사는이 예와 조리법 검토에 기여했다. 당신의 도움을 주셔서 감사합니다.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드"

우리는 '에서 이러한 블로그 게시물 (이 포함)에 대한 소스 코드와 조리법을 많이 가지고 sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정.

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

자세히 알아보기 Sensei

정적 분석은 무엇입니까?

정적 분석은 응용 프로그램을 실행하지 않고 소스 코드의 자동화 된 분석입니다.

프로그램 실행 중에 분석이 수행되면 동적 해석이라고 합니다.

정적 분석은 종종 다음을 감지하는 데 사용됩니다.

• 보안 취약점.
• 성능 문제.
• 표준을 준수하지 않습니다.
• 오래된 프로그래밍 구문 사용.

정적 분석 도구는 어떻게 작동합니까?

모든 정적 분석 도구에 공통적인 기본 개념은 소스 코드를 검색하여 일종의 경고 또는 정보와 관련된 특정 코딩 패턴을 식별하는 것입니다.

"JUnit 5 테스트 클래스는 '공개'가 될 필요가 없습니다"만큼 간단할 수 있습니다. 또는 "SQL 실행 문에서 사용되는 신뢰할 수 없는 문자열 입력"과 같은 식별하기 가 복잡한 것입니다.

정적 분석 도구는 이 기능을 구현하는 방법에 따라 다릅니다.

• 추상구트리(AST)를 만드는 소스 코드 구문 분석 기술
• 텍스트 정규 식 일치,
• 위의 조합.

텍스트의 정규 식 일치는 매우 유연하고 일치하는 규칙을 작성하기 쉽지만 많은 거짓 긍정으로 이어질 수 있으며 일치하는 규칙은 주변 코드 컨텍스트에 대해 무지합니다.

AST 일치는 소스 코드를 프로그램 코드로 취급하며 텍스트로 채워진 파일뿐만 아니라 보다 구체적이고 상황에 맞는 일치를 허용하며 코드에 대해 보고된 거짓 긍정 의 수를 줄일 수 있습니다.

연속 통합의 정적 분석

정적 분석은 CI(연속 통합) 프로세스 중에 수행되어 시간이 지남에 따라 코드 베이스에 대한 객관적인 보기를 수신하도록 검토할 수 있는 규정 준수 문제에 대한 보고서를 생성하는 경우가 많습니다.

어떤 사람들은 정적 분석 도구를 구성하여 코드의 특정 부분만 측정하고 규칙 하위 집합에 대해서만 보고하여 정적 분석을 코드 품질의 객관적인 척도로 사용합니다.

객관성은 시간이 지남에 따라 코드 평가에 따라 달라지지 않기 때문에 사용되는 규칙에 의해 제공됩니다. 분명히 사용되는 규칙과 구성의 조합은 주관적인 결정이며 다른 팀은 서로 다른 시간에 다른 규칙을 사용하기로 결정합니다.

CI에서 정적 분석을 수행하는 것은 유용하지만 프로그래머의 피드백을 지연시킬 수 있습니다. 프로그래머는 코딩할 때 피드백을 받지 않으며 나중에 정적 분석 도구를 통해 코드를 실행할 때 피드백을 받습니다. CI에서 정적 분석을 실행하는 또 다른 부작용은 결과를 무시하기가 쉽다는 것입니다.

팀이 정적 분석의 결과에 더 많은 주의를 기울이도록 하려면 일반적으로 메트릭이 트리거된 여러 규칙과 같은 메트릭을 초과하면 빌드 프로세스에서 임계값 메트릭을 구성하여 빌드에 실패하도록 구성할 수 있습니다.

IDE의 정적 분석

피드백을 더 빨리 받으려면 주문형 IDE에서 정적 분석 규칙을 실행하거나 코드가 변경될 때 주기적으로 실행되는 많은 IDE 플러그인이 있습니다.

그런 다음 프로그래머가 코드를 작성할 때 IDE에서 규칙 위반을 볼 수 있으며 규칙을 무시하기 어렵게 만들려면 편집기에서 밑줄이 표시된 코드로 렌더링하도록 위반을 구성할 수 있습니다.

나는 개인적으로 이것이 내 코딩을 개선하는 유용한 방법을 찾을 수 있습니다, 특히 정적 분석 도구에 의해 덮여 새로운 라이브러리로 작업 할 때. 그것은 거짓 긍정과 '시끄러운'수 있지만, 또는 규칙에 관심이 없습니다. 그러나 이는 특정 규칙을 무시하도록 정적 분석 도구를 구성하는 추가 단계를 사용하여 해결됩니다.

정적 분석 규칙에 따라 코드 수정

대부분의 정적 분석 도구를 사용하면 규칙 수정이 프로그래머에게 남아 있으므로 규칙 위반의 원인과 규칙을 수정하는 방법을 이해해야 합니다.

수정이 팀에 매우 자주 컨텍스트가 되고 사용된 기술과 합의된 코딩 스타일에 따라 위반을 해결할 수 있는 기능도 포함되는 정적 분석 도구도 거의 없습니다.

기본 규칙

정적 분석 도구에 기본 규칙이 있을 때 규칙의 품질에 대한 잘못된 신뢰가 발생할 수 있으며 프로그래머가 발생할 수 있는 모든 문제와 규칙이 적용되어야 하는 모든 상황을 다루고 있다고 믿게 됩니다. 경우에 따라 규칙을 적용해야 하는 상황은 미묘할 수 있으며 감지하기가 쉽지 않을 수 있습니다.

희망은 정적 분석 도구를 사용하고 규칙과 위반을 자세히 조사함으로써 프로그래머가 특정 도메인의 맥락에서 문제를 감지하고 피할 수있는 기술을 개발할 수 있기를 바랍니다.

도메인에 컨텍스트 규칙이 필요한 경우 정적 분석 도구에는 도메인 또는 라이브러리와 일치하는 규칙이 없을 수 있으며 도구구성 및 확장이 어려울 수 있습니다.

불만

이러한 '성가심'은 극복할 수 없습니다.

• 거짓 긍정
• 수정 사항 부족
• 규칙을 무시하는 구성
• 컨텍스트별 규칙 추가

그러나 정적 분석 도구를 사용하는 것이 매우 유용할 수 있기 때문에 처음에는 정적 분석 도구를 사용하지 않도록 변명으로 자주 사용됩니다.

• 주니어 개발자에게 더 나은 접근 방식을 강조표시
• 명확한 코딩 위반에 대한 빠른 피드백 확보
• 프로그래머가 이전에 발생하지 않은 모호한 문제 식별
• 프로그래머가 좋은 코딩 접근 방식을 채택했다는 것을 강화합니다(위반사항이 보고되지 않은 경우)

IDE 기반 정적 분석 도구

프로젝트의 개별 기여자로서 IDE 내에서 실행되는 정적 분석 도구를 사용하여 코드에 대한 빠른 피드백을 받는 것을 좋아합니다.

이렇게 하면 끌어오기 요청 검토 프로세스와 프로젝트가 가질 수 있는 CI 통합이 보완됩니다.

나는 나에게 우위를 줄 것이다 도구를 식별하고, 내 개별 워크 플로우를 개선하려고합니다.

도구가 IDE에서 실행되는 경우 동일한 기본 GUI 및 구성 접근 방식을 공유하는 경향이 있으므로 도구가 상호 교환방식으로 볼 수 있습니다.

도구는 겹치는 기능 이나 규칙 집합을 가질 수 있지만 최대한의 이점을 얻으려면 그들의 강점을 활용 하기 위해 여러 도구를 설치.

코딩이 아래에 나열될 때 적극적으로 사용하는 정적 분석 IDE 도구는 다음과 같습니다.

• 붙박이 IntelliJ 검사 - 일반적인 코딩 패턴
• 스팟 버그 - 일반적인 오류
• 수중 음파 탐지기 - 일반적인 사용 패턴
• 체크 스타일 - 일반적인 스타일 패턴
• Sensei 보낸 사람 Secure Code Warrior - 사용자 정의 규칙 생성

그들은 서로를 증강 하 고 보충 하기 위해 함께 잘 작동 하기 때문에 그들 모두를 사용.

인텔리제이 검사

IntelliJ를 사용하는 경우 이미 검사를 사용하고 있습니다.

다음은 IDE에 플래그가 지정된 정적 분석 규칙입니다. 그들 중 일부는 또한 문제를 해결하기 위해 코드를 다시 작성하는 QuickFix 옵션이 있습니다.

규칙은 켜고 끌 수 있으며 IDE에서 강조 표시하는 데 사용되는 오류 수준을 선택할 수 있습니다.

좋은 IntelliJ 검사가 많이 있습니다. 나는 이것을 쓰는 동안 그들을 읽었기 때문에 그것을 알고있다. IntelliJ 검사를 기본값으로 사용하고 구성하지 는 않았지만 이를 통해 읽어야 하는 검사에서 전체 값을 얻고 코딩 스타일과 관련된 검사를 식별하고 코드에서 이를 알 수 있도록 경고 수준을 구성합니다.

IntelliJ 검사의 가장 큰 장점은 IDE와 함께 무료로 제공되며 다음과 같은 근육 메모리를 구축하는 데 도움이 된다는 것입니다.

• 코드를 작성할 때 소스에서 경고 및 오류를 알아차리
• 규칙 위반을 알아보려면 플래그가 지정된 코드 위에 마우스를 마우스로 가져가십시오.
• alt+enter를 사용하여 문제에 대한 QuickFix를 적용합니다.

스팟버그

SpotBugs IntelliJ 플러그인은 정적 분석을 사용하여 코드의 버그에 대해 경고합니다.

SpotBugs는 IntelliJ 환경 설정에서 코드를 스캔하도록 구성할 수 있으며, 사용된 실제 규칙은 검출기 탭에서 찾을 수 있습니다.

코드를 작성하고 검토한 후 SpotBugs를 사용하는 경향이 있으며 '테스트 소스를 포함한 프로젝트 파일 분석'을 실행합니다.

이렇게 하면 버그, 데드 코드 및 명백한 최적화를 식별하는 데 도움이 됩니다. 또한 신고된 위반 사항 중 일부를 조사하여 무엇을 해야 할지 결정하도록 강요합니다.

SpotBugs는 문제를 찾을 수 있지만 문제를 해결하기 위한 QuickFix 작업을 제공하지는 않습니다.

SpotBugs는 구성하기 쉽고 IDE에서 상담하는 데 유용한 객관적인 두 번째 의견이 될 수 있습니다.

수나린트

수나린트 플러그인.

SonarLint는 IntelliJ 환경 설정에서 구성하여 코드의 유효성을 검사하는 규칙을 선택할 수 있습니다.

기본적으로 SonarLint는 실시간으로 실행되며 편집중인 현재 코드에 대한 문제를 표시합니다.

SonarLint는 빠른 수정 사항을 제공하지 않지만 위반 보고서와 관련된 문서는 일반적으로 명확하고 잘 문서화되어 있습니다.

나는 내가 자바의 최신 버전에서 알고 있던 새로운 자바 기능에 저를 경고하기 위해 과거에 유용 할 수 SonarLint를 발견했습니다.

체크스타일

CheckStyle 플러그인은 서식 및 코드 품질 규칙의 혼합을 제공합니다.

체크 스타일 플러그인은 '태양 검사'와 '구글 체크'와 함께 번들로 제공됩니다.

이러한 정의는 쉽게 온라인으로 찾을수 있습니다.

CheckStyle은 프로젝트가 자체 규칙 집합을 만드는 데 시간을 할애할 때 가장 많은 가치를 추가합니다. 그런 다음 IDE 플러그인을 구성하여 CI에 코드를 커밋하기 전에 해당 규칙 집합을 사용하도록 구성하고 프로그래머가 스캔을 수행할 수 있습니다.

CheckStyle은 CheckStyle 위반 횟수가 임계값을 초과할 때 CI 프로세스에 대한 빌드 실패 플러그인으로 매우 자주 사용됩니다.

Sensei

Sensei 코드를 일치시키고 QuickFixs를 만들기 위해 추상 구문 트리(AST)를 기반으로 정적 분석을 사용하면 문제가 있는 코드를 매우 구체적으로 식별할 수 있습니다.

AST를 사용하면 레시피와 연결된 QuickFixs가 코드에 새 클래스를 추가할 때와 같이 주변 코드를 이해할 수 있으며 해당 클래스에 대한 가져오기는 각 교체가 아닌 소스 파일에 한 번만 추가됩니다.

Sensei 존재하지 않거나 다른 도구에서 구성하기 어려운 사용자 지정 일치 규칙을 쉽게 빌드할 수 있도록 만들어졌습니다. 

구성 파일을 수정하는 대신 GUI에서 모든 구성을 수행할 수 있습니다. 새로운 레시피를 만들 때 GUI를 사용하면 레시피가 일치하는 코드를 쉽게 확인할 수 있습니다. 그리고 QuickFixes를 정의할 때 코드의 전후 상태를 즉시 비교할 수 있습니다. 이를 통해 팀, 기술, 심지어 개별 프로그래머에 고유한 매우 맥락적인 레시피를 쉽게 만들 수 있습니다.

사용 Sensei 대부분의 정적 분석 도구와 같은 다른 정적 분석 도구와 함께 문제를 발견하지만 해결하지는 않습니다. 일반적인 사용 사례 Sensei 다른 도구의 일치하는 검색을 복제하는 것입니다. Sensei 빠른 수정으로 확장합니다. 이렇게 하면 적용된 사용자 지정 수정 프로그램이 프로젝트의 코딩 표준을 이미 충족한다는 이점이 있습니다.

나는 주기적으로 자신을 만드는 찾을 수 Sensei IntelliJ Intensions 세트에 이미 존재하는 조리법은 Intension 보고서가 내가 만든 컨텍스트와 잘 맞지 않거나 IntelliJ에서 제공하는 QuickFix가 사용하려는 코드 패턴과 일치하지 않기 때문입니다.

기존 도구를 완전히 교체하는 대신 보강합니다.

Sensei 정적 분석 도구에서 지원되지 않는 SQL 라이브러리를 사용하는 경우와 같은 공통 규칙의 컨텍스트 변형을 식별할 때도 매우 유용할 수 있지만 정적 분석 엔진의 일반적인 SQL 규칙은 여전히 적용되며 이러한 규칙의 라이브러리 별 변형을 만들 수 있습니다. Sensei .

Sensei 언급 된 정적 분석 도구와 같은 일반적인 조리법이 많이있는 상자에서 나오지 않으며, 그 강도는 특정 코딩 스타일과 사용 사례에 맞게 구성된 QuickFixs로 완성 된 새로운 레시피를 쉽게 만들 수 있도록하는 것입니다.

참고 : 우리는 일반적인 사용 사례를 커버하기 위해 조리법의 공개 저장소에 노력하고 있습니다, 당신은 여기에서 찾을 수 있습니다.

요약

저는 함께 작업하고 구성할 수 있으며 특정 컨텍스트를 충족하기 위해 확장하기 쉬운 도구를 선택하는 경향이 있습니다. 수년 동안 IDE에서 정적 분석 도구를 사용하여 문제를 식별하고 사용하는 프로그래밍 언어 및 라이브러리에 대해 자세히 알아보세요.

나는 조합에 언급 된 모든 도구를 사용합니다 :

• IntelliJ 의도는 종종 연결된 QuickFixs와 함께 일반적인 코드 문제를 상자에 플래그를 표시하는 데 도움이 됩니다.
• SpotBugs 내가 놓친 수 있습니다 간단한 버그를 찾아 성능 문제에 저를 경고.
• SonarLint는 내가 알지 못했던 Java 기능을 식별하고 코드를 모델링하는 추가 방법을 안내합니다.
• CheckStyle은 CI 중에 적용되는 합의된 코딩 스타일을 준수하는 데 도움이 됩니다.
• Sensei 정적 분석 도구에서 찾은 일반적인 시나리오를 보강하고 다른 도구에서 구성하기 어려운 특정 프로젝트 또는 기술 레시피를 만드는 QuickFixes를 만드는 데 도움이 됩니다.

---

설치하다 Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".

예제 코드 및 일반적인 사용 사례에 대한 레시피의 저장소를 찾을 수 있습니다. Secure Code Warrior GitHub 계정, ' sensei - 블로그 예제 '프로젝트.

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

자세히 알아보기 Sensei

Sensei 프로젝트 자체에는 시간이 지남에 따라 구축 된 자체 조리법 세트가 있습니다. 이 블로그 게시물은 시나리오 중 하나의 예입니다. Sensei 팀은 레시피를 만들었습니다. Guice의 잘못된 구성으로 인해 테스트 중에 런타임에 NullPointer예외가 보고되었습니다.

이는 코드가 구문적으로 올바른 많은 종속성 주입 시나리오에 일반화될 수 있지만 배선 구성이 올바르지 않아 오류가 미끄러집니다.

이것은 종종 우리가 기술을 배우고있을 때 발생하며, 우리는 물건을 연결하는 것을 잊어 버리는 단순한 실수를 계속합니다. 그러나 이것은 또한 경험이 풍부한 전문가에게 일어나기 때문에, 잘 ... 우리 모두는 실수를 하고, 모든 것을 커버할 단위 테스트가 없을 수도 있습니다.

잘못된 종속성 주입 배선에서 런타임 예외

아래 코드는 NullPointer예외로 런타임에 실패합니다.

‍

injector = Guice.createInjector(new SystemOutModule());
CountReporter reporter = injector.getInstance(CountReporter.class);
String [] lines5 = {"1: line", "2: line", "3: line", "4: line", "5: line"};
reporter.reportThisMany(Arrays.asList(lines5));
Assertions.assertEquals(5, reporter.getCount());

코드는 구문적으로 정확하지만 SystemOutModule 구성에서 요청을 놓쳤기 때문에 실패합니다.

‍

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
    }
}

인젝터를 사용하여 만든 리포터를 사용하려고 할 때 완전히 인스턴스화되지 않았으며 보고를 호출할 때 NullPointer예외를 받습니다.

코드 검토에서 이를 놓쳤거나 종속성 주입을 트리거하는 단위 테스트가 없었고 빌드로 미끄러질 수 있습니다.

‍

경고 표시

이 경우 경고 표지판이 있으며 CountReporter에는 @Inject 인가가 아닌 정적 필드가 있습니다. CountReporter 클래스 자체는 패키지 비공개입니다.

복잡한 코드 베이스에서 바인딩을 구성하는 모듈 클래스가 이 작업을 위해 동일한 패키지에 있어야 하기 때문에 코드가 올바르지 않다는 경고 신호일 수 있습니다.

‍

class CountReporter {
    @Inject
    private static ILineReporter reporter;

코드 검토에서 포착했을 수 있는 또 다른 오류는 SystemOutModule 구성 메서드에서 필드를 실제로 바인딩하는 것을 잊어버린 것입니다.

바인더().요청정적 주입(카운트 리포터.class);

우리가 요청을 작성했다면Static주입 코드를 작성한 다음 CountReporter를 사용하려고 할 때 생성 된 구문 오류가 간단한 오류에 대해 경고했을 것입니다.

> '기자. 카운트 리포터는 '기자'에 공개되지 않습니다. 외부 패키지에서 액세스할 수 없습니다.

‍

슬프게. 우리는 잊어 버렸고 코드에는 구문 경고 표시가 없었습니다.

어떻게 할 수 있을까요? Sensei 도움말?

우리는 아마 사용하지 않을 것입니다 Sensei 누락 된 요청을 데리러 모든 Guice 구성 배선이 그 방법을 사용해야하기 때문에Static주입, 우리는 모든 배선이이 사용 사례만큼 간단 할 것이라고 보장 할 수 없습니다.

우리는 Sensei 규칙은 코드가 처음부터 다하지 않다는 몇 가지 경고 표시를 찾아야 합니다.

이 경우 다음을 의미합니다.

• @Inject 인가된 필드가 있는 클래스 찾기
• 클래스가 공개되지 않은 경우입니다.

위의 경고 표시는 유선되지 않았을 것 같지 않다는 경고 신호였습니다.

레시피를 만들면 코딩 중에 경고 표지판이 일찍 발생하고 끌어오기 요청에 대한 의존도를 줄이거나 기술 부채를 해결하여 단위 테스트를 추가할 수 있습니다.

레시피를 만드는 방법?

완료하려는 작업은 다음과 입니다.

• 보호된 개인 클래스에 있는 @Inject 포함된 필드와 일치하는 레시피 만들기

이를 사용하는 모듈을 식별하고 누락된 배선 코드를 추가할 수 있는 충분한 경고를 제공할 수 있기를 바랍니다.

내 CountReporter 클래스에서, 나는 새로운 조리법을 만들기 위해 Alt +Enter를 사용하고 처음부터 시작합니다

이 이름을 지정하고 설명을 추가합니다.

이름: Guice: 주입된 필드 가 공개되지 않음
설명: 주입된 필드가 공개되지 않은 경우 코드가 연결되지 않을 수 있습니다.
수준: 경고

내가 쓰는 검색은 주입으로 추가되었지만 공개로 범위가되지 않은 필드가있는 클래스를 찾습니다.

검색:
밭:
와:
주석:
유형: "com.google.inject.주입"
안으로:
수업:
없이:
수정자: "공개"

수리하다

레시피의 QuickFix는 범위를 변경하여 주입된 클래스를 수정합니다. 그러나 내가 변경해야 하는 유일한 코드는 아닙니다.

사용 가능한 픽스:

- 이름 : "클래스를 공개로 변경합니다. 또한이 클래스에 주입을 요청하는 것을 기억"
작업:
- 체인지수정자:
가시성: "공개"
대상: "부모 클래스"

레시피가 트리거되면 코드에서 수행할 수동 단계가 남아 있어 개체를 완전히 인스턴스화하기 위해 Static주입을 포함하는 줄을 추가합니다.

public class SystemOutModule extends AbstractModule {
    @Override
    protected void configure() {
        binder().bind(ILineReporter.class).to(SystemOutReporter.class);
        // instantiate via dependency injection
        binder().requestStaticInjection(CountReporter.class);
    }
}

나는 잠재적으로 이것을 집어 들기 위해 다른 조리법을 쓸 수 있었다. 정적 주입을 추가하는 것을 잊지 않는 한 나는 아마 내가 코딩 할 때 만든 반 정기적 인 오류가되었다.

‍

요약

우리가 공통의 루트 패턴으로 실수를 하는 것을 발견한다면, Sensei 문제를 감지하고 해결하는 것에 대한 지식을 명문화하는 데 도움이 될 수 있으며, 코드 검토를 통해 프로덕션으로 전환되지 않기를 바랍니다.

때로는 우리가 작성하는 조리법은 추론 패턴을 식별 즉, 그들을 일치시키는 것은 문제가 있다는 것을 보장하지 않지만 문제가있을 가능성이 높습니다.

또한, 우리가 작성하는 조리법과 QuickFixs, 완전히 포괄적 일 필요가 없습니다, 그들은 우리가 우리가 이상 복잡하지 않고 문제를 식별하고 해결하는 데 도움이 충분히 좋은해야합니다. 왜냐하면 그들은 지나치게 복잡해질 때 이해하기 가 더 어려워지고 유지보수가 더 어려워지기 때문입니다.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".

이 게시물의 소스 코드 및 레시피는 '에서 찾을 수 있습니다. sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정, 'guiceexamples' 모듈에서.

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

자세히 알아보기 Sensei

JUnit 5에 대한 방법 및 클래스 가시성 수정

프로그래밍의 즐거움 중 하나는 최신 상태를 유지하는 데 필요한 지속적인 학습입니다. 문제 중 하나는 새로운 접근 방식의 채택에 영향을 미칠 수 있는 친숙함과 사용 패턴을 구축한다는 것입니다. Sensei 사용되지 않도록 하고 앞으로 사용할 수정 사항을 표시하여 마이그레이션을 도울 수 있습니다.

예를 들어 JUnit 4에서 JUnit 5로 마이그레이션할 때 모든 테스트 클래스와 메서드를 공개적으로 작성하는 데 사용되었습니다. 그러나 JUnit 5를 사용하면 비공개로 패키지가 될 수 있습니다.

예를 들어 다음 대신

public class Junit5VisibilityTest {
    @Test
    public void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

나는 정말로 쓰고 싶다:

class Junit5VisibilityTest {
    @Test
    void thisDoesNotNeedToBePublic(){
        Assertions.assertTrue(true);
    }
}

그것은 이것에 코딩하는 근육 메모리를 구축하는 데 시간이 걸렸고, 나는 여전히 가끔 미끄러졌다.

사용 Sensei

와 Sensei 공개 방법과 클래스를 찾는 레시피를 만들고 선언을 자동으로 비공개로 수정할 수 있습니다.

이를 위해 레시피를 만들었습니다.

이름 - JUnit: JUnit 5 테스트 메서드는 공개할 필요가 없습니다.
설명 - JUnit 5 테스트 방법은 공개 가시성이 필요하지 않습니다.
레벨 - 오류

이 코딩 연습을 스탬프하고 IDE에서 코드를 작성할 때 문제를 더 높은 가시성을 원하기 때문에 오류로 분류했습니다.

계급 선언 수정

수업을 찾기 위해, 나는 Junit 5 즉, org.junit.jupiter.api.Test에서 @Test 아이 의 부가가있는 클래스를 검색합니다.

그리고 클래스에 수정자 공개가있는 경우 :

검색:
수업:
와:
아이:
주석:
유형: "org.junit.jupiter.api.Test"
수정자: "공개"

그런 다음 빠른 수정 프로그램이 수정자를 변경하여 가시성을 제거하여 기본값이 되도록 변경하고 기본값은 내가 찾고 있는 패키지 비공개입니다.

사용 가능한 픽스:
- 이름 : "JUnit 5 테스트 클래스에서 공개 가시성을 제거"
작업:
- 체인지수정자:
가시성: ""

방법 선언 수정

메서드 선언 개정 레시피는 클래스 레시피와 거의 동일합니다.

먼저 JUnit 5의 @Test 인하여 추가된 공개 방법을 검색합니다.

검색:
메서드:
주석:
유형: "org.junit.jupiter.api.Test"
수정자: "공개"

그런 다음 수정자를 기본 가시성으로 변경합니다.

사용 가능한 픽스:
- 이름 : "@Test 방법 공개 가시성 제거"
작업:
- 체인지수정자:
가시성: ""

힌트: 여러 가지 방법 수정

Sensei 현재 파일의 모든 위반에 QuickFix를 적용할 수 있습니다.

alt+enter를 사용하여 QuickFix를 적용할 때.

QuickFix 이름 메뉴를 확장하면 다음 옵션을 볼 수 있습니다.

"모두 해결: 'JUnit: JUnit 5 테스트 메서드는 공개될 필요가 없습니다' 파일의 문제"

그런 다음 해당 옵션을 선택하면 Sensei 내가 선택한 것뿐만 아니라 문제의 모든 발생을 수정합니다.

수업 수정

메서드가 공개될 필요가 없는 것과 마찬가지로 클래스도 마찬가지입니다.

클래스를 수정하기 위해 레시피와 QuckFix를 만들 수 있습니다.

이름 - JUnit: 주니 5 테스트 클래스는 공개될 필요가 없습니다.
설명 - 주니 5 테스트 클래스는 공개 할 필요가 없습니다
레벨 - 오류

나는 공공 의 클래스를 찾을 때 @Test 성서와 방법이 있습니다. 그런 다음 가시성을 변경하고 싶습니다.

검색:
수업:
수정자: "공개"
그 중:
- 어린이 :
메서드:
주석:
유형: "테스트"

변경수정자 동작으로 클래스 정의를 다시 변경할 수 있습니다.

사용 가능한 픽스:
- 이름 : "@Test 클래스 공공 가시성 제거"
작업:
- 체인지수정자:
가시성: ""

요약

정적 분석 도구는 처음에 JUnit에서 이 권장 접근 방식을 경고했습니다. 그러나 정적 분석 도구는 내가 프로그램으로 내 코드를 변경하는 근육 메모리를 구축하는 데 도움이되지 않았다.

'레벨'을 사용하여 경고합니다. 문제가 될 때 나는 처음에 '오류'를 만들고 코딩 접근 방식에서 자신을 짜내면서 이것을 줄이려고합니다.

사용할 수 있는 기억 Sensei QuickFix를 적용할 때 드롭다운 메뉴 옵션을 사용하여 현재 파일의 모든 문제를 동시에 해결합니다.

Sensei 레시피, 나는 실시간으로 내 오래된 코딩 접근 방식을 볼 수 있습니다. 그리고 QuickFix, 내가 가끔 내 코딩에 미끄러 경우 접근 방식을 강화하기 위해.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드".

소스 코드와 이에 대한 조리법은 ' sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정, '주니예제' 모듈에서.

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

개인 생성자 추가 Sensei

유틸리티 클래스에서 필드와 메서드가 정적일 때 인스턴스화할 이유가 없습니다.

예를 들어, 유틸리티클래스 유틸리티 = 새로운 유틸리티클래스();

아래 코드는 유틸리티 클래스를 간단하게 구현하는 것입니다.

public class UtilityClass {
    public static final Boolean ULTIMATE_TRUTH = true;
    public static boolean getTrue(){
        return ULTIMATE_TRUTH;
    }
}

이는 정적 분석 도구가 선택할 수 있는 코딩 패턴의 유형이지만 문제를 해결할 수 있는 기능을 제공하지 않는 경우가 많습니다.

사용할 수 있습니다 Sensei 코딩 패턴을 식별하고 자동으로 개인 생성기를 생성하여 클래스를 인스턴스화하는 것이 불가능합니다.

클래스 검색

유틸리티 클래스에 다음과 같은 새 레시피를 추가합니다.

•  정적 클래스: 개인 생성자 만들기

그리고 처음에는 클래스를 검색할 간단한 매치러를 만듭니다.

검색:

  class: {}

이것은 내가 빠른 수정을 작성하기 시작할 수있을만큼 좋은 모든 클래스와 일치합니다. 빠른 수정 이 작동하면 개인 생성자가 필요한 클래스가 있을 가능성이 더 높을 때 검색을 강조 표시하도록 수정합니다.

빠른 수정

빠른 수정의 경우 개인 생성기를 생성하려고 합니다.

예제 클래스에서는 다음과 같습니다.

   프라이빗 유틸리티클래스(){}

내 클래스에 위의 코드를 추가하려면 내 빠른 수정 메서드를 추가 하 고 메서드의 이름은 클래스의 이름을 사용 하 여 콧수염 템플릿 될 것입니다.

사용 가능한 픽스:

- name: "add private constructor"
  actions:
  - addMethod:
      method: "private {{{ name }}}(){}"

GUI 편집기에서는 변수 표시를 사용하여 콧수염 템플릿을 만든 다음 필드를 편집하여 개인 수정자, 브래킷 및 중괄호를 추가하여 구문적으로 올바르게 만듭니다.

이렇게 하면 이제 모든 클래스에 개인 생성기를 추가할 수 있습니다.

내가 콧수염 템플릿을 작성할 때 생성 된 코드를 볼 수 있기 때문에 QuickFix 미리보기는 나를 도움이됩니다.

이제 문제를 해결할 수 있다는 것을 알고 있습니다. 검색 조건을 구체화하여 가장 적절한 경우 레시피를 표시합니다.

누락된 생성자 검색

이상적으로는 모든 클래스에 대한 오류를 표시하는 레시피를 만들고 싶지 않습니다. 따라서 생성자가 없는 클래스에서만 일치되도록 검색에 몇 가지 추가 조건을 추가합니다.

검색:

  수업:
없이:
아이:
메서드:
생성자: 사실

YAML은 GUI와 약간 다릅니다.

GUI에서 생성자 '예'인 자식 메서드가 없는 클래스를 찾도록 구성합니다. 우리는 GUI를 좀 더 인간 친화적으로 만들기 위해 '사실'대신 GUI에서 '예'를 사용합니다.

이 레시피는 이제 생성자가 없는 모든 클래스에 대해서만 드러냅니다.

가능성이 범인에 대한 좁은 검색

그래서 더 나아가 정적 메서드 나 필드의 존재를 찾고 싶을 수 있습니다.

생성자가 없고 모든 공용 정적 필드 또는 모든 공용 정적 메서드가 있는 클래스를 찾습니다.

검색:

  수업:
와:
그 중:
- 어린이 :
메서드:
모두:
- 수정자 : "공개"
- 수정자 : "정적"
- 어린이 :
밭:
모두:
- 수정자 : "정적"
- 수정자 : "공개"
없이:
아이:
메서드:
생성자: 사실

이래 Sensei IDE에서 프로그래머로서 코드를 정적으로 분석하고 모든 오류를 보고하는 대신 이 필터는 기본 공개 생성자를 가질 만한 충분한 이유가 있는 코드 베이스의 대부분의 클래스를 배제하기에 충분합니다.

일부 프로젝트에서는 유틸리티 클래스에 개인 메서드가 있을 수 있으므로 'all'이 아닌 '모든' 공개 정적 메서드의 존재를 찾기위해 선택할 수 있습니다.

       - 어린이 :
밭:
그 중:
- 수정자 : "정적"
- 수정자 : "공개"

힌트

Sensei 정적 분석 도구를 대체하도록 설계되지 않았습니다. Sensei 코딩 프로세스 또는 기술과 관련된 일반적인 문제에 대해 정적 분석 도구를 보강할 수 있습니다. 문제를 강조하기 위해 일치하는 를 충분히 복제하고 QuickFix 코드를 생성하여 개발 프로세스를 지원합니다.

내가하려고하는 것은 내가 필요로하는 모든 상황을 포함하는 간단한 충분한 조리법을 만드는 것입니다,하지만 모든 클래스에서 제안되지 않도록 필터링합니다.

레시피를 작업할 때 위험을 해제하려고 할 때, 이 경우 개인 생성기를 만들 수 있는지 확실하지 않았기 때문에 QuickFix를 먼저 만들었습니다. 그런 다음 검색 조건을 리팩터링하여 보다 구체적으로 만듭니다.

때로는 조리법을 작업 할 때 검색을 수행하는 방법을 잘 모르기 때문에 먼저 작업합니다.

나는 QuickFix의 리팩터링과 검색 사이를 전환, 점진적으로 구축 할 때 만들 수있는 조리법을 쉽게 찾을 수 있습니다.

---

설치할 수 있습니다. Sensei "환경 설정 \ 플러그인"(맥) 또는 "설정 \ 플러그인"(윈도우)를 사용하여 IntelliJ 내에서 다음 그냥 검색 " sensei 보안 코드"

소스 코드와 이에 대한 조리법은 ' sensei -블로그 예제의 리포지토리는 Secure Code Warrior GitHub 계정, 'pojoexamples' 모듈에서.

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

‍

Tapjacking, "탭"과 "납치"의 조합, 그냥 그 의미. 공격자가 사용자가 탭을 납치하고 그가 의도하지 않은 일을하는 그를 속이는 공격이다. 그렇다면 어떻게 작동하고 어떻게 막을 수 있을까요?

그럼 화면 오버레이와 함께 우리의 이야기를 시작합니다. 화면 오버레이 또는 Google이 호출할 때 TYPE_APPLICATION_OVERLAY 형식을 사용하는 창입니다. 이들은 다른 애플 리 케이 션위에 그려진 창이며 일반적으로 화면의 일부를 모호하게. 앱에서 새 권한을 요청할 때 종종 사용됩니다(아래 예제 이미지).

이것은 실제로 시원하고 재미있는 기능이며 점점 더 많은 앱이 그것을 사용하기 시작하고, 페이스 북 채팅 거품에 대해 생각하거나, 아래스크린 샷과 같이 화면 의 모서리에 Google지도 탐색에 대해 생각하기 시작했습니다.

그러나 이러한 오버레이와 관련된 보안 위험이 있습니다. 활성 화면 오버레이는 탭을들을 수 있습니다, 페이스 북은 우리가 탭하거나 거품을 드래그 것을 어떻게 알 수 있습니까? 이를 통해 앱은 귀하를 감시하고 암호 및 신용 카드 데이터를 잠재적으로 도용할 수 있습니다.

한 단계 더 나아가, 탭잭킹이라는 용어가 나오는 곳이며, 오버레이는 다른 작업을 수행하도록 사용자를 속이는 다른 앱 위에 물건을 그릴 수 있습니다. 사용자는 오버레이와 상호 작용하고 있다고 생각하지만 실제로는 탭이 기본 앱에서 작업을 수행합니다. 이렇게 하면 오버레이가 이전 YouTube 동영상에서설명한 것처럼 특정 권한을 사용하도록 유도하거나 위험한 설정을 변경할 수 있습니다.

위의 데모 비디오는 2010년에 YouTube에 업로드되었기 때문에 이전 버전의 Android에서 수행되었습니다. 그러나 공격은 여전히 오늘날 관련이 있습니다, 취약점은 누가와 마시멜로와 같은 안드로이드의 최신 버전에서 탭 재킹을 허용하는 빛을 왔다으로.

그래서 당신은 그것에 대해 무엇을 할 수 있습니까? 사용자로서 이러한 오버레이의 결과를 인식하고 이를 사용하는 앱을 인식하는 것이 중요합니다. API 레벨 23 (Android 6.0 마시멜로)을 통해 사용자에게 명시적으로 부여해야 하는권한이 되었습니다. 그러나, 그 잎 50% 안 드 로이드사용자의 여전히 취약. "다른 앱에 표시"에서 설정에서 이 권한을 사용하는 앱을 확인할 수 있습니다.

개발자로서 사용자의 완전한 지식과 동의로 사용자 작업이 수행되도록 하는 것은 당사의 일입니다. 안드로이드는 필터링을 호출, 그냥 그렇게 보기에 대한 설정을 제공합니다경우가 적용. 이 옵션을 사용하도록 설정하면 다른 표시 창에 의해 뷰 창이 가려질 때마다 프레임워크가 수신되는 터치를 삭제합니다. 그만큼 간단, 설정 필터경우경우는 사실에 모호하고, 응용 프로그램은 탭 재킹에서 안전합니다.

행운을 빌어 요 다음 주 당신을 참조하십시오!

경우에 따라 응용 프로그램이 권한 요청 부여, 구매 또는 광고 클릭과 같은 사용자의 전체 지식과 동의를 통해 작업을 수행하고 있는지 확인할 수 있어야 합니다. 안타깝게도 악의적인 응용 프로그램은 사용자가 의도한 뷰 목적을 은폐하여 인식하지 못하고 이러한 작업을 수행하도록 스푸핑하려고 시도할 수 있습니다.

https://developer.android.com/reference/android/view/View.html

장치 암호화는 Android 장치의 모든 데이터를 암호화하는 프로세스입니다. Android 장치에 대해 이 기능이 활성화되면 사용자가 만든 모든 데이터가 저장소에 기록되기 전에 즉시 암호화됩니다. 이렇게 하면 권한이 없는 당사자가 데이터에 액세스하려고 해도 데이터를 읽을 수 없습니다. 이 스마트 폰 장치에 특히 좋은 기능입니다, 이들은 사용자에 의해 운반되고 다른 컴퓨팅 장치보다 손실 이나 도난하는 경향이 있기 때문에. 호기심 많은 파인더 나 도둑은 휴대 전화의 잠금을 해제 할 수 없다면 데이터에 액세스 할 수 없습니다.

안드로이드는 장치 암호화의 두 가지 유형이 있습니다 : 전체 디스크 암호화 및 파일 기반 암호화.

전체 디스크 암호화

전체 디스크 암호화API 수준 19 (안드로이드 4.4 KitKat)에 도입되었지만 API 레벨 21 (Android 5.0 롤리팝)의 새로운 기능은 실제로 사용을 시작했습니다. 전체 디스크 암호화는 단일 키를 사용하여 전체 장치 사용자데이터 파티션을 보호합니다. 키는 사용자 자격 증명으로 보호되며 디스크의 일부가 액세스하기 전에 부팅 시 제공해야 합니다.

이는 보안에 적합하지만 사용자가 자격 증명을 입력할 때까지 장치의 대부분의 기능을 사용할 수 없음을 의미합니다. 즉, 장치를 재부팅하지만 잠금 해제되지 않은 경우 알람과 같은 일부 기능은 작동할 수 없으며 서비스를 사용할 수 없으며 전화통화가 수신할 수 없습니다. 이러한 이유로 두 번째 암호화 모드가 만들어졌습니다.

파일 기반 암호화

파일 기반 암호화, 장치 암호화의 두 번째 모드, API 수준 24 (안 드 로이드 7.0 누가)이후 사용할 수 있다. 이 모드에서는 서로 다른 파일이 독립적으로 잠금을 해제할 수 있는 다른 키로 암호화됩니다. 이 암호화 모드를 사용하면 암호화된 장치가 잠금 화면으로 바로 부팅할 수 있는 Direct Boot 모드가 있어 장치의 잠금을 해제하기 전에 이전에 누락된 기능을 사용할 수 있습니다.

Direct Boot를 사용하면 장치의 잠금 해제 전에 제한된 컨텍스트 내에서 앱을 작동할 수 있습니다. 이렇게 하면 사용자 정보를 손상시키지 않고 예상대로 작동할 수 있습니다. 이 기능을 제공하기 위해 Android 장치에는 두 개의 저장소 위치가 필요합니다.

1. 자격 증명 암호화 된 저장소. 기본 저장소 위치, 사용자가 장치를 잠금 해제 한 후에만 사용할 수 있습니다.
2. 장치 암호화 된 스토리지. 직접 부팅 모드에서 사용할 수 있으며 사용자가 장치의 잠금을 해제한 후 사용할 수 있습니다.

직접 부팅 모드에서 실행하는 동안 앱이 데이터에 액세스해야 하는 경우 장치 암호화된 저장소를 사용해야 합니다. 그러나 보안의 의미를 알고 있어야합니다! 장치 암호화 된 스토리지는 중요한 데이터를 저장하는 데 사용되어서는 안됩니다! 장치 암호화 된 저장소는 장치가 성공적으로 부팅되는 즉시 사용할 수있는 키로 암호화됩니다. 사용자가 액세스하는 것만으로모든 데이터는 기본 위치인 자격 증명 암호화된 저장소에 저장되어야 합니다.

암호화가 무엇이거나 중요한 지에 대해 자세히 알아보려면 Secure Code Warrior 입구. 또는 몇 가지 문제를재생하여 암호화에 대한 지식을 테스트하려고 할 수 있습니다.

장치에 대한 단계별 가이드가 필요하십니까? 픽셀 개인 정보 보호에서 빌 헤스에서이 문서를 확인하십시오.

나는 당신이 새로운 것을 배웠으면 좋겠다. 다음 주에 뵙겠습니다!

기본 저장소 위치이며 사용자가 장치를 잠금 해제한 후에만 사용할 수 있는 자격 증명 암호화된 저장소입니다.

https://developer.android.com/training/articles/direct-boot.html