Secure Coding

개념
시큐어 코딩(Secure Coding)의 정의 - 서비스의 안정성과 신뢰성 확보를 위해 IT 시스템 개발 단계에서 주요 보안 취약점을 고려하여 소스코드 레벨에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법 - 소프트웨어 개발보안(Secure Coding): 해킹 등 사이버공격의 원인인 보안약점을 개발단계에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법

I. 공공 정보화 사업의 안전성을 위한 시큐어 코딩의 개요

가. 시큐어 코딩(Secure Coding)의 정의

  1. 서비스의 안정성과 신뢰성 확보를 위해 IT 시스템 개발 단계에서 주요 보안 취약점을 고려하여 소스코드 레벨에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법
  2. 소프트웨어 개발보안(Secure Coding): 해킹 등 사이버공격의 원인인 보안약점을 개발단계에서 사전에 제거하여 안전한 소프트웨어를 개발하는 기법

나. 시큐어 코딩의 목적

목적

시큐어 코딩의 목적

사이버 공격 예방

사이버 공격의 75%가 응용 프로그램의 취약점을 악용한 것(가트너 발표)

웹 어플리케이션

취약점 개선

사이트 교차 접속 스크립팅(XSS), SQL인젝션 공격 등의 웹 응용 프로그램에 내재된 보안 취약점을 이용한 고객 정보 유출 사고 발생

취약점 수정

비용 절감

설계 과정에서 발생한 결함이 개발 완료 후에 발견, 조치되는 경우, 설계 단계에서 결함을 수정하는 비용 대비 30배 비용 발생

보안취약점

대응

  • 최근의 사이버 공격의 진화에 다른 사전에 정보처리시스템의 보안취약점을 사전 대응
  • Zero Day공격, SQL인젝션 취약점, 침입차단시스템 등 보안장비의 우회 등

전자정부

서비스확대

ICT 신기술을 활용한 전자정부 서비스가 확대되고, 대부분의 행정서비스가 인터넷을 통해 제공되면서, 전자정부 서비스의 보안취약점을 지속적으로 진단, 제거에 효율적 관리 방안

안정성 및

신뢰성 확보

전자정부 서비스의 안정성 및 신뢰성 확보를 위해 정보시스템의 개발단계부터 개념 및 소스코드레벨에서의 대응조치를 제안하여 전자정부 서비스의 보안 정책을 강화하기 위함

  1. 보안 취약점 제거는 운영단계보다 개발단계가 훨씬 효율적
  2. 소스코드 레벨의 보안 취약점 잔존 최소화가 목적

다. 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 보안전문가를 중심으로 취약점의 한계를 극복하고자 소스코드의 취약점 패턴과 이에 대한 공격 및 보안조치를 활발히 연구하고 공유
  • 보안 취약점 사례의 체계적인 DB 구축, 정보 및 민간차원의 활동 진행

발주영역

(공공)

  • 정보 및 민간차원에서 발행되는 공신력을 보유한 가이드와 동향에 적극적인 준수
  • SW보안 전문 인력과 기관과의 긴밀한 협업과 지속적인 Research를 통한 적용의 의무화

감리영역

정보처리 시스템의 감리영역에서 감리법인은 정보시스템 감리 시 검사항목에 보안약점 제거여부를 반드시 포함 통해서 지속적 진행

개발영역

  • SW 개발의 전체 생명주기(SDLC)에 영향력이 있으며, 초기단계일수록 결함을 수정하는 비용이 줄어드는 분석결과를 토대로 개발의 단계의 충분한 시큐어 코딩 교육을 통해서 상대적으로 효과를 높일 수 있음
  • 보안개발의 실효성 제고를 위해 개발자가 보안취약점을 이해하고 보안조치를 반영할 수 있도록 사전 개발자 교육을 강화
  • 검수과정에 보안조치 반영여부 및 보안취약점 잔존여부를 확인하기 위해 절차를 적용할 필요 있음
  • 결과적으로 개발단계에서부터 보안을 고려해 소스코드를 작성하는 한편, 보안취약점을 사전에 진단 및 제거하기 위한 노력을 통해 안전한 전자정부 서비스를 보다 효과적으로 구현할 수 있음
  • 즉 시큐어 코딩 부문은 개발영역의 체계화된 괸리와 운영을 통해서 SW 보안을 실현할 수 있음

 

V. 소프트웨어 개발보안 가이드의 활성화 방안 및 세부 활동

가.소프트웨어 개발 보안 가이드 활성화 방안

  • 정부 및 공공기관 <1단계>의무적용을 통해 국가 정보화 사업에 SW개발보안 가이드 활성화
  • 민간기업, 대형 SI기업에 초기에 권고를 통한 적용 이후, 의무적용에 준하는 활성화를 유도하는 <2단계>실시
  • 소프트웨어 보안취약점에 따른 개발보안 가이드는 보안문제가 사회적으로 심각성이 더해가는 상황에서 단계적 적용을 통한 활성화가 필요
  • 이를 위해, 국가 및 정부, 공공기관 그리고 민간기업 등에서 SW개발 보안가이드 활성화를 위한 다양한 세부 활동이 필요함
  • ICT 신기술을 활용한 전자정부 서비스가 확대되고, 대부분의 행정 서비스가 인터넷을 통해 제공되면서, 전자정부 서비스의 취약점을 지속적으로 진단하고 보완하는 노력이 필수적,
  • 대국민서비스, 공공서비스, 전자정부 서비스 등의 안정성 및 신뢰성 확보
     

 

나. 소프트웨어 개발 보안 가이드 활성화를 위한 세부 활동

주체

세부활동

주요내용

국가 및 정부

보안연구 및 지속적 보안취약점 DB업데이트

  • 일회성 가이드 아닌 지속적 보안 취약점 DB업데이트를 통한 보안가이드 현행화 실시
  • SW보안전문가 중심 취약점 패턴과 보안공격 및 조치에 관한 연구활동 장려àDB의 지속적 Updateà현행화 단계로 순환적 체계 형성

가이드 홍보

국가차원에서 국가를 대상으로 한 사업 및 공공사업에 가이드 적용을 위한 교육의 주기적 실시, 홍보자료 배포

공공기관

정보화 사업 발주부분에 적용

국가를 대상으로 하는 정보화 사업에 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);

  }

}

}

 

 

댓글