금융권 오픈뱅킹의 현황과 문제점

I. 서론

예전에는 일반사용자는 Windows를 주로 사용하였고 Linux는 서버 운영체제, 전문가용 운영체제로 취급되었다. 그러나 시대가 변하면서 요즘은 개인이 Linux를 사용하는 경우도 많아졌다. 하지만 대부분의 금융 사이트의 보안 프로그램이 Windows 사용자 중심으로 개발되어 Linux 같은 운영체제를 사용하는 사람들은 금융 서비스를 이용할 수 없었다. 따라서 오픈 뱅킹 서비스가 생겼는데, 오픈 뱅킹 서비스는 다양한 운영체제와 브라우저에서 금융 서비스를 이용할 수 있게 해주는 서비스이다. 이 보고서는 국내 은행사의 오픈 뱅킹 현황과 웹 오픈 뱅킹에서 발생할 수 있는 취약점에 대해 서술한 보고서이다.

II. 은행별 오픈 뱅킹 현황 및 비교

III. 웹 취약성

1. Brute Force 취약점

Brute Force란 인증이 필요한 페이지에 사전파일에 있는 문자들을 하나씩 대입하거나 조합 가능한 모든 문자를 차례대로 하나씩 모두 대입해 인증을 풀어내는 공격이다. 문자들을 하나씩 대입해서 패스워드를 푸는 방식이라 단순하고 시간이 오래 걸리지만 의외로 Brute Force 공격으로 피해를 입은 사례가 많다. 예를 들면 2014년에는 애플의 ICloud 해킹으로 헐리우드 스타들의 사적인 누드사진들이 인터넷으로 배포되는 사건이 있었는데, 이 사건 당시 iCloud의 Brute Force 취약점도 논란이 되었다. 금융 서비스 또한 패스워드를 사용하여 로그인 하는 페이지가 다수 있으므로 Brute Force 공격을 주시해야한다.

2. SQL Injection 취약점

SQL Injection이란 코드 인젝션의 한 기법으로 웹 어플리케이션에서 사용자 입력 값에 대한 필터링이 제대로 이루어지지 않을 경우, 서버의 데이터베이스를 공격하거나 정보를 탈취할 수 있는 공격방식을 말한다. 주로 웹 어플리케이션이 사용자가 입력한 데이터를 제대로 처리하지 못하고 입력값을 SQL 명령의 일부로 해석했을 때 발생한다. 국내에서 발생된 “여기 어때“ 해킹 사건 또한 SQL Injection으로 인해 Database에 저장된 관리자 세션 ID가 탈취되어 발생하였다. SQL Injection 취약점은 데이터베이스를 사용하는 웹 사이트에서 발생할 수 있는 취약점으로 웹을 사용하는 오픈뱅킹 또한 취약점을 가지고 있을 수 있다. 금융 서비스에 대한 공격 트래픽중 36% 가량이 SQL Injection 공격이라고 한다.

3. XSS 취약점

XSS(Cross Site Scripting)란 코드 인젝션의 한 기법으로 웹 어플리케이션에서 사용자 입력 값에 대한 필터링이 제대로 이루어지지 않을 경우, 공격자가 입력이 가능한 폼에 악의적인 스크립트를 삽입하여 해당 스크립트가 희생자 측에서 동작하도록 하여 악의적인 행위를 수행하는 취약점이다. 공격자는 취약점을 이용하여 사용자의 개인정보 및 쿠키정보 탈취, 악성코드 감염, 웹 페이지 변조 등의 공격을 수행한다. 2010년 트위터 음란물 사건 또한 XSS로 인해 발생한 사건이다. 금융 서비스 또한 웹 페이지를 이용하기 때문에 XSS를 이용한 해킹에 취약할 수 있을 것이다. XSS는 금융 서비스에 대한 공격 트래픽 중 7.7%를 차지한다고 한다.

4. CSRF 취약점

CSRF(Cross Site Request Forgery)란 웹 어플리케이션 취약점으로 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다. XSS를 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, CSRF는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 CSRF 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다. 2008년 발생된 옥션 개인정보 유출 사건 또한 공격자가 이메일에 코드를 심은뒤 옥션 관리자에게 전송해 읽도록 유도해 암호를 변경하여 권한을 탈취한 CSRF 공격이 사용되었다.

5. RFI 취약점

