[정보보안] 가장 흔한 웹 취약점

주입 공격

---

주입공격의 문제점은 사용자의 신뢰되지 않은 데이터가 명령이나 또는 질의의 일부로 웹 애플리케이션에 바로 전달될 때 발생합니다. 공격자는 웹 애플리케이션을 속여 의도치 않은 명령을 수행하게 하거나 권한 없는 자료에 접근하도록 합니다. 주입공격은 해커가 웹애플리케이션에 먹인 악성 입력 값이 안전하지 않은 방식으로 작용할 때 일어납니다. 이것은 웹 애플리케이션을 공격하는 아주 오래된 방법 중 하나지만, 널리 퍼져 있고 대단히 파괴적이기 때문에 여전히 최고의 공격법입니다.

주입공격의 취약점은 웹 애플리케이션에서 사용자가 악의적으로 입력할 수 있는 곳이면 어디서나 발생할 수 있습니다. 가장 흔히 알려진 주입공격은 다음과 같은 기능을 목표로 합니다.

1. 구조화 조회 원어(Structured Query Language, SQL) 질의문

2. 경량 디렉터리 조회 프로토콜(Lightweight Direct Access Protocol, LDAP) 질의문

3. XML 경로 언어(XPATH) 질의문

4. 운영체제 명령어

주입 공격은 웹 애플리케이션이 사용자가 입력한 값을 검토하지 않은 채 받아들여 처리하면 언제나 발생합니다. 즉 해커는 웹 애플리케이션에 보내는 질의문에 영향을 주어 원하는 데이터를 결과 값으로 가져오도록 명령어를 재구성합니다. 이것은 대단히 위력적입니다.

크로스 사이트 스크립트

---

크로스 사이트 스크립트(XSS)는 응용프로그램이 사용자 입력 값을 요청의 일부로 받아들인 후 응답 결과로 사용하는 데 있어서 적절한 방식으로 데이터를 검증하거나 멸균하지 않은 경우에 발생합니다. 공격자가 XSS를 활용하면 희생자 브라우저에서 사용자 세션을 가로채고, 키 값을 저장하고, 사용자를 악성 사이트로 보내거나, 해커가 꿈꿀 수 있는 것은 무엇이든 처리하는 스크립트를 실행할 수 있습니다. 해커는 악성 스크립트를 희생자의 브라우저에 주입합니다. 이런 스크립트는 애플리케이션으로부터 전달되는 응답의 일부가 되므로 희생자 브라우저는 그 값을 신뢰하고, 따라서 해당 스크립트를 실행합니다.

XSS는 기본적으로 반사형(reflected)과 저장형(stored)의 두 가지 형태로 발현됩니다. 반사형 XSS는 훨씬 광범위하게 퍼져있지만 덜 해롭다고 여깁니다. 여기서 반사형 XSS를 덜 해롭다고 얘기하는 것은 해를 끼질 수 있는 영역이 제한되어서가 아니라, 반사형 XSS 공격에서 보내지는 페이로드는 단지 한 번의 요청 동안만 유효하기 때문입니다. 그래서 반사형 XSS를 "누르는 사람은 누구나 당하게 되는" 것으로 생각하면 됩니다. 즉 누구든 악성 스크립트를 포함하고 있는 링크를 누르면, 바로 그 사용자가 그 공격에 직접적으로 영향을 받게 됩니다. 그렇기 때문에 해커와 희생자는 1:1의 비를 갖게 됩니다. 물론 해커는 똑같은 악성 URL을 수백만의 잠재적인 희생자에게 보낼 수도 있지만, 그 링크를 누르는 사람들만 영향을 받을 뿐 그렇게 공격받은 사람들 간의 연관성은 없습니다.

저장형 XSS는 웹 애플리케이션에서 찾아내기가 더 어려울 뿐 아니라 다양한 요청에 걸쳐 지속되면서 한 번의 공격으로 여러 사용자를 무력화할 수 있기 때문에 훨씬 더 심각하게 피해를 줍니다. 이것은 해커가 악성 스크립트를 응용프로그램에 주입하고, 그 스크립트가 모든 방문자에게 노출될 때 발생합니다. 이 스크립트는 웹페이지를 생성하며 호출되는 데이터베이스나 사용자 포럼에서 메시지를 출력할 때, 또는 입력 값을 저장하는 메커니즘에 숨겨집니다. 정당한 사용자들이 요청하는 페이지마다 XSS 침투 메커니즘은 그 각각의 브라우저에서 실행됩니다. 그렇기 때문에 해커와 희생자 간에는 1:N의 관계가 성립합니다.

