SW보안약점진단원 : 구현단계 - 보안기능 (1/2)

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()