Secure Coding
태그 :
- 개념
- 시큐어 코딩(Secure Coding)의 정의 - 서비스의 안정성과 신뢰성 확보를 위해 IT 시스템 개발 단계에서 주요 보안 취약점을 고려하여 소스코드 레벨에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법 - 소프트웨어 개발보안(Secure Coding): 해킹 등 사이버공격의 원인인 보안약점을 개발단계에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법
I. 공공 정보화 사업의 안전성을 위한 시큐어 코딩의 개요
가. 시큐어 코딩(Secure Coding)의 정의
- 서비스의 안정성과 신뢰성 확보를 위해 IT 시스템 개발 단계에서 주요 보안 취약점을 고려하여 소스코드 레벨에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법
- 소프트웨어 개발보안(Secure Coding): 해킹 등 사이버공격의 원인인 보안약점을 개발단계에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법
나. 시큐어 코딩의 목적
목적 |
시큐어 코딩의 목적 |
사이버 공격 예방 |
사이버 공격의 75%가 응용 프로그램의 취약점을 악용한 것(가트너 발표) |
웹 어플리케이션 취약점 개선 |
사이트 교차 접속 스크립팅(XSS), SQL인젝션 공격 등의 웹 응용 프로그램에 내재된 보안 취약점을 이용한 고객 정보 유출 사고 발생 |
취약점 수정 비용 절감 |
설계 과정에서 발생한 결함이 개발 완료 후에 발견, 조치되는 경우, 설계 단계에서 결함을 수정하는 비용 대비 30배 비용 발생 |
보안취약점 대응 |
|
전자정부 서비스확대 |
ICT 신기술을 활용한 전자정부 서비스가 확대되고, 대부분의 행정서비스가 인터넷을 통해 제공되면서, 전자정부 서비스의 보안취약점을 지속적으로 진단, 제거에 효율적 관리 방안 |
안정성 및 신뢰성 확보 |
전자정부 서비스의 안정성 및 신뢰성 확보를 위해 정보시스템의 개발단계부터 개념 및 소스코드레벨에서의 대응조치를 제안하여 전자정부 서비스의 보안 정책을 강화하기 위함 |
- 보안 취약점 제거는 운영단계보다 개발단계가 훨씬 효율적
- 소스코드 레벨의 보안 취약점 잔존 최소화가 목적
다. SW개발보안 필요성
구분 |
설명 |
광의적측면 |
SDLC(SW개발생명주기) 각 단계별로 요구되는 보안활동 |
협의적측면 |
시큐어코딩(Secure Coding), 소스코드 구현단계의 보안활동 |
OSI 7계층 측면 |
|
경제적 측면 |
설계에서 제품출시까지 최대 30배의 비용차이 발생 |
- 소스코드를 통한 사이버 공격은 침입방지(IDS), 침입차단(IPS) 등 일반적 보안장비로 대응 어려움
Ⅱ. 정보처리시스템의 보안성 강화를 위한 시큐어 코딩의 적용대상 및 적용범위
가. SW개발보안 적용대상 및 범위 기준
대상 |
내용 |
의무대상 |
단계적으로 의무 대상을 확대하여 ‘15년에는 감리대상 전 정보화 사업에 소프트웨어 개발보안을 적용함. |
적용제외 |
상용 소프트웨어는 소프트웨어 개발보안 적용 대상에서 제외됨. |
적용범위 |
소프트웨어 개발 사업자가 반드시 제거해야 할 보안약점은 SQL 삽입, 크로스사이트스크립트(XSS) 등 43개 존재. |
감리영역 |
|
나. CWE(Common Weakness Enumeration)의 7 Pernicious Kingdoms 분류 (★★)
범위 |
설명 |
예제 |
입력 데이터 검증 및 표현 |
프로그램 입력 값에 대한 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식지정으로 인해 발생할 수 있는 보안취약점 |
XSS, SQL삽입, 버퍼 오버플로우, OS 명령어 삽입공격 등 |
보안기능 |
보안기증(인증, 접근제어, 기밀성, 암호화, 권한관리 등)을 적절하지 않게 구현 시 발생할 수 있는 보안취약점 |
중요 정보 평문 저장, 하드코드 된 패스워드 등 |
시간 및 상태 |
병렬 시스템, 프로세스나 쓰레드 환경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안취약점 |
DeadLock, 자원에 대한 경쟁 조건, 세션 고착 |
에러처리 |
에러를 처리하지 않거나, 불충분하게 처리하여 에러정보에 중요정보가 포함될 때 발생할 수 있는 보안취약점 |
에러처리 루틴 누락, 에러처리 통한 정보 노출 등 |
코드품질 |
복잡한 소스코드로 인해 관리성, 유지보수성, 가독성 저하가 발생하여 코딩 오류로 인해 유발되는 보안취약점 |
널 포인터 역 참조, 부적절한 자원 해제 등 |
캡슐화 |
중요한 데이터 또는 기능성을 불충분하게 캡슐화 하였을 때 인가되지 않은 사용자에게 데이터 누출이 가능해지는 보안약점 |
제거되지 않고 남은 디버거 코드, 시스템 데이터 정보 노출 등 |
API 악용 |
의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안약점 |
DNS Lookup에 의존한 보안결정 |
- 보안전문가나 개발자가 SW보안취약점을 소스코드 관점에서 이해하기 쉽게 유형을 분류
III. S/W 보안취약점유형(적용범위) 및 보안대책
가. 입력데이터 검증 및 표현
- 프로그램 입력 값에 대한 검증 누락 또는 부적절한 검증, 데이터의 잘못된 형식지정으로 인해 발생할 수 있는 보안약점
취약점 유형 |
공격기법 |
보안대책 |
XSS |
사용자 요청에 의해 검증되지 않은 외부 입력 데이터가 포함된 동적 웹페이지가 생성•전송되는 경우, 사용자가 해동 동적 웹페이지를 열람함으로써 웹페이지에 포함된 부적절한 스크립트가 실행되는 공격 |
외부로부터 입력된 문자열을 사용하여 경로 페이지를 생성할 경우, 사전에 위험한 문자열을 ReplaceAll()등과 같은 메소드를 사용하여 제거한 후 사용해야 함. |
SQL 삽입 |
공격자가 입력한 데이터에 대한 유효성을 점검하지 않아 DB쿼리 로직이 변경되어 공격자의 의도대로 중요 정보유출 또는 DB의 변경을 가하는 공격 |
외부 입력이나 외부 변수로부터 받은 값이 직접 SQL 함수의 인자로 전달되거나, 문자열 복사를 통하여 전달되는 것은 위험하므로 인자화된 질의문 사용해야 함. |
HTTP 응답 분할 |
HTTP요청 인자값 내에 CR이나 LF존재시, HTTP 응답이 분리되어, 두번째 응답에 악의적인 코드를 주입하여 XSS 및 캐시 훼손시키는 공격 |
외부에서 입력된 인자 값을 사용하여 HTTP 응답헤더에 포함시킬 경우 CR, LF등을 제거하거나 적절한 인코딩 기법을 사용해야 함. |
버퍼 오버플로우 |
프로그램이 버퍼가 저장할 수 있는 것보다 많은 데이터를 삽입하려고 할 때 또는 프로그램이 버퍼 경계 밖의 메모리 영역에 데이터를 삽입하려고 할 때 발생하는 취약점 |
버퍼 저장공간보다 많은 데이터 입력금지 - 버퍼 경계 밖 메모리 영역 참조 금지 입력에 대한 경계검사 실시 - strcpy()와 같은 버퍼 오버플로우에 취약한 함수 사용 금지 |
디렉토리 경로조작 |
지정된 디렉토리 외 경로로 접근할 수 있는 특수문자(“..”, “/”등) 경로명에 포함되어 있는 경우 APP가 제어하지 못하여 의도하지 않은 폴더 및 파일에 접근할 수 있는 보안 취약점 |
외부의 입력이 직접 파일이름 생성에 사용될 수 없도록 함. - replaceAll()함수를 이용하여 위험문자열 필터링 수행 |
운영체제 명령어 삽입 |
외부에서 입력받은 시스템 명령어 검증 없이 공격자가 원하는 명령어 실행이 가능하게 되어 부적절한 권한 변경 및 내부 중요 정보 변경으로 인한 프로그램 및 시스템 동작•운영에 악영향을 주는 보안취약점 |
외부로부터 전달된 값을 그대로 시스템 내부 명령어를 사용하지 않도록 함. - 명령어 생성에 필요한 값들을 사전 정의 후, 외부 입력에 따라 선택하여 사용토록 함 |
LDAP 삽입 |
공격자가 외부 입력을 통해 LDAP 명령어를 수행하는 보안 취약점
|
외부의 입력이 LDAP 필터 문자열로 사용될 경우, 가능한 입력의 집합 또는 위험한 입력 문자열의 집합을 설정하여 임의위 외부 입력이 필터 생성에 사용되지 않도록 관리 |
버퍼 범위 한칸 벗어난 부분 읽기 |
프로그램이 할당된 메모리의 범위를 벗어나서 읽는 경우에 발생하는 보안 취약점 |
버퍼 크기와 같은 값을 갖는 인덱스를 그대로 사용하지 않도록 함. - 버퍼 범위를 넘어서는 영역을 읽지 않도록 함. |
자원삽입 |
애플리케이션이 입력 컴포넌트를 통해 수신한 데이터를 적절하게 제어하지 않고 자원에 대한 식별자로 사용하면 의도한 통제범위 밖의 자원에 접근할 수 있는 보안 취약점 |
외부의 입력을 아무 검증 없이 자원 식별자로 사용 금지 - 외부의 입력에 따라 적합한 리스트(white list)에서 선택되도록 작성 |
나. API악용
- 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생 할 수 있는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
위험하다고 알려진 함수 사용 |
보안취약점을 고려하지 않고 개발되어, 사용자체가 취약한 함수들의 보안 취약점 - gets()함수의 사용 |
gets()함수 사용 금지 |
J2EE: System.exit()사용 |
J2EE 응용프로그램에서 System.exit()의 사용시 컨테이너 종료시킬 수 있는 보안 취약점 |
J2EE 프로그램에서 System.exit()사용 금지 |
Null 매개변수 미사용 |
Java표준에서 특정 메소드 사용시 매개변수가 null인 경우 지정된 값을 반환하지 못해 발생하는 예기치 못한 동작에 대한 보안 취약점 - Object.equals(), Comparator.compare()사용시 발생 |
Object.equals(), Comparable.compareTo()과 Comparator.compare()을 이용한 매개변수 전달 시 Null여부를 점검하는 과정을 거친 후 사용해야 함. |
Equals()와 hashCode()하나만 정의 |
동일 객체의 경우 동일한 해시코드를 가져야 함으로 인해 한 클래스 내에서 equals()와 hashCode()를 하나만 정의할 경우 보안 취약점 발생 |
한 클래스 내에 equals()를 정의하면 hashCode()도 정의해야 하고 hasCode()를 정의하면 equals()도 정의해야 함. |
다. 보안특성
- 보안특성(인증, 접근제어, 기밀성, 암호화, 권한관리 등)을 부주의하게 구현 시 발생할 수 있는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
하드코드된 패스워드
|
프로그램 코드 내부에 패스워드 포함 시, 관리자 정보 노출될 수 있는 보안취약점 |
패스워드는 암호화하여 별도 파일에 저장 - 소프트웨어 설치 시 직접 패스워드나 키를 입력하도록 설계 |
사이트 간 요청 위조 |
사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격 |
입력화면 폼을 작성 시 GET 방식보다 POST방식 사용 - 입력폼과 입력처리 프로그램에서 토큰사용 |
적절하지 못한 세션 만료
|
웹사이트가 인증에 사용된 기존 세션 인증 정보 또는 세션 아이디의 재사용을 허용하여 공격자가 이를 악용하여 발생하는 보안 취약점 |
세션의 만료시간 설정 시, 적당한 양수를 사용하여 일정 시간 이후 세션이 종료되도록 구현 |
부적절한 인가 |
프로그램이 모든 가능한 실행경로에 대해 접근제어를 검사하지 않거나 불완전하게 검사하는 경우, 공격자가 접근 가능한 실행경로를 통해 정보를 유출할 수 있는 보안 취약점 |
응용프로그램이 제공하는 정보와 기능을 역할에 따라 배분, 공격자에게 노출되는 공격표면(attack surface)을 최소화 - 사용자의 권한에 따른 ACL(Access Control List)을 관리 |
취약한 암호화 알고리즘의 사용
|
인가되지 않은 사용자에 의해 암호화된 정보의 노출 또는 변조가 발생될 수 있는 보안 취약점 |
학계 및 업계에서 이미 검증된 표준화된 알고리즘 사용 - 3DES, AES, SEED의 안전한 알고리즘 대체 및 사용 |
기밀정보의 단순한 텍스트 전송
|
텍스트 형태의 데이터를 통신채널을 통해 송수신시 스니핑되어 데이터가 노출될 수 있는 보안 취약점 |
패스워드 등 민감한 정보를 통신채널을 통해 송•수신시 반드시 암호화 |
라. 시간 및 상태
- 동시 또는 거의 동시 수행을 지원하는 병렬 시스템, 프로세스 또는 스레드 환경에서 시간 및 상태를 부적절하게 관리하여 발생 할 수 있는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
경쟁조건: 검사시점과 사용시점
|
병렬 실행 환경의 응용프로그램이 자원 사용하는 시점에 자원의 상태가 변경되어 교육착생, 경쟁조건 및 기타 동기화 오류가 발생되어 프로그램의 정상동작에 영향을 줄 수 있는 보안 취약점 |
동기화 구문 이용 - thread safe 함수 사용 - 상호배제, sychronized사용 |
제대로 제어되지 않은 재귀
|
재귀함수의 순환회수 제어실패로 무한루프 발생 및 자원고갈을 유발하여 시스템의 비정상적인 상태가 되도록 하는 문제점 |
모든 재귀 호출을 조건문 블록이나 반복문 블록안에서만 수행토록 함
|
J2EE 잘못된 습관: 스레드의 직접 사용
|
웹 응용프로그램에서 스레드 직접사용에 따른 교착상태, 경쟁조건 및 기타 동기화 오류 발생 문제 |
J2EE에서 스레드 사용대신 병렬 실행을 위한 프레임워크 사용해야 함 |
마. 에러처리
- 에러를 불충분하게 처리하거나 전혀 처리를 하지 않거나 에러 정보에 과도하게 많은 정보가 포함될 때 발생할 수 있는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
취약한 패스워드 요구조건
|
강하지 않은 사용자 패스워드 조합규칙에 따른 사용자 계정 보안 취약점 |
패스워드 생성시 강한 조건 검증 필요 - 패스워드는 문자/특수문자를 조합하여 최소 9자리 이상으로 생성 |
오류 메시지 통한 정보 노출
|
프로그램이 실행환경, 사용자, 관련 데이터에 대한 민감한 정보를 포함하는 오류메시지를 생성, 외부에 제공 시 공격자의 악성행위를 도와주게 되는 보안 취약점 |
에러메시지는 정해진 사용자에게 유용한 최소한의 정보만 표현 - 예외사항을 내부적으로 처리하고 사용자에게 민감한 정보를 포함하는 오류 출력금지 - 시스템 구성 시 디폴트 오류 페이지나 메시지가 어떤 정보도 노출하지 않도록 함. |
바. 코드품질
- 복잡한 소스코드로 인해 관리성, 유지보수성, 가독성이 저하되어 SW 개발, 유지보수시 타입변환 오류, 자원(메모리 등)의 부적절한 반환 등과 같이 개발자가 범할 수 있는 코딩오류로 유발되는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
부호 정수를 무부호 정수로 타입 변환 오류 |
부호정수(Signed integer)를 무부호 정수(unsigned integer)로 변환하면서 음수가 큰 양수로 변환, 해당 값이 배열의 인덱스로 사용시 정수 오버플로우가 발생하는 보안 취약점 |
무부호 정수타입 변수의 경우, 입력 또는 반환값에 대한 정수타입 확인 - 배열 등 메모리에 함수 반환값을 복사▪저장할 때, 반환값의 크기 확인 |
정수를 문자로 변환
|
정수를 문자(character)로 변환하면서 표현할 수 없는 범위의 값이 잘려나가 문자에 대한 저장값이 올바르지 않은 보안 취약점 |
정수를 문자로 변환할 경우, 변환 값의 크기가 변환 값이 저장도리 변수의 크기보다 크지 않도록 함. |
자원의 부적절한 반환
|
프로그램 자원 사용 후, 적절히 반환하지 않음 으로 인해 프로그램 오류 또는 에러로 사용이 끝난 자원을 반환하지 못하는 보안 취약점 |
자원을 획득하여 사용한 후, 반드시 자원 해제 |
사. 캡슐화
- 중요한 데이터 또는 기능성을 불충분하게 캡슐화하였을 때 인가되지 않은 사용자 또는 시스템에게 데이터 누출이 가능해지는 보안 취약점
취약점 유형 |
공격기법 |
보안대책 |
제거되지 않고 남은 디버거 코드
|
디버깅 목적으로 삽입된 코드가 제거되지 않음으로 인해 공격자가 식별 과정을 우회하거나 의도하지 않은 정보와 제어 정보가 누출될 수 있는 보안 취약점 |
디버거 코드는 개발 완료 후, 삭제처리
|
민감한 데이터를 가진 내부 클래스 사용
|
내부 클래스는 컴파일 과정에서 패키지 수준의 접근성으로 바뀌기 때문에 의도하지 않는 정보공개가 발생하거나, 권한이 없는 클래스를 사용하고자 할 때 발생하는 취약점 |
내부클래스 사용시 외부클래스의 private필드 접근금지 - Private로 지정된 클래스의 접근금지 -내부클래스 사용시 정적(static) 또는 지역적(local) 또는 익명(anonymous) 내부 클래스 사용 |
시스템 데이터 정보 누출
|
getMessage()를 통해 오류와 관련된 시스템 정보, 관리자 정보, DB 정보 등 민감한 정보가 에러정보에 포함되어 공개되는 경우, 공격자가 시스템에 대한 공격을 할 수 있는 보안 취약점 |
공격의 빌미가 될 수 있는 시스템 데이터 정보, 오류정보 등 상세한 정보는 최종 사용자에게 노출 금지
|
IV. 소프트웨어 개발보안에서 시큐어 코딩 연구 및 추진사항
가. SW 개발보안은 SW 생명주기(SDLC)의 각 단계별로 요구되는 보안활동을 모두 포함하며, 좁은 의미로는 SW 개발과정에서 소스코드를 작성하는 구현단계에서 보안취약점을 배제하기 위한 시큐어 코딩(Secure Coding)을 의미함
부문 |
연구 및 추진사항 |
연구영역 |
|
발주영역 (공공) |
|
감리영역 |
정보처리 시스템의 감리영역에서 감리법인은 정보시스템 감리 시 검사항목에 보안약점 제거여부를 반드시 포함 통해서 지속적 진행 |
개발영역 |
|
- 결과적으로 개발단계에서부터 보안을 고려해 소스코드를 작성하는 한편, 보안취약점을 사전에 진단 및 제거하기 위한 노력을 통해 안전한 전자정부 서비스를 보다 효과적으로 구현할 수 있음
- 즉 시큐어 코딩 부문은 개발영역의 체계화된 괸리와 운영을 통해서 SW 보안을 실현할 수 있음
V. 소프트웨어 개발보안 가이드의 활성화 방안 및 세부 활동
가.소프트웨어 개발 보안 가이드 활성화 방안
- 정부 및 공공기관 <1단계>의무적용을 통해 국가 정보화 사업에 SW개발보안 가이드 활성화
- 민간기업, 대형 SI기업에 초기에 권고를 통한 적용 이후, 의무적용에 준하는 활성화를 유도하는 <2단계>실시
- 소프트웨어 보안취약점에 따른 개발보안 가이드는 보안문제가 사회적으로 심각성이 더해가는 상황에서 단계적 적용을 통한 활성화가 필요
- 이를 위해, 국가 및 정부, 공공기관 그리고 민간기업 등에서 SW개발 보안가이드 활성화를 위한 다양한 세부 활동이 필요함
- ICT 신기술을 활용한 전자정부 서비스가 확대되고, 대부분의 행정 서비스가 인터넷을 통해 제공되면서, 전자정부 서비스의 취약점을 지속적으로 진단하고 보완하는 노력이 필수적,
- 대국민서비스, 공공서비스, 전자정부 서비스 등의 안정성 및 신뢰성 확보
나. 소프트웨어 개발 보안 가이드 활성화를 위한 세부 활동
주체 |
세부활동 |
주요내용 |
국가 및 정부 |
보안연구 및 지속적 보안취약점 DB업데이트 |
|
가이드 홍보 |
국가차원에서 국가를 대상으로 한 사업 및 공공사업에 가이드 적용을 위한 교육의 주기적 실시, 홍보자료 배포 |
|
공공기관 |
정보화 사업 발주부분에 적용 |
국가를 대상으로 하는 정보화 사업에 SW개발 보안가이드 적용확대 |
감리부분에 적용 |
정보시스템 감리 시 검사항목의 보안약점 제거 여부를 반드시 포함함으로써 개발단계에서 적용 및 활성화 |
|
개발부분에 적용 |
|
|
민간기업 |
SI 프로젝트 시 가이드 적용 |
PMO 구성 및 RFP에 구축단계에서 가이드 사용 유도, 개발 표준 문서에 포함 또는 테일러링 시 적용부분 명시 |
교육 및 홍보 |
개발자, 품질 및 아키텍트 등 가이드 교육을 통한 보안 취약성 인지 활동 수행 |
|
품질점검 활동에 적용 |
개발 생명 주기에서 각 단계 말 검토 시 품질전문가 통한 가이드 적용여부 확인 및 점검 |
VI. 안전하지 않은 소스코드 개선 사례
가. 안전하지 않은 C언어 코드 사례 1
구분 |
내용 |
문제 코드 |
void User_check(SQLHSTMT sqlh) { Char *query = getenv(“query_string”); SQLExecDirect(sqlh, query, SQL_NTS); } |
취약점 분류 |
입력 데이터 검증 및 표현 |
공격 유형 |
SQL Injection |
원인 및 영향 |
- SQL 쿼리를 수행하는 로직으로, getenv를 통하여 외부로부터 입력된 query_string 값을 그대로 실행한다. - 이 때 query_string을 구성하는 사용자 입력값에 ‘ OR 1=1; 와 같은 SQL Injection 코드가 포함되어 있다면, 사용자를 확인하는 User_check 함수는 언제나 ‘참’의 결과를 반환한다. - 공격자는 자신이 소유할 수 있는 권한 이상의 권한을 소유하게 된다. |
개선 방법 |
- SQL 쿼리를 실행하기 전에 사용자 입력 값에 대한 필터링을 수행하고, 인자화된 쿼리 수행으로 구조를 변경한다. |
개선 코드 |
void User_check(SQLHSTMT sqlh) { char *id = getenv(“id”); char *pw = getenv(“pw”); char query[MAX_QUERY_LENGTH]; id = validateSQLParameter(id, “ID”); // id의 유효성 확인, trim 등의 처리 후 반환 pw = validateSQLParameter(pw, “PW”); // pw의 유효성 확인, trim 등의 처리 후 반환
sprint(query, “SELECT * FROM user WHERE id=’%s’ and pw=’%s’”, id, pw); SQLExecDirect(sqlh, query, SQL_NTS); } |
나. 안전하지 않은 C언어 코드 사례 2
구분 |
내용 |
문제 코드 |
#include <stdio.h> #include <stdlib.h> #define BUFSIZE 100 void f() { char buf[BUFSIZE]; gets(buf); } |
취약점 분류 |
API 오용 |
공격 유형 |
Buffer overflow |
원인 및 영향 |
표준 입력(stdin)으로부터 사용자의 입력을 받는 gets 함수는 사용자 입력의 최대 크기를 제한할 수 없으므로, Buffer Overflow 공격의 주 대상이 되므로, 이미 위험하다고 알려져 있는 함수임 |
개선 방법 |
입력 값의 최대 크기를 지정할 수 있는 fgets 함수를 gets대신 사용 |
개선 코드 |
#include <stdio.h> #include <stdlib.h> #define BUFSIZE 100 void f() { char buf[BUFSIZE]; fgets(buf, BUFSIZE, stdin); } |
다. 안전하지 않은 JAVA 언어 코드 사례 3
구분 |
내용 |
문제 코드 |
public class S_check extends HttpServlet { public void noExpiration(HttpSession session) { if(session.isNew()) { session.setMaxInactiveInterval(-1); } } } |
취약점 분류 |
보안기능 |
공격 유형 |
세션 아이디 재사용 |
원인 및 영향 |
- 세션이 신규로 생성된 경우, 미사용 세션의 최대 유지시간을 ‘-1’로 설정하는 것은 무제한으로 설정하는 의미 - 피해자가 오랫동안 PC를 비우는 사이에 악의적 목적을 가진 공격자가 사용자 PC를 점거 가능 - 세션 하이재킹 등의 공격이 보다 수월해짐 |
개선 방법 |
- 미사용 세션의 최대 유지 시간을 양수로 정의함 |
개선 코드 |
public class S_check extends HttpServlet { public void noExpiration(HttpSession session) { if(session.isNew()) { session.setMaxInactiveInterval(60*60); } } } |