TLS Report는 Benjamin Black씨가 인터넷상의 주요 사이트의 보안에 대해 살펴본 것을 정리하기 위한 새로운 사이트입니다.

여태껏 주요 사이트들에 대한 다양한 통계들이 나온바 있지만, 보안 분야는 처음입니다. 최고 혹은 최악의 목록들이 조금 놀랍습니다.

• Best: UBS.com, good to see a bank up there; openid.ee, good to see an OpenID provider; worldofwarcraft.com, real-time and secure
• Worst: wachovia.com, bad to see a bank down there; usmap.cnet.navy.mi, a .mil will scare anyone; cpscontractor.nih.gov, ditto for a .gov.

물론, 논란의 여지는 있습니다만, 어쨌거나 정말 멋진 서비스입니다!

from TLS Report: Best and Worst Security Charts

Jeremiah Grossman씨가 crossdomain.xml 사용에 대한 글을 작성하신 뒤, 해당 파일에 느슨한 정책을 적용한 도메인들을 찾아보기로 하시고는 결과를 공개하셨습니다.

crossdomain.xml 파일은 동일근원정책(Same-Origin Policy)이 기본적으로 적용되어있는 웹 브라우저에서 크로스 사이트로 사용할 수 있는 몇 안되는 방법 중 하나입니다. 해당 파일에 접근을 허용할 도메인을 기술하면 Flash에서 해당 사이트의 컨텐트에 접근할 수 있습니다. 허용할 도메인을 기술하는 방법에는 IP주소, 도메인, 서브도메인, 그리고 모든 것을 허용하는 별표(*)가 있습니다.

신뢰할 수 있는 사이트에 있는 Flash에서는 사이트의 모든 컨텐트를 읽을 수 있습니다. 이에는 (인증해야하는) 컨텐트, (세션) 쿠키 등이 포함됩니다. 악의적인 공격자나 웹 사이트 소유자가 서버 해킹이나 XSS를 통해 신뢰할 수 있는 도메인에 있는 사이트의 제어권을 얻는다면, 문제가 될만한 데이터를 쉽게 빼갈 수 있습니다. 개인정보 침해, 계정 탈취, 민감한 자료 유출, CSRF 보호책도 쉽게 피해갈 수 있습니다.

Jeremiah씨는 crossdomain.xml 을 실제로 사용하고 있는 유명 사이트와 그들이 어떻게 설정해두었는지가 궁금하셨다고 합니다.

from crossdomain.xml misconfigurations galore on Ajaxian

Nicholas C. Zakas 씨가 자신의 새 책을 위한 예비 작업으로서 주요 4개 브라우저에 대한 브라우저 쿠키 제약을 연구하셨습니다:

제가 발견한 가장 흥미로운 사실은 Safari는 도메인당 설정할 수 있는 쿠키의 갯수가 제한이 없다는 것입니다. 사실, 여러분은 쿠키 헤더가 해석하기엔 너무 커 서버가 에러를 일으킬 수도 있을 만큼의 쿠키를 클라이언트에 설정할 수 있습니다.

그가 발견한 다른 사항은 이렇습니다:

• Microsoft 는 Internet Explorer 8 의 도메인당 쿠키 제한을 50개까지 늘렸다고 말했지만, 제가 발견한 바로는 IE7 도 도메인당 50개의 쿠키를 허용합니다. 그렇습니다. 이는 출시된 브라우저의 첫번째 버전이 그런 것이 아니라 시스템 패치로 인해 증가한 것입니다. 하지만 여전히, 일반적으로 한계라고 생각하는 20개 보다는 많습니다.
• Firefox는 도메인당 50개의 쿠키 제한이 있습니다.
• Opera는 도메인당 30개의 쿠키 제한이 있습니다.
• Safari/WebKit은 Safari 3.1을 통해 봤을 때 인지할 수 있는 한계가 없는 것 같아 가장 흥미로웠습니다. 제가 10,000개의 쿠키를 설정하고 그 쿠키를 전부 Cookie 헤더에 실어 보내 테스트를 해보았습니다. 문제는 헤더의 크기가 서버가 처리할 수 있는 정도를 넘어버렸다는 것인데, 그래서 서버에서 에러가 발생했습니다.
  

위에서 보듯이 브라우저의 도메인당 쿠키 제한이 20개라는 널리 알려진 지식은 더이상 바른 지식이 아닙니다. 또다른 재미있는 모순은 너무 많은 쿠키가 설정되면 브라우저가 어떻게 반응하는가에 대한 것입니다. 인식할 수 있는 숫자는 모두 설정할 수 있는 Safari를 제외하면, 두가지 접근 방법이 있습니다:

