728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용
       7-1.DNS Lookup 에 의존한 보안결정
       7-2. 취약한 API사용

이 장에서는 "7.API 오용" 에 대한 점검항목을 설명한다.


7-1.DNS Lookup 에 의존한 보안결정

구분 설명
원인/영향 DNS Lookup 명령어를 통해 얻은 도메인명을 가지고 유효성을 판단하는 경우 DNS 위변조시에는
잘못된 도메인명에 의해서 트래픽이 공격자를 경유하게 될 수도 있고, 공격자가 마치 동일 도메인에
속한 서버인 것처럼 위장할 수 있다
대응 ① 보안결정에 DNS 조회결과를 사용하지 않는다. -> IP주소를 직접 참조한다.

취약)
String ip = req.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip); <-- ip에 대한 도메인명을 조회
if (addr.getCanonicalHostName().endWidth('trustme.com")) {  <-- 조회된 도메인명으로 체크
      ………….
}

안전)
String ip = req.getRemoteAddr();
if (ip == null || "".equals(ip)) return;
String trustedAddr = "127.0.0.1" ;
if (ip.equals(trustedAddr)) {    <-- ip 주소값으로 체크
       .........
 }



7-2. 취약한 API사용

구분 설명
원인/영향 ① J2EE 애플리케이션이 컨테이너에서 제공하는 자원연결관리를 사용하지 않고 직접 제작하는 경우
② J2EE 애플리케이션이 프레임워크 메소드를 호출하지 않고 Socket을 직접 사용하는 경우
③ J2EE 애플리케이션에서 System.exit() 사용은 컨테이너까지 종료시킨다. 
대응 ① 컨테이너에서 제공하는 자원연결관리 기능을 사용한다
② Socket 을 직접 사용하지 않고 프레임워크 메소드를 호출하여 사용한다.
③ J2EE 애플리케이션에서 System.exit() 을 사용하지 않는다.

취약) conn = DriverManager.getConnection(url, user, pw);   <-- 자원에 대한 직접 연결 하고 있음
안전) DataSource datasource = (Datasource) ctx.lookup(CONNECT_STRING);  <-- 연결 스트링
        conn = datasource.getConnection():  

취약) socket = new Socket ("kisa.co.kr", 8080) ;    <-- 소켓으로 직접 연결 시도
안전) URL url = new URL ("http://127.0.0.1:8080/DataServlet");
       URLConnection urlConn = url.openConnection();

취약) catch (EXception e) {
           System.exit(1);
       }

 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

CISA CPE 등록하기  (0) 2019.12.04
소스코드 보안약점 진단 후기...  (0) 2019.12.01
SW보안약점진단원 : 구현단계 - 캡슐화  (0) 2019.11.29
SW보안약점진단원 : 구현단계 - 코드오류  (0) 2019.11.28
SW보안약점진단원 : 구현단계 - 에러처리  (0) 2019.11.27
728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
      6-1.잘못된 세션에 의한 데이터 정보 노출 (싱글톤 멤버변수)
      6-2. 제거되지 않고 남은 디버그 코드
      6-3. 시스템 데이터 정보 노출
      6-4. Public 메소드로부터 반환된 Private 배열  (Get함수)
      6-5. Private 배열에 Public 데이터 할당 (Set함수)
  7. API 오용

이 장에서는 "6.캡슐화" 에 대한 점검항목을 설명한다.
(두음 : 잘제시PP)



6-1.잘못된 세션에 의한 데이터 정보 노출 (싱글톤 멤버변수)

구분 설명
원인/영향 다중스레드환경에서 Servlet, JSP, Controller 등 싱글톤으로 존재하는 객체들의 멤버변수가
여러 스레드에 의해 공유되면서 다른 스레드에게 정보를 노출시킬 수 있다.
대응

 ① 싱글톤 패턴을 사용하는 경우, 변수 범위(scope)에 주의하여 사용한다
