Sonarqube Custom Ruleset 정의의 기준 (with 행자부 보안취약점 대응, OWASP top 10 2020)

현 Sonarqube 버전에 맞는 Ruleset을 재정의를 하라는 작업을 받았다. 전에 작성했던 글과 연장선상에 있는 글이다. 새로 나온 수많은 Sonar way를 다 사용할수는 없다. 이중에서 골라서 사용을 해야 한다. 하지만 무슨 근거로 골라야하나? QA 활동을 해본적이 없는데 난감한 상황이었다. 그냥 내가 위험할것 같으면 적용을 하고 아닌거 같으면 빼야 하나? 아니다.. 정답?은 있었다. 바로 행자부(행정안전부)에서 보안취약점 대응표, OWASP 10을 기준으로 Ruleset을 정하면 된다. 

 

 

SonarQube 행자부 보안취약점 대응표

• FB: FindBugs
• FSB: FindSecurityBugs
• SQ: SonarQube 자체 지원

No.		행자부 SW 보안약점	FB	FSB	PMD	SQ
1	입력데이터 검증 및 표현	SQL 삽입	O	O		CWE-89
2		경로 조작 및 자원 삽입	O	O		CWE-99
3		크로스사이트 스크립트	O	O		CWE-79, RSPEC-5131
4		운영체제 명령어 삽입		O		CWE-78
5		위험한 형식 파일 업로드				CWE-434
6		신뢰되지 않는 URL 주소로 자동접속 연결		O		CWE-601
7		XQuery 삽입				CWE-652
8		XPath 삽입		O		CWE-643
9		LDAP 삽입		O		CWE-90
10		크로스사이트 요청 위조				CWE-352
		디렉토리 경로 조작				CWE-22(23,36)
11		HTTP 응답분할	O	O		CWE-113
12		정수형 오버플로우				CWE-190
13		보안기능 결정에 사용되는 부적절한 입력값		O		CWE-807
14		메모리 버퍼 오버플로우 (C-Language)		O		CWE-119
15		포맷 스트링 삽입				CWE-134
16	보안기능	적절한 인증 없는 중요기능 허용				CWE-306
17		부적절한 인가				CWE-285
18		중요한 자원에 대한 잘못된 권한 설정				CWE-732
19		취약한 암호화 알고리즘 사용		O		CWE-327
20		중요정보 평문저장		O		CWE-312
21		취약한 암호화 알고리즘 사용		O	x
22		하드코드된 비밀번호	O	O		CWE-798, CWE-259
23		충분하지 않은 키 길이 사용		O		CWE-326, Link
24		적절하지 않은 난수값 사용	O	O		CWE-330
25		하드코드된 암호화 키		O		CWE-798, CWE-259
26		취약한 비밀번호 허용				CWE-521
27		사용자 하드디스크 저장되는 쿠키를 통한 정보노출				CWE-539
28		주석문 안에 포함된 시스템 주요정보				CWE-615
29		솔트 없이 일방향 해쉬 함수 사용				CWE-759
30		무결성 검사없는 코드 다운로드				CWE-494
31		반복된 인증시도 제한 기능 부재				CWE-307
32	시간 및 상태	경쟁조건: 검사시점과 사용시점 (TOCTOU)				CWE-367
33		종료되지 않은 반복문 또는 재귀 함수	O			CWE-835
34	에러처리	오류 메시지를 통한 정보노출			O	CWE-209
35		오류 상황 대응 부재			O	CWE-390
36		부적절한 예외 처리	O		O	CWE-754
37	코드오류	Null Pointer 역참조	O		O	CWE-476
38		부적절한 자원 해제	O		O	CWE-404
39		해제된 자원 사용				CWE-416 (C language)
40		초기화되지 않은 변수 사용				CWE-457 (C language)
41	캡슐화	잘못된 세션에 의한 데이터 정보노출				CWE-488, CWE-543
42		제거되지 않고 남은 디버그 코드				CWE-489
43		시스템 데이터 정보노출				CWE-497
44		Public 메소드부터 반환된 Private 배열	O		O	CWE-495
45		Private 배열에 Public 데이터 할당			O	CWE-496
46	API 오용	DNS Lookup에 의존한 보안결정				CWE-247
47		취약한 API 사용				CWE-676

출처 : confluence.curvc.com/pages/viewpage.action?pageId=33327477

 

SQ(Sonarqube)에 몇몇 링크가 연결이 안되는점이 아쉽다. 

 

 

OWASP 10 (2020 ver)