1. 최근 최소 사용(LRU) 방법은 쿠키 제한에 도달했을 때, 새로운 쿠키를 위한 공간을 만들기 위해 가장 오래된 쿠키부터 제거합니다. Internet Explorer와 Opera가 이 방식을 사용합니다.
2. Firefox는 약간 이상합니다: 마지막 쿠키가 항상 저장되어 있음에도 불구하고 무작위로 남겨둘 쿠키를 결정하는 것 같습니다. 일정한 법칙이 전혀 없는 것 같습니다. Firefox에서는 쿠키 제한 이상으로 사용하지 마십시오.
   

쿠키의 전체 크키는 브라우저마다 매우 다양합니다. 이 부분이 파악하기에 좀 힘들었던 부분입니다. 하지만 제가 테스트한 결과가 있습니다:

• Firefox와 Safari는 쿠키를 4097 영문자까지 허용합니다. 4096 은 이름, 값, 등호(=)까지 포함한 것입니다.
• Opera는 쿠키를 4096 영문자까지 허용합니다, 마찬가지로 이름, 값, 등호까지 포함한 것입니다.
• Internet Explorer는 쿠키를 4095 영문자까지 허용합니다. 이름, 값, 등호까지 포함한 값입니다.

from Browser cookie restriction research on Ajaxian

때때로 웹 개발이 재밌는 아이디어를 구현하고 안전하게 작동하도록 하기 위해서 새로운 방식으로 사용되던 대략 백만년쯤전의 지식을 살펴보는 것도 재밌습니다.

브라우저의 각각의 window 들은 name 속성을 가지고 있습니다. 팝업을 사용하지 않고 각각의 이름을 통해서 서로 통신하도록 한다면 정말 쓸모없어질 속성입니다.

그런데, Thomas Frank씨가 쿠키에 의존하지 않고 세션 변수를 저장하는데 window.name을 사용하는 작은 라이브러리를 작성했습니다. 그의 연구결과는 window.name에 2MB 정도의 데이터를 저장할 수 있다고 증명하는 것 같습니다. 이 속성이 페이지가 리로드될 때도 사용할 수 있으므로, 일종의 세션이 될 수 있습니다. 하지만 코멘트에는 보안적인 면에서 우려할만한 일도 있음을 시사하고 있습니다:

sessvars에 크로스 도메인 플래그가 있습니다. 기본값이 false이긴 하지만 이것은 단지 실수로 여러분의 sessvars 에서 다른 사이트의 window.name 쓰레기 값을 가져오지 않는 것일 뿐입니다. 여러분이 작성한 실제 데이터는 다른 도메인의 다른 스크립트에 의해 사용될 수 있습니다. 또는 누구라도 브라우저의 주소표시줄에서 javascript:alert(window.name) 만 입력해도 가능합니다.

from What's in window.name from Ajaxian

4월자 IE 보안패치 릴리스

2008년 4월자 IE 누적 보안 업데이트가 Windows Update 사이트를 통해 다운로드 받을 수 있게 되었습니다. 혹은, 새로운 Microsoft Update 를 통해 이 패치와 기타 등등을 다운로드 받을 수도 있습니다. 개인적으로 모든 Microsoft 제품을 최신으로 업데이트 한 것이 확실하지 않다면 Microsoft Update 사이트를 통해 업그레이드 하는 것을 권장합니다.

이 업데이트는 1개의 원격 코드 실행 취약성을 다루고 있습니다. 이 보안 업데이트는 Internet Explorer가 HTML을 다루고 데이터를 검증하는 방식을 수정함으로써 취약점을 제거했습니다. 이 업데이트에 대한 상세한 정보를 보시려면, 아래의 문서를 보시면 됩니다.

• Microsoft Security Bulletin MS08-024
• Microsoft Knowledge Base Article 947864

이 업데이트는  Windows 2000의 IE5.01, IE6 서비스 팩 1,  Windows XP에서 IE6 , Windows XPSP2 의 IE7 그리고 Windows Vista의 IE7, Windows Serve 2003의 IE6, 그리고 Windows Serve 2003의 IE7 에서 "치명적(Critical)" 등급으로 분류되었습니다.

상기하는 차원에서 말씀드리면, IE 보안 업데이트는 누적 패치이고 각 버전의 Internet Explorer에 대해 이전에 릴리스된 업데이트를 포함하고 있습니다.

Windows Update나 Microsoft Update 를 통해 이번 보안 업데이트와 IE 패치가 아닌 다른 업데이트도 다운로드 받을 것을 모두에게 권장합니다. Windows 사용자들에게는, Microsoft의 최신 업데이트를 통해 시스템을 항상 최신으로 유지하기 위해 자동 업데이트를 설정해 둘 것을 적극 권장합니다.

from Fingerprint: A print for your typing on Ajaxian

