본문 바로가기

블로그

LG CNS 기술블로그 DX Lounge에서 최신 IT 소식을 만나보세요!

보안

소프트웨어 개발 보안 – 시큐어 코딩

2016.07.18

사이버 공격 기술은 끊임없이 진화하고 있습니다. 해커들은 다양한 소프트웨어와 시스템의 취약점을 찾아내 공격하는데요. 다음 그림은 소프트웨어 취약점을 통해 공격하는 패턴입니다.

DB와 연동된 소프트웨어에서 입력된 데이터의 유효성을 검증하지 않는다면, SQL문을 조작하여 DB에 저장된 열람 권한이 없는 정보들에 접근할 수 있거나, 디렉토리 경로 조작을 통해 서버 내 주요 파일을 다운로드 할 수 있습니다.

l SQL 삽입: 웹페이지에서 입력이 가능한 부분에 공격 스크립트를 삽입하여 공격 시도
l 디렉토리 경로 조작: 접근 제한 영역에 대한 경로 문자열 구성, 정보 누출 유발

시큐어 코딩(Secure Coding)은 소프트웨어를 개발하는 과정에서 코딩 시에 개발자의 실수나 오류, 약점 또는 취약점이 삽입되지 않도록 프로그래밍하여 서비스 함으로써 사전에 악의적인 사이버 공격을 차단하기 위한 작업입니다.

그러나, 직접 코딩을 하는 개발자의 입장에서는 취약점을 하나하나 고려하는 프로그래밍이란 어려운 일인데요. 국내에서는 2012년 12월부터 시큐어 코딩에 대한 법규가 제정 및 시행되어 그 기준을 제시하고 있습니다.

l 정보시스템 구축, 운영 지침 (안전행정부고시 제2012.25호)

기준으로 제시되고 있는 소프트웨어 보안약점 47개 항목은 다음과 같이 구성되어 있습니다.

l 소프트웨어 개발 보안 가이드

다음에서는 소프트웨어 개발 보안 가이드 구성항목별 대표적인 취약점인 코딩 패턴과 조치 방안을 살펴보도록 하겠습니다.

입력 데이터 검증 및 표현

① SQL 삽입

외부에서 입력한 값이 SQL Query의 파라미터로 검증 없이 사용되어, 공격자가 Query 구조를 변경하여 임의로 데이터베이스 명령어를 실행할 수 있습니다.

다음 예시를 보면 ${name} 구문을 사용하면 값으로 ‘ OR ‘X’=’X 가 전달되어 모든 값이 삭제되므로 #{name}의 형태로 코딩하여 Query 구조가 변경되지 않도록 해야 합니다.

만약, Query 문이 XML 파일에서 정의되어 ${변수명} 구문을 사용해야 한다면, 다음과 같이 해당 Query 문을 실행하는 소스에서 Query 실행 전 Query 구조를 변경할 수 있는 “, ‘, ; #, * 등의 특수문자를 점검하는 함수로 호출하여 처리할 수 있습니다.

② 크로스 사이트 스크립트

공격자가 웹 페이지에 악의적인 스크립트(script)를 삽입하여 사용자 측에서 실행되도록 유도하는 것입니다. 이를 예방하기 위해, 외부에서 입력된 파라미터에 대해 사용자 브라우저에서 실행될 수 있는 스크립트 생성에 이용되는 문자열이 있는지 검증해야 합니다.

다음 예시를 보면 javax.servlet.http.HttpServletRequest.getParameter에서 전달된 attachment를 검증하지 않고 있습니다. attachment에 <, >, &, “ 와 같은 스크립트 코드가 입력되고 이 값이 그대로 사용되면, 공격자에게 사용자의 Cookie 정보가 전달될 수 있습니다.

크로스 사이트 스크립트 공격을 예방하기 위해서 입력 값에서 script 생성에 사용되는 문자열을 제거하는 로직을 적용합니다.

다음의 경우 출력값을 텍스트로 처리해서 취약점을 제거합니다.

보안 기능: 하드 코드 된 패스워드

프로그램 코드 내에 패스워드를 하드 코드하는 경우에 발생합니다. 패스워드는 암호화하여 별도의 파일에 저장해서 사용해야 합니다. 소프트웨어 설치 시 사용하는 디폴트 패스워드와 키 등을 사용하는 대신 “최초 로그인” 코드를 두어 사용자가 직접 패스워드와 키를 입력하도록 구성하는 방식이 권장되고 있습니다.

시간 및 상태: 검사시점과 사용시점 (TOCTOU)

