HTML5의 5가지 보안 위협

* 본 글은 아래 블로그의 내용에 대한 번역을 바탕으로한다.

http://www.esecurityplanet.com/features/article.php/3916381/Top-5-Security-Threats-in-HTML5.htm

  HTML5 표준은 현재 메이저 브라우저인, IE, Firefox, Safari, Chrome 그리고 Opera의 최신 버전, 혹은 베타 버전에서 동작되고 있다. 이는 많은 Web app 개발자들의 욕구를 반영한 결과라고 볼 수 있다. 그러나 이런 HTML5는 몇가지 보안 문제를 가지고 있다. 물론 이런 문제는 HTML5가 현재 만들어지고 있는 규정이라는 측면에서, 해결 될 수 있는 문제이며 우리는 이런 논의를 지속함으로써, 더욱더 안전한 Web 기준을 확립할 수 있는 것이다.

보안 문제는 다음과 같이 5가지를 들 수 있다.

1. Cross-Document Messaging

 HTML4의 경우에는 한 도메인의 페이지에서 다른 도메인의 접근이나, 데이터 교환등을 허락하지 않는다. 예를 들면 1번 도메인의 페이지를 브라우져로 읽었을때, 그 페이지에서 클릭 이벤트를 받는 자바스크립트 함수를 통해, 마우스의 위치를 받을 수 있다. 이런 마우스의 위치 정보는 2번 도메인 페이지로 전달 될 수 없다. 이런 HTML4의 제한은 악의적인 사이트가 합법적인 사이트로 부터 데이터를 가로채는 것을 막는다. 그러나 이는 또한 다른 도메인의 합법적인 사이트들간 데이터 교환을 막아버리게 된다. 오늘날 많은 Web 기반 application은 다양한 도메인의 내용을 통합한다. 그러나, 그렇게 하기 위한 Web based app의 능력은 이런 제한으로  HTML4에서는 불가능하다.

 HTML5는 postMessage라는 새로운 API를 제공한다. 이는 한 도메인에서 다른 도메인으로 데이터를 전달하는 스크립트에 대한 framework이다. 이런 데이터 요청이 해킹이 아닌지 명확하게 하기 위해서, postMessage는 개발자가 데이터 요청의 origin check을 할수 있게하는 object property를 포함한다. 그러나 HTML5는 이런 origin check를 강요하진 않기 때문에, 부주의한 개발자는 origin check를 빼먹을 수 있으며, 이는 결과적으로 해킹 사이트에 postMessage 요청을 노출하게 된다.

2. Local Storage

 HTML5에서 새로운 기능은 Local storage이다. client-side SQL 데이터베이스는 자바스크립트를 통해 접근이 가능하다.(현재 SQLite는 HTML5에서 빠져 버렸다.) 다른 HTML5 특징과 같이 local storage는 3rd party 개발자(Google Gears)에 의해 존재해 왔고 결국 채택되게 된 것이다.

 local storage에 대한 접근은 web application의 속도를 빠르게 만든다. 특히, 같은 데이터에 대한 쿼리가 필요할 때, 효과가 좋다. 그러나 이것은 부주의한 개발자들에게 새로운 보안 위협을 가져다 준다.

 

 민감한 데이터(이메일 메시지 혹은 비밀번호)를 오프라인 데이터베이스에 저장할때, 개발자는 SSL을 사용할 필요가 있고 자신만의 유일한 데이터베이스 이름을 만들 필요가 있다. 또한 개발자는 준비된 SQL statement를 사용해야 한다.(자바 스크립트 코드로 직접 만들지 말고) 그렇지 않으면 해커들이 가로채거나, 이러한 쿼리를 SQL injection 공격을 통해 실행해버리게 된다.

3. Attribute Abuse

 HTML5에는 새로운 태그가 많이 생겼다. 새로운 속성이 있는데, 이는 친숙한 태그들에 적용되고 이런 속성들이 abuse 될 수 있다. 이런 속성값들이 자동적인 스크립트 실행의 트리거가 될 경우 위협이 되게 된다.

 

 예를 들면, HTML5의 autofocus 속성은 자동적으로 브라우져의 focus를 특정한 element로 이동시킨다. 그러나 이런 속성은 해킹 사이트들이 autofocus 속성을 훔처서, 악성 코드가 실행 되게하는 윈도우로 포커스를 옮겨 버릴 수 있다. 사용자는 무의식 중에 이런 악성 코드를 실행하게 되버린다. 이와 마찬가지로 poster와 srcdoc 속성도 악성 사이트에 의해 남용될 수 있다. 

4. Inline Multimedia and SVG

 HTML5는 이전 버전 보다 멀티미디어 부분에서 우위에 있다. 지금까지, 브라우저는 단순히 3rd party의 플러그인에 의존해서, MP3, MP4 비디오 포맷을 포함한 멀티미디어 포맷을 재생하면 되었다.

 하지만 HTML5에서는 <audio>, <video> 그리고 <svg> 태그를 이용해서, 벡터 그래픽이나 인기있는 미디어 포맷을  외부 플러그인 없이, 표현할 수 있다. 그러나 이런 점은 브라우저 개발자가 복잡한 멀티미디어 렌더링을 수행해야하는 부담으로 작용할 수 있다. 결과적으로 이런 점이 보안에 위협이 될 수 있다.

 예를 들면 구글 크롬의 초기 버전은 SVG 파싱 버그가 있었다. 만약 특정 방식으로 동작하게 하면, 스크립트가 다른 도메인 페이지의 객체 속성에 접근할 수 있게 된다.  결과적으로,  크로스 도메인 보안 정책을 침해하게 되는 것이다.

 

 각 브라우저는 새로운 태그를 지원하기 위해서, 이런 복잡한 멀티미디어를 실행할 필요가 있기 때분에, 각각에서 갑자기 나타나는 버그로 인해, 해커들의 공격에 노출 될 수 있는 것이다.

5. Input Validation

 사용자 input을 관리하는데 있어서, - 특히  input이 나중에 보여지게 될 경우 - 언제나 주의할 필요가 있다.  악의적인 사용자들은 때때로, 열악한 input  체크를 이용해서,  실행 코드 또는 다른 트리거를 훔쳐낼 수 있다.

 웹 개발자들은 서버측의 견고한  input validation에 의지해왔다.  그러나 이런 방법은 비록 Ajax가 이런 상황을 좋게 만들었음에도,

열악한 사용 환경을 제공한다.  HTML5는 client-side input validation을 지원한다. 이는 웹 개발자가 직접 form 자체에 input에 대한 경계값을 줌으로써, 직접 input validation을  할 수 있게 해준다. 결과적으로 사용자는 서버 사이드 input validation 없이 페이지 자체에서 input validation을 빠르게 수행할 수 있다.

 그러나 이런 input validation은 개발자들에게 보안에 대한 잘못된 정보를 제공할 수 있다. 잘못된 validation 정의는 사용자가 체크를 피해갈 수 있게 한다. 이런 문제는 HTML5에 한정된 것은 아니지만,   HTML5에 새롭게 적용된 input validation syntax 덕분에 개발자가  쉽게 validation code를 생성하는데 있어서 실수를 할 수 있다.

 추가적으로 해커들은 client-side validation - 예를 들자면, 잘못된 regular expression(regex) - 를 이용해서 Denial of Service(DOS) 공격을 할 수 있다.