OWASP TOP 10	DESC	action
1. 인젝션  ( Injection )	인젝션 취약점은 오류메시지에서 민감한 정보가 유출 등등 바람직하지 않고 위험한 결과를 초래 할 수 있습니다. 사용자로 부터 입력받은 값을 이용해 데이터 베이스 접근을 위한 쿼리( Query )를 만들며 SQL injection, LDAP injection 또는 파일 시스템 injection 에 한정 되지 않는다. 응용 프로그램 ( 양식 필드 또는 검색어 )에 사용자가 제공하는 데이터를 취하고 적절한 입력 유효성 검사 없이 서버나 데이터베이스를 통과 할 때 주입 결함이 발생 한다. 해커는 응용프로그램을 악용 의도로 문자열을 만들 수도 있다.	- 서버 측 입력 검증, 특수문자 필터링 및 유효성 검사 - 화이트리스트 조합 사용
2. 인증 취약점  ( Broken  Authentication )	인증 취약점은 2013년 부터 OWASP TOP 10에 취약점 목록에서 빠지지 않고 나오고 있습니다. 잘못 구성된 인증 시스템은 공격자가 합법적인 사용자로 가장할 수 있으으며 손상된 암호, 세션 토큰 등등 으로 이에따른 기술적 영향은 심각하다. 만약에 인증 취약점이 발생 한다면 다른 사람으로 로그인을 통해 해당 자원에 접속 할 수 있다.	- 멀티 팩터 ( multi-factor ) 인증을 구현 - 기본 자격 증명 사용 금지 - 높은 수준의 암호 정책 구현 - 지연 로그인, 무작위 세션 ID , 세션 시간 초과 등등 으로 제어 실패한 로그인 시도 기록(log)
3. 민감한 데이터 노출  ( Sensitive  Data Exposure )	일반적으로 암호화 되어야 하는 정보( 금융 정보, 건강기록 등등 )들을 일반 텍스트로 볼 수 있다. 중간자 공격을 통하여 해커는 전송중에 데이터를 도용 및 탈취하여 악의적인 목적으로 사용할 수 있고 이러한 민감한 데이터 노출은 지난 몇 년 동안 점점 일반화가 되어가고 있다.	- 암호화를 적용 하고 적절한 키 관리 및 표준 알고리즘 사용 - 불필요한 데이터에 민감한 데이터를 포함하는 응답을 피한다. - 캐싱 비활성화
4. XML 외부 엔티티  ( XXE )	XXE는 XML 문서에 외부 참조로 포함된 일부 페이로드가 처리되고 실행될 수 있는 응요프로그램에서 XML 파서를 할용 한다. 이 취약점은 정적 분석도구를 운영하는 회사들의 의해 반환된 통계를 바탕으로 리스트에 추가되었습니다. 지난 몇 년 동안 XML처리의 취약점이 꾸준히 증가하여 웹 어플리케이션에 더욱 심각한 위험이 되고 있습니다. 공격자가 XML 파일에 이러한 엔티티를 추가하거나 수정하여 아그이적인 소스를 가르킬 경우 디도스( DoS ) 공격이나 SSRF 공격을 일으킬 수 있습니다. 그들은 또한 내부 시스템을 스캔하고, 포트 스캔을 실행하고, 데이터 추출하는 등의 작업을 할 수 있습니다.	- XML 문서 내의 적대적 데이터를 방지하기 위해 서버측 입력 유효성 검사, 삭제  검사 등을 구현 - XML 외부 엔티티 및 DTD 처리를 사용하지 않도록 설정 - Timeout을 설정 - JSON과 같은 덜 복잡한 형식을 사용하고, 중요한 데이터의 연속화를 방지하고, 모든 XML 프로세스 및 라이브러리 패치
5. 취약한 접근 제어  ( Broken  Access Control )	취약한 접근 제거는 수동 인증 및 권한 제어 기능이 망가진 곳에 공격자가 권한을 부여받아 사용자로서 허가를 우회하여 접속할 수 있도록 하는 접속 제어 시스템의 취약성을 말한다. 예를 들어, 애플리케이션은 사용자가 URL의 일부를 수정하는 것만으로 로그인한 계정을 변경할 수 있게 할 수 있다.	- 공공 자원이 예외인 경우 기본적으로 다른 모든 자원을 거부하고 액세스 제어 실패 및 알림 관리자에 대한 로그를 유지 - 애플리케이션 전체에 걸쳐 교차 출처 리고스 공유( Cross-Origin Resource Sharing, CORS ) 사용을 최소화하는 등 액세스 제어 검사를 구현
6. 보안 구성 오류  ( Security  Misconfigurations )	이 범주는 응용 프로그램 데이터를 안전하게 유지하는 광범위한 제어장치의 부적절한 구현을 이야기한다. 보안 헤더를 잘못 구성하고, 민감한 정보를 누출하는 장황한 오류 메시지를 무시하며, 패치 또는 업그레이드 시스템을 무시하며, 기본 구성을 사용하는 것은 모두 이 취약점을 야기할 수 있다. 동적 어플리케이션 보안 테스트 (DAST )등등 을 이용하여 잘못된 구성을 감지 할 수 있다.	- 시스템 강화 프로세스를 포함하여 안전한 설치 프로세스 구현, 불필요하고 사용되지 않는 기능 또는 프레임워크 제거 - 제로 트러스트 모델 구현하고 나머지는 차단 하면서 원하는 동작만 허용하는 "segmented application architecture(세그먼트 애플리케이션 아키텍처)"를 활용, 컨테이너화 또는 ACL을 통해 구성요소 또는 이용자 간의 안전한 분리를 제공하는데 도움이 됨 - 사용 권한 검토 및 업데이트
7. 크로스사이트 스크립팅  ( Cross-Site Scripting  = XSS )	공격자는 기본적으로 다른 사람의 웹 응요 프로그램의 페이지 출력에 스크립트를 주입하며 브라우저는 그것이 페이지의 일부라고 믿게 되고 스크립트를 실행하게 되는 것이다. EX) 공격자가 피해자에게 악성 링크가 있는 이메일을 보내서 신뢰할 수 있는 출처에서 온 것처럼 보이게 할 수 있다. 링크를 클릭하면 코드는 피해자의 웹 브라우저에서 실행되며 세션, 쿠기, 사용자 자격 증명을 훔치거나 악성코드를 전달하는 데 사용 될 수 있음	- 상황에 맞는 인코딩을 적용 - 콘텐트 보안정책 (CSP = Content Security Policy)를 경감 대책 활성화 - 엔티티 적용
8. 안전하지 않은 역 직렬화  ( Insecure Deserialization )	직렬화 개념은 응용 프로그램 코드에서 객체를 가져다가 바이트 스트림으로 변환하거나 디스크에 저장하는 등의 다른 용도로 사용 할 수 있는 형식으로 변환하는 것이다. 탈선화는 그 반대인 직렬화된 데이터를 애플리케이션에서 사용할 수 있는 객체로 다시 변환하는 것을 말한다. 이 공격은 이러한 데이터 객체가 다른 쪽 끝에서 탈선화되면 분산된 서비스 거부(DoS) 공격이나 원격 코드 실행과 같은 심각한 결과를 초래할 수 있도록 변조 되는 것을 말함	- 신뢰할 수 없는 출처에서 직렬화 된 객체를 허용 금지 - 무결성 검사 구현, 제약 조건 적용 - 모니터링하면서 예외와 오류를 기록
9. 알려진 취약점과 구성 요소 사용  ( Using Components with  Known vulnerabilities )	라이브러리 등의 구성요소를 사용하여 먼저 그 합법성을 검증하지 않거나 해당 구성요소의 업데이트된 버전을 사용하지 않고 특정 기능을 구현하는 광범위한 문제를 언급한다.	클라이언트 및 서버 측 구성 요소의 종속성과 함께 버전 업데이트 및 패치, 모니터링
10. 불충분한 로깅 및 모니터링  ( Insufficient logging  ans monotoring )	데이터 침해를 감지하기 위해 조직은 웹 응용 프로그램의 맥락에서 관심 있는 이벤트를 기록해야 합니다.  로깅은 동일한 IP에서 반복적으로 실패한 로그인 시도와 같은 웹 으용프로그램에서 이벤트 또는 보안 발생을 기록하는 것을 말합니다. 모니터링은 이러한 로그를 지속적으로 주시하여 적절한 조치를 위해 사고 대응팀으로 이관하는 것을 말합니다.	- 의심스러운 활동 ( EX: 로그인 실패, 액세스 제어 실패, 입력 유효성 검사 실패 등등 )을 기록하여 중앙 집중식 로그 관리 솔루션에 입력될 수 있는 형식 - 변조 또는 삭제를 방지하기 위해 중요한 거래에 대한 세부 감사 추적 유지 사고 대응 및 복구 계획 수립

참고 : pr0vervbi0rum.tistory.com/30

 

하지만 막막했던 Ruleset 정의를 이것들을 보며 기준을 잡고 설정을 해나가면 될듯 하다. 

 

끝!