② java에서 HttpServlet 클래스의 하위클래스나 JSP, Controller 에서 멤버변수를 선언하지 
   않도록 하고 필요한 경우 지역변수를 선언하여 사용한다

취약) <%! 
             String username = "/";   <-- 멤버변수로 선언
       %>

안전) <%
             String username = "/";    <-- 지역변수로 선언
       %>
취약) 
 @controller
public class TrendForecastController {
   pirvate  int  currentPage = 1 ;<-- Controller에서 멤버변수로 선언되어 스레드간 공유
   public void doSomething(HttpServletRequest request) {
        currentPage = integer.parseInt(request.getParameter("page"));
   }

취약)  
@controller
public class TrendForecastController {
    public void doSomething(HttpServletRequest request) {
         int currentPage = integer.parseInt(request.getParameter("page")); <-- 지역변수
         }
  }



6-2. 제거되지 않고 남은 디버그 코드

구분 설명
원인/영향 디버그 용도로 삽입된 코드가 제거되지 않고 남아 있어서 공격자가 그 정보를 이용해서 공격가능
대응 ① SW배포전 반드시 디버그 코드를 삭제한다.
② 디버그 용도로 개발한 main()함수는 디버깅이 끝나면 삭제한다.



6-3. 시스템 데이터 정보 노출

구분 설명
원인/영향 예외 상항 발생시 오류처리가 제대로 이루어지지 않아서 시스템의 오류메시지가 사용자에게
노출되어 내부시스템, 데이터베이스, 프로그램 구조에 대한 정보가 노출될 수 있다.
  ->"에러처리 4.1 오류메시지를 통한 정보노출" 과 비슷..
대응 ① 예외처리시 시스템정보를 노출하는 getMessage() 함수 사용을 금한다.
② 시스템 설정을 통해 오류가 발생하는 경우 default 오류 페이지가 노출될 수 있도록 한다.

취약) catch (IOException e) {
           System.err.print(e.getMessage());
       }

안전) catch (IOException e) {
           logger.error ("IOException Occurred!");
       }



6-4. Public 메소드로부터 반환된 Private 배열  (Get함수)

구분 설명
원인/영향 private으로 선언된 배열을 public으로 선언된 메소드를 통해 반환하는 경우 그 배열의 레퍼런스가
외부에 공개되어서 외부에서 악의적으로 그 캡슐화된 배열의 값을 수정할수 있다.
대응 ① 배열 반환시 배열의 복제본을 반환한다.
② 배열을 그대로 반환하는 경우라면 수정을 제어하는 별도 Public 메소드를 선언하여 사용한다.

취약) private String[] colors ;      <-- private 배열 멤버변수 선언
       public String[] getColor() {
            return this.colors;       <-- 배열 멤버변수를 그대로 리턴
        }

안전) private String[] colors ;      <-- private 배열 멤버변수 선언
       public String[] getColor() {
            String[] copyArray = null;  <-- 복제본 변수 선언
            if (this.colors != null) {
                 copyArray = new String[this.colors.length];
                 for (int i = 0 ; i < this.colors.length ; i++)
                 {
                   copyArray[i] = this.colors[i] ;<-- 복제본 변수에  멤버변수값을 복사
                  }
                 return copyArray;       <-- 복제본 변수 리턴
       }



6-5. Private 배열에 Public 데이터 할당 (Set함수)

구분 설명
원인/영향 Public 메소드에 입력된 데이터를 Private 배열에 저장하는 경우 Private 배열의 레퍼런스가
공개되어 외부에서 이 레퍼런스를 이용해서 private배열의 값을 임의 수정할 수 있다.
대응 ① Public함수에서 데이터를 전달 할 때 "레퍼런스"가 아닌 "값" 자체를 전달해서
    Private배열에 할당함으로써 Private멤버로서의 접근권한을 유지한다.

취약) private String[] datas ;      <-- private 배열 멤버변수 선언
       public void setDatas (String[] datas) {
            this.datas = datas <-- 외부에서 입력한 배열데이터를 그대로 멤버변수에 셋팅
        }