파일과 같은 공유 자원을 여러 스레드가 공유하여 사용할 때, 동기화(synchronized)를 이용하여 한 번에 하나의 스레드가 접근 가능하도록 하지 않으면 프로그램에 여러 가지 문제 – 교착상태, 경쟁 조건, 기타 동기화 오류 등이 발생할 수 있습니다.

아래 예제는 파일의 존재를 확인하는 부분과 실제 파일을 사용하는 부분을 실행하는 과정에서 시간차가 있을 경우, 파일 삭제가 실행되면 프로그램이 예상치 못한 흐름으로 진행될 수 있습니다. 이 때 시간차를 이용하여 파일을 변경하는 공격에 취약할 수 있어, 동기화 구문을 적용하여 하나의 스레드만 접근 가능하도록 합니다.

에러 처리: 오류 메시지를 통한 정보노출

오류 메시지는 정해진 사용자에게 유용한 최소한의 정보만 포함해야 합니다. 소스 코드에서 예외 상황은 내부적으로 처리하고 사용자에게 민감한 정보를 포함하는 오류가 출력되지 않도록 해야 합니다. 아래 그림에서는 SQL 삽입과 경로 정보, 서버 버전 정보를 노출하고 있습니다.

l 오류 메시지를 통한 정보 노출: 민감한 정보가 포함된 오류 메시지를 출력, 공격자의 악성 행위를 도와줄 수 있음

코드 오류: Null Pointer 역참조

Null이 할당될 수 있는 변수에 대해 Null 검사 없이 역참조 되었을 경우, 프로그램 실행 중에 NullPointerException을 발생시키고 이는 프로그램을 비정상적으로 종료시킬 수도 있습니다.

캡슐화: 잘못된 세션에 의한 데이터 정보 노출

멀티 스레드(Multi-thread)1 환경에서 정보를 저장하는 멤버 변수가 포함되는 경우 다른 사용자에게 정보가 열람될 수 있습니다. Java에서는 HttpServlet 클래스의 하위 클래스에서 멤버 필드를 선언하지 않도록 하고 필요한 경우 지역변수를 사용해야 합니다.

지금까지 소프트웨어 보안약점의 대표적인 경우와 조치 방안을 간단히 살펴보았습니다. 그렇다면, 이러한 시큐어 코딩을 적용했는지 어떻게 확인할 수 있을까요?

개발자가 일일이 코드를 리뷰할 수도 있겠지만, 시간이 많이 걸리고 실수나 판단 오류도 개입될 수 있기 때문에 소스 코드를 Scanning 해서 취약점을 찾아내는 솔루션을 적용하는 추세입니다.

상용 솔루션들도 시중에 많이 제공되고 있지만, 소스 코드가 공개되어 누구나 자유롭게 사용할 수 있고, 배포할 수 있는 공개 소프트웨어로도 소스 코드 취약점을 점검하는 환경을 구성할 수 있습니다.

행정자치부에서는 “공개 소프트웨어를 활용한 소프트웨어 개발 보안 점검 가이드”를 제공하고 있는데요. Jenkins, FindBugs, FindSecurityBugs, PMD를 이용하여 소프트웨어 보안 약점을 분석하고 리포팅 할 수 있도록 소개하고 있습니다.

l 공개 소프트웨어 점검 도구 구성도
  1. 개발자는 Eclipse에 플러그인 된 FindBugs, FindSecurityBugs, PMD를 활용하여 소프트웨어 보안약점을 자가 점검하고, 완료된 코드는 형상관리 서버에 반영합니다.
  2. Jenkins 서버는 주기적으로 형상 관리 서버로부터 개발코드를 연동하여 플러그인 된 FindBugs, FindSecurityBugs, PMD를 통해 소프트웨어 보안약점 관련 분석을 실시하고, 분석된 결과를 리포팅합니다.
  3. 소프트웨어 보안약점 결과는 Jenkins를 통해 PM•품질담당자•개발자에게 전달됩니다.

소프트웨어 보안약점을 자동적으로 분석하는 도구까지 살펴보았는데요.

그렇다면, 소프트웨어 보안약점 분석 도구를 적용하고 보고된 모든 취약점을 조치하면 시큐어 코딩이 완료될 수 있을까요? 안타깝지만, 소프트웨어 보안약점 도구로 주기적으로 소스 코드를 검사하는 효율성은 큰 장점이지만, 여러 가지 상황과 가능성을 고려하여 지속적으로 정보를 수집, 관리하고, 설계와 코드에 반영해야 합니다.