XSS의 두 가지 방식은 똑같은 페이로드를 갖지만 서로 다른 방법으로 전달되는 셈입니다.

인증과 세션 관리 무너뜨리기

---

세션은 사용자가 인증하면 할당되는 교유의 식별자를 말하는데 웹 애플리케이션이 어떻게 활용하는가에 따라 여러 취약점과, 또는 그와 엮어진 공격법이 만들어집니다. 세션은 웹 사용자를 공격하는 중요한 요소가 되기도 합니다.

인증이나 세션 관리 기능이 정확하게 구현되지 않았다면 해커는 구현상의 오류를 추적하여 패스워드, 키 값, 세션 토큰 또는 사용자를 나타내는 정보를 알아냅니다. 인증과 관련 있는 웹 애플리케이션의 기능 몇 가지를 예로 들자면 패스워드 초기화, 비밀번호 변경 및 계정 복구와 같은 것이 있습니다.

웹 애플리케이션은 세션을 관리하여 각 사용자의 요청 내용을 추적합니다. 만일 세션 관리 기능이 없으면 매번 요청할 때마다 로그인을 해야합니다. 어떤 상품을 검색한 후 로그인하고, 장바구니에 넣고 싶으면 또 로그인하고, 계산할 때, 그리고 지불정보를 입력할 때에도 또 로그인하는 경우를 생각해 봅시다. 그래서 세션션 관리 기능이 만들어져서 사용자는 매번 방문할 때 한번만 로그인하면 되고, 웹 애플리케이션은 어떤 사용자가 장바구니에 무슨 상품을 넣었는지 기억할 수 있게 됩니다. 다만 아쉬운 것은 인증이나 세션 관리가 본래의 인터넷에 비하면 나중에 나온 것이라는 점입니다. 그러니까 쇼핑이나 지불 기능이 없을 때는 인증이나 세션을 관리할 필요가 없었습니다. 그래서 오늘날 우리가 아는 인터넷은 인증과 세션 관리를 위해 초기의 것으로부터 비틀어지고 새로운 방식으로 진화해온것으로 볼 수 있습니다.

크로스 사이트 요청 변조

---

크로스 사이트 요청 변조(Cross-Site Request Forgery, CSRF)는 이미 인증된 피해자(사용자)에게 정교하게 만들어진 악성코드를 보내고 그 피해자가 모르는 사이에 필요한 매개변수(변수)를 정당한 요청인 양 써서 위장합니다.

이는 해커가 희생자에게 웹 애플리케이션상에서 특정 행위를 반드시 하게 만드는 반사형 XSS와 비슷합니다. 악성 스크립트는 여전히 피해자의 브라우저에서 실행되지만, CSRF는 웹 애플리케이션에 정당한 명령을 요청합니다. CSRF로 할 수 있는 것 중에는 비밀번호 바꾸기, 새로운 사용자 만들기, CMS를 통해 웹 애플리케이션 만들기와 같은 것이 있습니다. 해커가 요청을 완료하기 위하여 꼭 필요한 매개변수를 정확히 알고 있고 또한 피해자가 애플리케이션에 인증되어 있는 상황이라면 마치 사용자가 알고 일부러 하는 것처럼 수행됩니다. 

잘못된 보안 설정

---

이 취약점은 특히 모든 응용 계층의 보안(혹은 부실함 그 자체)을 다룹니다. "응용 계층"은 웹 애플리케이션 프로그램이 실제로 접근하고 실행하는 운영체제, 웹 서버와 데이터베이스 관리 시스템을 뜻합니다. 이 위험은 보안 설정을 강화하여 허가 받지 않은 상태에서는 웹서버에 접근할 수 없도록 조치하지 않으면 심각한 수준이 됩니다. 이를 통해 웹서버에 전염시킬 수 있는 취약점의 사례로는 다음과 같은 것들이 있습니다.

1. 오래되거나 쓸모 없는 소프트웨어

2. 활성화된 불필요한 서비스

3. 안정하지 않은 계정 정책

4. 장황한 오류 메시지

 효과적인 보안이란 응용프로그램, 프레임워크, 애플리케이션 서버, 웹 서버, 데이터베이스 서버 및 운영체제 각각에 대해 안전하고 정의하고 적용할 때 가능합니다. 이러한 모든 환경의 기본값을 안전하고 새롭게 정의하고 구현하고 유지해야 합니다. 또한 소프트웨어나 애플리케이션에서 사용하는 프로그램 라이브러리는 늘 최신 상태로 유지해야 합니다.