안전) private String[] datas ;      
       public String[] setDatas (String[] datas) {
            if (datas != null) {
                 this.datas =  new String[datas.length];
                 for (int i = 0 ; i < datas.length ; i++)
                 {  
                     this.datas[i] = datas[i] ;   <-- 멤버변수에 값을 복사
                  }  
       }

 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

소스코드 보안약점 진단 후기...  (0) 2019.12.01
SW보안약점진단원 : 구현단계 - API 오용  (0) 2019.11.30
SW보안약점진단원 : 구현단계 - 코드오류  (0) 2019.11.28
SW보안약점진단원 : 구현단계 - 에러처리  (0) 2019.11.27
SW보안약점진단원 : 구현단계 - 시간 및 상태  (0) 2019.11.26
728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
      5-1. Null Pointer 역참조
      5-2. 부적절한 자원 해제
      5-3. 해제된 자원 사용
      5-4. 초기화되지 않은 변수 사용
  6. 캡슐화
  7. API 오용

이 장에서는 "5.코드오류" 에 대한 점검항목을 설명한다.
(두음 : 널부해초)


5-1. Null Pointer 역참조

구분 설명
원인/영향 Null로 설정된 참조변수의 주소값을 참조하는 경우 공격자는 의도적으로 널포인트 역참조를 
유발하여 그 결과로 발생하는 예외상황을 이용하여 추후의 공격을 계획하는데 사용할 수 있다
대응 ① 참조변수를 레퍼런스하기전에 NULL인지 검사한다

취약) public static int cardinality (Object obj, final Collection col) {
         if (obj.equals("aaa")) {  <-- object 파라미터값을 null검사 안하고 바로 사용
         }

안전) public static int cardinality (Object obj, final Collection col) {
         if (null != obj && obj.equals("aaa")) {  <-- object 파라미터값을 null검사
         }



5-2. 부적절한 자원 해제

구분 설명
원인/영향 자원(메모리,DB연결,파일..) 들을 사용후 반드시 해제하여야 하는데 부적절한 로직 및 코드누락으로
자원해제가 안될경우 자원고갈로 인해 오류가 발생한다
대응 ① 자원할당후 반드시 자원해제가 되도록 코드를 작성한다
② 자바의 경우 자원해제코드는 finally 블록에 기술해서 누락되지 않도록 한다


5-3. 해제된 자원 사용

구분 설명
원인/영향 C,C++ 에서는 개발자가 자원을 직접 해제해야하는 경우 해제된 자원을 다시 해제하거나
해제된 자원을 다시 사용하는 경우 오류발생
취약) free(temp);
       stmcpy(temp, argv[1], BUFFER_SIZE-1);   <-- temp해제후 다시 사용
대응 ① 자원해제 후 그 메모리를 참조하고 있던 포인터를 참조 추적이나 형변환
  , 수식에서의 피연산자 등을 사용하여 해제된 메모리에 접근하지 못하도록 한다.
② 자원해제 후 포인터에 NULL을 저장하거나, 다른 적절한 값을 저장하면 예상치 못한 
   코드의 실행을 막을수 있다



5-4. 초기화되지 않은 변수 사용

구분 설명
원인/영향 C언어에서 스택 메모리에 저장되는 지역변수는 생성시 자동으로 초기화 되지 않는데
, 이 변수를 그냥 참조할 경우 이전에 이 메모리에 저장되어 있던 데이터를 의도치 않게
참조하게 되어 악성코드가 실행될 수 있다
대응 ① 모든 변수는 사용전에 반드시 올바른 초기값을 할당한다
취약) int x , y ;
안전) int x = 0 , y = 0 ;



728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

