SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다. (입보시에캡코아)
1. 입력데이터 검증 및 표현
2. 보안기능
2-1. 적절한 인증없는 중요기능 허용
2-2. 부적절한 인가
2-3. 중요자원에 대한 잘못된 권한 설정
2-4. 취약한 암호화 알고리즘 사용
2-5. 중요정보 평문 저장
2-6. 중요정보 평문 전송
2-7. 하드코드된 비밀번호
2-8. 충분하지 않은 키 길이 사용
2-9. 적절하지 않은 난수값 사용
2-10. 하드코드된 암호화 키
2-11. 취약한 비밀번호 허용
2-12. 사용자 하드디스크에 저장되는 쿠기를 통한 정보노출
2-13. 주석문 안에 포함된 시스템 주요 정보
2-14. 솔트없이 일방향 해쉬 함수 사용
2-15. 무결성 검사 없는 코드 다운로드
2-16. 반복된 인증시도 제한 기능 부재
3. 시간 및 상태
4. 에러처리
5. 코드오류
6. 캡슐화
7. API 오용
이 장에서는 "2.보안기능" 에 대한 점검항목을 설명한다. (첫번째)
2-1. 적절한 인증없는 중요기능 허용
< Key Point >
개인정보수정, 계좌이체등 중요기능은 재인증을 다시 할것!!
물론 재인증시에는 "보안기능 결정에 사용되는 부적절한 입력값 " 처럼 Session정보 이용)
| 구분 | 설명 |
| 원인/영향 | 적절한 인증없이 패스워드 등 개인정보를 열람,수정을 허용하는 경우 공격자가 정보를 변조할 수 있다. 예) 회원정보수정시 로그인한 사용자와 요청한 사용자의 일치여부를 확인하지 않는 경우 |
| 대응 | ① 중요한 정보에 대한 열람,수정시 재인증을 한다. ② 안전하다고 확인된 라이브러리나 프레임워크(OpenSSL, ESAPI의 보안기능) 를 적용한다. |
2-2. 부적절한 인가
< Key Point >
: 삭제 권한
| 구분 | 설명 |
| 원인/영향 | 권한이 있는 사용자만 사용가능한 기능에 대해 올바른 접근권한이 체크되지 않으면 권한없는 사용자가 우회해서 해당 기능을 사용할 수 있다. |
| 대응 | ① URL을 조작을 통해 리소스에 직접 접근할수 없도록 한다. ② 파라미터 조작을 통해 직접 기능수행을 할수 없도록 한다. ③ ACL을 이용하여 권한체크를 한 후 기능수행을 허용한다. (해당 사용자에게 delete권한이 있는지 확인한 후 삭제작업을 수행한다.) |
2-3. 중요자원에 대한 잘못된 권한 설정
< Key Point >
: 파일에 대한 접근권한
| 구분 | 설명 |
| 원인/영향 | 중요자원에 대해 읽기,쓰기 권한을 잘못 설정하는 경우 인가되지 않은 사용자가 그 자원을 사용할수있음 (예) system.ini 파일 |
| 대응 | ① 설정파일,환경파일,라이브러리등은 관리자만 읽고 쓸수 있도록 설정한다. ② 중요자원 접근시 인가받은 사용자인지 다시 한번 확인한다. |
2-4. 취약한 암호화 알고리즘 사용
| 구분 | 설명 |
| 원인/영향 | 중요정보를 암.복호화할때 취약한 암호 알고리즘을 사용하는 경우 중요정보가 노출될수 있다 |
| 대응 | ① 자체알고리즘보다는 검증된 표준화된 알고리즘 사용 ② DES,RS5 는 취약 , 대칭키(3DES,AES,SEED,ARIA) , 비대칭(RSA,ECC) , 해시(SHA-2) 사용 |
2-5. 중요정보 평문 저장
| 구분 | 설명 |
| 원인/영향 | 패스워드 등 개인정보는 암호화하지 않고 저장시 유출될 수 있다. (예) GetPassword() 식으로 다른곳에서 패스워드를 가져오는거라면 안전하다고 판단.. |
| 대응 | ① 중요정보는 반드시 암호화된 형태로 보관한다. ② 삭제할 때도 민감한 데이터는 안전하게 삭제한다. |
2-6. 중요정보 평문 전송
| 구분 | 설명 |
| 원인/영향 | 중요정보전송시 암호화하지 않거나 안전하지 않은 채널로 전송시 스니핑을 통해 노출될수 있다 (예) String password = getPassword(); <-- 안전 o.wirte(password); <-- 패스워드를 암호화하지 않고 바로 쓰기(전송) Cipher c = Cipher.getInstance("AES/CBC/PKCSSPadding); encPassword = c.update(password.getBytes()); <-- 패스워를 AES알고리즘으로 암호화 o.write(encPassword, 0 , encPassword.length); <-- 암호화된 패스워드를 write(전송) |
| 대응 | ① 로그인은 반드시 HTTPS를 이용한다. ② 중요정보는 암호화해서 전송한다. ③ 쿠키에 중요정보가 있을경우 보안속성을 활성화한다. 유효기간(MaxAge, Expired) secure속성 활성화 (setSecure(true);) HttpOnly속성 활성화 (SetHttpOnly(True);) |
2-7. 하드코드된 비밀번호
| 구분 | 설명 |
| 원인/영향 | 프로그램 내부코드에 비밀번호를 하드코딩하는 경우 노출위험 |
| 대응 | ① 비밀번호는 암호화하여 별도파일이나 DB에 저장하여 사용 ② 최초비밀번호 모드를 두어 사용자가 직접 비밀번호를 설정할 수 있게 설계 |
2-8. 충분하지 않은 키 길이 사용
| 구분 | 설명 |
| 원인/영향 | 암호화에 사용되는 키 길이가 충분히 길지 않은 경우 공격자가 쉽게 키를 찾아낼수 있게 된다. (예) KeyGen = c.getInstance("RSA"); keyGen.initialize(1024); <-- 공개키방식에서 1024 bit의 키 길이는 취약함 |
| 대응 | ① 대칭키(AES,3DES,SEED,ARIA) - 128bit 이상 ② 공개키(RSA) - 2048bit 이상 |
2-9. 적절하지 않은 난수값 사용
| 구분 | 설명 |
| 원인/영향 | 예측 가능한 난수를 발생시키는 취약한 API를 사용하는 경우 공격자는 다음 난수를 예측할수 있어 시스템 공격이 가능해진다. (예) import java.Math; int ran = (int)(random() * scope) - 1 ; <-- 취약한 math.random() 함수 사용 import java.util.random; Random jur = new Random(); <-- 안전한 util.random() 함수사용 jur.setSeed(new date().getTime()); <-- seed설정으로 인해 안전함. |
| 대응 | ① 취약한 난수발생함수 - java.lang.Math.random() ② 안전한 난수발생함수 - java.util.Random() java.security.SecureRandom() |
'정보보안' 카테고리의 다른 글
| SW보안약점진단원 : 구현단계 - 시간 및 상태 (0) | 2019.11.26 |
|---|---|
| SW보안약점진단원 : 구현단계 - 보안기능 (2/2) (0) | 2019.11.25 |
| SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (2/2) (0) | 2019.11.23 |
| SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (1/2) (0) | 2019.11.22 |
| SW 개발보안 가이드 : 분석/설계단계 - 에러처리 와 세션통제 (0) | 2019.11.21 |