A Study on Tools for Development of AI-based Secure Coding Inspection (1)
시작
어떤 주제의 기술 블로그로 시작을 하면 좋을까 생각을 해보았다.
작년에 했던 프로젝트인 AI 기반의 시큐어 코딩 점검 도구에 대한 연구라는 큰 타이틀을 가지고 키워드라던가 세부 주제에 대해 조금 더 조사해보고자 한다.
나는 프로젝트 자체가 처음이었기도 하고 지금도 그렇지만 작년에는 기초가 지금보다도 부족한 상태였다. 또 팀원들은 나보다 학년이 높기는 했지만 주제에 관한 경험은 전무했기 때문에 프로젝트 기간 중 대부분을 조사하는 데에 할애했다.
가장 부족하다고 생각했고, 민폐는 끼치지 말자라는 생각에 시간을 정말 많이 투자했었다.
첫 스타트를 다들 어떻게 끊어야 할지 몰랐기에 멘토님께서는 다양한 취약점 분석툴들을 소개해주셔서 이것들을 조사해보기로 했다.
아마 몇 주간은 작년의 프로젝트를 다룰 듯 하다 !
조사 시작 _ aboutPMD
자바 애플리케이션 취약점 분석: Find Security Bugs
https://find-sec-bugs.github.io/
모바일 애플리케이션 취약점 분석: MobSF
https://github.com/MobSF/Mobile-Security-Framework-MobSF
Sonar Qube
https://www.sonarsource.com/products/sonarqube/
Programing Mistake Detector(PMD)
https://pmd.sourceforge.io/pmd-4.2.6/rules/basic.html
그 외
https://egovframe.go.kr/wiki/doku.php?id=egovframework:dev2:imp:inspection#전자정부_표준프레임워크_표준_inspection_룰셋
이런 링크들을 타고 가서 취약점 분석 도구를 분석.
정적 분석(DAST)과 동적 분석(SAST)
- 동적 분석 : 공격자가 사용하는 방식으로 접근하여 웹어플리케이션의 취약점을 분석함
- 실제 공격자가 어플리케이션을 공격하는 환경을 인위적으로 조성하여 실제 공격이 통하는지의 여부를 발견하는 분석법
- 웹해킹분석 / 모의해킹분석으로 불리기도 함
- 실제 운영 중인 어플리케이션 대상으로 가상 공격이 이뤄지기에 예상되는 취약점 및 대응방안들을 미리 대비 가능
- 외부 -> 내부 접근
- 정적 분석 : 소스코드를 대상으로 그 안에 내재된 잠재적인 취약점을 분석
- 운영 중인 어플리케이션 대상이 아닌 소스코드 대상으로 접근하기 때문에 초기 단계부터 적용이 가능
- 동적 분석에서 발견되지 못하는 취약점을 조기 발견하고 대응 가능 -> 실시간으로 취약점 분석 가능
- 내부 -> 외부 접근
정적 분석이 필요한 이유?
- 잠재적으로 버그가 발생할 수 있는 코드, 안티 패턴, 코드 스타일 위반 여부, 성능 문제, 오타, 사용되지 않은 코드, 잠재적 보안 취약점 등을 발견 가능
What is PMD?
: Programming Mistake Detector is Java Source Code Analyzer
: 자바 프로그램의 소스코드를 분석하여 프로그램의 부적절한 부분을 찾아내고 성능을 높이도록 도와주는 공개 소프트웨어 점검 도구
- 사용하지 않는 변수, 아무런 처리도 하지 않은 catch-block, 불필요한 objector 생성 등 찾아냄
- 시스템 개발 공정의 구현 및 테스트 단계에서 정적 분석에 활용할 수 있음
: 프로그래머가 자각하지 못한 에러 혹은 위험 요소를 사전에 탐지하여 위험을 미리 제거해주는 강력한 소스 코드 분석기
: 단독 형태로도 쓰이고 eclipse나 IntelliJ와 같은 Java IDE에 플러그인 형태로 배포되어 사용
: 코드의 결함을 탐지하여 사용자에게 리스트를 보여줌, 그러나 리스트가 진짜 결함이라고 단정지을 수 없기에 리스트를 보고 확인 과정을 거치는데 이때 정적 분석 도구가 결함이 아닌 것을 결함으로 탐지해 리스트에 보여주면 오탐지 결과, 즉, False positive를 발생시킨 것
PMD를 사용해보며
IntelliJ를 사용하여 짧은 코드를 써본 후 PMD를 실행시켜봄
eclipse는 error로 설치 불가했음;
- IntelliJ 사용 경험이 없어서 그나마 알던 JAVA 프로젝트 생성 후 임의의 간단한 코드 실행
- 처음에는 클래스 이름을 hello로 설정했고, PMD를 실행시켜보니 1violations라고 경고문이 뜸
ClassNamingConventions 알려줌 -> 클래스 이름을 대문자로 쓰라고 권장
- SystemPrintln 경고문은 아무래도 출력만 할 수 있게끔 용도 제한되어 있기 때문에 logger 사용 권장
-> logger : 화면 출력 이외에도, 파일로 로그 정보를 기록하는 등 디버깅을 위한 많은 기능과 정보를 제공
-> 디버깅 위해서 logger 수정후
- 등등 다른 경고문이 많이 떴지만.. 생략
- 전자정부 표준프레임워크 표준 Inspection 룰셋
- Code Inspection을 위한 룰셋으로 논리오류/구문오류/참조오류 영역을 대상으로 하는 총 39개의 룰을 표준으로 설정한 것
| 번호 | 룰 이름 | 권장방안 |
|---|---|---|
| 1 | EmptyCatchBlock | Catch Block에 반드시 예외를 다루는 코드를 작성 |
| 2 | EmptyIfStmt | 빈 if문 구문의 사용 피하기 |
| 3 | EmptyWhileStmt | 빈 while문 구문의 사용 피하기 |
| 4 | EmptyTryBlock | 내용이 없는 try 블록이 없어야 함 |
| 5 | EmptyFinallyBlock | 내용이 없는 finally 블록이 없어야 함 |
| 6 | UnnecessaryConversionTemporary | 기본 데이터 타입을 String으로 변환할 때 불필요한 임시 변환 작업을 피하기 |
| 7 | EmptyStatementNotInLoop | 필요없는 문장(;)이 없어야 함 |
| 8 | WhileLoopsMustUseBraces | 중괄호없이 사용된 while문의 사용 피하기 |
| 9 | AssignmentInOperand | 피연산자 내 할당문 피하기 (해당 코드 복잡하고 가독성 떨어지게 만듦) |
| 10 | UnnecessaryParentheses | 불필요한 괄호 사용할 경우 메소드 호출처럼 보여서 소스 코드의 가독성을 떨어뜨릴 수 있음 |
| 11 | SimplifyBooleanExpressions | boolean 사용 시 불필요한 비교 연산을 피하기 |
| 12 | SwitchStmtsShouldHaveDefault | switch 구문에는 반드시 default label이 있어야 함 |
| 13 | AvoidReassigningParameters | 넘겨받는 메소드 parameter 값을 직접 변경 X |
| 14 | FinalFieldCouldBeStatic | final field를 static으로 변경하면 overhead를 줄일 수 있음 |
| 15 | EqualsNull | null 값과 비교하기 위해 equals 메소드 사용X |
| 16 | SimpleDateFormatNeedsLocale | SimpleDateFormat 인스턴스를 생성할 때 Locale을 지정 |
| 17 | ImmutableField | 생성자를 통해 할당된 변수를 Final로 선언 |
| 18 | AssignmentToNonFinalStatic | static 필드의 안전하지 않은 사용 가능성이 존재 |
| 19 | AvoidSynchronizedAtMethodLevel | method 레벨의 synchronization보다 block 레벨 synchronization 을 사용 |
| 20 | AbstractClassWithoutAbstractMethod | Abstract Class내에 Abstract Method가 존재X |
| 21 | UncommentedEmptyMethod | 빈 메소드임을 나타내는 주석 추가 |
| 22 | AvoidConstantsInterface | Interface는 클래스의 behavior을 구현하는 데에만 사용 |
| 23 | DuplicateImports | import문 중복된 것 삭제 |
| 24 | ImportFromSamePackage | 동일 패키지에 있을 경우 import문 필요X |
| 25 | SystemPrintln | System.out.print 사용 피하고 전용 logger 사용 |
| 26 | VariableNamingConventions | final 이 아닌 변수는 밑줄 포함 X |
| 27 | MisleadingVariableName | 변수명에 잘못된 prefix 사용-> non-field 이름이 m_으로 시작 X |
| 28 | AvoidArrayLoops | loop문 이용한 배열복사 대신 System.arraycopy() 메소드 이용 |
| 29 | UnnecessaryWrapperObjectCreation | 탐지된 코드 삭제 후 별도의 parse관련 전용 메소드 사용을 권장 |
| 30 | AvoidThrowingRawExceptionTypes | 가공되지 않은 Exception은 throw 비추천 |
| 31 | AvoidThrowingNullPointerException | throw 비추천 |
| 32 | StringInstantiation | 불필요한 String Instance 코드 삭제 후 간단한 형태의 코드로 변경 |
| 33 | StringToString | 불필요한 toString() 메소드 코드 제거 |
| 34 | InefficientStringBuffering | StringBuffer 함수내에서 비문자열 연산 이용하여 직접 결합하는 코드 사용 탐지, append 메소드 사용 권장 |
| 35 | InefficientEmptyStringCheck | whitespace/Non-whitespace확인을 위한 별도의 로직 구현 권장 |
| 36 | UselessStringValueOf | String을 append 할 경우, String.valueOf 함수 필요X |
| 37 | UnusedPrivateField | 사용되지 않는 Private field 탐지 ->해당 소스 확인 후 삭제 |
| 38 | UnusedPrivateMethod | 사용되지 않는 Private Method 선언 탐지 ->해당 소스 확인 후 삭제 |
| 39 | UnusedFormalParameter | 메소드 선언 내에 사용되지 않는 parameter 탐지 ->해당 소스 확인 후 삭제 |
PMD 실행 과정
PMD를 적용하여 소스 코드의 취약점을 파악
PMD를 실행하기 위해서는 Tools-Run PMD-pre Defined-ALL 을 선택하면 취약점을 알려주는 실행창이 뜸
SystemPrintln이라고 떴는데 이 경우에는 System.out.println의 사용을 피하고 전용 logger를 권장한다는 문구가 뜬 것임.
이번 포스팅 결론
- 기본 룰셋 사용(여러 ver)
- SQL Injection, OS Injection, 안드로이드는 찾을 수 없었음
- 캐치 블락, 변수명, 클래스 네임 등만 분석 가능
- 암호화 알고리즘 설명은 없고, 하드코드만 설명해줌
- 사용 등에 대한 경고 위주로 보안 취약점은 설명이 없음
- 단점 : 룰셋이 여러 개라 선택해야 함, 복잡한 분석 및 어려운 분석은 어려움.
다양한 분석 도구 중 내가 맡았던 것이 PMD였는데 다른 팀원분들의 조사 결과 SonarQube를 중점적으로 찾아보는 것으로 결론남.