타이핑을 항상 똑같은 방식으로 하세요? 사용자 이름하고 패스워드를 입력할 때라면 어떠세요?

이런 생각을 실천으로 옮기신 분이 있습니다. Marcus Westin 씨는 jQuery를 이용해서 타이핑 시간을 측정하는 Fingerprint를 만들었습니다.

사용은 쉽습니다:

이렇게 하면 'timestamp-down'과 'timestamp-up' 이라는 필드가 자동으로 생성되고 얻은 시간값을 서버로 보냅니다. 각 값들은 컴마로 구분되어있습니다.

이걸 분석하면 정말로 보안에 사용할 수도 있을까요?

from IE 8 Security Updates on Ajaxian

Microsoft가 일련의 보안 업데이트를 내보냈습니다. 그 중에는 IE8 보안 Part I: DEP/NX 메모리 보호 에 언급된 것도 있었습니다.

다음 몇 주에 걸쳐, 우리는 안전 필터같은 Beta 1의 보안 개선과 보다 안전한 매시업을 위한 AJAX 기능(XDomainRequest과 XDM)에 대해 상세히 블로그에 올릴까 합니다. 이것이 릴리스의 보안 노력의 전체 목록은 아닙니다. 곧 앞으로의 마일스톤이 진행되는 동안 더 말할 기회가 있을 것입니다.

Internet Explorer 8 보안 기능은 보안 허점의 세가지 주요 원인에 주목했습니다: 소셜 엔지니어링(social engineering), 웹 서버, 그리고 브라우저 취약성. 이 글은 브라우저의 취약성을 보완해주는 기능인 IE 8의 데이터 실행 방지(DEP)에 대해 다룹니다.

Eric은 이어 DEP에 대해서 상세히 설명했습니다:

Windows Vista에서의 Internet Explorer 7은  인터넷 옵션에서 “온라인 공격 방지를 위해 메모리 보호 사용” 옵션이 꺼져있는 것이 기본값입니다. 이 옵션이 데이터 실행 방지(DEP) 혹은 실행 방지에 관련되어 있습니다.

Windows Server 2008과 Windows Vista SP1 혹은그 이후 버전에서 Internet Explorer 8는 기본값으로 이 옵션을 사용합니다.

DEP/NX는 실행 불가능으로 표시한 메모리에서 코드가 실행되는 것을 막음으로써 공격을 차단합니다. DEP/NX는 주소 공간 레이아웃 불규칙화(ASLR)같은 다른 기술과 조합되면 버퍼 오버런(overrun)과 같은 메모리 관련 취약성에 대한 공격을 어렵게 합니다. 가장 좋은 점은, 이러한 방지기술이 Internet Explorer와 로드된 추가 기능에도 적용된다는 것입니다. 이런 보호를 제공하기 위해 사용자의 추가 행동이나 입력창을 필요로 하지 않습니다.

그들은 또한 이런 글도 포스팅했습니다:

• IE 자동 컴포넌트 활성화 가능: ActiveX를 포함하면 나타나던 "이 컨트롤을 활성화 하려면 클릭..."이라는 문구가 Internet Explorer에서 이제 완전히 사라지게 됐습니다.
• IE 4월 보안 업데이트: 2008년 4월의 IE 누적 보안 패치가 Windows Update 사이트를 통해 사용 가능합니다.

from window.crypto: want crypto primitives in the browser? You may already have it on Ajaxian

초라한 JavaScript 개발자들을 위해서 사용할만한 crypto 헬퍼가 브라우저에 추가되면 참 좋을 것 같습니다. 그래서 예전에 요청한 적이 있었습니다.

Brad Neuberg 씨가 Gecko 에 window.crypto 라는 내장 crypto가 있음을 발견했습니다.

Mozilla는 웹페이지가 어떤 암호 관련 서비스에 접근할 수 있도록 하는 특별한 JavaScript 객체를 정의해두었습니다. 이 서비스들은 웹 페이지가 필요로 하는 기능과 악의적 웹 사이트로부터 사용자들을 보호하려는 요구 사이의 균형점입니다. 대부분의 이 서비스는 JavaScript에서 window 객체를 통해 window.crypto와 같이 사용할 수 있습니다. 예컨데, 암호 엔진을 통해 10 byte의 랜덤한 숫자를 얻으려면 이렇게 사용하면 됩니다:

var myrandom = window.crypto.random(10);

서비스에서 제공하는 것은 이렇습니다: 스마트 카드 이벤트, 인증 요청 생성, 사용자 인증 가져오기, 랜덤한 숫자 생성, 토큰과 서명 로깅

원본글 : Using a hash property for security and caching


Douglas Crockford 씨가 보안과 성능을 위해 hash=attribute 를 쓰는게 좋다고 하는군요.