SW보안약점진단원 : 구현단계 - API 오용  (0) 2019.11.30
SW보안약점진단원 : 구현단계 - 캡슐화  (0) 2019.11.29
SW보안약점진단원 : 구현단계 - 에러처리  (0) 2019.11.27
SW보안약점진단원 : 구현단계 - 시간 및 상태  (0) 2019.11.26
SW보안약점진단원 : 구현단계 - 보안기능 (2/2)  (0) 2019.11.25
728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
      4-1. 오류메시지를 통한 정보노출
      4-2. 오류 상황 대응 부재
      4-3. 부적절한 예외 처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "3.에러처리" 에 대한 점검항목을 설명한다.


4-1. 오류메시지를 통한 정보노출

구분 설명
원인/영향 오류메시지에 시스템정보와 같은 민감한 정보가 노출되어 공격에 활용할 수 있다.
취약) e.printStackTrace();  <-- 스택정보가 노출됨.
안전) logger.error("ERROR-01 : 파일 열기 에러");  <-- 별도 에러코드 정의
대응 ① 시스템오류 메시지 대신에 별도의 오류메시지를 정의하여 출력해준다.

 

4-2. 오류 상황 대응 부재

구분 설명
원인/영향 발생한 오류에 대해서 아무런 조치를 하지 않아 프로그램이 비정상적인 상태로 실행되는 겅우

취약) catch (Exception e) {
          // do nothing
       }
   
안전) catch (Exception e) {
          s.setMessage(e.getMessage());  <-- 원래 e.getMessag()는 시스템정보 노출
          return (makeLogin(s));
       }    
안전) catch (Exception e) {
         logger.error("ERROR-01 : 파일 열기 에러");  <-- 별도 에러코드 정의
       }    
대응 ① 발생오류별로 적절한 에러처리 루틴이 작성되어야 한다.
② 특별히 처리해야할 루틴이 없는 오류라 하더라도 
    logger.error("에러상황에 대한 간단한 메시지 또는 에러코드") 가 수행될수 있어야한다



4-3. 부적절한 예외 처리

구분 설명
원인/영향 모든 오류에 대해 하나의 방식으로 예외처리를 하는 경우 각각의 상황에 따라 적절한 예외처리를 
할수 가 없어서 부적절한 Resource 관리로 인해 시스템이 중지될 수 있다.
대응 ① 각각의 예외상항에 대해 적절한 예외처리 코드를 수행할수 있도록 한다

취약) catch (Exception e) {
          System.err.println("Exception : " + e.getMessge());
       }

안전) catch (MalformedURLExcepton e) {
       }
       catch (IOExcepton e) {
       }
       catch (ParseExcepton e) {
       }
       finally {
       }



 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

SW보안약점진단원 : 구현단계 - 캡슐화  (0) 2019.11.29
SW보안약점진단원 : 구현단계 - 코드오류  (0) 2019.11.28
SW보안약점진단원 : 구현단계 - 시간 및 상태  (0) 2019.11.26
SW보안약점진단원 : 구현단계 - 보안기능 (2/2)  (0) 2019.11.25
SW보안약점진단원 : 구현단계 - 보안기능 (1/2)  (0) 2019.11.24
728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
  2. 보안기능
  3. 시간 및 상태
      3-1. 경쟁조건: 검사시점과 사용시점 (TOCTOU)
      3-2. 종료되지 않은 반복문 또는 재귀함수
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "3.시간 및 상태" 에 대한 점검항목을 설명한다.



3-1. 경쟁조건: 검사시점과 사용시점 (TOCTOU)

구분 설명
원인/영향 병렬실행환경에서 자원을 검사하는 시점(TOC)과 사용하는 시점(TOU)의 상태가 
달라서 교착상태에 빠지거나 동기화오류가 발생할 수 있다.
대응 ① 공유자원에 대해서는 여러 스레드의 접근을 위해서 동기화 구문을 적용한다.
② 동기화는 성능에 영향을 미치므로 최소한의 임계코드 주변에만 적용한다.
    (SYNCHRONIZED)



3-2. 종료되지 않은 반복문 또는 재귀함수

구분 설명
원인/영향 재귀함수의 순환횟수 또는 귀납조건을 설정하지 않아 무한루프에 빠지게 되어 자원을 고갈

