2019년 소프트웨어 개발 보안

점점 보안이 강조되고 있다. 나 또한 처음에 보안에 대한 관심은 있지 않았다. 그러나 단 한번 보안과 관련된 안 좋은 일을 맞이하고 나서부터는 개발할 때 보안을 많이 신경 쓰고 있는 상황이다.

 

모든 우리나라의 관리되고 있는 웹 사이트가 그럴 것이다. 각 기업들은 중요 정보를 가지고 있다. 일반적으로 그런 중요 정보는 고객의 정보가 될 것이고, 실제로 만나지 않은 고객에게 물건(상품)을 파는 회사인 경우가 많다. 고객과 직접 대면하지 않고 진행할 수 있는 업무를 비대면 업무라고 한다. 대표적으로 금융권에 존재하는 회사들이 그렇다. 회사 내부 직원들이 사용을 한다면 네트워크를 폐쇄적으로 설정하면 되지만, 외부 고객 사용을 위해서는 특정하게 80 PORT 정도는 열어주는 상황이다.

 

이것이 악의적인 의도를 가진 사람들의 유일한 진입 통로이다. 이 이야기는 무엇이면, 악의적인 의도를 가진 사람이 유일하게 회사의 고객정보를 탈취 할 수 있는 통로가 비대면 업무라는 이야기인 것이다. 나와 같은 개발자가 아무런 생각 없이 상용 프로그램을 만들게 되면 많은 고객들의 정보가 위험하게 노출될 수 있다는 이야기이다.

 

이번에 행정안전부, 한국인터넷진흥원(KISA)에서 주최하는 2019년 SW개발보안 기본과정 교육을 듣게 되었다. 기본과정에서는 개발자의 실수, 논리적 오류 등으로 인해 발생될 수 있는 보안약점들을 최소화하여 안전한 소프트웨어를 개발하기 위해 소프트웨어 개발 각 단계별 적절한 보안활동 수행 방안에 대해 설명했다.

 

우선 보안활동 수행 방안에 대해 설명하기 전 보안 취약점 유형을 설명하도록 하겠다. 보안 취약점 유형은 다 설명하기도 힘들 정도로 많이 있지만, 여기서는 대표적으로 5가지만 설명하도록 하겠다.

 

• SQL Injection
• XSS(Cross-Site-Scripting)
• CSRF(Cross-Site request forgery)
• 웹쉘 업로드
• 파일 업로드, 다운로드

첫번째 SQL Injection이다. DB를 조회하는 Query문을 공격자가 임의로 변형을 시키는 방법이다. 가령 예를 들어 아래와 같이 로그인을 하기 위한 회원가입 확인 여부 Query문이 존재한다고 생각해 보자.

SELECT * FROM MEMBER WHERE ID = 'bangno' AND PWD = '123456';

개발자의 의도는 해당 사이트 회원 중에서 패스워드까지 일치를 하는지 확인하는 것이다. 그러나 여기서 공격자가 아래와 같이 SQL을 변형하면 어떻게 될까?

SELECT * FROM MEMBER WHERE ID = '' OR a = 'a' AND PWD = '' OR a = 'a';

bangno라고 들어가 있는 곳에 ' OR a = 'a 라고 써서 넣고 PWD의 input에도 동일하게 넣었다. 이렇게 공격자가 변경을 해서 SQL이 수행이 되면 모두 true가 되어서 전체 회원의 정보가 나오게 된다. 만약에 개발자가 결과값이 한건만 나오는 SQL Method를 사용했다고 해보자. 개발자가 수행 로직은 한건만 나오도록 처리가 되지 않으니 오류가 발생하게 될 것이다. 이때 시스템 에러 메시지 처리를 미숙하게 처리하였다면, 공격자는 한건만 나오는 Method를 사용했다고 파악이 가능하다. 이후 회원 가입하는 페이지에서 불특정 ID 중복확인을 해보고 중복이 된다는 메시지가 존재하게 되면(중복된 ID가 있습니다.라는 메시지도 사실은 공격자에게 힌트를 줄 수 있는 메시지이다.) 아래와 같이 수행을 하여서 접속이 가능하게 된다.

