1. MD5 원리

MD5는 암호화가 아닌 단방향 해시 알고리즘이다.

MD5 코드는 32비트로 총 32자의 16진수로 이루어져 있다.

그렇다면 나올 수 있는 총 가짓 수는 16^32(16의 32승)이 된다.

그런데 문제는. 이세상의 모든 어구(입력값)는 16^32보다 많다는 것이다.

MD5코드는 제한적으로 정해져 있는 반면에, 다른 어구는 무한히 많을 수 있고,

모든 어구는 MD5코드로 변환이 가능 하니, 결국에는 겹칠 수 밖에 없는 것이다.

이와 같은 현상을 "비둘기 집의 원리" 라고 한다.

즉, n개의 비둘기집에 (n+1)마리 이상의 비둘기가 들어갔다면, 두 마리 이상의 비둘기가 들어간 비둘기집이 적어도 하나 있다.

이런 이유로 인해 복호화가 불가능하다고 알려져 있고 암호화가 아니라 해시알고리즘이라 한다.

2. MD5,SHA1 크래킹

2005년 중국의 한 학자에 의해 MD5와 SHA1 해시 알고리즘이 격파되었다.

하지만 “비둘기 집의 원리”에 의해 입력값보다 출력값이 적으므로 동일한 출력값에 의해 충돌은 일어날 수 밖에 없기 때문에 완벽하게 격파되었다고 보기는 힘들다.

그리고 현재 바투 회원DB에 있는 회원들의 MD5값을 복호화해보니 결과가 나오지 않는 경우도 많았다.(어떤 패턴에 의한 문자열만 복호화가 가능한 것으로 추측됩니다.)

이미 수 많은 웹 사이트들이 여전히 MD5 해싱알고리즘을 이용하여 비밀번호를 저장한다.

사용자의 패스워드를 쿠키로 심는다던지, 로그인 하는 과정에서 브라우저에서 비밀번호를 MD5로 변환하여 서버로 보낸다면 스니핑 공격을 통해 사용자의 비밀번호가 노출될 것이다.

웹 사이트에서는 비밀번호를 쿠키로 저장하지도 않고 서버에서 MD5로 변환하여 DB와 체크하기 때문에 해커들에 의해 노출될 염려는 없어 보인다.

하지만 웹 사이트 관리자가 사용자의 비밀번호를 크래킹할 수 있으므로 분명히 개선되어야 한다.

3. 대안

MD5와 SHA1이 격파된 다음, 세계 암호연구영역에서는 그보다 더 안전한 SHA-256, SHA-512연산법으로 전환할 것을 주장했으며, 이런 내용은 미국국가표준연구원에서 발표한 성명서에 적혀있다.

또한 SHA256, SHA384, SHA512 같은 해쉬함수는 이미 표준이 되어 있고 JDK1.5.0에서는 실제로 제공하고 있기도 한다.

MD5는 32자리, SHA-1 은 40자리, SHA256은 64자리의 16진수 문자열이 출력된다.

아래 메소드는 SHA256해시알고리즘으로 암호화하는  모듈이다.

/// <summary>
  ///
  /// </summary>
  /// <param name="plainText"></param>
  /// <returns></returns>
  public static string GetSHA256HashCode(string plainText)
  {
   byte[] clearBytes =
     System.Text.Encoding.UTF8.GetBytes(plainText);
   byte[] result;
   SHA256 shaM = new SHA256Managed();
   result = shaM.ComputeHash(clearBytes);
   return Convert.ToBase64String(result);
  }
 

4. 결론

앞서 말한 이유대로 해커에게 사용자의 비밀번호를 노출시키는 부분이 없기 때문에

사용자의 패스워드를 해킹당할 가능성은 드물어 보인다.

하지만 한국정보보호진흥원 및 국제사회에서 MD5,SHA1 해시 알고리즘이 깨졌다고 보고 있고

대안으로 SHA256, SHA512 알고리즘으로 변경하도록 권고하고 있다고 한다.

SHA256도 언제 완벽한 알고리즘과 슈퍼성능의 컴퓨터로 뚫릴지는 모르지만 당분간은

뚫릴 가능성이 없다고 한다.

설령 뚫린다고 해도 많은 강도가 높은 알고리즘이 연구되어 있고 표준으로 체택되어 있기 때문에

유기적으로 대처해 나가면 문제가 없을 것으로 판단한다.

웹 사이트 구축에 필수적인 요소로 사이트맵이 있습니다.

웹사이트에서 닷넷에서 제공하는 사이트맵 컨트롤인 SiteMap을 이용하여 어떻게 구성

하는지 알아보는 것이 이 문서의 목적입니다.

Web.sitemap 파일 구조

<siteMapNode url="~/HomeMain/Main.aspx" title="홈"  description="메인 페이지">