소프트웨어 보안약점 분석 도구는 완벽하지 않습니다. 보통 정적 분석 즉, 소프트웨어가 실행되지 않고 소스 코드 상태에서 취약한 부분을 찾는 것으로 오탐이 없을 수 없습니다.

예를 들어, 소프트웨어 보안약점을 분석하는 도구에서는 SQL Query에서 다음과 같이 변수가 아닌 상수로 사용된 특수문자를 SQL 삽입 취약점으로 검출하기도 합니다.

점검 시 오탐에 대해서 효과적으로 관리하지 못하면 개발 진행에 영향을 줄 수 있으며, 오탐을 계속 분석을 하게 되어 점검 효율이 떨어지게 됩니다. 정기적으로 분석하고, 분석 결과가 보고될 때마다 오탐 여부를 확인하고, 그 내용을 다음 분석에 반영하는 등의 꾸준한 관리가 필요합니다.

또한, 비즈니스 로직의 논리적 오류를 이용한 취약점에는 정적 분석의 한계가 있습니다. 대표적인 예가 URL 파라미터 위변조 취약점인데요.

웹 페이지에서 요청을 할 때, 요청에 대한 값을 가지고 있는 변수를 조작하여 비정상적인 동작을 유발하는 것입니다. 이를테면 웹사이트 게시판에 비밀글을 게시했을 때, 자신이 게시한 글의 웹페이지 주소가 http://www.aaa.com/list.php?a=1234 라면, 1234를 1235로 바꿨을 때 다른 사람이 쓴 비밀글이 조회 가능한 취약점이 있는 소스는 탐지해내지 못합니다.

이 취약점은 공공 I-PIN 부정발급 등에 이용되었는데요. I-PIN 부정발급 사례에서는 해커가 미리 입수한 개인 정보를 이용해 아이핀을 여러 번 발급해보면서 인증 완료 정보가 발급되는 로직을 파악한 후 이를 적용해 인증 완료를 수행한 후 아이핀을 발급받았습니다.

또한, 최근에 급속도로 증가하고 있는 모바일의 경우에는 적용 기준이 다릅니다. 예를 들면, 웹은 SQL 삽입으로 정보를 추출하는 등의 문제가 있다면, 모바일 서비스는 중요한 데이터를 안전하지 않은 SD 카드에 저장되도록 코딩하거나 불필요하게 디바이스에 있는 위치 또는 문자 정보에 접근하는 등이 취약점이 발생할 수 있습니다.

즉, 서비스와 플랫폼 특성에 따라서 취약점의 종류와 내용이 달라지게 됩니다. 그러므로, 시큐어 코딩을 기본적으로 가져가되, 환경, 서비스, 플랫폼 등을 고려한 취약점 점검 및 관리가 필요합니다.

글 | LG CNS 보안컨설팅팀

[‘보안, 이렇게 하면 된다’ 연재 현황]

  • [1편] ISMS 의무인증 대상 확대! 어떻게 대응해야 할까?
  • [2편] ISMS 인증을 위한 보안솔루션 구성 방안
  • [3편] ISMS 인증 주요 결함사항 및 대응방안
  • [4편] 정보보호 관련 인증 및 평가 제도
  • [5편] 스마트폰의 보안 위협과 대응 방안
  • [6편] IoT 보안 취약점 사례 소재 및 취약점 진단
  • [7편] 스마트폰 앱 서비스 보안의 현재와 미래
  • [8편] 중국 개인정보 보호법 제도 동향 및 대응방향
  • [9편] 출입 보안을 위한 보안 설계
  • [10편] 소프트웨어 개발 보안 – 시큐어 코딩
  • [11편] 당신의 출입카드는 안녕하십니까?
  • [12편] 통합 보안 관리 동향 및 활용 방안
  • [13편] 비대면 실명인증이란 무엇인가?
  • [14편] 프로젝트에서 소스 코드 보안 점검하기
  • [15편] 차세대 행위 기반 위협 탐지 방식에 관하여
  • [16편] 핀테크 보안 위협과 대응 방안
  • [17편] 인공지능과 보안
  • [18편] ‘보안은 제품이 아니라 절차다!’라는 말의 의미
  • [19-1편] 인증의 완성판 생체인증에서 다중 생체인증까지 ①
  • [19-2편] 인증의 완성판 생체인증에서 다중 생체인증까지 ②
  • [20-1편] 중국 네트워크 안전법 분석 및 대응 방안 ①
  • [20-2편] 중국 네트워크 안전법 분석 및 대응 방안 ②
  • [21편] 유전자 정보 보안 안전한가?

챗봇과 대화를 할 수 있어요