Tip - 해당되는 글 9건
Internet Explorer 8 무엇이 달라졌나 ②
오늘은 날씨가 좋군요 ^^

상쾌하기도 하고~ 제가 12층에서 근무하는데 전경이 좋습니다 ^^

Data URI Support : Windows Internet Explorer 8

오늘은 이걸 알아보도록 하겠습니다.

먼저 IE8의 랜더링 화면을 보려면 Tool메뉴 - Developer Tools - View - Change Compatibility - Mode에서
Standards(Internet Explorer 8)을 선택해야 합니다. ㅎㅎ 잠시 팁이였구요.

Data URI... 과연 이것은 무엇일까요? 다들 아시나요?? 저는 이야기만 들어봤을뿐 실제로 사용해 본 적은 없었습니다.

그래서 이기능이 IE에서 지원이 안되고 있었는지 조차 별 관심이 없었던거죠.. 화이트페이퍼를 보면서 "이거 원래 안되었었나?"라는 의문이 들었죠. 근데 원래 지원안했답니다. ^^

테스트를 해보니 FF 2, FF 3, Safari 3, Opera 9.x 에서는 다 지원되는군요... 역시 IE는 외톨이였나봅니다. ^^

잠시 딴대로 이야기가 샜었는데.. 왜 Data URI를 사용할까요? MS에서 제공한 화이트페이퍼에는 이렇게 정의하고 있습니다.

"css나 image와 같은 작은 외부 자원들를 웹페이지에 직접적으로 삽입할 수 있게 한다"라고 되어있습니다.

그럼 왜 직접 삽입해야할까요? 이유는 보안입니다. 즉 이미지나 css등의 경로를 웹페이지에 적어주는 방식(<img src="/xxx/xxx.jpg" />)은 URI가 노출되어 해당 서버의 디렉토리 구조를 노출하게 됩니다. 또한 css의 경우도 마찬가지겠지요. 그럼 여기서 의문이 생기죠... data URI를 사용하면 어느정도까지 보안을 강화해 주는걸까요?

제가 테스트 해본바로는
1. URI 숨김으로 인한 서버의 디렉토리 구조 감춤
2. 웹페이지에 직접 해당 리소스를 넣음으로서 http connection을 통해 이미지를 가져오는 일이 없음, 즉 이미지를 별도로 다운로드하지 않음.

2번에서 알수있듯이 이미지자체를 웹페이지에 넣다보니 웹페이지 사이즈가 커짐을 알 수 있습니다. 당연하겠죠?

아래 그림은 네이버 로고를 Data URI로 넣은 모습입니다.
사용자 삽입 이미지

아래의 그림은 Data URI와 <img>를 함께 사용한 것입니다.
사용자 삽입 이미지

위 그림 두개에서 자세히 보셔야 할부분은 FireBug의 화면중 Net이란 곳이구요... Net은 실제 웹상에서
데이터가 network를 통해 브라우져가 해당 리소스를 다운받았다는 것을 표시해줍니다.

1번의 그림의 경우 이미지 다운이 안된것으로 표시가 되었고, 2번의 경우 그림이 다운된 것으로 표시가 되었습니다.

MS에서는 Object / Img / Link / Css 엘리먼트만을 지원한다고 하는군요.

백문이불여일견... 테스트한 html을 첨부하니 다운받으셔서 직접 테스트 해보시는게 가장 좋을것 같습니다.

테스트 파일 :
data_uri.html





posted by blankus

태그 - data uri, ie 8, ie 8 beta, ie8, Internet Explorer 8
Tip  |  2008/03/07 18:34
Trackbacks  0 | Comments  2
Internet Explorer 8 무엇이 달라졌나 ①
오랜만에 포스팅을 하는 것 같습니다.

그동안 너무 방황하며 살았던것 같구요... 이제 따스한 봄(?)이 저멀리서 다가오고 있으니 마음도 추스리고

열심히 또 블로그질을 해야겠습니다.

그 시작으로 IE 8 beta 1이 선보였는데, 무엇이 어떻게 바뀌었는지를 알아보도록 하겠습니다.

1. Data URI Support
2. HTML Improvements and ACID2
3. Improved Namespace Support
4. DOM Core Improvements
5. CSS 2.1 Compliance
6. Selectors API
7. Circular-Memory-Leak Mitigration
8. Versioning and Cross-Document Interaction
9. Better AJAX development
10. Versioning and Internet Explorer Modes
11. Improved Protected-Mode API Support
12. Platform Performance Improvements

이 순서로 진행할 예정입니다.

posted by blankus
태그 - ie 8, ie 8 beta, ie8, Internet Explorer 8
Tip  |  2008/03/06 11:59
Trackbacks  0 | Comments  0
[자료] Cross Domain XHR W3C proposal

새해복 많이 받으세요 ^^

오랜만에 포스팅을 하는 것 같습니다. 이런 저런 일로 바쁘게 지내다 보니 한참을 잊고 있었네요..ㅎㅎ

오늘은 간만에 반가운 소식을 전해볼까 합니다. 이미 다들 알고 계실지도 모르겠지만..