RFI(Remote File Inclusion)란 악성 스크립트를 웹 어플리케이션 서버에 전달하여 특정 페이지를 통하여 전달한 악성 코드가 실행되도록 하는 것이다. 악성 스크립트의 위치는 공격 대상 서버가 아니라 원격지에 있다. 쉽게 말해서 웹 어플리케이션에 공격자 자신의 코드를 원격으로 삽입한다는 것이다. 이 취약점은 웹 서버에서 GET Request, POST Request, Cookie등의 Parameter 값을 제대로 검사하지 않아 발생하는 취약점이다.

6. LFI 취약점

LFI(Local File Inclusion)란 RFI와 동일하게 악성 스크립트를 웹 어플리케이션 서버에 전달하여 특정 페이지를 통하여 전달한 악성 코드가 실행되도록 하나 악성 스크립트가 공격대상 서버에 위치한다는 차이점이 있다. (RFI : 대상 파일이 원격지에 위치, LFI : 대상파일이 공격대상 서버에 위치) 금융 서비스에 대한 LFI 공격이 47%에 달할만큼 LFI 공격이 많이 일어난다고 한다.

IV. 웹 취약성 해결 방안

1. Brute Force 취약점

1-1) 로그인 재시도 딜레이 설정

Brute Force의 특성상 암호를 랜덤으로 대입하여 맞추는 것이기 때문에 한번에 성공할 확률은 적고 수많은 시도를 해야 할 것이다. 따라서 특정 IP 등에서 비정상적인 로그인 실패횟수 등이 감지되면 해당 IP를 일정 시간동안 차단하고 해당 계정을 보호조치 하는 기능을 구축해야한다.

1-2) 복잡한 암호 패턴

회원가입 폼 등에서 복잡한 암호 패턴 조건을 적용하여 처음부터 강력한 암호를 설정하도록 한다. 특수문자나 대문자 등을 사용해 예측하기 어렵고 충분히 긴 암호를 설정하면 Brute Force를 이용해 암호를 푸는 데 오래 걸린다.

1-3) 주기적인 암호 변경 알림

서버쪽에서 공격시도를 감지하여 막아내는 것도 중요하지만 사용자에게 주기적으로 암호를 변경하라고 알려주는 것 또한 중요하다. 암호 변경이 해커의 시도를 매번 무산시키는 것은 아니므로, 유출이나 공격이 의심될 때 암호를 변경하는 것이 중요하다.

2. SQL Injection 취약점

2-1) 입력값 검증

사용자의 입력이 DB Query에 동적으로 영향을 주는 경우 입력된 값이 개발자가 의도한 값인지 검증하도록 설정해야 한다.

2-2) 저장 프로시저 사용

저장 프로시저를 사용하여 사용하고자 하는 Query 형식을 미리 지정하여 입력값을 SQL 명령으로 이어 붙이지 않고 매개변수로 처리한다.

2-3) 서버 보안

의도치 않은 Query를 차단하는것도 중요하지만 Database를 최소한의 권한으로 운영하거나 에러 메시지 노출 차단등 기본적인 서버 보안도 매우 중요할 것이다.

3. XSS 취약점

3-1) 입력 값 제한

사용자의 입력값을 제한하여 스크립트를 삽입하지 못하도록 해야한다. http://helloworld.com?page=1 와 같은 URL의 경우 사용자의 입력값인 page등의 값을 숫자로만 허용한다거나 해당 값의 유효성 검사를 거치게 한다.

3-2) 입력 값 치환

XSS 공격은 <script> 태그 등 여러 방법을 사용할 수 있기 때문에 XSS 공격을 차단하기 위해 태그문자등 위험한 문자 입력시 HTML Entity로 필터링하고 서버에서 브라우저로 전송시 출력되는 위치에 맞게 문자를 인코딩 하는 것이다. 이렇게 인코딩하면 웹 페이지에는 <script>로 보이지만 HTML 문서에서는 <script>로 나타나서 브라우저에서 일반 문자로 인식하고 실행되지 않는다.

3-3) 스크립트 영역에 출력 자제

이벤트 핸들러 영역에 스크립트가 삽입되는 경우 보호 기법들을 우회할 수 있기 때문에 사용자의 입력을 출력하는 것은 최대한 피해야한다.

4. CSRF 취약점

4-1) Referer 체크