취약) int factorial (int i) {
        return I * factorial(ii-1);
    }

안전) int factorial (int i) {
        if (I <= 1) {     
           return I;
        }
        return I * factorial(ii-1);
    }
대응 ① 재귀함수 사용시 재귀호출횟수를 제한하거나, 초기값을 설정하여 재귀호출을 제한한다

 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

SW보안약점진단원 : 구현단계 - 코드오류  (0) 2019.11.28
SW보안약점진단원 : 구현단계 - 에러처리  (0) 2019.11.27
SW보안약점진단원 : 구현단계 - 보안기능 (2/2)  (0) 2019.11.25
SW보안약점진단원 : 구현단계 - 보안기능 (1/2)  (0) 2019.11.24
SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (2/2)  (0) 2019.11.23
728x90
반응형
SMALL

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-10. 하드코드된 암호화 키

구분 설명
원인/영향 암호화에 사용되는 키를 소스코드에 하드코딩한 경우 실행파일을 역컴파일하면 
키값이 유출될수있다.
(예)  String Key = "222##FFd:Fdrfdfs;  <-- 하드코딩된 키값을 그대로 사용
      sKeySpec = new.SecretKeySpec(Key.getBytes(), "AES");
  
      String Key = getPassword("./password.ini");  <-- 키값을 안전한 곳에서 가져온다.
      Key = decrypt(Key);  <-- 복호화해서 사용한다.
대응 ① 암호화 키는 암호화하여 별도 안전한 곳에 저장하여야 한다.




2-11. 취약한 비밀번호 허용

구분 설명
   
원인/영향 비밀번호 조합규칙이 미흡한 경우 패스워드 사전공격이나 Brute Force 공격에 의해 
노출될수 있다.
(예) String id = request.getParameter("id");
     String pwd = reqeust.getParameter("pwd");
     registDAO.regist(id,pwd);    <-- 조합규칙 체크없이 바로 등록

     String id = request.getParameter("id");
     String pwd = reqeust.getParameter("pwd");
     Pattern pattern = Pattern.Compile("((?=.*[a-zA-Z])(?=.*[0-9]).{10,})");
     Matcher matcher = pattern.matcher(pwd);  <-- 패턴을 체크
     if (!matchermatches()) {
           return "비밀번호 조합규칙 오류";
     }
대응 ① 3가지 종류의 문자,숫자,특수문자로 8자리 이상
② 2가지 종류의 문자,숫자,특수문자로 10자리 이상
③ 한글,영어등 사전적 단어 포함 금지
④ 널리 알려진 단어 사용 금지
⑤ 사용자ID와 연관있는 단어 사용금지
⑥ 3자가 쉽게 알수 있는 개인정보 포함 금지
⑦ 패턴이 존재하는 비밀번호 사용금지
⑧ 숫자와 영문자를 비숫한 문자로 치환한 형태를 포함한 구성의 비밀번호 사용 금지
⑨ 이전 비밀번호와 연관성 있는 단어 사용 금지



2-12. 사용자 하드디스크에 저장되는 쿠기를 통한 정보노출

구분 설명
원인/영향 개인정보 등 중요한 정보를 영속적인 쿠키에 저장함으로써 유출의 위험이 있고 
이를 통해 보안체계를 우회하는 공격이 수행될 수 있다
대응 ① 쿠키의 만료시간은 최소한으로 설정
② 영속적인 쿠키에는 중요정보를 저장하지 않는다.

   예) setMaxAge (60*60*24*30*12) ;    <-- 만료시간을 1년으로 설정..위험..
       setMaxAge (60*60*24); <-- 만료시간을 1일로 했지만 이것보다는 암호화해서 
                                         저장하는게 안전



2-13. 주석문 안에 포함된 시스템 주요 정보