SELECT * FROM MEMBER WHERE ID = 'bangno'--' AND PWD = '?';

ID값 뒤는 주석처리를 해버려서 로그인이 가능하다. 이건 SQL Injection의 한가지 예 일 뿐이다. 바로 위와 같은 현상들이 발생하지 않게 하기 위해 요즘은 ibatis와 같은 영속성 프레임워크를 사용한다. ibatis와 같은 Tool을 사용하게 되면 Input값과 Query문이 합쳐지기 전에 컴파일이 수행된다. 그렇게 되면은 공격자가 Query문을 조작하려고 하여도 조작된 문장은 String으로만 Query문에 포함되게 된다. 그러나 LIKE문에서 사용 가능한 %, _ 의 경우에는 별도 Validation 처리를 해주는 것이 좋다.

 

두 번째 XSS(Cross-Site-Scripting)이다. 공격자가 가장 좋아하는 방법이다. 그렇기 때문에 모의해킹 점검을 하게 되면 항시 나오는 취약점 중 하나이다. XSS에는 3가지 종류의 XSS가 존재한다.

• Refective XSS
• Stored XSS
• DOM XSS

XSS의 종류가 3가지 정도 되지만 기본적인 공격 방식은 동일하다. 악의적인 스크립트 코드를 Web Application에 삽입하고 해당 코드가 실행되도록 하는 것이다. 간략하게 설명을 하자면 Refective XSS는 공격자가 "hello"라고 입력하게 되면 "hello"라고 응답되는 현상이다. Stored XSS의 경우 웹 스크립트를 DB에 저장해 놓고 고객이 조회를 했을 때 발동될 수 있도록 하는 방법이다. DOM XSS도 동일하다. 데이터가 조회되고 DOM파일에 삽입이 될 때 발동되도록 되는 방법이다. XSS 취약점의 경우 HTML Filtering 방법으로 방어할 수 있다. 그리고 DOM XSS의 경우 HTML에 무조건 String 형태로 출력될 수 있다도록 처리한다. 여기서 가장 좋은 방법은 고객이 위험한 게시물을 함부로 보지 않도록 하는 것이 중요하다. 결국 XSS의 경우 고객의 이벤트 행동에 따라서 발생이 가능하기 때문이다.

 

세 번째 CSRF(Cross Site Request Forgery)이란 공격자가 세션 탈취, XSS 등을 통해 자신이 의도한 행위를 사이트가 신뢰하는 인증된 사용자의 권한을 통해 실행하게 되도록 하는 방법이다. 예를 들어 /ch/changePwd.do?PWD=123라는 패스워드 변경 URL이 존재한다고 해보자. 공격자는 의도적으로 게시판에 스크립트가 실행될 수 있도록 만들어 놓는다. 고객이 게시판의 내용을 무심코 클릭했을 경우 고객은 의도하지 않았지만 패스워드가 공격자가 예상한 "123"으로 바뀌게 된다. 이러한 공격 방식을 CSRF라고 한다. 보통 CSRF 공격을 대비하기 위해서는 사용자에게

 

지금 패스워드를 변경 하려고 하는데 너 진짜 이거 하고 싶어?

라고 물어볼 수 있도록 고객의 패스워드를 다시 입력하도록 한다. 그러나 매번 입력하는 것은 고객 입장에서는 귀찮은 행위 일 수 있다. 특히 위 예시인 패스워드 변경의 경우 해도 되겠지만, 글을 등록하는 프로세스에서 매번 물어볼 경우 고객 입장에서는 많이 귀찮을 수 있다. 그래서 각각 프로세스 구간마다 Token값들을 만들어 놓아서 이 작업을 하기 위한 Token값이 존재하는지 유효성 점검을 하도록 한다. 하지만 Token 정도로는 방어하기가 많이 어려울 수 있다. 그래서 CAPTCHA 기술을 많이 사용하고 있다.

 