Referer 체크는 백엔드 단에서 해당 요청의 Referer를 확인하여 도메인이 일치하는지 검증하는 방법으로, 일반적으로 Referer 체크만으로 대부분의 공격을 방어할 수 있다. 하지만 같은 도메인 내의 페이지에 XSS 취약점이 있는 경우 공격에 취약해질 수 있다. 도메인 단위 검증에서 좀 더 세밀하게 페이지 단위까지 일치하는지 검증하면 도메인 내의 타 페이지에서 CSRF 취약점에 의한 공격을 방어 할 수 있다.

4-2) 시큐리티 토큰(Security Token) 사용 :

Referer 검증이 불가능한 환경이라면 시큐리티 토큰을 사용할 수 있다. 우선 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청마다 해당 난수 값을 포함해 전송한다. 이후 백엔드 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증하는 방법이다. 이 방법도 결국 같은 도메인 내 XSS 취약점이 있다면 공격에 취약하다.

4-3) 더블 서밋 쿠키(Double Submit Cookie) 검증 :

더블 서밋 쿠키 검증은 시큐리티 토큰 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법이다. 웹 브라우저의 동일 출처 정책(Same Origin Policy)으로 인해 자바스크립트에서 타 도메인의 쿠키 값을 확인 및 수정하지 못한다는 것을 이용한 방어기법이다. 스크립트 단에서 요청 시 난수 값을 생성하여 쿠키에 저장하고 동일한 난수 값을 요청하여 파라미터에 저장하여 서버로 전송한다. 서버 단에서는 쿠키의 토큰값과 파라미터의 토큰 값이 일치하는지 검사하면 된다. 피싱 사이트에서는 도메인이 달라 쿠키에 값을 저장하지 못하므로 가능한 방어 기법이다.

5. RFI, LFI 취약점

5-1) 입력값 치환

현재 디렉터리 이외의 외부 경로로 접근을 불가하게 입력값을 검증한다. ../ 과 같은 문자를 공백 등으로 치환하는 것만으로는 우회가 가능하므로 접근 가능한 경로를 제한한다.

5-2) 원격지 파일 접근 불가 설정

PHP를 사용할 경우 환경 설정파일 수정으로 원격지의 파일을 열지 못하게 설정할 수 있다.

5-3) 에러페이지 출력 끄기

원격지 파일 접근 불가 설정을 하였어도 파일을 불러올 수 없다는 에러 메시지가 출력되는데 에러 메시지는 공격자에게 또 다른 정보를 제공할 여지가 있으므로 에러 페이지 자체도 출력되지 않게 하는 것이 좋다.

V. 결론

예전에는 국내 금융 회사에서 Windows만 주로 지원 했으나 현재 오픈 뱅킹 서비스가 도입되어 보다 다양한 운영체제와 브라우저에서 금융 서비스를 편리하게 이용할 수 있게 되었다. 그러나 오픈 뱅킹 서비스를 개시한지 오래되었음에도 불구하고 아직도 리눅스에서 조차 제대로 서비스가 제공되지 않거나 서비스가 불안정한 문제점이 있어 많은 개선이 필요해 보인다. 그리고 금융 서비스를 제공하는 금융 회사는 자사 웹 어플리케이션의 취약점을 주기적으로 점검하여야 할 것이다. 더군다나 단순한 정보가 아닌 민감한 개인정보와 고객의 재산을 취급함으로써 보안에 더욱 더 신경 써야 할 것이다.

VI. 참고 문헌

“2년간 금융권 API 공격 5억 건 달해” http://www.thespeaker.co.kr/news/article.html?no=2952

[웹보안] 브루트 포스(BRUTE FORCE) 공격 https://m.mkexdev.net/426

[Web] CSRF(Cross Site Request Forgery) 공격 기법 https://swk3169.tistory.com/24

[Web Security] RFI & LFI 취약점 (Remote File Inclusion & Local File Inclusion Vulnerability) https://m.blog.naver.com/PostView.nhn?blogId=siren258&logNo=145489344

SQL Injection 대응 방안 http://blog.plura.io/?p=6056

Apple Patches Brute Force Password-Cracking Security Hole in iCloud https://www.intego.com/mac-security-blog/apple-patches-brute-force-password-cracking-security-hole-in-icloud/

트위터 XSS공격 당해…백악관 대변인도 피해 https://www.zdnet.co.kr/view/?no=20100922074501&re=R_20111218162100

사이트 간 요청 위조 http://wiki.hash.kr/index.php/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0#cite_note-7

[No1.Linux 2018] 주요 은행의 인터넷 뱅킹 http://no1linux.org/hottips/28760