Medium - The Top 10 Security Risks in Web Applications
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 웹 응용프로그램 보안 취약점 Top 10; 여러분의 취약점과 이것을 해결하는 방법에 대해서 알아봅시다.
Photo by Vladyslav Cherkasenko on Unsplash.
매년 OWASP (Open Web Application Security Project)에서 보안 취약점 Top 10을 공개합니다. 이 문서는 웹 응용프로그램 보안에 대한 경각심을 일깨워주며 특히 개발자들에게 유용합니다. 해당 보고서는 웹 응용프로그램의 가장 크리티컬한 취약점들을 광범위하게 나타내고 있습니다.
개발자라면 이런 보안 취약점들 중 하나가 여러분의 응용프로그램에 위협에 될수도 있다는 것을 아셔야 합니다. 이런 위험을 인지하는 것이 가장 중요합니다. 취약점들에 대해 알게되고 그러한 취약점을 피하도록 하는 프로세스는 보안 취약점을 줄이는 데 매우 중요하죠. 서론은 이만 줄이고 보안 취약점 Top 10을 바로 알아봅시다.
1. Injection
인젝션은 개발자들에게는 그리 새로운 것이 아닐겁니다. 우리 모두는 응용프로그램에 인젝션이 가능한 부분이 있으면 위험하다는 것을 알고 있죠. 인젝션은 SQL, NoSQL, OS, LDAP을 비롯해서 매우 다양한 흐름을 가지고 있습니다. 인젝션은 신뢰할 수 없는 코드가 인터프리터에 명령으로 전달되거나 쿼리로 보내질 때 발생할 수 있습니다. 공격자의 악의적인 코드는 인터프리터가 의도하지 않은 동작을 하게 하거나 권한이 없어도 데이터에 접근할 수 있도록 합니다. 이것은 유저가 입력하는 데이터를 제대로 검증하고 필터링 하지 않아서 발생합니다.
많은 분들이 아시겠지만 데이터 처리는 프론트엔드 측에서 하는 것으로 충분하지 않습니다. 데이터 서버쪽에서도 항상 유효성을 검사하도록 해야합니다. 항상 말이죠. 프론트엔드 데이터 처리는 항상 우회하기 쉽습니다 (e.g. 사용자가 자바스크립트를 비활성화 하는 경우 )
2. Broken Authentication
많은 보안 취약점들이 인증에서 문제가 된 것으로 드러났습니다. 주로 인증이 올바르게 구현되지 않아서 그런 것이었습니다. 응용프로그램의 함수는 인증과 세션관리와 연관되어 있는데 종종 올바르게 개발되지 않는 경우가 있습니다. 이 때문에 공격자들에게 패스워드, 키, 세션 토큰과 같은 것들이 노출되게 되며 타인의 개인정보를 일시적 / 영구적으로 빼낼 수 있습니다.
이 모든 것이 인증 코드 일부가 제대로 동작하지 않아서 입니다. 하지만 이런 것을 평가할 수 있는 방법이 있습니다. 가능하다면 다중 인증을 구현해서 자동화, 크리덴셜 셔플링, 브루트 포스, 크리덴셜 재사용 공격들을 막을 수 있습니다. 아니면 취약한 패스워드 체크하는 것을 만들 수도 있죠. 사용자들이 사용하면 안되는 취약한 패스워드 top 10,000 같은 리스트도 있습니다.
추가적으로 관리자 크리덴셜을 유저들에게 배포하거나 전달해서는 안됩니다. 당연한 일처럼 느껴지시겠지만 의외로 종종 발생합니다.
3. Sensitive Data Exposure
많은 웹 응용프로그램과 API들이 금융, 건강 정보와 같은 민감 데이터를 적절하게 보호하고 있지않습니다. 공격자들은 안전하게 보호되지 않은 이런 민감 데이터를 이용하여 신용 카드 사기, 개인정보 도용, 그리고 다른 범죄에 활용하게 됩니다.
민감데이터는 추가적인 보안절차 외에도 브라우저단에서 교환될 때 추가적인 경고가 필요합니다. 만약 여러분의 앱이 얼마나 취약한지 알기 위해 여러분은 어떻게 데이터가 전송되는지 보셔야 합니다. 데이터가 평문으로 전송되나요? 이것은 HTTP, SMTP, FTP와 같은 프로토콜에서 위험합니다. 그리고 요즘에는 오래된 암호화 알고리즘이나 간단한 암호화 알고리즘은 너무나 쉽게 뚫려버립니다.
아마 가장좋은 방법은 민감 데이터는 외부로 노출되기 전에 항상 암호화를 하는 것일 겁니다.
4. XML External Entities
XXE ( XML External Entities ) 는 응용프로그램이 입력된 XML을 파싱할 때 발생하는 공격입니다. 오래되거나 잘못 설정된 XML 프로세서들은 XML 문서 내부에 외부 객체들을 실행합니다. 외부 개체들은 파일 URI 핸들러를 이용하여 내부 파일 공유, 내부 포트 스캔, 원격 코드 실행, DDOS 공격에 사용됩니다. 많은 XXE 취약점은 XML 프로세서의 파싱을 거치지 않고 XML 파일을 그대로 사용해서 발생합니다.
5. Broken Access Control
인증된 사용자들에게만 동작하도록 하는 제한이 올바르게 동작하지 않는 경우가 많습니다. 대가 사용자들이 너무 많은 권한을 갖고 있기 때문에 문제가 발생하죠. 공격자들은 이런 결점을통해 허가되지 않은 함수에 접근하거나 사용자의 개인 데이터에 접근해서 조작하거나 권한을 바꿔버릴 수 있습니다.
개발자들을 위한 가장 좋은 규칙은 공유 자원을 제외하고는 모두 default로 접근을 제한하는 것입니다. 불편보다 안전을 택하는 것이 낫습니다. 더 나아가면 접근 제어 실패 로그를 활용해서 너무 많은 접근 제어 실패가 발생하는 곳을 관리할 수도 있습니다.
6. Security Misconfiguration
보안 설정 문제는 매우 흔하게 볼 수 있는 문제입니다. 일반적으로 default 설정이 안전하지 않은 경우로 불완전한 설정, ad-hoc 설정, 잘못 설정된 http 헤더, 민감 정보를 포함하고 있는 에러메시지 등이 해당됩니다. OS 뿐만아니라 프레임워크, 라이브러리, 어플리케이션 단까지 보안설정이 되어야 하며 항상 최신 상태를 유지하는 것이 좋습니다.
보안 설정의 실수를 줄이기 위해서 필요하지 않은 기능은 설치하지 않거나 끄는 것이 좋습니다. 또한 유저에게 표시되는 에러메시지는 과도한 정보를 포함하지 않도록 해야 합니다. 그리고 기본 계정과 비밀번호도 자주 바꾸도록 하세요.
7. Cross-Site Scripting
XSS ( Cross-site scripting )은 요즘 가장 핫안 웹 취약점 중 하나입니다. XSS 취약점은 응용프로그램이 신뢰할 수 없는 웹 페이지 데이터를 가지고 유효성이나 예외처리를 충분히 하지 않을 때나 기존 웹 페이지가 HTML이나 자바스크립트를 만들어 낼 수 있는 브라우저 API를 이용하여 사용자 데이터를 이용해 갱신될 때 발생할 수 있습니다. XSS는 공격자들이 피해자의 브라우저에서 스크립트를 실행할 수 있게하여 사용자의 세션을 취득하거나 웹사이트의 외관 손상, 위험한 사이트로 리다이렉션 등을 할 수 있습니다.
여러분의 웹사이트를 XSS 공격으로부터 방어하려면 React와 같이 설계단에서 자동으로 XSS를 예외처리하는 프레임워크를 사용할 수 있습니다. 그리고 HTML 응답에서 신뢰할 수 없는 HTTP 요청 데이터가 있는 경우 항상 예외처리를 하는 것이 좋습니다.
8. Insecure Deserialization
Deserialization 공격은 매우 어렵습니다. 기본 코드를 변경하거나 수정하지 않고는 작동하지 않는 경우가 많기 때문입니다. 그러나 매우매우 위험한 공격입니다. Deserialization 공격은 원격 코드 실행을 가능하게 해서 replay attack, injection attack, 권한 상승 공격과 같은 데에 사용됩니다. 사실 이 공격을 막기위해 여러분이 할 수 있는건 아주 적습니다.
예를들면 모든 시리얼라이즈 객체에 디지털 서명을해서 무결성을 검사하는 것을 구현하는 것 등입니다. 이것은 악의적인 객체 생성이나 데이터 조작을 막아줍니다. 다른 것은 객체를 생성하기 전에 Deserialization 단계에서 strict type을 사용하도록 강제하는 것입니다. 그렇지만 이 기술을 우회하는 것도 시연이 되었으므로 그렇게 쓸모있는 것은 아닙니다.
다른 것은 Deserialization 코드를 낮은 권한에서 실행되도록 하는 것입니다. 만약 이게 불가능하다면 항상 예외, 실패 에러로그를 남기면서 올바르지 않은 타입이 입력되는 곳이 어딘지 찾아야 합니다.
9. Using Components With Known Vulnerabilities
이 취약점은 아주 저를 피곤하게 했습니다. 몇몇 개발자들은 그냥 코드가 동작하니까 알려진 취약점이 있는 컴포넌트도 사용하곤 합니다. 여기서 컴포넌트는 라이브러리, 프레임워크 등 소프트웨어 모듈을 의미합니다.
컴포넌트들은 모두 응용프로그램과 같은 권한으로 실행되기 때문에 취약한 컴포넌트가 악용되면 심각한 데이터 유출 혹은 서버가 넘어갈 수도 있습니다. 취약점이 알려진 컴포넌트를 쓰는 API들과 응용프로그램들은 다양한 공격이 가능하게 보안을 약화시키는 요소입니다.
피해를 최소하하기 위해서 항상 사용하지 않는 의존성, 기능, 파일들은 제거해야 합니다. 추가적으로 모든 컴포넌트들에 대해 정기적으로 발견된 취약점이 있는지 체크하는 것이 중요합니다. security bulletins를 구독하면 간단하게 하실 수 있는 일이죠.
10. Insufficient Logging and Monitoring
로깅과 모니터링을 충분하게 하지 않거나 사건 발생에 대해 비효율적으로 통합을 해놓으면 공격자들이 장기적은 공격을 할 수 있습니다. 이것은 아주 치명적인 결과를 가져올 것입니다. 공격자들이 조작을 하거나 데이터를 파괴할 수 있고 여러 시스템을 조작할 수도 있습니다. 놀라운 사실은 많은 breach 연구에서 breach가 파악되는 시간은 보통 200일이 지나서이고 그것마저도 내부 프로세스나 모니터링이 아닌 외부 단체에 의해 발견된다고 합니다.
Summary
- OWASP TOP 10 정리