<siteMapNode

url="~/Board/LectureMain.aspx"

title="강좌홈"

titleImage="../IMG/common/title/pageT_lecture03.gif" descImage="../IMG/common/title/pageT_lecture01.gif"

description="강좌 메인 페이지" id="Lecture">

                     <siteMapNode

url="~/Board/BoardList.aspx?type=lecture&amp;mno=68"

title="수상전"

titleImage="../IMG/common/title/pageT_lecture03.gif" descImage="../IMG/common/title/pageT_lecture01.gif"

description="">

</siteMapNode>

                     <siteMapNode

url="~/Board/BoardList.aspx"

title="게시판"

titleImage="../IMG/common/title/pageT_lecture03.gif" descImage="../IMG/common/title/pageT_lecture01.gif"

description="">

</siteMapNode>

</siteMapNode>

</siteMapNode>

소스코드에서 sitemap 파일 접근

(1). 디자인 파일

<asp:SiteMapPath

ID="SiteMapPath1"

runat="server"

Font-Bold="False"

CssClass="C_Title_org"

ForeColor="blue">

</asp:SiteMapPath>

디자인 영역에서 위와 같이 컨트롤을 등록하면 web.sitemap에 해당하는 계층대로 사이트맵 텍스트와 url이 생성됩니다.

만일 위 사이트맵 파일에서 ~/Board/BoardList.aspx?type=lecture&mno=68 경로로 접근했다면

홈 > 강좌홈 > 수상전 으로 링크가 등록되어 출력이 됩니다.

(2). 소스코드 파일

.1) Title, Url, Description 속성 조회

this.browserTitle = (SiteMapPath1.Provider != null) ?

SiteMapPath1.Provider.CurrentNode.Title : "웹 사이트";

SiteMapPath1.Provider.CurrentNode.Url

SiteMapPath1.Provider.CurrentNode.Description

Title, Url, Description는 SiteMap Control 내부에 정의되어 있는 속성입니다.

2) 사용자 정의 속성 조회

this.titleImage = (SiteMapPath1.Provider.CurrentNode != null) ?

        SiteMapPath1.Provider.CurrentNode["titleImage"] : string.Empty;

웹 개발자는 페이지 별로 임의의 속성을 정의해줄 수 있습니다.

Web.sitemap 컨트롤의 내부 속성에 key 값과 value값을 설정한 후 소스코드에서

위와 같이 어트리뷰트로 조회할 수 있습니다.

웹 사이트를 배포할 때 디자인 파일(*.aspx, *.ascx, etc)과 소스코드를 컴파일한  

binary(웹사이트명.dll) 파일로 업데이트할지(닷넷 1.1버전), 아니면 런타임으로 자동 컴파일하도록

비하인드 파일(*.cs)까지 업데이트할지(닷넷 2.0버전)에 대해 고민해 볼 것입니다.

닷넷 1.1 버전에서는 페이지의 코드 비하인드 파일을은 미리 컴파일하여 웹사이트명.dll로

컴파일해야 했지만 ASP.NET 2.0에서는 처음 실행될 때 런타임으로 코드비하인드 페이지까지

자동으로 컴파일되기 때문에 개선된 배포방법이라고 생각합니다.

하지만 코드 비하인드 파일을 웹 서버에 업로드 해야하는 보안상의 문제가 있습니다.

사실 비하인드 파일은 DB와 직접 통신하지 않고 비지니스 로직 프로젝트나 기타 외부

라이브러리와 Adapter 역할을 하는거라 보안상 문제가 될 소지는 적어 보입니다.

각각의 방식에 대한 장단점으로 어떤게 있는지 내용을 정리해 봤습니다.

소스코드 컴파일(1.1) 배포방식

장점

- 디자인 파일만 업데이트하고 bin 폴더에 바이너리 파일을 업데이트 하면 되므로

웹 서버에 리소스를 줄일 수 있다.

- 바이너리로 관리되므로 보안상 문제가 없다.

단점

- 바이너리 업데이트일 경우 사소한 버그를 고치더라도 전체 소스코드를 업데이트해야 하므로

비효율적이다.

- 사이트 오픈 초기에 잦은 업데이트일 경우 업데이트의 비용이 많이 든다.

런타임시 컴파일(2.0) 배포방식

장점

- 업데이트한 페이지만 컴파일하므로 전체 페이지에 영향을 주지 않으므로 관리상 이점이 있다.

- 업데이트에 대한 비용이 적게 들기 때문에 빠른 업데이트가 가능하다.

단점

- Adapter역할을 하는 소스코드라 할지라도 소스 코드를 업데이트해야 하기 때문에

이로 인한 문제가 발생할 수 있다.

