드디어 OWASP Top 10이 업데이트 되었다!!!
내 기억이 맞다면 2017년도 이래로 4년만에 업데이트 된 것이다.
내용의 변화가 무척 흥미롭다. 얼른 알아보자.
(원문 : https://owasp.org/Top10/)
우선 2017년도와 비교했을때의 큰 변화는 아래와 같다.
- Injection이 왕좌를 내려놓고 3위로 물러났으며 왕좌는 Broken Access Control이 차지했다.
- XSS가 단일항목에서 Injection으로 흡수되었다.
- XXE가 단일항목에서 Security Misconfiguration으로 흡수되었다.
- Insecure Deserialization이 단일항목에서 Software and Data Integrity Failure로 흡수되었다.
자 하나씩 순서대로 보도록 하자.
1. Broken Access Control (부적절한 인가)
2017년도 5위에서 2021년도 1위가 되어 왕좌를 차지한 항목이다.
현업에서 모의해킹을 진행하면서 늘 느꼈던 점인데, 개발자분들이 사용하시는 프레임워크 또는 라이브러리들이 점차 발전하며 기술적인 취약점 보다는, 구현단계에서 보안을 신경쓰지 않았거나 실수를 하여 발생하는 취약점들이 훨씬 많아지고 있고, 그 중에서도 사용자의 권한을 확인하여 인가여부를 결정하는 로직에서 특히나 취약점이 자주 발생한다는 것이다.
대표적으로 사용자 검증을 세션 or 토큰을 사용하지 않고 임의의 Request Header나 파라미터를 이용하여 하는 경우가 많이 발견된다. 첨언을 하자면 인가에 대한 여부 판단은 반드시 예측이 불가하며, 임의로 수정이 불가한 세션 or 토큰을 이용해야 한다.
업무를 하며 느꼈던 부분이 OWASP Top 10에 반영된 것을 보니, 내가 일을 헛으로 하진 않았구나 싶다.
2. Cryptographic Failures (암호화 문제)
2017년도 3위 항목이었던 Sensitive Data Exposure 항목이 이름이 바뀌며 2위로 등극했다.
Sensitive Data Exposure은 취약 원인이라기 보다는 취약한 결과쪽에 가까워 갱신된 이름은 이전보다 원인에 포커싱 하여 암호화 관련 취약점에 초점을 맞추었다고 한다.
아무래도 점차 하드웨어가 발전함에 따라 암호화 알고리즘에 대한 취약점이 계속해서 발생하고 있는데, 여전히 취약한 암호화 알고리즘을 사용하는 서비스들이 많고, 또 관심을 잘 가지지 않아 문제가 자주 발생하기 때문에 2위가 된 것이 아닐까 싶다.
3. Injection (인젝션)
1위의 왕좌에서 내려온 Injection이다.
XSS도 이번에 Injection에 포함되었다는 것이 특이한 점인데, 아무래도 XSS를 Web Frontend code Injection으로 본게 아닐까? 라는 추측을 하고 있다. 공격방식이 아무래도 코드를 임의로 삽입하는 것이니 가능성이 있다고 생각한다.
Injection에는 LDAP Injection, SQL Injection, Command Injection등 수많은 Injection 공격이 있는데, 대표적으로 가장 유명한 SQL injection만 봐도 예전에는 꽤나 자주 발생을 했었는데, 요즘엔 개발 프레임워크의 발전으로 인해 거의 ORM을 사용하고 있고 기본적으로 제공하는 보안모듈에서 막아주기도 하기에, 발생하기가 쉽지 않은 상황이 되었다.
개발 환경이 점차 고도화되고 발전함에 따라 점차 그 영향도가 떨어지는것이 느껴진다. 시간이 빠름을 새삼 느낀다.
(라떼는 SQL Injection이 많이 나왔어!)
4. Insecure Design (안전하지 않은 설계)
2021년도에 새로 생긴 항목이다. 설계단계에서 보안에 신경쓰지 않는 경우를 의미한다.
요즘 보안업계에서는 원점 회귀(Shift Left) 보안의 중요성이 대두되고 있는데, 이는 개발 프로세스에서 가능한 한 초기 시점에 보안을 신경쓰는 것이라고 생각하면 된다.
만약 모든 개발이 완료되어 배포가 이루어진 뒤, 서비스를 사용자가 사용하고 있는 상황에 뒤늦게 취약점이 발견되었다면 이를 조치하기가 쉬울까? 어려울 것이다. 이미 사용자는 사용을 하고있고 특히나 요즘 서비스들은 실시간성, 서비스 가용성, 속도에 상당히 민감한데 취약점을 이제와서 조치하고 이를 급하게 배포하게 되면 어떤 장애가 날지도 모르고, 배포 중 서비스 가용성에 문제가 생길수도 있는 등 여러가지 고려할 부분이 많아 조치를 하기가 쉽지 않다. 그래서 보안을 초기에 잡아야 한다는 것이다.
개인적인 생각으로는 모든 취약점의 시작점이 아닐까 싶다. 다른 항목들 보다는 범위가 많이 넓지만, 충분히 4위에 있을만한 항목이라고 생각한다.
5. Security Misconfiguration (보안 설정 미흡)
2017년 6위에서 2021년 5위가 된 항목이다.
설명이 크게 필요하지 않다. 보안관련한 설정이 미흡한 경우를 의미한다.
개발자가 테스트용도로 편의를 위해 사용하던 설정을 운영용 서비스에도 실수로 반영하는 등 설정 미흡으로 인한 취약점은 여전히 잘 나오고 있기 때문에, 충분히 5위에 있을법하다고 생각한다.
XXE를 이 항목에 합친것은 조금은 신기했다. 아무래도 XXE를 단일항목으로 구분하기에는 사이즈가 좀 작아서 그런가? 라는 생각도 든다.
6. Vulnerable and Outdated Components (공개된 취약점이 있거나, 지원이 종료된 컴포넌트 사용)
2017년 9위에서 2021년 6위가 된 항목이다.
역시나 간단하다 공개된 취약점이 있거나, 지원이 종료된 컴포넌트를 사용하는 경우를 의미한다.
CVE가 있는 라이브러리나 컴포넌트를 사용할 경우, 당연히 이를 통해 1-day exploit 공격을 당할 수 있다.
지원이 종료된 라이브러리나 컴포넌트를 사용할 경우, 취약점이 발견된다고 해도 이를 패치하지 않아 공격 당할 수 있다.
그래서 사용하고 있는 라이브러리나 컴포넌트에 대해서는 지속적으로 공개된 취약점이 있는지 확인하고 패치작업을 수행해 주어야 하며, End of Service 또는 End of Life 기한을 확인하여 대응해야 한다.
7. Identification and Authentication Failures (불충분한 인증)
2017년도 2위항목에서 2021년도 7위로 떨어진 항목이다.
여전히 Top 10에 필수적이지만, 표준화된 프레임워크가 인증에 많은 도움을 주고있어 순위가 떨어졌다고 되어있다.
하지만 난 이 의견에는 조금 반대이다.
물론 표준화되고 고도화된 프레임워크는 인증에 있어 많은 기능들을 제공해주고 있어서 많은 도움을 주는 것은 사실이다. 하지만 개인적으로 현업에서 인증에 대한 부분은 여전히 상당히 많이 문제가 되고 있다고 생각한다. 대표적으로 서버의 부하를 줄이기 위해 stateless한 토큰인 JWT를 많이 사용하게 되면서 인증에 대한 문제가 많이 발생하고 있는데... 자세한 내용은 다른 포스팅에서 다루도록 하겠다.
7위라는 점은 개인적으로는 아쉽게 느껴지는 순위이다.
8. Software and Data Integrity Failures (데이터 무결성 확인 문제)
2021년도에 새롭게 신설된 항목이다.
무결성을 검증하지 않고 소프트웨어를 업데이트 하거나, 서비스 배포 시 사용된 리소스나 코드의 무결성을 검증하지 않는 경우를 의미한다.
조금 쉽게 생각하면 개발할때 사용하는 라이브러리가 있다고 했을때, 만약 dns spoofing등의 공격을 당해 똑같아 보이는 라이브러리지만 그것이 악의적으로 변조된 라이브러리라면, 무결성 체크를 하지 않고 그대로 서비스 배포시 악의적인 목적을 가진 해커에게 해당 라이브러리를 통해 공격을 당할 수 있다.
무결성 체크에 대한 부분은 상당히 중요한 부분이고, 패치와 함께 같이 관리되면 좋지않을까 싶은 생각이 든다.
9. Security Logging and Monitoring Failures (보안 로깅과 모니터링 문제)
2017년도에 10위에서 2021년도에 9위가 된 항목이다.
보안 로깅과 모니터링 관련 문제인데, 로깅과 모니터링을 잘 하지않으면 침해에 대한 분석 및 대응이 어려워지는 것은 사실이다.
하지만 이 항목은 개인적으로 조금은 의아하긴 하다.
OWASP Top 10이 Web 어플리케이션 보안 리스크 순위인데, 보안 로깅과 모니터링이 맞나...? 라는 생각이 좀 든다.
물론 중요한 항목은 맞으나, Web 어플리케이션 리스크에 포함되는게 맞는건가? 저걸로 인해 공격을 당할 수 있나? 리스크가 맞나? 라는 의문이 지속적으로 든다.
10. Server Side Request Forgery (서버사이드 요청 변조)
2021년에 신설된 항목이다. 조금은 놀란 항목이다.
SSRF는 CSRF와는 다르게 서버들끼리 이루어지는 요청을 변조하는 공격의 의미하는데, 최근 많이 이슈가 된 항목이다.
서버들끼리 internal 통신을 수행할때의 요청을 변조하는 것이다 보니, 공격이 상당히 어려운점이 있다.
다른 내부 서버가 어떤것이 있는지 모르고, 어떤 internal API가 있는지도 모르고 모르는것 투성이이기 때문이다.
하지만 클라우드를 사용한다면 어떨까?
대표적으로 AWS에는 인스턴스의 메타데이터를 조회할 수 있도록 Link-local address를 제공한다.
outbound를 제어하고 있지 않다면 모든 인스턴스는 해당 주소를 통해 메타데이터를 조회할 수 있는데, 이때 다양한 정보가 노출된다.
SSRF의 어려운점이 정보부족이었는데, 이렇게 공개되어있는 정보가 있다면? 우리는 쉽게 SSRF취약점을 이용해 인스턴스의 정보를 빼낼 수 있다. 그래서 주로 클라우드 환경에서 많이 발생한다.
SSRF가 순위에 들었다? 클라우드 환경으로의 변화가 많이 이루어졌다는것을 새삼스레 느낄수 있는 부분이 아닌가 싶다.
공부 열심히 해야겠다.
느낀점
확실히 예전에는 공격 방식을 단일 항목으로 지정하여 순위를 매기는 형태였다면, 점차 공격 방식처럼 좁은 한 부분이 아니라 취약점이 나오게 되는 원인처럼 큰 범위로 항목을 지정하여 순위를 매김을 알 수 있다.
우리나라 주요정보통신기반시설 취약점 분석 평가 항목이나, 전자금융기반시설 취약점 분석 평가 항목도 OWASP처럼 취약점이 나오게 되는 원인으로 항목을 다시 정리하여 배포하는것도 괜찮지 않을까 싶다. 지금은 너무 단일 공격 방식이랑 취약점의 원인이랑 뒤죽박죽이라...
전반적으로 만족스러운 업데이트인데... 인증쪽만 조금은 불만이다! 나만 그런가!
공부할게 많아졌다. 노력하자.
'Webhacking' 카테고리의 다른 글
| [T0M4TO] Heavy Query Time based SQL Injection (0) | 2021.11.21 |
|---|
