안녕하세요.
이번 Secure Coding 2편에서는 보안 요구 사항 정의와 시큐어 코딩에 대해 알아보도록 하겠습니다.
Secure Coding 1편의 내용은 아래 링크를 통해 확인해주세요.
1. 보안 요구 사항 정의
1.1 입력 데이터 검증 및 표현
1.1.1 SR1-1
| 구분 | 항목 | 요구 사항 내용 |
| SR1-1 | DBMS 조회 및 결과 검증 |
1. 애플리케이션에서 DB연결을 수행할 때 최소 권한의 계정을 사용해야 한다. 2. 외부 입력값이 삽입되어 SQL쿼리문을 동적으로 생성해서 실행하지 않도록 해야 한다. 3. 외부 입력값을 이용해 동적으로 SQL쿼리문을 생성해야 하는 경우 입려값에 대한 검증을 수행한 뒤 사용해야 한다. |
▶ 데이터베이스와 연동되어 있는 어플리케이션의 입력된 데이터에 대한 유효성을 검증하지 않을 경우, 공격자가 입력 폼 및 URL에 SQL문을 삽입하여 DB로부터 정보를 열람하거나 조작할 수 있는 보안 취약점
[취약점 목록 및 공격 내용]
① 작은 따옴표(‘) 를 이용한 SQL Injection
: 데이터베이스에서 특수한 의미를 가지는 문자로, 공격자는 이 문자를 이용하여 SQL 구분에 임의의 SQL 구문을 삽입
② 더블 대시(--)를 이용한 SQL Injection
: 주석문과 같은 의미를 가지고 있는 문자열로 뒤에 오는 모든 SQL 구문을 주석으로 처리하여 사용자 계정을 확인
1.1.2 SR1-2
| 구분 | 항목 | 요구 사항 내용 |
| SR1-2 | XML 조회 및 결과 검증 |
XML문서를 조회하는 기능을 구현해야 하는 경우 XML 쿼리에 사용되는 파라미터는 반드시 XML쿼리를 조작 할 수 없도록 필터링해서 사용하거나, 미리 작성된 쿼리문에 입력값을 자료형에 따라 바인딩해서 사용해야 한다. |
▶ XML 문서를 조회할 경우 입력 값 조작을 통해 XQurey나 XPath와 같은 쿼리문 구조를 임의로 변경하여 허가되지 않은 데이터를 조회하거나 인증 절차를 우회하는 취약점
[취약점 목록 및 공격 내용]
① XQuery 삽입
: XQuery를 조작할수 있는 임의의 문자열을 삽입
1.1.3 SR1-3
| 구분 | 항목 | 요구 사항 내용 |
| SR1-3 | 디렉터리 서비스 조회 및 결과 검증 |
LDAP 인증서버를 통해 인증을 구현하는 경우 인증요청을 위해 사용되는 외부입력값은 LDAP 삽입 취약점을 가지지 않도록 필터링해서 사용해야 한다. |
▶ 외부 입력값이 LDAP(Lightweight Directory Access Protocol) 조회를 수행하기 위한 필터 생성에 사용되는 경우 필터 규칙을 변경 할 수 있는 입력값에 대한 검증 작업을 수행하지 않아 발생되는 취약점
[취약점 목록 및 공격 내용]
① LDAP 삽입
: XQuery를 조작할수 있는 임의의 문자열을 삽입
1.1.4 SR1-4
| 구분 | 항목 | 요구 사항 내용 |
| SR1-4 | 시스템 자원 접근 및 명령어 수행 입력 값 검증 |
1. 외부 입력값을 이용하여 시스템자원(IP, PORT번호, 프로세스, 메모리, 파일 등)을 식별하는 경우 허가되지 않은 자원이 사용되지 않도록 해야 한다. 2. 서버 프로그램 안에서 셀을 생성하여 명령어를 실행해야 하는 경우 외부 입력값에 의해 악의적인 명령어가 실행되지 않도록 해야 한다. |
▶ 공격자가 입력값 조작을 통해 시스템이 보호하는 자원에 임의로 접근하거나, 적절한 검증절차를 거치지 않은 사용자 입력값에 의해 의도하지 않은 시스템 명령어가 실행되어 운영에 악영향을 미칠 수 있는 취약점이다.
[취약점 목록 및 공격 내용]
① 경로 조작 및 자원 삽입
② 운영체제 명령어 삽입
1.1.5 SR1-5
| 구분 | 항목 | 요구 사항 내용 |
| SR1-5 | 입력데이터 검증 및 표현 |
1. 사용자로부터 입력 받은 값을 동적으로 생성되는 응답페이지에 사용하는 경우 크로스사 이트스크립트(XSS) 필터링을 수행한 뒤 사용해야 한다. 2. DB조회결과를 동적으로 생성되는 응답페이지에 사용하는 경우 HTML인코딩 또는 크로 스사이트스크립트(XSS) 필터링을 수행한 뒤 사용해야 한다. |
▶ 웹 페이지에 악의적인 스크립트를 포함시켜 웹페이지를 열람하는 접속자의 권한으로 부적절한 스크립트가 수행되어 정보유출 등의 공격을 유발할 수 있다.
[취약점 목록 및 공격 내용]
① 크로스사이트 스크립트
1.1.6 SR1-6
| 구분 | 항목 | 요구 사항 내용 |
| SR1-6 | 웹 기반 중요기능 수행 요청 유효성 검증 |
시스템으로 전송되는 모든 요청에 대해 정상적인 사용자의 유효한 요청인지, 아닌지 여부를 판별할 수 있도록 해야 한다. |
▶ 공격자는 세션탈취, XSS 등을 통해 자신이 의도한 행위(수정, 삭제, 등록 등)를 사이트가 신뢰하는 인 증된 사용자의 권한을 통해 실행되게 할 수 있다.
[취약점 목록 및 공격 내용]
① 요청 위조 코드 등록하여 공격 (크로스사이트 요청 위조 CSRF)
1.1.7 SR1-7
| 구분 | 항목 | 요구 사항 내용 |
| SR1-7 | HTTP 프로토콜 유효성 검증 |
1. 외부입력값을 쿠키 및 HTTP 헤더정보로 사용하는 경우, HTTP 응답분할 취약점을 가지지 않도록 필터링해서 사용해야 한다. 2. 외부입력값이 페이지이동(리다이렉트 또는 포워드)를 위한 URL로 사용되어야 하는 경우, 해당 값은 시스템에서 허용된 URL 목록의 선택자로 사용되도록 해야 한다. |
▶ 공격자가 HTTP 요청에 삽입한 인자값이 응답헤더에 포함되어 사용자에게 전달될 때 첫 번째 응답을 종료시키고 두 번째 응답의 악의적인 코드가 실행되거나, 사용자의 입력값을 외부 사이트의 주소로 사용하여 자동으로 위험한 URL로 접속 유도
[취약점 목록 및 공격 내용]
① HTTP 응답 분할
② 신뢰되지 않은 URL 주소로 자동접속 연결
1.1.8 SR1-8
| 구분 | 항목 | 요구 사항 내용 |
| SR1-8 | 형용된 범위 내 메모리 접근 |
1.C나 C++ 같이 메모리를 프로그래머가 관리하는 플랫폼을 사용하는 경우 메모리 버퍼의 경계값을 넘어서 메모리를 읽거나 저장하지 않도록 경계설정 또는 검사를 반드시 수행해야 한다. 2. 개발시, 메모리 버퍼오버플로우를 발생시킬 수 있는 취약한 API를 사용하지 않도록 통제해야 한다. |
▶ (버퍼오버플로우) 스택(Stack)이나 힙(Heap)에 할당되는 메모리에 문자열 등이 저장될 때 최초 정의된 메모리의 크기를 초 과하여 문자열을 저장하는 경우 버퍼오버플로우가 발생한다.
[취약점 목록 및 공격 내용]
① 버퍼오버플로우
② 포맷 스트링 삽입
1.1.9 SR1-9
| 구분 | 항목 | 요구 사항 내용 |
| SR1-9 | 보안기능 동작에 사용되는 입력값 검증 |
1. 사용자의 역할, 권한을 결정하는 정보는 서버에서 관리해야 한다. 2. 쿠키값, 환경변수, 파라미터값 등 외부입력값이 보안기능을 수행하는 함수의 인자로 사 용되는 경우, 입력값에 대한 검증작업을 수행한 뒤 제한적으로 사용해야 한다.
3. 중요상태정보나 인증, 권한결정에 사용되는 정보는 쿠키로 전송되지 않아야 하며, 불가 피하게 전송해야 하는 경우에는 해당 정보를 암호화해서 전송해야 한다. |
▶ 사용자가 전달하는 쿠키, 환경변수, 히든필드의 사용자권한을 나타내는 변수를 조작한 뒤 서버로 요청하거나, 허용된 값을 넘어서도록 변조하거나, 공격자가 의도적으로 널 포인터 역참조를 발생시키는 등 오류를 발생시켜 공격
[취약점 목록 및 공격 내용]
① 보안기능 결정에 사용되는 부적절한 입력값
② 정수형 오버플로우
③ Null Pointer 역 참조
1.1.10 SR1-10
| 구분 | 항목 | 요구 사항 내용 |
| SR1-10 | 업로드 · 다운로드 파일 검증 |
1. 업로드되어 저장되는 파일의 타입, 크기, 개수, 실행권한을 제한해야 한다. 2. 업로드되어 저장되는 파일은 외부에서 식별되지 않아야 한다. 3. 파일 다운로드 요청시, 요청파일명에 대한 검증작업을 수행해야 한다. 4. 다운로드 받은 소스코드나 실행파일은 무결성 검사를 실행해야 한다. |
▶ 서버측에서 실행될 수 있는 스크립트 파일(asp, jsp, php파일 등)을 업로드를 하여, 웹을 통해 직접 실행하거나, 외부입력값에 대해 경로 조작에 사용될 수 있는 문자를 이용하여 접근제한 영역에 접근을 하거나, 원격으로부터 소스코드 또는 실행파일을 실행할 하여 서버의 변조, DNS 스푸핑 (Spoofing) 등 공격자가 악의적인 코드를 실행또는 정보를 탈취하는 취약점
[취약점 목록 및 공격 내용]
① 위험한 형식 파일 업로드
② 경로 조작 파일 다운로드
: ../ 등의 경로 조작하는 문자열을 삽입을 허용함으로써 접근 제한 영역에 접근
ex) download.jsp?filename=../../../config.xml
③ 무결성 검사 없는 코드 다운로드
1.2 보안기능
1.2.1 SR2-1
| 구분 | 항목 | 요구 사항 내용 |
| SR2-1 | 인증 대상 및 방식 |
1. 중요기능이나 리소스에 대해서는 인증 후 사용 정책이 적용되어야 한다. 2. 안전한 인증방식을 사용하여 인증우회나 권한 상승이 발생하지 않도록 해야 한다. 3. 중요기능에 대해 2단계(2-factor)인증을 고려해야 한다. |
▶ 중요기능이나 리소스를 요청하는 경우 인증이 되었는지를 먼저 확인하지 않고 요청을 처리하는 경우 중요 정보나 리소스가 노출될 수 있다.
[취약점 목록 및 공격 내용]
① 적절한 인증 없는 중요기능 허용
1.2.2 SR2-2
| 구분 | 항목 | 요구 사항 내용 |
| SR2-2 | 인증수행 제한 |
1. 로그인 기능 구현 시, 인증시도 횟수를 제한하고, 초과된 인증시도에 대해 인증제한 정책 을 적용해야 한다. 2. 실패한 인증시도에 대한 정보를 로깅하여 인증시도 실패가 추적될 수 있게 해야 한다. |
▶ 로그인 시도에 대한 횟수를 체크하지 않으면 로그인 시도 횟수가 초과되었을 때 계정에 대한 보호조치가 설정되어 있지 않은 경우 패스워드 무작위 대입공격이 시도될 수 있다.
[취약점 목록 및 공격 내용]
① 반복된 인증 시도 제한 기능 부재
1.2.3 SR2-3
| 구분 | 항목 | 요구 사항 내용 |
| SR2-3 | 비밀번호 관리 |
1. 패스워드를 설정할 때 한국인터넷진흥원의 『암호이용안내서』 의 패스워드 생성규칙을 적용해야 한다. 2. 네트워크를 통해 패스워드를 전송하는 경우 반드시 패스워드를 암호화하거나 암호화된 통신 채널을 이용해야 한다. 3. 패스워드 저장시, 솔트가 적용된 안전한 해시함수를 사용해야 하며, 해시함수 실행은 서 버에서 해야 한다. 4.패스워드 재설정/변경시 안전하게 변경할 수 있는 규칙을 정의해서 적용해야 한다. 5. 패스워드 관리 규칙을 정의해서 적용해야 한다. |
▶ 회원가입 시에 안전한 패스워드 규칙이 적용되지 않아서 취약한 패스워드로 회원가입이 가능할 경 우 무차별 대입공격을 통해 패스워드가 누출될 수 있으며, 프로그램 코드 내부에 하드코드된 패스워드를 포함하고, 이를 이용하여 내부 인증에 사용하거나 외부 컴포넌트와 통신을 하는 경우, 관리자 정보가 노출될 수 있어 위험하다
[취약점 목록 및 공격 내용]
① 취약한 비밀번호 허용
② 하드코드된 비밀번호
1.2.4 SR2-4
| 구분 | 항목 | 요구 사항 내용 |
| SR2-4 | 중요 자원 접근 통제 |
1. 중요 자원 및 기능에 대한 접근 통제 정책을 수립하여 적용해야 한다. 2. 관리자 페이지에 대한 접근 통제 정책을 수립하여 적용해야 한다. |
▶ 인터넷을 통해 접근 가능할 경우 SQL삽입 및 접근에 대한 제어를 하지 않아 무차별대입공경에 대해 서버가 처리 하여 정보가 누출되는 취약점
[취약점 목록 및 공격 내용]
① 관리자 페이지 노출
: 관리자 페이지로 추정되는 URL을 이용하여 공격의 빌미를 제공하게 되는 취약점
Ex) www.aa.co.kr/admin.jsp, www.aa.co.kr/test.jsp, www.aa.co.kr/superuser.jsp
② SSI 삽입
: SSI(Server-side Includes)는 HTML 문서 내 변수 값으로 입력된 내용을 서버가 처리하여 명령이 수행됨에 따라 정보가 누출 되는 취약점
③ 부적절한 인가
: 프로그램이 실행 가능한 경로에 대해 완전하게 검사하지 않아 공격자가 접근 가능한 실행 경로를 통해 정보를 유출 할 수 있는 취약점
1.2.5 SR2-5
| 구분 | 항목 | 요구 사항 내용 |
| SR2-5 | 암호키 관리 |
1. DB데이터 암호화에 사용되는 암호키는 한국인터넷진흥원의 「암호이용안내서」에서 정 의하고 있는 방법을 적용해야 한다. 2. 설정파일(xml, Properties)내의 중요정보 암호화에 사용되는 암호키는 암호화해서 별 도의 디렉터리에 보관해야 한다. |
▶ 코드 내부에 하드코드된 암호화 키, 주석문 안에 암호키를 사용하여 암호화를 수행하면 암호화된 정보가 유출될 가능성 이 높아진다.
[취약점 목록 및 공격 내용]
① 하드코드 된 암호키
② 주석문 안에 포함된 시스템 주요 정보
1.2.6 SR2-6
| 구분 | 항목 | 요구 사항 내용 |
| SR2-6 | 암호 연산 |
1 .대칭키 또는 비대칭키를 이용해서 암·복호화를 수행해야 하는 경우 한국인터넷진흥원 의 『암호이용안내서』에서 정의하고 있는 암호화 알고리즘과 안전성이 보장되는 암호키 길이를 사용해야 한다. 2. 복호화되지 않는 암호화를 수행하기 위해 해시함수를 사용하는 경우 안전한 해시 알고 리즘과 솔트값을 적용하여 암호화해야 한다. 3. 난수생성시 안전한 난수 생성 알고리즘을 사용해야 한다. |
▶ base64와 같은 지나치게 간단한 인코딩 함 수를 사용하면 패스워드를 안전하게 보호할 수 없고, 검증된 암호화 알고리즘을 사용하더라도 키 길이가 충분히 길지 않으면 짧은 시간 안에 키를 찾아낼 수 있고, 예측 가능한 난수를 사용하는 것은 시스템의 보안약점을 유발한다. 패스워드를 솔트 없이 저장한다면 모든 패스워드에 대해 해시값을 미리 계산하고 이를 통해 패스워드를 찾을 수 있게 된다.
[취약점 목록 및 공격 내용]
① 취약한 암호알고리즘 사용
② 충분하지 않은 키 길이 사용
③ 적절하지 않은 난수 사용
④ 솔트 없이 사용하는 일방향 해시함수
1.2.7 SR2-7
| 구분 | 항목 | 요구 사항 내용 |
| SR2-7 | 중요 정보 저장 |
1. 중요정보 또는 개인정보는 암호화해서 저장해야 한다. 2. 불필요하거나 사용하지 않는 중요정보가 메모리에 남지 않도록 해야 한다. |
▶ 사용자 중요정보 및 시스템 중요정보를 처리하는 과정에서 이를 평문으로 저장하거나, 영속적인 쿠키(Persistent Cookie)에 저장된다면, 공격자는 접근할 수 있는 보다 많은 기회를 가지게 되며, 이는 시스템을 취약하게 만든다.
[취약점 목록 및 공격 내용]
① 주요 정보 평문 저장
② 사용자 하드 디스크에 저장되는 쿠키를 통한 정보 노출
1.2.8 SR2-8
| 구분 | 항목 | 요구 사항 내용 |
| SR2-8 | 중요 정보 전송 |
1. 인증정보와 같은 민감한 정보 전송시 안전하게 암호화해서 전송해야 한다. 2. 쿠키에 포함되는 중요정보는 암호화해서 전송해야 한다. |
▶ 프로그램이 보안과 관련된 민감한 데이터를 평문으로 송·수신할 경우, 통신채널 스니핑을 통해 인가 되지 않은 사용자에게 민감한 데이터가 노출될 수 있다.
[취약점 목록 및 공격 내용]
① 주요 정보 평문 전송
: 인증 정보와 같이 중요한 정보를 전송할 경우 암호화 해서 전송해야 한다.
1.3 에러처리
1.3.1 SR3-1
| 구분 | 항목 | 요구 사항 내용 |
| SR3-1 | 예외처리 |
1. 명시적인 예외의 경우 예외처리 블럭을 이용하여 예외발생시 수행해야 하는 기능이 구현 되도록 해야 한다. 2. 런타임 예외의 경우 입력값의 범위를 체크하여 애플리케이션이 정상적으로 동작할 수 있 는 값만 사용되도록 보장해야 한다. 3. 에러가 발생한 경우 상세한 에러 정보가 사용자에게 노출되지 않게 해야 한다. |
▶ 웹 서버에 별도의 에러 페이지를 설정하지 않은 경우, 에러 메시지를 통해 서버 데이터 정보 등 공격 에 필요한 정보가 노출되며, 시스템, 관리자, DB정보 등 시스템의 내부 데이터가 공개되면, 공격자에게 또 다른 공격의 빌미를 제공하게 된다.
[취약점 목록 및 공격 내용]
① 오류메시지를 통한 정보노출
② 시스템 정보 노출
1.4 세션통제
1.4.1 SR4-1
| 구분 | 항목 | 요구 사항 내용 |
| SR4-1 | 세션통제 |
1. 세션간 데이터가 공유되지 않도록 설계해야 한다. 2. 세션이 안전하게 관리되도록 해야 한다. 3. 세션ID가 안전하게 관리되도록 해야 한다. |
▶ 인증시 일정한 규칙이 존재하는 세션ID가 발급되거나 세션 타임아웃을 너무 길게 설정한 경우 탈취 가능성이 있으며, 다중 스레드 환경에서는 싱글톤(Singleton)객체 필드에 경쟁조건(Race Condition) 발생할 수 있다.
[취약점 목록 및 공격 내용]
① 불충분한 세션관리
② 잘못된 세션에 의한 정보노출
2. 시큐어 코딩
2.1 SQL 삽입 (SR1-1)
1) 개요 : 데이터의 유효성을 검증하지 않아 공격자가 URL입력란에 SQL을 삽입하여 DB로 부터 정보를 열람하거나 조작할 수 있는 보안 취약점
2) 보안대책 : DB쿼리에 사용되는 외부 입력값에 대해 특수문자 및 쿼리 예약어를 필터링하고, 프레임워크를 사용하는 경우에는 외부 입력 값 검증 모듈 및 보안 모듈을 사용한다.
3) 코드 예제 : 외부에서 입력받은 gubun의 값으로 [ a’ or ‘a’ = ‘a ]를 입력하면 조건절이 [gubun=‘a’or’a’=‘a’]로 바뀌어 모든 데이터를 조회 할 수 있다.
- 안전하지 않은 코드의 예
String gubun = request.getParameter(“gubun”);
SELECT ID, USRE_NAME, GUBUN FROM TEST
WHERE GUBUN = ‘”+ gubun +”’ “;
- 안전한 코드의 예
String gubun = request.getParameter(“gubun”);
SELECT ID, USRE_NAME, GUBUN FROM TEST
WHERE GUBUN = ? ;
Pstmt.setString (1, gubun);
2.2 크로스 사이트 스크립트 (SR1-5)
1) 개요 : XSS 공격을 통해 정상적인 페이지와 유사한 피싱 사이트로 유도하여 개인정보를 탈취하거나 악성 사이트로 유도하여 악성 코드를 유포 / 사용자 쿠키 정보를 획득하여 Replay Attack등에 공격
2) 보안대책 : 외부 입력값에 스크립트가 삽입되지 못하도록 문자변환 함수또는 메서드를 사용하여 < > & “ 등을 < > & " 로 치환한다
3) 코드 예제 : 파라미터(id)에 <script>alert(document.cookie);</script> 와 같은 스크립트 코드가 입력되고, 이 값을 그대로 출력에 사용하는 경우, 공격자는 공격코드를 이용하여 피해자의 쿠키 정보를 빼돌릴 수 있다.
- 안전하지 않은 코드의 예
<% String customerID request.getParameter(“id”); %>
요청한 사용자 : <%=customerID%>
- 안전한 코드의 예
예제1 – 출력값을 HTML 인코딩
String cleanData = input.replaceAll(“<“,”<”).replaceAll(“>”,”>”);
Out.println(cleanData);
예제2 – 라이브러리를 이용하여 필터링
XssFilter filter = XsssFilter.getInstance(“aaa.xml”);
Out.append(filer.doFilter(data));
2.3 취약한 암호화 알고리즘 (SR2-6)
1) 개요 : 표준화 되지 않은 암호화 알고리즘을 사용하는 것은 공격자가 알고리즘을 분석하여 무력화시킬 수 있는 가능성이 있으며, 컴퓨터의 성능이 향상됨에 따라 알고리즘이 해독되어 취약점이 발생 하기도 한다.
2) 보안대책 : 표준화된 알고리즘을 사용하고 취약하다고 알려진 DES RC5 등의 암호화 알고리즘 대신 3DES, ASE, SEED등의 안전한 암호화 알고리즘으로 대체하여 사용한다.
3) 코드예제 : 보안 강도가 낮은 암호 알고리즘 사용 시 암호화된 통신 내용이 유출 되는 등의 위협이 존재함에 따라, 암호 알고리즘의 보안 강도의 적절성 여부를 점검한다.
- Apache 서버 설정
<VirtualHost *:443>
DocumentRoot “D:/WebServer/Apache2.2/htdocs”
ServerName www.krx.co.kr:443
ErrorLog “logs/error.log”
TransferLog “logs/access.log”
SSLEngine on
SSLProtocol –ALL +TLSv1.2
SSLCipherSuite ALL:+HIGH:+MEDIUM:!SSLv2:!PSK:!SRP:!ADH:!AECDH:!EXP:!RC4:!MD5:!SHA:!DES
- Tomcat 서버 설정
* 서버, 버전별 적용 방법은 https://mozilla.github.io/server-side-tls/ssl-config-generator/ 참고
<Connector port=“8443” protocol=“org.apache.coyote.http11.Http11NioProtocol” SSLEnabled=“true”
maxThreads=“512” scheme=“https” secure=“true” keystoreFile=“D:\Apache2.2\keystoreFile.jks”
keystorePass=“keystorePassword” clientAuth=“false” sslProtocol=“TLS”
ciphers=“TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA”>
4) 전송시 암호화
4-1) 웹 서버와 클라이언트 간 암호화
웹 브라우저에 기본적으로 내장된 SSL/TLS 프로토콜로 접속하는 SSL방식과 웹 브라우저에 보안 프로그램을 설치하여 접속하는 응용 프로그램 방식으로 구분할 수 있다.
4-2) 개인정보처리시스템 간 암호화
개인정처리시스템 간에 개인정보를 전송할 때 암호화르 ㄹ지원하기 위하여 공중망을 이용한 가상사설망(VPN:Virtual Private Network)를 구축할 수 있으며, VPN은 기반이 되는 보안 프로토콜의 종류에 따라 IPsec VPN, SSL VPN, SSH VPN 으로 구분할 수 있다.
4-3) 개인정보취급자 간 암호화
개인정보 취급자가 개인정보를 전송할 때 이메일을 이용할 경우 네트워크를 통해 전송되는 과정에서 공격자에 의해 유출되거나 위변조 될 가능성을 보호하기 위해서 PGP 또는 S/MIME를 이용하는 이메일 암호화 방식과 이메일 첨부문서 암호화 방식
5) 저장시 암호화
5-1) 개인정보처리시스템 암호화 방식
개인정보를 처리하고 관리하는 개인정보처리스템은 DB에 저장된 개인정보를 암호화 하여 저장함으로써 유출, 위.변조, 훼손 등 방지
5-2) 업무용 컴퓨터 보조 저장 매체 암호화 방식
업무용 컴퓨터에서는 하드, 이동식 디스크 또는 보조저장매체에 저장된 개인정보의 보호를 위해 개별 문서 파일 단위 암호화, 디렉토리, 디스크 암호화 등의 방법을 상용
6) 암호키 관리
6-1) 암호키 수명주기
6-2) 단계별 암호키 관리
6-3) 암호키 유효기간
2.4 중요 정보 평문 전송 (SR2-7)
1) 개요 : 사용자 또는 시스템의 중요정보가 포함된 데이터를 평문으로 송.수신할 경우, 통신채널 스나핑을 통해 인가되지 않은 사용자에게 민감한 데이터가 노출될 수 있는 보안 취약점
2) 보안대책 : 민감한 정보를 통신채널을 통하여 내보낼 때에는 반드시 암호화 과정을 거처야 하며, 필요할 경우 SSL 또는 HTTP등과 같은 보안 채널을 사용해야 하며, 브라우저 쿠키에 중요 데이터를 저장하는 경우 쿠키 객체에 보안 속성을 설정하여야 한다.
3) 코드예제 : 네트워크를 통해 서버로 전송하기 전에 AES 등의 안전한 암호화 알고리즘으로 암호화한 안전한 프로그램
- 안전하지 않은 코드의 예
try {
Socket s= new Socket(“Taranis”, 4444);
PrintWriter o = new PrintWriter(s.getOutputStream().true);
String password = getPassword();
o.write(password);
} catch(FileNotFountException e) { }
- 안전한 코드의 예
try {
Socket s= new Socket(“Taranis”, 4444);
PrintWriter o = new PrintWriter(s.getOutputStream().true);
Cipher c = Cipher.getInstance(“AES/CBC/PKCS5Pading”);
String password = getPassword();
byte[] encPassword = c.update(password.getByte());
o.write(password);
} catch(FileNotFountException e) { }
4) 와이어샤크 이용한 점검
2.5 부적절한 인가 (SR2-4)
1) 개요 : 적절한 인증과정이 없이 중요정보(계좌이체 정보, 개인정보 등)를 열람(또는 변경)할 때 발생하는 보안약점이다.
2) 보안대책 : 클라이언트의 보안검사를 우회하여 서버에 접근하지 못하도록 설계하고 중요한 정보가 있는 페이지는 재인증을 적용(은행 계좌이체 등)한다. 또한 안전하다고 검증된 라이브러리나 프레임워크(OpenSSL이나 ESAPI의 보안기능 등)를 사용하는 것이 중요하다.
3) 코드예제 : 회원정보 수정시 수정을 요청한 사용자와 로그인한 사용자의 일치 여부를 확인하지 않고 처리하고 있다.
- 안전하지 않은 코드의 예
if (service.modifyMember(memberModel)) {
mav.setViewName(“redirect:/board/list.do”);
session.setAttribute(“userName”, memberModel.getUserName());
return mav
}
- 안전한 코드의 예
if (userId != null && requestUser != null && !userId.equals(requestUser)) {
mav.addObject(“errCode”, 1);
mav.addObject(“member”, memberModel);
mav.setViewName(“/board/member_modify”);
return mav
}
4) Burp Suite 이용한 점검
아래 링크를 통해 Secure Coding 3편의 내용을 확인하실 수 있습니다.
'백엔드' 카테고리의 다른 글
| 2020 보안기술 개발 동향 (0) | 2020.06.04 |
|---|---|
| Secure Coding 메뉴얼 3편 (0) | 2019.11.18 |
| Secure Coding 메뉴얼 1편 (0) | 2019.11.04 |
| 사내 IaaS 구축하기 (0) | 2018.06.25 |
| Private Cloud 구축을 위한 DC/OS 설치 (0) | 2018.02.06 |