참고) cs파일은 ISAPI필터를 통해 외부에서 접근이 금지(403에러)되어 있기 때문에 직접적으로

외부에서 소스코드를 해킹할 수 있는 방법은 없다.

페이지별 DLL 배포

장점

- 페이지 당 하나의 dll이 배포되므로 수정할 페이지의 dll만 업로드하면 되므로 관리가 편리하다.

단점

- 페이지당 하나의 dll이 생성되므로 웹 소스 관리가 복잡해진다.

- 페이지 별로 동적으로 DLL 이 생성되기 때문에, 상호 개체간의 참조가 불가능하다.

IFormatProvider KR_Format = new System.Globalization.CultureInfo("ko-KR", true);   
DateTime date = DateTime.ParseExact("20090429000000", "yyyyMMddHHmmss", KR_Format);

"요즘 입사하는 후배들 3無…위아래·자기희생·情도 없어"
퇴근만 챙기는 부하들 보면 패주던 옛 상사가 그립기도
똥고집 상사에 부하도 할말 많아…훈시·화만내는 권위주의 신물

1.  IE8 소개

IE8의 새로운 기능과 크게 성능, 표준화, AJAX 프로그래밍, 보안, 확장에 대하여 알아보도록 한다.

2.  IE8 성능

2.1.                  이전 버전과 IE8의 스크립트 처리 성능비교

IE6, IE7 의 가장 큰 단점은 스크립트 처리속도가 크롬,FF에 비해 상당히 느렸다.

IE8 내부 매커니즘은 스크립트 처리속도를 상당히 개선시켰다.

Sun Spider Javascript BenchMart 에 의해 이전 버전과 IE8의 성능 측정을 해본 결과

상당히 많은 개선이 있다는 것을 알 수 있다.

2.2.                   브라우저별 주요 30대 사이트 성능 측정비교

Microsoft에서 최대한 테스트 환경을 맞춘 후 세계 주요 30대 사이트의 처리시간을 측정하였다.

사이트 테스트는 각 사이트별 방문자 수, 네트워크 트래픽, 클라이언트 환경 등 동일한 환경에서

측정을 하는 것은 거의 불가능에 가깝지만, 위 수치를 본다면 IE8에서는 이전 버전에서 확연히

차이가 있었던 속도 개선에 많은 향상을 가져오게 되었다.

3.  IE8 표준

3.1.                   지구촌 IE 버전별 점유율

3.2.                  한국의 IE 버전별 점유율

3.3.                   IE의 버전별 웹 표준 지원 현황

Acid2 / Acid3 Test 기준

* Acid2는 웹 표준 프로젝트가 HTML을 렌더링하는 웹 브라우저와 다른 응용 프로그램들에서 웹 페이지 렌더링 결점을 파악하기 위해 고안한 테스트 제품군이다

* Acid3는 웹 브라우저가 (특히 DOM과 자바스크립트와 관련하여) 얼마나 잘 웹 표준을 준수하고 있는 지를 검사하는 웹 표준 프로젝트의 테스트 페이지이다

3.4.                   IE 8과 낡은 웹 사이트(IE6, IE7)의 호환성 문제

IE 8이 웹 표준 준수율을 극도로 개선함으로써 미래의 웹 개발자는 자연스럽게 표준을 준수하게 될 것이고 웹 브라우저의 호환성 문제는 점차 사라질 것이다.

그러나, 과거에 작성된 낡은 페이지들은 오래된 브라우저에 최적화 되어 있기 때문에 IE 8

브라우저에서는 오히려 깨질 것이다.

3.4.1.      낡은 웹 사이트를 IE 8에서 깨지 않기

낡은 웹 사이트라고 해서 모두 같은 것은 아니다.

낡은 웹 사이트는 크게 세 가지 유형으로 나뉜다.

첫째, DTD가 없는 웹 사이트.

둘째, DTD가 있는 웹 사이트.

셋째, DTD 없는 페이지와 DTD 있는 페이지가 웹 사이트에 혼재되어 있는 경우.

3.4.1.1.   DTD가 없는 웹 사이트 대응법

DTD가 없는 페이지는 아무 대응을 할 필요가 없다.

IE 8은 DTD가 없는 페이지를 여전히 Quirks Mode로 렌더링 하기 때문에 웹 사이트는 깨지지 않는다.

* Quirks mode는 오래된 웹 브라우저들을 위해 디자인된 웹 페이지의 하위 호환성을 유지하기 위해 W3C나 IETF의 표준을 엄격히 준수하는 Standards Mode를 대신하여 사용되는 웹 브라우저의 기술을 나타낸다.

같은 코드라도 웹 브라우저마다 서로 해석을 달리 하기 때문에, 전혀 다른 결과물을 보여주게 된다.