Ajax의 XHR통신중 크로스 도메인이 상당히 불편해 하고 있는걸로 알고있습니다. 허나 W3C에서 이를 공식적으로 지원하기 위해
움직이고 있군요. http://www.w3.org/TR/access-control/ 이곳을 보시면 자세한 설명이 나와있으니, 참고하시면 되겠습니다.

허나 영어이기때문에.. 조금은 난해할 수 도 있지만, 저희는 글보다는 코드를 주로 보지 않습니까? ㅎㅎ

그럼 오늘은 이 기쁜(?)소식을 짧게 전하는 것으로 마치겠습니다.

posted by blankus

태그 - cross domain, javascript, 크로스 도메인
Tip  |  2008/01/08 23:52
Trackbacks  0 | Comments  0
Javascript Hijacking ... part 1
추석연휴는 잘 보내셨나요? ㅎㅎ 저는 조부모님댁이 서울이라... 회사서 휴일당직도 하고, 휴일같지 않은 휴일을 많이 보냈답니다.ㅎ

오늘은 자바스크립트 하이잭킹에 대해서 소개하겠습니다. Hijack이란 단어는 "강탈하다", "뺏다"의 뜻이 있습니다.
단어에서 느끼듯이 주제는 그러합니다. ^^. 이번 글은 www.fortifysoftware.com에서 제공한 pdf의 내용이며,
오역이 있더라도 잘봐주세요. 그리고 중요치 않다고 생각되는 부분은 과감하게 생략토록 할것이고, 문장의 매끄러움을 위해 의역도 포함했습니다.



Javascript Hijacking

Brian Chess, Yekaterina Tsipenyuk O'Neil, jacob West

{brain, katrina, jacob}@fortifysoftware.com
march 12, 2007


요약

Ajax어플리케이션이라 불리우는 리치 웹 어플리케이션들은 데이터 전송기술로서 자바스크립트를 사용하여 만든다. 이번 지면에서는 제목처럼 자바스크립트 하이잭킹, 즉 취약성에 대해서 다룬다.
공격은 웹브라우저의 강제 SOP(Same Origin Policy)를 우회하는 <script>태그를 사용하여 시작된다.
전통적인 웹어플리케이션들은 취약하지 않았다. 왜냐하면, 과거의 것들은 데이터 전송기술로 자바스크립트를 이용하지 않았기 때문이다.

우리는 유명한 12개의 Ajax프레임워크를 분석했다.[ 서버사이드용 4개 : DWR(Direct Web Remoting), Atlas(ASP.NET Ajax), xajax, GWT(Google Web Toolkit), 클라이언트용 라이브러리 8개 : PrototypeJS, Script.aculo.us, Dojo, Moo.fx, jQuery, YUI, Rico, MochiKit]  
위의 것들중 유일하게 DWR 2.0만이 자바스크립트 하이잭킹을 막기위해 구현한 것이 존재했다. 대부분의 프레임워크들은 어떠한 보호장치도 제공하지 않았고, 그들의 문서에서 조차 보안에 관련된 내용을 언급하지 않았다.

우리는 두가지의 완화법에 대해서 논의할 것이다. 악의 있는 요청을 줄이는것과 자바스크립트를 직접실행하는 공격자에 대한 방어가 그것이다.

1. 소개
비록 'Web 2.0'이란 단어가 정확한 정의를 가지고 있지는 않지만, 최근엔 일반적으로 두가지로 사용되고 있다. 첫번째는 'Web 2.0'이 웹 어플리케이션으로 하여금 사회적 상호작용 또는 일반적 합의점을 제공하는 것이고 두번째는 웹 프로그래밍 기술이 풍부한 사용자의 인터페이스를 이끌도록 제공하는 것이다.
이러한 기술들이 때로는 Ajax라는 이름으로 구현되고 있다. 여기서는 자바스크립트 하이잭킹의 단어처럼 취약성에 대해서 논의할 것이다.  이것은 많은 리치 웹 어플리케이션에 의해 사용되는 데이터 전송기술을 이용하는  공격이다. 자바스크립트 하이잭킹은 비인증 공격자가 생성된 매쉬업중 하나를 사용하여 취약한 웹 어플리케이션으로부터 중요 데이터를 읽을 수 있도록 허용한다. 이러한 취약점은 이미 논의되었지만 웹프로그래머들은 이러한 문제점을 좌시했고, 심지어 많이 알려진 이 단어(하이잭킹)조차 모르고있다.

자바스크립트 하이잭킹은 널리 알려진 취약점의 다른 형태로 변형된다 : cross-site request forgery.
cross-site request forgery 공격은 취약한 웹사이트에게 HTTP Request를 하나 또는 여러개를 submit할때 공격이 시작된다. 일반적은 cross-site request forgery 공격은 데이트 무결점을 훼손시킨다. 이는 공격자에게 취약한 웹사이트의 저장된 정보를 수정할 수 있는 능력을 준다.

취약한 웹사이트는 이미 많은 곳에 존재한다. 자바스크립트 하이잭킹에 대해서 주장한 사람들중 하나인 Jeremiah Grossman은 Gmail의 취약성을 발견했고, 구글메일은 이문제를 수정했다.

posted by blankus
태그 - Hijacking, javascript, javascript hijacking
Tip  |  2007/09/27 10:40
Trackbacks  2490 | Comments  0