구분 설명
원인/영향 개발자편의로 주석문안에 시스템 주요정보를 남겨두게 되면 역컴파일을 통해 쉽게 유출이
가능하며 이를 통해 공격자는 시스템공격이 가능
대응 ① 주석문에는 시스템 중요정보를 적지않는다.
② 개발시 필요해서 남겨둔 주석문이라면 개발완료후 확실하게 제거한다.



2-14. 솔트없이 일방향 해쉬 함수 사용

구분 설명
원인/영향 일방향 해쉬함수 사용시 salt 를 사용하지 않으면 공격자는 레인보우 테이블과 같이 
가능한 모든 해쉬값을 미리 계산한 후 전수조사를 통해 평문을 추출할 수 있다
대응 ① 해쉬함수 사용시 반드시 salt를 적용한다.

취약) md = MessageDigest.getInstance("SHA-256");
       md.update(password.getBytes());  <-- 패스워드만 입력하고
       byte byteData[] = md.digest();      <-- 해쉬한다. (즉 암호화한다)

안전) md = MessageDigest.getInstance("SHA-256");
       md.update(password.getBytes());
       md.update(salt);       <-- 해쉬하기 전에 salt를 추가 입력해준다.
       byte byteData[] = md.digest();   



2-15. 무결성 검사 없는 코드 다운로드

구분 설명
원인/영향 원격으로부터 소스코드나 실행파일을 다운로드하여 사용할 때 무결성 검사없이 
수행하는 경우 중간에서 해당 소스코드나 실행파일에 악성코드를 삽입하는 등 
위변조를 할수 있어서 의도하지 않은 결과를 유발할 수 있다
대응 ① 다운로드시 해쉬값을 첨부해서 전송하거나, 암호화해서 전송한다.
② 다운로드를 받은 후에는 무결성검사를 수행한 뒤 최소권한으로 실행한다.

취약) URL[] classURLs = new URL[] { new URL("file:subdir/")};
     URLClassLoader loader = new URLClassLoader(classURLs);
     Class loadedClass = Class.forName("LoadMe",true, loader);<-- 파일을 다운받아
                                                                바로 Load. 취약
     
안전) <서버측>
     String jarfile = "./download/util.jar";
     byte[] loadfile = FileManager.getBytes(jarfile);
     loadfile = encrypt(loadfile, privateKey);    <-- 다운로드할 파일을 개인키로 암호화
     FileManager.createfile(loadfile, jarFileName);  <-- 암호화된 파일을 생성함.

     <클라이언트측>
     URL[] classURLs = new URL[] { new URL("http://filesave.com/download/util.jar")}; <-- 다운로드
      ... 중간생략
     loadfile = decrypt(loadfile,publicKey); <-- 복호화
     FileManager.createfile(loadfile, jarFile) ;
     URLClassLoader loader = new URLClassLoader(classURLs);
     Class loadedClass = Class.forName("MyClass",true, loader); <-- 복호화된 파일을
                                                                   Load . 안전 



2-16. 반복된 인증시도 제한 기능 부재

구분 설명
원인/영향 인증기능 구현 시 인증시도 횟수를 적절한 로직으로 제한하지 않으면 
무작위 대입 인증시도 공격을 받을 수 있다.
대응 ① 인증시도 횟수 제한

안전) while ((isValidUser == 0) && (count < MAX_ATTEMPS)) {   < 횟수 제한 추가
       }

 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

SW보안약점진단원 : 구현단계 - 에러처리  (0) 2019.11.27
SW보안약점진단원 : 구현단계 - 시간 및 상태  (0) 2019.11.26
SW보안약점진단원 : 구현단계 - 보안기능 (1/2)  (0) 2019.11.24
SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (2/2)  (0) 2019.11.23
SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (1/2)  (0) 2019.11.22
728x90
반응형
SMALL

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()     
728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

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
728x90
반응형
SMALL