3.4.1.2.   DTD가 있는 웹 사이트 대응법

DTD가 있는 페이지라고 해서 모두 같은 것은 아니다.

첫째, IE 5에 최적화 된 페이지.

둘째, IE 6에 최적화 된 페이지.

셋째, IE 7에 최적화 된 페이지.

l  IE 5에 최적화 된 페이지 대응법.

<meta http-equiv="X-UA-Compatible" content="IE=5" />

l  IE 6에 최적화 된 페이지 대응법.

IE 6에 최적화 된 페이지는 완전히 개편해야 한다.

적어도 IE 7에 최적화 시켜야 하는데 그렇지 않으면 구제할 방법이 없다.

IE 8 브라우저에 IE 6 렌더링 엔진이 없기 때문이다.

IE 6에 최적화된 페이지를 IE 7에 최적화 하는 것은 어렵지 않다.

IE 6에 최적화 된 페이지는 IE 7에 최적화 작업 후 다음 코드로 대응한다.

<meta  http-equiv="X-UA-Compatible" content="IE=7" />

l  IE 7에 최적화 된 페이지 대응법.

<meta http-equiv="X-UA-Compatible" content="IE=7" />

3.4.1.3.   DTD가 혼재되어 있는 웹 사이트 대응법

DTD가 혼재 되어 있는 웹 사이트는 DTD가 없는 페이지와 DTD가 있는 페이지를 구분하여 각각 다른 방법으로 대응해야 한다.

DTD가 없는 페이지는 아무런 대응을 하지 않는다.

IE 8은 DTD가 없는 페이지를 Quirks Mode로 렌더링 하기 때문에 페이지는 깨지지 않는다.

DTD가 있는 페이지는 IE 7에 최적화 시킨 후 다음 코드 적용.

<meta http-equiv="X-UA-Compatible" content="IE=7" />

만약, X-UA-Compatable 호환 코드를 DTD가 있는 페이지에만 별도로 적용하는 것이 어렵다면

모든 페이지에 호환 코드를 추가하는 방법도 있다.

DTD가 있는 페이지만 IE 7에 최적화 시킨 후 모든 페이지에 다음 코드를 적용한다.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

DTD가 없는 페이지는 여전히 Quirks Mode로, DTD가 있는 페이지는 IE 7 표준 모드로 렌더링 할 것이다.

l  Meta 호환 코드를 서버측 응답 헤더에 적용하는 방법

web.config 파일에 아래의 코드를 추가한다.

IE 8이 웹 표준을 잘 지원하고 있기 때문에 웹 표준을 잘 지킨 사이트는 낡은 브라우저에서 깨질 수 있다.

낡은 브라우저는 웹 표준을 완전히 지원하지 않기 때문이다.

또한, 낡은 브라우저라고 해서 다 같은 브라우저가 아니다.

IE 7, IE 6, IE 5 세 가지 버전의 브라우저 엔진은 지원하는 표준의 범위가 다르기 때문에 렌더링도 각각 다르다.

렌더링이 제각기 다르기 때문에 각각의 브라우저에 대응하는 CSS 코드도 달라야 한다.

IE 8이 등장 했지만 낡은 브라우저와의 호환성을 유지하기 위하여 향상된 표준 코드를 사용하지 않는 것은 바보같은 짓이다.

IE 8이 지원하는 표준 CSS 코드를 얼마든지 사용할 수 있다.

향상된 브라우저에 향상된 스타일을 제공하고 더 나은 사용자 경험을 제공 해야 한다.

4.  AJAX in IE8

4.1.                  XMLHttpRequest

timeout property와 ontimeout event 추가됨.

setTimeout과 abort() 이용하던 기존 꼼수를 대체.

4.2.                  Cross Domain Request(XDR)

-       다른 도메인간 AJAX 통신 지원

-       XMLHttpRequest 대신 XDomainRequest 객체를 통해 XDR 지원

-       XDomainRequest 객체는 비표준 확장

-       XMLHttpRequest2 (XS-XMLHttpRequest)작업중

-       FF 3.5 –지원예정

-       FF 3.0 -privileged script에서만 지원

-       MS는 XMLHttpRequest 확장이 위험하다는 판단

-       Dynamic Script Tag, Server Proxy, Flash 등으로 대체구현 가능

4.3.                  Cross Document Messaging(XDM)

-       두 Frame 사이의 메시징 통신 기법

-       HTML5 표준

-       FF 3.0

-       Webkit Nightly

-       Opera 9.5

-       대체구현

n  URL Hash + setIntervalpolling

n  Server Proxy

n  Google Caja

4.4.                   HTML/JSON Sanitizing

-       출신이 의심스런 HTML 및 JSON을 “착하게” 새니타이징한다.

-       빠른 JSON parsing / stringify