네 번째는 웹쉘 업로드이다. 네 번째 내용의 경우 다섯 번째 파일 다운로드, 업로드와 연결되는 내용이기 때문에 같이 설명하도록 하겠다. 파일을 업로드할 수 있는 곳에 웹쉘을 업로드시킨다. 웹쉘 업로드가 가장 위험한 것은 시스템 내부의 정보를 탈취할 수 있다. 또는 프로그램 로직을 조작할 수 있기 때문이다. 파일을 업로드할 시 화이트리스트로 확장자를 점검해야 한다. 여기에서 한 단계 더 나아가 업로드되는 파일 내용까지 검열을 하여서 웹쉘 스크립트 내용이 존재하지 않는지를 확인한다.

 

파일 다운로드의 경우 공격자가 https://nextshds.tistory.com/../../../systemInfo.info를 브라우저 주소창에 적어서 핵심 정보를 탈취하려고 할 수 있다. ../와 같은 상위 디렉토리로 접근할 수 있는 방법을 사용 못하게 하기 위해 URL 유효성 점검을 한다. 아니면 파일 다운로드 주소를 암호화 처리를 하여서 조작하지 못하도록 해야 한다. 또는 해당 사이트에 다운로드 가능한 파일은 특정 힌트 값을 부여해서 해당 힌트 값이 존재하는 파일만 다운로드가 가능하도록 한다.

 

아래의 사이트에 접속 하면 지금까지 발견된 보안 취약성 유형을 확인해 볼 수 있다.

http://cwe.mitre.org/

CWE - Common Weakness Enumeration

위에서 보안취약점 유형과 조치 방법에 대해서 간략하게 설명을 하였다. 그러면 행정안전부와 한국인터넷진흥원에서 설명하는 보안활동 수행 방법은 어떤 것인가?

출처 : 한국인터넷진흥원 2019년 SW개발보안 기본과정

 

위 보안 설계 구현 프로세스를 정의하기 위해서 행정안전부는 아래의 보안약점 47개를 만들어서 설계와 구현 단계 때 해야 하는 내용들을 정리하였다.

 

출처 : 한국인터넷진흥원 2019년 SW개발보안 기본과정

위 47개의 보안약점이 설계와 구현 단계에서 어떻게 적용되어야 하는지 설명하고 있다. 입력 데이터 검증 및 표현, 보안 기능, API 오류 - 취약한 API 사용의 경우 설계 단계에서 많이 도출되어 구현 단계 때 적용되어야 하는 보안약점이다. 에러 처리, 코드 오류, 캡슐화의 경우 구현 단계에서 개발자가 유의하여 개발해야 하는 부분이다.

 

실제로 개발자 입장에서 프로그램을 구현하다 보면, 보안과 관련된 부분까지 신경 쓰기 힘들다. 당장에 시간에 쫓겨서 기능을 만들기에도 급급한 상황이 많다. 그렇다고 소프트웨어 보안의 경우 보안팀만 신경 써야 하는 것도 아니며, 인프라팀만 신경써야 하는 부분도 아니다. 소프트웨어와 관련된 모든 이해집단들이 신경을 써야 하는 부분이다. 보안에는 완벽이란 존재하지 않는다. 특히 비대면 업무를 진행하게 되는 사이트의 경우 외부에서 내부로 들어올 수 있는 방법이 여러 가지가 생길 수 있다. NAT에서 막지 못했으면 Load Balancer에서 막고 그렇지 못했을 경우 Web Server에서 막고 아니면 WAS에서 막고 아니면 DB에 접속되기 전 길목에서 공격자를 차단하게 설계를 해야 한다. 고객의 정보가 탈취가 되었더라도 공격자가 활용하지 못하도록 해야 한다. 한번 방어막을 설치하였다고 해서 그 방어막이 안 뚫릴 것이다는 생각은 하면 안 된다. 수시로 공격자의 대한 모니터링을 진행하면서 허점이 보일 경우 즉각적으로 조치할 수 있는 자세를 가져야 한다.

 

끝으로 재미 삼아 아래의 사이트에 들어가서 내가 사용하는 또는 우리 사이트에서 관리되고 있는 주요 비밀번호가 몇 시간, 몇 달 만에 해제될 수 있는지 확인해보자

https://howsecureismypassword.net/

How Secure Is My Password?

※ 참조

• 한국인터넷진흥원 2019년 개발보안 기본과정
• 모의 해킹으로 배우는 웹 공격과 대응 화이트 해커를 위한 웹 해킹의 기술(저자 : 최봉환)