SW개발보안가이드중 구현단계에서의 점검항목은 크게 7가지 이다.  (입보시에코캡아)
  1. 입력데이터 검증 및 표현
      1-1. SQL삽입
      1-2. 경로조작 및 자원삽입
      1-3. 크로스 사이트 스크립트 (XSS) 
      1-4. 운영체제 명령어 삽입
      1-5. 위험한 형식 파일 업로드
      1-6. 신뢰하지 않은 URL주소로 자동 접속 연결
      1-7. XQuery 삽입
      1-8. XPath 삽입
      1-9. LDAP삽입
      1-10 크로스사이트 요청 위조 (CSRF)
      1-11 HTTP 응답 분할
      1-12 정수형 오버플로우
      1-13 보안기능 결정에 사용되는 부적절한 입력값
      1-14 메모리 버퍼 오버플로우
      1-15 포맷 스트링 삽입
  2. 보안기능
  3. 시간 및 상태
  4. 에러처리
  5. 코드오류
  6. 캡슐화
  7. API 오용

이 장에서는 "1.입력데이터 검증 및 표현" 에 대한 점검항목을 설명한다. (두번째)



1-6. 신뢰하지 않은 URL주소로 자동 접속 연결

구분 설명
원인/영향 외부입력값을 외부사이트로 이동할 주소로 사용하는 경우 공격자는 입력값을 조작하여 
피싱 사이트로 유도해서 XSS 공격을 할 수 있다.
대응 ① WhiteList - 자동 연결을 허용할 URL과 도메인을 목록으로 관리한다.
취약) String rd = request.getParameter("rediect");
       response.sendRedirect(rd);    

안전) String allowURL[] = { "/main.do","/login.jsp","list.do" }; <- 허용할 도메인 WhiteList 정의
       String rd = request.getParameter("rediect");
       rd = allowURL[Integer.parseInt(rd)];
       if (rd == 0) {
           response.sendRedirect(rd);
       ]



1-7. XQuery 삽입

구분 설명
원인/영향 외부입력값을 검증없이 XQuery 쿼리문 생성에 이용할 경우 조작된 입력값에 의해 데이터를
무단조회
대응 ① 필터링 - 외부입력값에 대해 특수문자 및 예약어를 필터링한다.
② 파라미터화된 쿼리문 - 정적쿼리로 쿼리문 구성
취약) String name = pros.getProperty("name");
       String es = "doc('user.xml')/userlist/user[ name='" + name + "' ]";

안전) String name = pros.getProperty("name");
       String es = "doc('user.xml')/userlist/user[ name='$xname' ] ";
       expr = conn.prepareExpression(es);
       expr.bindString(new QName("xname") , name , null);
       expr.executeQuery));



1-8. XPath 삽입

구분 설명
원인/영향 외부입력값을 검증없이 XPath 쿼리문 생성에 이용할 경우 조작된 입력값에 의해 데이터를 
무단조회
대응 ① 필터링 - 외부입력값에 대해 특수문자 및 예약어를 필터링한다.
② 파라미터화된 쿼리문을 지원하는 XQuery 표현식을 사용한다
안전) public String XPathFilter (String input) {
           if (input != null) return input.replaceAll("[ ' , \\[ ]" , "");  <-- ' , [  문자 치환
           
     // 외부입력값에 대해 필터를 적용한다.
     String name = XPathFilter(props.getProperty("name"));
     expr = xpath.compile("//user/user[login/text()=' + name + "']/home_dir/text()"); 
      ......



1-9. LDAP삽입

구분 설명
원인/영향 외부입력값을 LDAP필터문에 사용하는 경우 공격자는 입력값을 조작하여 정보를 유출하거나 조작
대응 LDAP필터에 사용되는 외부입력값에는 특수문자가 포함되지 않도록 제거한다.



1-10 크로스사이트 요청 위조 (CSRF)

구분 설명
원인/영향 공격자가 심어놓은 악성코드가 포함된 요청이 검증없이 서버로 전달될 때 희생자의 권한으로
악성코드가 실행되어 게시판자동글쓰기, 자동회원가입, 등의 공격이 수행될 수있다.
대응 ① POST방식 - 폼작성시 GET방식이 아닌 POST방식으로 사용
② CSRF토큰  - 입력화면과 서버사이에 CSRF토큰을 통해 인증
③ 추가/재인증 - 중요기능에 대해서는 추가적인 인증이나 재인증을 요청하는 방식 사용



1-11 HTTP 응답 분할

구분 설명
원인/영향 HTTP요청시 쿠키및 헤더정보에 삽입한 외부입력값이 HTTP응답헤더에 포함되어 사용자에게
다시 전달될 때 개행문자을 이용하여 첫번째 응답을 종료시키고 두번째 응답에 악의적인 
스크립트를 주입해서 XSS공격을 유발
(setHeader, addCookies…등으로 입력한 값은 나중에 응답페이지의 헤더에 포함되어 리턴된다)
대응 ① 개행문자 - 외부입력값을 응답헤더에 포함시킬 경우 개행문자(CRLF)포함시 제거한다.



1-12 정수형 오버플로우

구분 설명
원인/영향 외부입력값을 정수형으로 사용시 정수값이 허용된 범위를 벗어나는 큰 수가 입력되면 실제 
저장되는 값은 음수이거나 아주 큰 수가 되어 반복문제어, 메모리할당 등의 조건으로 사용시 
시스템오류 발생 ,악성코드 실행등의 문제를 유발
대응 ① 범위체크 - 입력값의 범위를 체크



1-13 보안기능 결정에 사용되는 부적절한 입력값 

구분 설명
원인/영향 사용자가 전달하는 쿠키,환경변수,히든필드값을 조작하여 상승된 권한을 획득하거나 
파라미터를 조작해서 금액 같은 중요값 변경가능
대응 ① 중요정보는 서버에 저장하고 보안절차도 서버에서 실행한다.
② 보안결정에 사용되는 값은 외부입력값을 사용하지 않고 내부 세션값을 사용한다.
취약) Cookie[] cookies = request.getCookies();
       Cookie c = cookies[0];
       if (c.getName().equals("role")) {
               userRole = c.getValue();  <-- 쿠키값을 가지고 바로 권한 할당
       }

안전) HttpSessioni session = context.getSession(id);
       String userRole = (String)sesssion.getValue("role");  <-- 세션에 있는 정보로 권한 할당.



1-14 메모리 버퍼 오버플로우

구분 대응
원인/영향 버퍼의 크기보다 큰 값을 버퍼에 저장할 때 버퍼의 경계를 넘어서 저장되면서 다른 메모리영역을
침범하여 리턴주소를 조작하여 임의의 악성코드가 실행되게 할 수 있다.
대응 ① 버퍼의 범위를 벗어나서 접근이 안되도록 할당된 버퍼의 크기내에서 데이터가 사용될수 
   있도록 한다.
② 문자열 저장을 위해 메모리 버퍼를 사용하는 경우 널(NULL)문자로 종료한다



1-15 포맷 스트링 삽입

구분 설명
원인/영향 printf(), fprintf(), sprintf() 와 같은 포맷스트링 출력함수를 사용하는 경우 외부입력값을 
조작을 통해 메모리내용을 읽거나 리턴주소를 조작하여 임의의 악성코드를 실행되게 
할수 있다.
대응 ① 사용자의 입력값을 바로 포맷문자열로 바로 사용하거나 포맷스트링생성에 바로 사용하지 
    않는다.

 

728x90
반응형
LIST

'정보보안' 카테고리의 다른 글

SW보안약점진단원 : 구현단계 - 보안기능 (2/2)  (0) 2019.11.25
SW보안약점진단원 : 구현단계 - 보안기능 (1/2)  (0) 2019.11.24
SW보안약점진단원 : 구현단계 - 입력데이터 검증 및 표현 (1/2)  (0) 2019.11.22
SW 개발보안 가이드 : 분석/설계단계 - 에러처리 와 세션통제  (0) 2019.11.21
SW보안약점진단원 : 분석/설계단계 - 보안기능  (0) 2019.11.20

+ Recent posts

티스토리툴바