MS Visual Studio 2005로 WPF 개발환경 구축하기

개발 노트 2008. 9. 1. 23:41 posted by 무병장수권력자


출처 : 서비의 다락방 ( http://www.yunsobi.com )

MS 비주얼 스튜디오 2008에는 기본적으로 WPF개발 환경이 포함되어 있지만 비주얼 스튜디오 2005환경에서 WPF 개발을 하기 위해선 몇 가지 프로그램을 추가 설치해야 합니다.

MS 비주얼 스튜디오 2005 개발환경에서 WPF(Windows Presentation Foundation) 개발 환경을 구축하기 위해 설치 해야 하는 프로그램의 일람을 정리해 둡니다.

우선 OS와 비주얼 스튜디오 2005까지 설치가 된 상태에서 시작하겠습니다.

1. Visual Studio 2005 SP1 설치 ( 다운로드 )
2. .Net Framework 3.5 설치(3.0 unInstall을 우선 수행 )  (
다운로드 )
3. Windows SDK for Windows Vista 설치  (
다운로드 )
4. Visual Studio 2005 Extensions for WPF and WCF 설치  (
다운로드 )
5. Visual Studio 2005 Extensions for WWF 설치  (
다운로드 )
6. (Option)Microsoft Expression Design 설치  (
다운로드 )
7. (Option)Microsoft Expression Blend 설치  (
다운로드 )
8. (Option)Microsoft Expression Web 설치  (
다운로드 )
9. (Option)XmlNotepad 설치  (
다운로드 )
10. (Option)WPF Performance Tool 설치  (
다운로드 )

개발 환경을 구축하는데 위에 열거한 모든 프로그램을 추가 설치 해야 하는 것은 아닙니다.
4번 항목까지만 설치하면 기본적인 개발환경은 갖추어지며, 그 나머지는 필요에 따라 선택적으로 설치 하시면 됩니다.


시덥잖은 Google App Engine 튜토리얼

Google 2008. 8. 21. 09:51 posted by 무병장수권력자


작성자 : 김문규
최초 작성일 : 2008. 8.21

튜토리얼 대로 따라만 하면 되는 건데..저는 proxy 설정 때문에 고생했습니다.
다음과 같은 순서로 하시면 되겠습니다.

GAE 계정은 있으시죠? ㅎㅎ

1. python 설치
 - 전 2.5를 깔았습니다.
the Python website

2. App Engine SDK 설치
 - Download the App Engine SDK

3. helloworld 폴더 생성
 - 아무거나 해도 상관없음

* 소스 파일 입니다.
4. helloworld/helloworld.py 작성
print 'Content-Type: text/plain'
print ''
print 'Hello, world!'

* 설정 파일 입니다.
5. helloworld/app.yaml 파일 작성
application-id란 GAE 계정을 따고 나서 등록한 application의 이름입니다. 저의 경우에는 mymk.appspot.com이 주소이고 application-id는 mymk 입니다.
application: 당신의 application-id
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
  script: helloworld.py

6. local test
 - GAE가 설치된 폴더에서 dev_appserver.py helloworld/ (주의 사항은 뒤에 /가 꼭 있어야 합니다.)
 - server가 정상적으로 로딩되면
http://localhost:8080 에서 페이지를 확인 할 수 있습니다.

7. GAE 업로드
 - proxy 뒤에 있다면? 환경변수 http_proxy 추가
windows : 제어판->환경변수->시스템 변수 추가 http_proxy, 당신의 proxy 주소:port
Unix/Linux : export http_proxy="당신의 proxy 주소:port"

다른 건 문제가 없을 것입니다. 여러분의 네트워크 설정에 맞추어서 proxy만 잘 설정하시면 문제없이 첫번째 GAE 애플리케이션 생성에 성공하실 겁니다.

제가 만든 GAE 인스턴스 입니다. mymk.appspot.com
아~ 이제는 무엇을 만들어 봐야 할까요? ^^

'Google' 카테고리의 다른 글

Google의 On2 Technologies 인수!  (0) 2009.08.07
Google Wave  (0) 2009.06.11
Google App Engine 계정을 드디어 받았습니다.  (2) 2008.08.20
Google's Master Plan  (0) 2008.07.24
Google Code Jam  (0) 2008.07.09


Google App Engine 계정을 드디어 받았습니다.

Google 2008. 8. 20. 22:57 posted by 무병장수권력자


우리나라는 Google App Engine 계정을 받을 수가 없습니다.

계정을 얻기 위해서는 SMS를 통한 사용자 인증 과정이 필요합니다. 그런데, 우리나라 통신사는 제휴가 안되었는지 SMS를 받을 수가 없기 때문입니다. 여기서 참 당황스런 부분은 제가 보기엔 전 세계를 통털어 구글이 보내는 SMS를 받을 수 없는 나라는 우리나라 뿐인것 같습니다. 무슨 사정이 있는지는 모르겠지만 우리나라 통신사 들이 하는 행패를 보면 충분히 이해도 갑니다.

그래서 결국에는 일본에 사는 친구를 통해서 어렵게 계정을 등록했습니다.

사용자 삽입 이미지


별거 아니지만 제가 워낙 관심을 가지고 있는 서비스라 꼭 해보고 싶었기에~ 기분이 참 좋습니다.

기쁜 맘으로 구글링을 통해서 Helloworld를 뿌려보기로 맘 먹었습니다. 그런데 잘 안되네요....ㅎㅎ 역시 항상 한방에 되는 것 없습니다. OTL....

내일 해봐야 겠습니다. 다음 포스팅의 주제가 될 지는 아직 확실치 않습니다. 다만 관심이 있을 뿐이에요. ^^

'Google' 카테고리의 다른 글

Google Wave  (0) 2009.06.11
시덥잖은 Google App Engine 튜토리얼  (0) 2008.08.21
Google's Master Plan  (0) 2008.07.24
Google Code Jam  (0) 2008.07.09
Google App Engine Overview  (0) 2008.06.11


[실전 security ⑧] 보안 점검 Check Sheet

보안, 암호화 2008. 8. 18. 17:41 posted by 무병장수권력자


실전! 개발자를 위한 Security 체크 포인트
⑧ 보안 점검 Check Sheet

작성자 : 김문규
최초 작성일 : 2008. 8. 12
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

이번 포스트는 그동안 연재한 웹 서비스 시스템 개발 보안의 강좌의 마지막 입니다. 실제 구현 시 확인해야 할 체크 포인트 들입니다. 굉장히 많습니다. 귀찮습니다. 하지만, 보안은 누군가가 귀찮아야 하는 것이라는 것을 명심하시길 바랍니다.

1. 설계 단계
1) 접근 통제 정책 설계 시 핵심 Check Point
- Access 권한 설정 기준이 있는가?
- Access 권한 설정 기준은 "최소한의 권한 원칙(Least privilege)"을 적용하였는가?
- 동일 사용자 ID로 다른 PC에서 동시 로그온이 불가능 한가?
- 일정시간 미사용 시 자동 로그오프 되는가?
  (30분 이상 미사용 시 자동 로그오프를 권장하나 업무의 성격에 따라 변경가능)
- 무자격 사용자 ID(예. 퇴직, 전배, 6개월이상 미사용자)를 자동 제거 하는 프로세스가
  있는가?

2) 감사 정책 설계 시 핵심 Check Point
- 사용자별 접속내역 로깅을 기록관리하는가?
 (로깅항목: 사용자 ID, Login/Logout시간, 접속IP)
- 접속내역 로깅을 보관하고 있는가?
 (3개월 이상 보관 할 것을 권장하나 업무의 성격에 따라 변경 가능)
- 사용이력 로깅을 기록관리하는가?
 (로깅항목: 사용자ID, 사용시간, 사용이력-조회,수정,삭제, 프로그램ID)
- 사용이력 로깅을 보관하고 있는가?
 (3개월 이상 보관 할 것을 권장하나 업무의 성격에 따라 변경 가능)
- 로그온 시 보안경고 메시지 및 최종 사용정보를 표시하는가?
 (보안메시지- 시스템에서 하는 모든 활동이 모니터링 되고 있음을 알림,
 최종사용정보- 로그온 시 최종 사용시간, 접속IP를 표시)

3) 상세 설계 시 핵심 Check Point
- 입력값이 정확하게 들어오는지에 대한 검증이 이루어지고 모듈간 전달되는 파라미터값을 검증하도록 설계되어 있는가? 
- 입력값의 검증시 Client쪽만의 검증에 의존하지 않고 서버쪽의 검증도 수행하는 방식으로 설계하는가?
- 웹 어플리케이션 설계시 대표적인 입력공격(XSS, SQL injection공격 등) 등에 대한 대책이 설계되었는가?
- 다양한 사용자에 대한 어플리케이션 접근 위험이 분석되어 이에 따른 식별 및 인증 방안이 설계 되었는가?
- 강화된 인증이 요구되는 경우 생체인식이나 인증서 등의 강화된 인증 방식을 설계하였는가?
- 식별 및 인증을 통합 관리하는 방안이 설계 되었는가?
- 어플리케이션의 서비스 계정은 최소 권한 요구사항을 만족하는가?
- 일정기간 사용하지 않는 서버 계정은 사용 중지가 되도록 설계되는가?
- 인증의 문제발생시 계정을 즉시 Disable시킬 수 있도록 설계되어있는가?
- Client가 인증할 경우 암호화되지 않은 인증 값을 전달하지 않도록 설계되는가?
- 인증을 위하여 cookie를 사용하는 경우 cookie보호를 위한 암호화를 적용하는가?
- 어플리케이션이 강력한 패스워드를 강제하는가?
- 패스워드의 주기적인 변경, 실패 로그인 시도수를 제한하는가?
- 패스워드의 유출방지를 위해 패스워드가 암호화되어 저장되도록 설계되었는가?
- 인증 실패시 너무 많은 정보를 제공하지 않도록 설계하는가?
- 같은 사용자 계정으로 한명 이상이 로그인했을 경우를 허용하지 않도록 설계되었는가?
- 로그온이후 일정시간 동안의 사용이 없을 경우 자동 로그아웃되는 등이 설계에 반영되었는가?
- 허가를 위해 가능한 Role-based 접근방법을 사용하는가?
- Role을 사용할 경우 Role에 대한 적절한 권한 분리가 이루어지는가?
- 응용프로그램이 시스템레벨의 자원을 접근할 경우 꼭 필요한 것만 접근할 수 있도록 설계되었는가?
- 응용프로그램이 DB에 접근할 경우 직접적인 접근이 아닌 가능한 stored procedure를 사용하여 간접적으로 접근하도록 하는가?
- 일반사용자는 응용프로그램을 통하지 않고는 정보가 저장되어 있는 데이터베이스에 접근할 수 없도록 설계되었는가?
- 하나의 강력한 관리자 권한을 부여하지 않고, 개발자, 운영자, 시스템 관리자 등의 권한의 차별화를 고려하여 권한에 적합한 관리자 권한을 설정, 부여하는가?
- 응용프로그램의 기능사용을 통제하기 위한 메뉴 환경이 제공되는가?
- 응용프로그램의 구성설정 내용의 저장은 안전하게 저장되도록 하는가?
- 일정기간 동안 미사용시 사용자의 로그인 기능을 폐쇄하도록 설계하는가?
- 세션 identifier를 암호화되지 않은 채널로 전송하지 않도록 하는가?
- 세션 쿠키는 암호화하여 전송하는가?
- Query string내의 session identifier를 전달하지 않도록 설계하는가?
- Session lifetime은 제한하고 Session 상태를 안전하게 저장하도록 하는가?
- 동일 사용자의 동시 세션수를 제한하는가?
- 민감한 데이터의 저장시 암호화 등을 통하여 안전하게 저장하는가?
- 민감한 데이터의 네트워크상의 전송시 유출이나 변조에 보호되도록 암호화 등의 대책을 적용하는가?
- Cookie에 민감한 데이터를 저장하지 않도록 하는가?
- 민감한 데이터의 사용에 대한 로깅을 수행하는가?
- 암호화 적용시 개별적인 암호화를 사용하지 않고 증명된 암호화를 적용하는가?
- 암호화를 적용할 경우 적절한 키 사이즈와 정확한 알고리듬을 적용하는가?
- 암호화키를 안전하게 보관하도록 설계하는가?
- 암호화키가 주기적으로 변경될 수 있도록 하는가?
- 다음과 같은 주요 보안 로깅/감사를 위한 항목을 정의하고 로깅 메커니즘을 설계하였는가?
 : 실패 로그인/로그아웃
 : 인증정보의 변경
 : 특수 권한의 수행
 : 주요 Operation의 수행 등 
- 정보보호로그기록이 허가되지 않은 인력에 의해 삭제되거나 기능이 제거될 수 없도록 설계되었는가?
- 정보보호로그를 분석할 수 있도록 설계되었는가?
- 개발자, 운영자, 시스템 관리자 등의 권한의 차별화를 고려하여 관리자 권한을 부여하는가?
- 구조화된 예외처리를 사용하여 민감한 정보가 예기치 않게 누설되지 않도록  하고 있는가?
- Client에게 많은 정보를 누설하지 않도록 예외처리 메시지 집합을 정의 하는가?
- 사용 및 전송 데이터에 대한 무결성 요구가 있을 경우 무결성 요구에 대한 설계가 이루어졌는가?
- 메시지에 대한 부인방지 요구가 있을 경우 부인방지 요구에 대한 설계가 이루어졌는가?

4) 테스트 시나리오 작성 시 핵심 Check Point
- 테스트의 목적과 책임이 정의되었는가?
- 테스트의 범위, 가정, 제약조건, 상호연관성이 정의되었는가?
- 테스트 방법론 및 절차가 정의되었는가?
- 테스트 시나리오가 정의되었는가?
- 테스트 계획, 테스트를 위한 준비사항이 정의되었는가?
- 테스트를 위한 팀의 구성 및 책임과 역할이 정의되었는가?
- 테스트의 평가 기준이 정의되었는가?

2. 개발 단계
1) 개발 단계 Check Point
- 중간페이지를 비정상적으로 접근이 불가능 한가?
 (중간페이지까지 정상적으로 접속후 해당 URL book-marking후 다른 브라우저에서 중간페이지 접속 시도)
- Data를 조회할 때 URL에 표시되는 Key값을 변조하여 권한 밖의 정보 조회가 불가능한가?
- 중요정보(Password, Key값)가 쿠키, Get방식, Hidden 등에 매개변수 조작이 가능한 평문형태로 존재하지 않는가?
- 신뢰되지 않은 입력에 대해 유효성을 체크하는가?
- SQL Injection을 이용하여 인증을 통과하지 않는가?
- 불필요한 에러 메시지를 출력하여, 시스템 정보가 노출되지는 않는가?
- HTML 주석에 필요이상의 정보가 노출되어 있지는 않은가?
- 암호 구현시 공인된 알고리즘이 사용되고 키는 안전하게 저장되어 있는가?
- 사용자가 원격에서 실행 가능한 임의의 프로그램(PHP, ASP, JSP 등)을 업로드할 수 없도록 차단되었거나 실행되지 않도록 되어있는가?
- 사용자로부터 html tag 입력이 불가능하도록 되어있는가?

3. 구현 단계
1) 구현 단계 Check Point
- S/W의 기본취약점 및 디폴트 패스워드는 제거 되었는가?
- 기존에 운영중인 중요한 Data가 안전하게 전송, 생성, 폐기 되었는가?
- 시스템 릴리이즈전 보안담장자나 CERT요원에 의해 보안성 검토를 수행하고 이를 책임자에게 보고 하였는가?
- 설계서에서 제시된 정보보호 요구기능들이 구현되는가?
- 각종 정보보호시스템들이 구현되는가?
- 정보보호 관련 코드는 별도로 문서화하여 관리하는가?
- 구축 시 정보보호관련 설계변경 요구시 그 영향도와 위험을 평가하여 변경승인을 수행하는가?
- 승인된 설계변경 사항들을 추적하여 문서화하고 있는가?

2) 운영 단계 Check Point
- 시스템에 대한 이관 및 운영을 위한 운영관리 방안 및 계획이 수립되었는가?
- 정보시스템의 안전한 관리를 위하여 운영자들을 위한 설명서가 작성되었는가?
- 정보시스템의 안전한 이용을 위하여 사용자들을 위한 정보보호 설명서가 작성되었는가?
- 접근 권한관리가 적절히 이루어지고 있는가?
- 운영시스템에 대한 변경은 절차에 의해 이루어지고 기록 관리되고 있는가?
- 주기적으로 자체점검활동을 하고 그 결과를 보고하고 있는가?
- 점검결과가 문서화 되고, 주관 기관의 승인을 득하였는가?
- 점검 결과 정보보호 대책 및 기능이 적절히 작동하는지 평가되었는가?
- 취약성 분석을 수행하여 명시된 대책이 시스템의 알려진 취약성으로부터 충분히
 보호하는지 평가되었는가?

4. 맺음말
항상 마지막 포스트를 정리할 때는 뿌듯함이 느껴집니다. 마치 책거리를 하는 느낌입니다. 이번 포스트도 제가 부족한 부분인 보안을 공부하면서 시작했는데... 이렇게 길고 커질 줄은 몰랐습니다. 정리하다 보니 실을 포스트에 정리된 내용은 너무나 간단해서 실전에 적용할 것이 없다고 생각되네요.
하지만, 이런 기본들이 쌓여서 다음번 보안 교육때는 더 고급 과정을 이해할 수 있으리라고 기대합니다. 저와 같은 보안 초보 개발자들에게 한줄기 빛과 같은 강좌였길 바랍니다. ^^

그럼 이만! 쓩!



[실전 security ⑦] Application Security

보안, 암호화 2008. 8. 18. 11:52 posted by 무병장수권력자


실전! 개발자를 위한 Security 체크 포인트
⑦ Application Security

작성자 : 김문규
최초 작성일 : 2008. 8. 18
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

이번 장에서는 전체 웹 서비스 시스템에 걸쳐서 고려해야 할 엔지니어링 적인 보안 요소에 대해서 알아볼 예정입니다. 코드상의 보안 이슈보다 시스템 구성/설정과 관련된 이슈를 다루겠습니다.
사실은 개발자에게는 이런 요소가 더 어려운 부분인 것 같습니다. 공개된 자료도 없고 특히나 경험적인 부분이 많이 필요한 필드이기 때문입니다.
많은 내용을 다루지는 못하겠지만 기본적인 내용 파악을 주 목적으로 알아보도록 하겠습니다.

1. 안전한 시스템 구성
사용자 삽입 이미지

1) Dual Firewall
웹서버의 앞과 뒤에 모두 f/w을 설치하는 구성입니다. 1차 방화벽은 DMZ 안에 위치한 웹서버를 보호하는 것이 주 목적이지만 이것이 100% 안전하다고 할 수 없습니다. 따라서, 1차 방화벽이 뚫렸을 경우에 DB 서버를 안전하게 보호하기 위해 (물론 App 서버도) 2차 방화벽을 사용합니다.
* 최근에는 reverse telnet 같은 outbound 패킷을 이용한 공격 방법이 이용되고 있기 때문에 방화벽 정책 구성 시 inbound와 outbound 모두 고려하여 정책을 수립하여야 합니다.

2) NAT
웹 서버 이후의 모든 장치는 NAT를 이용하여 사설 IP를 이용하는 것이 좋습니다. NAT를 이용해서 외부에 내부의 네트워크 구성을 감출 수 있기 때문입니다.

상황에 따라 시스템의 구성은 유동적일 수 있습니다. 하지만, 위에서 설명한 보안 요소들은 매우 기본적인 내용이기 때문에 그 내용을 이해하고 필요한 경우에 적용할 수 있어야 하겠습니다.

2. 웹 서버 보안 요소

웹서버는 다음과 같은 기본 적인 취약점을 가지고 있습니다. (WAS 서버 또한 이와 매우 유사한 문제점을 가지고 있습니다. 이론적인 내용이 같기 때문에 설명은 생략합니다.)
- 디폴트 ID / Password
- 소스 노출 취약점
- 디렉토리 리스팅 취약점
- 기본 인증 취약점
- 웹 서버 자체 취약점

이번 절에서 각각을 자세히 알아보도록 하겠습니다.

1) 디폴트 ID / Password 취약점
웹 서버 설치시 디폴트로 생성되므로 반드시 Password를 변경 해야 됩니다.
웹 서버 제품별로 웹서버 관리화면(포트) 디폴트 패스워드가 존재합니다. 디폴트 패스워드를 방치했을 경우 웹서비스가 다운되거나, 중요 시스템정보가 노출되어 해킹에 이용될 수 있습니다.
특히, 인터넷에 오픈된 사이트의 경우 관리포트는 내려서 운영하시거나 방화벽에서 소스 IP를 고정하여 관리자만 접근 할 수 있도록 하는게 바람직합니다.

2) 소스 노출 취약점
웹 브라우저에 프로그램 소스가 노출되는 현상으로 웹서버를 패치, 환경설정을 변경하거나 불필요한 샘플파일(JRun의 viewsource.jsp)을 삭제 해야 됩니다.
예전에는 웹서버 IIS에서 ASP소스 노출이 되었으나, 최근에는 웹어플리케이션 서버 (weblogic, Tomcat 등)에서 임의의 URL 입력으로 소스가 노출되는 취약점들이 많이 보고 되고 있습니다.

3) 디렉토리 리스팅 취약점
웹 서버의 디렉토리 구조가 보이는 현상으로 웹서버의 설정값을 변경 하거나 디렉토리 리스팅 취약점이 존재하는 경우 패치를 하여야 합니다.
간혹 일부 웹서버(Iplanet-舊 Netscape, Apache 등) 웹 서비스 신규 생성시 디폴트가 디렉토리 리스팅 허용(Fancy)로 되어 있어 웹서버 설치시 주의하셔야 합니다.

4) 기본 인증 취약점
기본 인증은 웹서버에서 기본적으로 제공하는 인증 방법입니다.
HTTP를 이용해서 웹 서버의 특정 디렉토리와 그 이하의 모든 디렉토리에 접근 제어를 할 수 있습니다.   그러나 ID/패스워드 전송시 MIME type에 사용되는 BASE64 인코딩 기법을 사용하기 때문에 취약점이 존재합니다. BASE64알고리즘은 암호 알고리즘이 아니라, 단순 Encode/Decode 알고리즘이기 때문에 쉽게 디코딩, 노출이 가능합니다.

이번엔 기본 인증관련 취약점과 관련하여, 인코딩된 패킷을 스니퍼 프로그램을 이용하여 가로챈 경우를 살펴볼까요?
인코딩된 패킷을 가로채 보면, 아래와 같이 인코딩된 부분이 보입니다. 
Authorization: Basic dGVzdDp0ZXN0MDA=  
dGVzdDp0ZXN0MDA= 부분을 인터넷에 돌아다니는 base64 디코딩 툴로 디코드해보면 test:test00가 추출이 됩니다. 이는 곧 <웹 관리자 id:패스워드>라는 뜻이지요.
또한 무작위 공격(brute force attack) 또는 사전 공격(dictionary attck)을 통해 기본인증이 적용된 웹페이지의 ID와 Password가 노출될 수도 있습니다.

자, 그럼 어떻게 해야 할까요?
해결방법은 기본인증을 사용하지 않고, Digest방식을 사용하는 것입니다. Digest방식은 md5와 같은 암호 알고리즘을 사용하여 id/패스워드가 전송되기 때문에 쉽게 노출되지 않고, 안전하게 사용할 수 있습니다. (제품별로 Digest방식을 지원 못하는 제품도 있음)

참고 1 : 다양한 웹 인증 방법
 
 
 
인증 방식
특 징
보안
수준
비 고
① 기 본
평문형태 혹은 Base64 인코딩
방법으로 전송합니다.
낮음
 
② 다이제스트
MD5와 같은 일방향 알고리즘을
사용하여 복호화가 불가능합니다.
보통
HTTP1.1 지원
브라우저 필요
③ 통합 윈도우(NTLM)
마이크로소프트의 독점 인증
프로토콜로 OS의 사용자ID와
연동됩니다.
HTTP 요청/응답 헤더 안에서
구현됩니다.
높음
인트라넷 적합
④ 인증서
클라이언트측 인증서를 이용하여
인증을 수행합니다. SSL/TLS사용시
Enable하여 사용할 수 있습니다.
보통
인증서 배포 필요
⑤ 폼-기반
사용자 정의 폼이 입력에 사용되고,
백엔드에서 사용자 정의 로직을
사용하여 처리됩니다. 일반적으로
로그온 상태를 유지하기 위하여
쿠키를 사용합니다.
높음
SSL 적용 필요

다양한 인증방법 중 ④인증서 방식 외 모든 인증 방식들은 패스워드 추측(Password Guessing)에 취약합니다. 최근에는 웹 인증을 파괴하는 자동화된 툴(Webcracker, Brutus)들이 많이 나와 있어 주의해야 합니다.
가장 좋은 방법은 강력한 패스워드 규칙 사용과 패스워드 오류시 잠금기능 (Lock)을 적용하는 것입니다.


5) 웹 서버 자체 취약점
제품 자체가 근본적으로 가지는 취약점을 말합니다. IIS의 유니코드 취약점이 그 대표적인 예입니다.
주기적으로 문제점을 파악하여 반드시 패치하거나 최신 버전으로 업그레이드를 하여야 합니다.
-  제품별 취약점 조회 사이트
  http://www.securityfocus.com
http://www.securitymap.net


3. DB 서버 보안 요소

응용시스템의 소스노출 취약점을 이용해 DB서버의 정보(ID,Password 등)를 획득하고 공격하는 경우가 많이 있습니다. 이럴 경우 DB connection부분에 사용되는 Password를 암호화 해서 사용하면 좀 더 안전한 웹사이트를 구축할 수 있습니다.

DbCon(userid, password, serverip, datasource, databasenm)
                                             ▼
<%
tmptext =
dbcon
("ACYRDhDxLx","ACHnACNHLxho2VZH","LjLjGa0M37WHZHycnOnO7sNH0", "OlDxrbrbb7S7vjLs","")

set db = server.createobject("adodb.connection") db.open tmptext
%>






실전! 개발자를 위한 Security 체크 포인트
⑥ 암호화 기술

작성자 : 김문규
최초 작성일 : 2008. 8. 12
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

이번 포스트에서는 굉장히 친숙한 보안 용어들에 대해 알아보려 합니다. SSL, 공인 인증, 대칭키, 비대칭키 암호화, PKI .... 정말 많이 들어 봤습니다. 하지만, 자세히 모르고 있는 경우가 많습니다. 이들이 대략적으로 무엇인지 알아보기로 하겠습니다.


1. SSL

1) SSL 이란?
미국의 Netscape사에 의해 개발된 SSL 프로토콜은 클라이언트와 서버 사이에서 오가는 데이터의 인증 및 암호화 통신을 위해 사용되는 프로토콜

2) 수행 단계

SSL이 수행되는 단계는 총 3가지로 분류된다.
 - SSL Server Authentication
사용자의 웹브라우저가 상대방의 웹서버를 인증하는 단계이다.
SSL을 지원하는 웹브라우저는 표준 공용키 암호화 기법을 사용하여 서버의 인증서와 공용 ID를 실제로 브라우져가 신뢰하는 인증기관(Trusted CA)으로부터 발급받았는지 여부를 인증하는 기능을 내장하고 있다.

 - SSL Client Authentication
웹서버가 자신에게 요청한 클라이언트를 인증하는 단계이다.
서버 인증 시에 사용했던 동일한 기법으로 인증하는데 서버에 내장된 SSL 지원 소프트웨어나 서버 앞에 배치된 SSL 하드웨어는 클라이언트의 인증서와 공용 ID 를 실제로 서버가 신뢰하는 인증기관(Trusted CA)으로부터 발급 받았는지 여부를 인증하는 기능을 내장하고 있다.

 - Encrypt Connection
서로에 대한 인증단계 이후 정상적으로 종결되면 클라이언트와 서버사이에 교환되는 모든 데이터는 사적인 내용을 보호하기 위한 암호화를 요구받는다. 또한 SSL커넥션을 통해 암호화된 데이터 역시 전송 중 변경을 방지(Message Integrity)하기 위해 Hash 알고리즘이라고 불리는 기술에 의해 보호된다.

위의 3가지 단계를 기반으로 실제로 구현되는 순서는 다음과 같으며, 다음 순서를 진행하기에 앞서 SSL 또한 TCP 프로토콜에 기반을 두고 있으므로 반드시 TCP 3 Handshake는 이루어져 있어만 한다.

3) SSL Handshaking

사용자 삽입 이미지


각 스텝에서 교환되는 데이터의 주된 내용은 아래와 같습니다.

Step Action
1 ClientHello 메시지를 Serve전송 : SSL 버젼번호, 암호화방식 등
2 Client가 전송한 메세지에 대한 응답 :
Client 가 제안한 SSL 옵션들에 대해서 사용할 기능을 선택하여 Client 에게 답변. 필요시 디지털 인증서의 요청 및 전달
3 ServerKeyExchange 메시지 전송 :
서버의 공개키를 포함하는 메세지 전송.
4 ServerHelloDone 메시지 전송 :
서버가 Client에게 일련의 작업이 정상종료 됨을 알려줌.
5 Client의 Key정보 전송 :
클라이언트는 암호화에 사용되는 세션 키와 함께 클라이언트에서 지원하는 Cipher Suite를 서버로 전송하며, 서버가 인증서를 요청한 경우에는 클라이언트의 인증서도 함께 전송
6 Client 는 보안서비스 시작 메세지 전송 :
Client와 서버간의 일련의 Key교환 및 교섭작업의 완료를 알림
7 협상성공 및 보안검증의 완료메세지 전송 : Client측
8 서버도 보안서비스 시작 메세지 전송 :
Client와 서버간의 일련의 Key 교환 및 교섭작업의 완료를 알림
9 협상성공 및 보안검증의 완료메세지 전송 : 서버측

4) SSL의 암호화 방식

SSL에서는 대칭키 암호화 방식, 공개키 암호화, 디지털 인증 기술을 모두 사용하게 됩니다.

먼저 디지털 인증서 교환을 통해 상대방에 대한 인증을 확실히 하고 이를 통해 공개키 암호화의 단점을 보완하였습니다.
다음으로 공개키 암호화 기술을 이용해서 세션키를 클라이언트, 서버가 공유합니다. 비용은 비싸지만 세션키를 보호하기 위하여 높은 수준의 보안 기술을 사용하게 됩니다.
마지막으로 공유된 세션키를 이용해서 대칭키 암호화 방식으로 통신합니다. 이 방식은 공개키 방식에 비해 낮은 수준의 보안을 제공하지만 데이터 처리 부하가 적어서 빠르게 통신이 가능해 지기 때문에 사용합니다.

참고로 SSL에서 세션키를 통해 암호화하는 암호화 기법으로는 DES, 3DES, RC2, RC4등이 있고 40비트부터 168비트까지 사용됩니다. 메시지 무결성(Message Integrity) 보장을 위해 사용되는 Hash 알고리즘으로는 MD5나 SHA1.등이 주로 사용 됩니다.

이에 대한 조금더 자세한 내용은 본 포스트의 3절에서 다룹니다.


2. 공인 인증

1) 역할
인터넷 뱅킹 혹은 Online 쇼핑 등은 거래당사자들의 비대면거래에 의해, 상행위가 이루어집니다. 눈으로 볼 수 없는 상대편을 인정하고, 신뢰하여야 거래가 이루어지지요. 그렇다면, 어떻게 인증하고 신뢰할 수 있을까요? 바로 공인인증서가 그 역할을 수행할 수 있습니다. 전자상거래가 요구하는 인증/무결성/부인봉쇄를 위해 전자서명을 하면 될 것이고, 비밀성을 보장받으려면 암호화를 하면 되는 것입니다.

공인인증이란, 어떤 문서를 모든 사람들이 신뢰할 수 있도록 공탁이란 것을 하듯이, 공인인증서를 이용하여 "이 거래는 법적으로 유효한 것입니다"라고 인감도장을 찍음으로써 거래를 신뢰할 수 있도록 하는 것입니다.
또한 이 공인인증서는 국가가 인정한 공인기관(CA)으로 하여금 유효성을 관리하도록 하고 있지요.

2) 공인 인증 과정
사용자 삽입 이미지

RA는 은행, CA는 금융 결제원에 해당됩니다. (이외에도 CA는 한국 증권 전산, 한국 전산원, 한국 정보 인증, 한국 전자 인증, KTNET이 있습니다.)

다음은 각 과정을 자세히 설명한 것입니다.
Step Action
1 본인확인 :
공인인증서를 발급받기 위해서는 반드시, 대면확인을 통하여,
본인임을 증명하여야 합니다.  Online상의 카드인증 및 실명인증 등은 아직까지 대면확인의 효력을 갖지 못합니다. 그러다 보니, 제1금융권(은행)의 경우, 통장개설시 실명확인 및 주민등록증 등에 의한
대면확인이 가능하므로 RA의 기능을 수행할 수 있지요.
2,3 신청정보 전송 :
은행의 Teller등에 의하여, 본인확인 절차를 거친 후, 등록 요청기관/
주민NO 등의 정보를 CA로 전송합니다.
4,5 응답 :
CA는 RA 로부터의 요청을 접수 후, 임시번호의 역할을 하게 되는,
참조번호와 인가코드를 RA를 통하여, 신청자에게 전달합니다.
6 인증서신청 :
사용자는 일정기간 내에 전달받은 참조번호와 인가코드를 이용하여, CA로부터 일정한 유효기간(1년)을 갖는 인증서를 발급받습니다.
7 인증서 발급정보 배포 :
CA는 신규 발급한 인증서의 발급정보를 각 금융기관 등에
배포함으로써, 인증서의 유효성을 검증합니다.


3. 암호화 알고리즘

1) 대칭키 암호화
대칭키 암호 알고리즘은 비밀키 암호 알고리즘 혹은 단일키 암호 알고리즘이라고 불리기도 하는데 이 방식은 송/수신자가 동일한 키에 의해 암호화 및 복호화 과정을 수행합니다.

 - 블록 암호 알고리즘
블록 암호 알고리즘은 고정된 크기의 입력 블록을 고정된 크기의 출력 블록으로 변경하는 암호알고리즘에 의해 암호화 및 복호화 과정을 수행합니다.
대표적인 알고리즘으로 DES(Data Encryption Standard), Triple DES, Skipjack, IDEA(International Data Encryption Algorithm), FEAL(Fast Data Encipherment Algorithm), MISTY 등이 있습니다.

 - 스트림 암호 알고리즘
스트림 암호 알고리즘은 이진화된(binary) 평문과 키 이진 수열을 배타적 논리합 (eXclusive-OR) 이라는 비트 단위 이진 연산으로 결합하여 암호문을 생성하는 방식입니다.
스트림 암호 알고리즘은 사용하는 스트림이 주기적인지 아닌지에 따라 두 가지로 분류 가능합니다.
키 스트림이 어떤 주기를 갖고 반복되는 경우에 사용하는 주기적 스트림 암호 알고리즘과, 키가 반복이 없는 경우에 사용하는 비주기적 스트림 암호 알고리즘이 있습니다.
대표적인 알고리즘으로는 RC4,SEAL(Software-optimized Encryption Algorithm)등이 있습니다.

2) 비대칭키 암호화
공개키 암호 알고리즘을 사용하는 시스템은 암복호화에 사용되는 Key Set을 다르게 생성, 배포 및 관리함으로 높은 수준의 보안 유지가 가능합니다.  공개키 암호 시스템은 두 개의 Key Set을 생성하여 그 중 하나를 공개하고 (Publickey), 나머지 하나는 비밀키로 자신이 보관하여 (Private Key) 사용하는 암호 시스템 방식입니다.
사용자 삽입 이미지
 - RSA 암호화
 - Rabin 암호화
 - Merkle-Hellman Knapsack 암호화
 - Graham-Shamir 암호화
 - McEliece 암호화, Elliptic Curve 암호화

3) 비교
항 목
대칭키
비대칭키
비용
속도
키배포 및 관리의 편리성
안전성


4) Hybrid 방식 암호화
실제의 업무에 있어서는 대칭키 및 비대칭키방식을 혼용하여 사용하는 방식을 사용합니다.
전송하고자 하는 실제 Data는 대칭키방식을 이용하여 암호화하고, 이때 사용되는 대칭키는 PKI방식의 비대칭키를 이용하여 암호화를 한 후, 이를 전송하게 되는 방식입니다.
실제 데이터를 대칭키방식으로 암호화함으로써, 속도 및 길이의 효율성을 높이며 대칭키는 PKI방식을 이용함으로써, 키배포의 위험성을 없애고 보안을 강화할 수 있는 것입니다.
사용자 삽입 이미지

5) Hash
해쉬함수는 임의의 고정된 길이의 비트 문자열(해쉬코드)을 출력하는 함수로써, 다음과 같은 성질을 갖고 있습니다.
 -  출력된 해쉬코드에 대한 원본 비트 문자열을 찾아내는 것은 불가능
 -  주어진 입력에 대해 같은 해쉬코드를 생성하는 또 다른 입력값을 찾아내는 것은 불가능

이와 같은 성질을 이용하여, 해쉬함수는 전자서명의 무결성을 보장하는 데 많이 이용되고 있습니다. 또한, 비밀번호와 같이 복호화할 필요가 없는 자료의 단방향 암호화에도 사용되고 있습니다.

- Hash를 이용한 데이터 교환의 동작 순서는 아래와 같습니다.

송신자에서
① 송신하고자 하는 문자열의 해쉬코드를 구합니다.
② 구해진 해쉬코드에 비밀키로 서명을 합니다.
③ 평문과 ②의 데이타를 묶어서 수신자의 공개키로 암호화 합니다.

수신자에서
④ 자신의 개인키로 복호화합니다.
⑤ 풀려진 전자서명(해쉬코드+송신자의 비밀키) 값을 송신자의 공개키로 풀어서 해쉬코드를 구합니다.
⑥ ④에서 구한 평문을 해쉬함수를 적용하여 그 결과와 ⑤의 해쉬 코드를 비교하여 무결성을 검증합니다.

4. 맺음말
시작할 때 말씀드린 것처럼 본 포스트에서 다룬 내용은 엔지니어에게 아주 익숙한 보안 용어들입니다. 하지만, 막상 동작 과정을 설명해보라고 하면 쉽지 않은 것이 사실입니다.
저 역시 보안 관련 종사하는 엔지니어가 아니라서 마찬가지 였고 내용을 차근차근 학습하면서 '아 이런거구나'라면 혼잣말을 했습니다. 개인적으로는 정말 도움이 많이 되는 내용들이 었습니다.
기회가 되신 다면 더 깊은 내용을 확인하시는 것도 도움이 되시겠지만, 워낙 내용이 갑자기 어려워질 수 있으니 각오 단단히 하시길 바랍니다. ^^
그럼 이만...쓩!


[실전 security ⑤] 안전한 CGI 프로그래밍

보안, 암호화 2008. 8. 11. 11:18 posted by 무병장수권력자


실전! 개발자를 위한 Security 체크 포인트
⑤ 안전한 서버 프로그래밍

작성자 : 김문규
최초 작성일 : 2008. 8. 11
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

이번 포스트에서는 안전한 CGI 프로그래밍에 관련된 내용을 배우게 됩니다. 요즘 뭐 CGI 프로그래밍을 사용하는 사람이 있겠습니까? 그래서 이번 포스트에서는 CGI라는 특별한 케이스 보다는 서버 사이드 프로그래밍을 하면서 조심해야 하는 몇가지 부분에 대해서 공유하고자 합니다.

1. Shell을 실행하는 보안이 취약한 함수

1) 내부 명령어를 실행 가능하게 하는 인터페이스를 제공하지 말아야 합니다.

C system(), popen()
perl system(), open(), eval(), exec(), ' '(backticks)
php system(), passthru(), exec(), popen(), escapeshellcmd(), ' '(backticks)
asp Run("cmd.exe")
jsp exec() (Runtime객체)

2) asp, jsp와 같이 실행 가능한 파일이 업로드 되지 않도록 해야 합니다.
 - 1) 과 같은 명령의 수행이 가능한 파일이 업로드 될 경우에 보안 취약점이 발생합니다.

3) 해결책
 - 첨부파일 업로드시 파일명의 확장자 검사를 합니다.
 
 - 첨부파일 업로드시 파일명의 확장자를 임의로 변경하여, 실행되지 않도록 합니다.
   예) test.asp 업로드후-> test.asp021230

 - 업로드된 파일의 물리적인 위치를 유추할 수 없도록 합니다.

 - 첨부파일 업로드되는 디렉토리는 별도로 구성하여 asp, jsp, php등 실행되지 않도록 웹서버의 환경설정을 조정합니다.
   예) asp의 경우 업로드 디렉토리의 IIS관리자 → 등록정보 → 홈디렉토리 탭 → 실행권한 → 스크립트권한 제거

2. File Open (download) 주의 사항

1) URL을 통한 직접 다운로드을 제한합니다.
http://192.168.168.128:8080/upfile/진단신청서.gul
파일 다운로드 시 위와 같이 URL Link 만 연결하는 경우가 있습니다. 해당 파일이 중요하지 않다면 문제 되지 않지만 대외비 이상 문서, 혹은 개인정보 등 이 저장된 중요 파일이라면 반드시 다운로드 프로그램 (예: download.asp) 이용하여 세션 체크 후 정상적인 사용자만 접근하도록 해야 합니다. 

3. 사용하지 않는 HTTP method 옵션을 제거합니다.

1) 보안에 취약한 PUT, DELETE 옵션을 제거합니다.
 - PUT은 웹 서버 리소스의 변경을 초래할 수 있는 HTTP method 입니다.
 - DELETE는 웹 서버 리소스의 삭제를 초래할 수 있는 HTTP method 입니다.

참고 1 : 웹서버의 OPTION 확인방법
1) telnet [server ip] 80 로 접속한 후
2) OPTIONS / HTTP/1.0 엔터 2번 치면
3) 아래와 같이 결과화면이 나옵니다.
    ALLOW옵션에 아래와 같이 PUT, DELETE가 나타나면 취약한 서버입니다.
    (→ 아래 그림참조)

사용자 삽입 이미지

2) 해결책
 - PUT, DELETE의 허용 옵션을 제한합니다.
 예) [IIS 조치방법]
 인터넷서비스관리자 → 웹사이트 등록정보 → 홈디렉토리 탭 → "쓰기"옵션 제거

4. 맺음말
이번 장에서는 크게 어려운 내용이 보이지 않습니다. 실은 강의 원본이 CGI를 기준으로 되어 있어서 제가 잘 이해하지 못하는 부분도 있고 해서 일부 생략하고 제가 아는 내용과 이해하는 내용만 정리했습니다.
개인적으로는 3번째 PUT, DELETE에 대한 내용이 관심이 갑니다. 이유는 REST는 PUT, DELETE를 적절하게 사용하기 때문입니다. REST의 철학과 정면으로 배치되고 있기 때문에 다른 방법을 찾아야 하지 않을까 생각됩니다. 아직 방법은 잘 모릅니다. ^^ 추후 이 내용을 공유할 수 있는 기회가 있길 바랍니다.


Color Table (색상표)

개발 노트 2008. 8. 6. 19:12 posted by 무병장수권력자


#93DAFF #98DFFF #9DE4FF #A2E9FF #A7EEFF #ACF3FF #B0F7FF #B4FBFF #B9FFFF #C0FFFF
#87CEFA #91D8FA #A5D8FA #AFDDFA #B9E2FA #C3E7FA #CDECFA #D7F1FA #E1F6FA #EBFBFF
#00BFFF #0AC9FF #14D3FF #1EDDFF #28E7FF #32F1FF #3CFBFF #46FFFF #96FFFF #C8FFFF
#00A5FF #00AFFF #00B9FF #00C3FF #00CDFF #00D7FF #00E1FF #00EBFF #00F5FF #00FFFF
#1EA4FF #28AEFF #32B8FF #3CC2FF #46CCFF #50D6FF #5AE0FF #6EE0FF #6EEAFF #78F3FF
#1E90FF #289AFF #32A4FF #3CAEFF #46B8FF #50C2FF #5ACCFF #64D6FF #6EE0FF #78EAFF
#96A5FF #A0AFFF #AAB9FF #B4C3FF #BECDFF #C8D7FF #D2E1FF #DCEBFF #E8F5FF #F4FFFF
#86A5FF #90AFFF #9AB9FF #A4C3FF #AECDFF #B8D7FF #CCE1FF #E0EBFF #EBF5FF #F9FFFF
#6495ED #6E9FED #78A9ED #82B3ED #8CBDED #96C7ED #A0D1F7 #AADBFF #B4E5FF #BEEFFF
#0078FF #0A82FF #148CFF #1E96FF #28A0FF #32AAFF #3CB4FF #46BEFF #50C8FF #5AD2FF
#0064FF #0A6EFF #1478FF #1E82FF #288CFF #3296FF #3CA0FF #46AAFF #50B4FF #5ABEFF
#0000FF #3232FF #5050FF #646EFF #6478FF #6482FF #648CFF #6496FF #64A0FF #64AAFF
#4169E1 #4B73E1 #557DE1 #5F87E1 #6991E1 #739BE1 #7DA5E1 #87AFEB #91B9F5 #9BC3FF
#0064CD #0A6ECD #1478CD #1E82CD #288CD2 #3296D7 #3CA0E1 #46AAEB #50B4F5 #5ABEF5
#5A5AFF #6464FF #6E6EFF #7878FF #8282FF #8C8CFF #A0A0FF #B4B4FF #C8C8FF #D2D2FF
#7B68EE #8572EE #8F7CEE #9986EE #A390EE #AD9AEE #B7A4EE #C1AEEE #CBB8EE #D5C2EE
#6A5ACD #7E6ECD #8878CD #9282CD #9C8CCD #A696CD #B0A0CD #BAAAD7 #C4B4E1 #CEBEE1
#0000CD #2828CD #4646CD #6464CD #6E6ED7 #7878E1 #8282EB #8C8CF5 #9696FF #A0A0FF
#00008C #14148C #28288C #3C3C8C #50508C #646496 #7878AA #8C8CBE #A0A0C8 #B4B4DC
#483D8B #52478B #5C518B #665B8B #70658B #7A6F95 #84799F #8E83A9 #988DB3 #A297BD
#000069 #1E3269 #323C73 #3C467D #3C5087 #3C5A91 #46649B #506EA5 #5A78AF #6482B9


#3DFF92 #47FF9C #51FFA6 #5BFFB0 #65FFBA #6FFFC4 #79FFCE #75FFCA #7AFFCF #7FFFD4
#55EE94 #5FEE9E #69EEA8 #73EEB2 #7DEEBC #87EEC6 #91F8D0 #9BFFDA #A5FFE4 #AFFFEE
#66CDAA #70D2B4 #7AD7BE #84DCC8 #8EE1D2 #98EBDC #9DF0E1 #A2F5E6 #A7FAEB #ACFFEF
#AAEBAA #B4F0B4 #BEF5BE #C8FAC8 #D2FFD2 #DCFFDC #E1FFE1 #E6FFE6 #EBFFEB #F0FFF0
#80E12A #8AE634 #94EB3E #9EF048 #A8F552 #B2FA5C #BCFF66 #C1FF6B #C6FF70 #CBFF75
#52E252 #5CE75C #66EC66 #70F170 #7AF67A #84FB84 #89FB89 #8EFB8E #93FB93 #98FB98
#64CD3C #6ED746 #78E150 #82EB5A #8CF064 #96F56E #9BFA73 #A0FA78 #A5FA7D #AAFA82
#13C7A3 #18CCA8 #1DD1AD #22D6B2 #27DBB7 #2CE0BC #31E0C1 #36E0C6 #3BE0CB #40E0D0
#46B4B4 #50BEBE #5AC8C8 #64D2D2 #6EDCDC #73E1E1 #78E6E6 #7DEBEB #82F0F0 #87F5F5
#20B2AA #2ABCB4 #34C6BE #3ED0C8 #48DAD2 #52E4DC #57E9E1 #5CEEE6 #61F3EB #66F8F0
#5F9EA0 #69A8AA #73B2B4 #7DBCBE #87C6C8 #91D0D2 #96D5D7 #9BDADC #A0DFE1 #A5E3E6
#3CB371 #46BD7B #50C785 #5AD18F #64DB99 #6EE5A3 #73EAA8 #78EFAD #7DF4B2 #82F9B7
#2E8B57 #389561 #429F6B #4CA975 #56B37F #60BD89 #65C28E #6AC793 #6FCC98 #74D19D
#228B22 #2C952C #369F36 #40A940 #4AB34A #54BD54 #5EC75E #63CC63 #68D168 #6DD66D
#497649 #538053 #5D8A5D #679467 #719E71 #7BA87B #80AD80 #85B285 #8AB78A #8FBC8F
#006400 #0A6E0A #147814 #1E821E #288C28 #329632 #3CA03C #41A541 #46AA46 #4BAF4B
#008C8C #0A9696 #14A0A0 #1EAAAA #28B4B4 #32BEBE #37C3C3 #3CC8C8 #41CDCD #46D2D2
#008080 #0A8A8A #149494 #1E9E9E #28A8A8 #32B2B2 #37B7B7 #3CBCBC #41C1C1 #46C6C6


#FFB6C1 #FFBBC6 #FFC0CB #FFC5D0 #FFCAD5 #FFCFDA #FFD4DF #FFD9E4 #FFDEE9 #FFE3EE
#FFAAAF #FFB4B9 #FFBEC3 #FFC8CD #FFD2D7 #FFDCE1 #FFE1E6 #FFE6EB #FFEBF0 #FFF0F5
#FF9E9B #FFA8A5 #FFB2AF #FFBCB9 #FFC6C3 #FFD0CD #FFD5D2 #FFDAD7 #FFDFDC #FFE4E1
#FF7A85 #FF848F #FF8E99 #FF98A3 #FFA2AD #FFACB7 #FFB1BC #FFB6C1 #FFBBC6 #FFC0CB
#FF5675 #FF607F #FF6A89 #FF7493 #FF7E9D #FF88A7 #FF92B1 #FF9CBB #FFA6C5 #FFB0CF
#FF82FF #FF8CFF #FF96FF #FFA0FF #FFAAFF #FFB4FF #FFBEFF #FFC8FF #FFD2FF #FFDCFF
#FF7DB4 #FF87BE #FF91C8 #FF9BD2 #FFA5DC #FFAFE6 #FFB4EB #FFB9F0 #FFBEF5 #FFC3FA
#FF69B4 #FF73BE #FF7DC8 #FF87D2 #FF91DC #FF9BE6 #FFA5F0 #FFAAF5 #FFAFFA #FFB4FF
#FF1493 #FF1E9D #FF28A7 #FF32B1 #FF3CBB #FF46C5 #FF50CF #FF5AD9 #FF64E3 #FF6EED
#DB7093 #DB7A9D #DB84A7 #E08EB1 #E598BB #EAA2C5 #EAB1D4 #EFACCF #F4BBDE #F4B6D9
#D7567F #DC6089 #E16A93 #E6749D #EB7EA7 #F088B1 #F592BB #FA9CC5 #FFA6CF #FFB0D9
#C71585 #C71F8F #C73399 #C73DA3 #CC47AD #D151B7 #D65BC1 #E065CB #EA6FD5 #F479DF
#CD1039 #CD1F48 #CD2E57 #CD3861 #CD426B #D24C75 #D7567F #DC6089 #E16A93 #E6749D
#B9062F #B91A4D #BE2457 #C32E61 #C8386B #CD4275 #D24C7F #D75689 #DC6093 #E16A9D


#FAEB78 #FAF082 #FAF58C #FAFA96 #FAFAA0 #FAFAAA #FAFAB4 #FAFABE #FAFAD2 #FAFAD2
#FFDC3C #FFE146 #FFE650 #FFEB5A #FFF064 #FFF56E #FFFA78 #FFFA82 #FFFF8C #FFFF96
#FFC81E #FFD228 #FFD732 #FFDC3C #FFE146 #FFE650 #FFEB5A #FFF064 #FFF56E #FFF978
#FFB400 #FFBE0A #FFC314 #FFC81E #FFCD28 #FFD232 #FFD73C #FFDC46 #FFE150 #FFE65A
#FDCD8C #FDD296 #FDD7A0 #FDDCAA #FDE1B4 #FDE6BE #FDEBC8 #FDF5D2 #FDF5DC #FDF5E6
#FAC87D #FACD87 #FAD291 #FAD79B #FADCA5 #FAE1AF #FAE6B9 #FAEBC3 #FAEBCD #FAEBD7
#FFA500 #FFAF0A #FFB914 #FFC31E #FFCD28 #FFD732 #FFDC37 #FFE13C #FFE641 #FFEB46
#FF9100 #FF9B00 #FFA500 #FFAF00 #FFB900 #FFC300 #FFC800 #FFCD00 #FFD200 #FFD700
#FF8200 #FF8C0A #FF9614 #FFA01E #FFAA28 #FFB432 #FFB937 #FFBE3C #FFC341 #FFC846
#FFA98F #FFB399 #FFBDA3 #FFC7AD #FFD1B7 #FFDBC1 #FFE0C6 #FFE5CB #FFEAD0 #FFEFD5
#FFA374 #FFAD7E #FFB788 #FFC192 #FFCB9C #FFD0A1 #FFD5A6 #FFDAAB #FFDFB0 #FFE4B5
#FF9473 #FF9E7D #FFA887 #FFB291 #FFBC9B #FFC6A5 #FFD0AF #FFD0AF #FFD5B4 #FFDAB9
#FF7F50 #FF895A #FF9364 #FF9D6E #FFA778 #FFB182 #FFBB8C #FFC091 #FFC596 #FFCA9B
#CD853F #CD8F49 #D29953 #D7A35D #DCAD67 #E1B771 #E6C17B #EBC680 #F0CB85 #F5D08A
#D2691E #D27328 #D27D32 #D7873C #DC9146 #E19B50 #E6A55A #EBAA5F #EBAF64 #F0B469
#AE5E1A #B86824 #C2722E #CC7C38 #D68642 #E0904C #E59551 #EA9A56 #EF9F5B #F4A460
#8B4513 #8B4F1D #8B5927 #8B6331 #906D3B #957745 #9F814F #A48654 #A98B59 #AE905E


#FF9696 #FFA0A0 #FFAAAA #FFB4B4 #FFBEBE #FFC8C8 #FFD2D2 #FFDCDC #FFE6E6 #FFF0F0
#F08080 #F08A8A #F09494 #F59E9E #FAA8A8 #FAB2B2 #FAB7B7 #FABCBC #FAC1C1 #FAC6C6
#F56E6E #F57878 #F58282 #F58C8C #F59696 #F5A0A0 #F5AAAA #FAB4B4 #FABEBE #FAC8C8
#F06464 #F06E6E #F07878 #F08282 #F08C8C #F09696 #F4A0A0 #F4AAAA #F4B4B4 #FEBEBE
#FF0000 #FF3232 #FF4646 #FF5050 #FF5A5A #FF6464 #FF6E6E #FF7878 #FF8282 #FF8C8C
#EB0000 #EB3232 #EB4646 #EB5050 #EB5A5A #EB6464 #F06E6E #F57878 #FA8282 #FA8C8C
#CD0000 #CD3C3C #CD4646 #CD5050 #D25A5A #D76464 #DC6E6E #E17878 #E68282 #EB8C8C
#CD5C5C #CD6666 #CD7070 #CD7A7A #D28484 #D78E8E #DC9898 #E6A2A2 #EBACAC #F0B6B6
#B90000 #B93232 #B93C3C #B94646 #B95050 #BE5A5A #C35F5F #C86464 #CD6969 #D26E6E
#B22222 #B24040 #B24A4A #B25454 #B75E5E #BC6868 #C17272 #CB7776 #CB7C7C #D08180
#A52A2A #AA3E3E #AF4848 #B45252 #BE5C5C #C36666 #CD7070 #CD7A7A #D28484 #D78E8E
#800000 #803232 #853C3C #8F4646 #945050 #9E5A5A #A36464 #AD6E6E #B77878 #C18282


#CD853F #CD8B45 #CD904A #D2954F #D29A54 #D79F59 #D7A45E #E1A963 #E1AE68 #E6B36D
#DB631F #E56D29 #E57733 #EA813D #EF8B47 #EF904C #F49551 #F49A56 #F49F5B #F4A460
#D2691E #D27328 #D77D32 #D7873C #DC9146 #E19B50 #E6A055 #EBA55A #F0AA5F #F5AF64
#A0522D #A05C37 #A06641 #A5704B #AA7A55 #B4845F #B98E69 #C39873 #CDA27D #D7AC87
#8B4513 #8B4F1D #8B5927 #8B6331 #906D3B #9A7745 #A4814F #AE8B59 #B89563 #C29F6D
#DA70D6 #DF75DB #E47AE0 #E97FE5 #EE84EA #F389EF #F88EF4 #FD93F9 #FF98FE #FF9DFF
#BA55D3 #BF5AD8 #C45FDD #C964E2 #CE69E7 #D36EEC #D873F1 #DD78F6 #E27DFB #E782FF
#9932CC #9E37D1 #A33CD6 #A841DB #AD46E0 #B24BE5 #B750EA #BC55EF #C15AF4 #C65FF9
#9400D3 #9905D8 #9E0ADD #A30FE2 #A814E7 #AD19EC #B21EF1 #B723F6 #BC28FB #C12DFF
#942894 #9E329E #A83CA8 #B246B2 #BC50BC #C65AC6 #D064D0 #DA6EDA #E478E4 #EE82EE
#8c008c #960a96 #a014a0 #aa1eaa #b428b4 #be32be #c83cc8 #d246d2 #dc50dc #e65ae6
#800080 #8a0a8a #941494 #9e1e9e #a828a8 #b232b2 #bc3cbc #c646c6 #d050d0 #da5ada
#834683 #8d508d #975a97 #a164a1 #ab6eab #b578b5 #bf82bf #c98cc9 #d396d3 #dda0dd
#828282 #8c8c8c #969696 #a0a0a0 #aaaaaa #b4b4b4 #bebebe #c8c8c8 #d2d2d2 #dcdcdc
#000000 #282828 #323232 #3c3c3c #464646 #505050 #5a5a5a #646464 #6e6e6e #787878



[실전 security ④] 안전한 DB 프로그래밍

보안, 암호화 2008. 8. 6. 10:09 posted by 무병장수권력자


실전! 개발자를 위한 Security 체크 포인트
④ 안전한 DB 프로그래밍

작성자 : 김문규
최초 작성일 : 2008. 8. 6
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

이번 포스트에서는 안전한 DB 프로그래밍에 관련된 내용을 배우게 됩니다. 실제 엔터프라이즈급 애플리케이션에서 DB는 필수이며 이 부분이 취약해 진다면 겉만 번드드르한 허당이 되어 버리고 맙니다.
DB 관련된 보안은 어렵고 범위도 넓어 보입니다. 저 개인적으로 더 많은 공부를 하고 싶은 부분입니다.

1. SQL Injection

1) SQL Injection 이란?

SQL 문에서 동적으로 입력받는 값을 교묘하게 조작하여 DB를 해킹하는 것을 말합니다.
예1)
select * from users where username='변수 1' and password='변수 2'
는 정상적인 경우 다음처럼 동작합니다.
(변수 1 = superman, 변수 2 = abcdef)
select * from users where username='superman' and password='abcdef'

하지만, 해커가 아래와 같이 입력할 수 있었다면?
(변수 1 = a' or 1<2 or 'a' < 'b, 변수 2 = 123456)
select * from users where username='a' or 1<2 or 'a' < 'b' and password='123456'

정말 교묘하게도 위 쿼리는 전체 사용자 정보를 몽땅 다 보여주는 쿼리로 바뀌어 버립니다.
이것이 바로 SQL Injection 입니다.

절대 이게 다가 아닙니다. 관심이 있으신 분은 꼭 자세한 내용을 확인하시길 바랍니다.
다음은 추천 참고 사이트 입니다.
1.
http://www.silksoft.co.za/data/sqlinjectionattack.htm
   - Understanding and Preventing SQL Injection Attacks

2.
http://www.sqlsecurity.com/faq-inj.asp
   - SQL Injection FAQ

2) 대응책

아래의 것이 완벽한 대응책은 될 수 없겠지만, 중요한 내용에 대한 정리이니 꼭 확인하시고 코딩하실 때 기계적으로 적용하시길 바랍니다.

 - 사용자가 숫자를 입력해야 한다면, ISNUMERIC 함수 등을 이용해 입력을 검사합니다.
 
 - 입력 폼에서 특수문자( ' ; | -) 필터링 기능을 추가합니다.
 
 - 사용자가 문자열을 입력한다면 Escaping 처리합니다. Escaping 처리는 특수문자를 Keyword로 인식하지 않고 단순 문자로 인식하게 합니다.
    ※ DB 종류에 따라 다르게 적용
      * MS SQL, Oracle : ' 을 ' ' ( 작은 따옴표 두 개 )로 변경
      * MySQL : '을 \' 로 변경 

 - php를 사용하는 경우라면, php.ini 설정에서 magic_quotes_gpc = On 으로 설정합니다.
 
 - java를 사용하는 경우라면, 자동으로 '를 \'로 치환해주는 Prepared Statement를 사용하여 SQL문을 작성합니다.

 - 절대 서버 에러 내용을 사용자에게 보여주지 않습니다.
    ※ IIS 웹서버
기본웹사이트 → 등록정보 → 홈디렉토리 → 구성 → 응용프로그램 디버깅
"텍스트 오류 메시지를 클라이언트에게 보내기" 선택함
    ※ Php인 경우
Php.ini에서 display_errors = off 설정합니다.

2. DB 암호화

DB 서버는 시스템상에 가장 뒤에 숨어 있지만 여러가지 취약점을 통해 해킹 당할 가능성은 존재합니다.
1절에 설명한 SQL Injection을 통해서 관리자 계정 정보가 노출될 수도 있고, 뒤에서 설명하겠지만 WAS의 취약점을 공략해서 DB 연결 정보가 해킹당할 수도 있습니다. 물론 이외에도 다양한 경우가 있을 것으로 생각됩니다.
그렇기 때문에 DB의 내용이 해킹당했을 경우를 대비하여 DB 내부의 중요 데이터는 항상 암호화 해야 합니다.
이를 위해서는 주로 다음의 방법을 사용합니다.

1) 대칭키 암호화

 - 동일한 키를 공유하면서 이를 이용하여 암호화와 복호화를 하는 방식으로 암호화와 복호화의 속도가 빠르며 알고리즘이 비교적 단순하여 하드웨어를 구현하기 용이한 반면 키관리 및 분배가 어렵습니다.
 - 암호 세션키를 이용하여 인터넷 상에서 전달되는 데이타가 128비트 대칭키 방식 알고리즘으로 암호화되어 처리됨으로써 기밀성이 보장됩니다.
 - SEED는 대칭키 암호 알고리즘으로, 16byte 블록 단위로 메시지를 처리하는 블록 암호 알고리즘입니다.

2) 해쉬 함수의 이용

 - MD5 : 128비트(16바이트) 출력값
 - SHA : 160비트(20바이트) 출력값으로 미국 표준 해쉬 알고리즘입니다.
 - 일반적으로 SHA가 더 안전하다고 알려져 있지만 속도는 20%정도 더 느립니다.
 - 해쉬 함수의 효과 :  대칭키로 암호화하는 경우는 암호화 알고리즘이 유출될 경우, 암호화된 값을 토대로 원래의 패스워드를 유추하는 것이 상대적으로 쉽습니다.    그러나, 해쉬는 일방향 함수이기 때문에 패스워드를 유추해 내기란 계산상 불가능합니다.  따라서, 패스워드와 같이 복호화가 필요없이 값의 일치여부만 확인하면 되는 경우에는 해쉬함수를 사용하면 훨씬 더 안전하게 고객의 패스워드를 보호할 수 있습니다.

3. 맺음말
내용의 중요도에 비해 너무 짧은 포스트가 아닌가 생각됩니다. 개인적으로는 입사 초기에 제가 개발한 서버에 대해 SQL Injection의 우려가 있다고 회사 보안팀에서 압력을 받은 적이 있습니다. 아무런 생각없이 개발했던 것이 결국에는 뽀롱이 나고 만 것이죠.
실제로 고도의 해커가 아니어도 간단한 툴만으로도 SQL Injection 공격이 가능합니다. 그래서 더욱더 주의할 필요가 있는 것이지요.
SQL Injection에 대해서 좀 더 자세히 공부하시기를 강추 합니다.


[실전 security ③] 안전한 웹 서버 프로그래밍

보안, 암호화 2008. 8. 5. 20:12 posted by 무병장수권력자


실전! 개발자를 위한 Security 체크 포인트
③ 안전한 웹 서버 프로그래밍

작성자 : 김문규
최초 작성일 : 2008. 8. 6
* 본 포스트는 SDS e-campus의 '실전 개발자를 위한 Security 체크포인트' 강의 내용을 발췌하여 재구성한 개인적인 학습노트 입니다.

1. 안전한 웹 프로그램 작성 지침

1) 중간페이지가 바로 접속되어서는 안됩니다.

 - 보안이 필요한 모든 페이지에서 세션 검사

2) 중요 정보가 노출되어서는 안됩니다.
 - GET 방식으로 전송되는 모든 데이터는 암호화하여 변조 방지
 - Hidden 필드의 변조 방지
 - 참조 1의 매개 변수 값을 안전하게 보호하는 방법 참조

3) 중요(인증)정보는 평문형태의 Cookie를 사용하면 안됩니다.
 - 참조 1의 매개 변수 값을 안전하게 보호하는 방법 참조

4) 개발자가 아닌 사용자는 HTML tag 입력이 불가해야 합니다.
 - 만일 입력이 꼭 필요한 경우에는 공격의 소지가 없는 일부 태그만을 사용가능 하도록 제한합니다.

5) 사용자ID 및 패스워드는 암호화해서 전송해야합니다.
 - SSL 암호화 (128 bit 이상) 사용
 - ActiveX Control을 이용
 - 자바 스크립트로 구현할 경우에는 replay attack이 가능하지 않도록 주의합니다.

6) 중요한 HTML 소스는 암호화합니다.
 -

사용자 삽입 이미지


2. 맺음말
이번 장은 조금 더 자세한 수준으로 공부하게 된 것 같습니다. 제 생각에는 이 내용을 숙지하고 직접 간단한 예제를 작성해 보아야 하지 않을까 생각됩니다. 저도 일단은 apache를 깔고서 취약점을 공개한 코드랑 아닌 코드랑 비교해 보아야 겠습니다. 시간이 허한다면 이 내용도 추후에 추가토록 하겠습니다.
그럼! 이만!
 

참조 1. 매개 변수 값을 안전하게 보호하는 방법

1) 매개 변수의 암호화
hidden, cookie와 같은 매개변수를 클라이언트에서 서버로 전달할 때 대칭키 방식으로 암호화합니다. 키와 알고리즘은 노출되지 않도록 하고, 키는 Session별로 다르게 하여 (timestamp 등 활용) 동일한 접속이라고 하더라도 접속할 때마다 다르게 전송 합니다.

2) 매개 변수의 조작 여부 확인
또 한가지 방법은 매개변수의 조작여부를 체크하는 것입니다.
hidden, cookie에 변수 하나를 Check 값으로 저장해 (서버→클라이언트)로 내려 갔을 때와 (클라이언트→서버)로 돌아온 값들의 조작여부를 확인합니다. 이런 Check하는 변수에 md5, sha1과 같이 해쉬 알고리즘을 이용하여 체크하는 과정을 체크섬 이라고 합니다. (서버→클라이언트)로 갔던 체크 값과 (클라이언트→서버)로 올라왔을 때 체크 값이 일치하면 정상, 틀리면 변수값 조작이 있었던 것이므로 비정상 에러를 출력하는 것입니다.
예) <input type=hidden name=val1 value="7308022748398">
     <input type=hidden name=val2 value="아무개">
     <input type=hidden name=check
                                 value="q4837ksdafjgjsdg8345arfE78==">
이때 주의해야 할 것은 무슨 알고리즘을 사용하였는지 안다면 쉽게 Check 값도 조작이 가능하다는 것입니다. 그런 경우에 사용 가능한 것이 Salt를 활용하는 것입니다.
변수값1 + 변수값2 + "임의의 값"(Salt)     ->(해쉬 함수)   체크값
위와 같이 소금(Salt)을 쳐 놓으면 소금(Salt)은 서버프로그램에만 들어있기 때문에 체크값을 조작하기란 어려울 것입니다.

사용자 삽입 이미지


참조 2. Cross-Site Scripting 공격이란?

[출처]
XSS(Cross Site Scripting) 취약점에 대해 #3|작성자 지름중독 쭈니아빠
(http://blog.naver.com/jakehong?Redirect=Log&logNo=120003091823)

먼저 XSS를 이용해 공격을 한다는것은 사용자의 입력내용을 포함하는 HTTP요청에 대해 동적으로 HTML을 생성하는 어플리케이션(CGI)이 공격대상이 됩니다. 정적인 웹페이지, 즉 일반적인 HTML로 작성된 웹페이지에서는 이 문제는 일어나지 않습니다.
이해를 돕기위해 간단한 예제를 보겠습니다.

사용자 삽입 이미지
그림 3-1 : 텍스트입력란이 있는 cgi 프로그램
그림 3-1과 같이 텍스트을 입력받는란이 있어 여기에 사용자가 임의의 문자열을 입력한후 "전송하기"버튼을 누르면 사용자의 입력한 문자열을 웹페이지에 출력해주는 cgi 프로그램이 있다고 하면 결과는 다음과 같을것입니다.

사용자 삽입 이미지
그림 3-2 : 사용자가 입력한 문자열을 이용해 동적 HTML페이지를 생성한 결과
간단한 예제지만 이처럼 사용자가 입력한 문자열을 이용해 동적 HTML 출력하는 경우에 XSS취약점공격이 끼어들 가능성이 있는 페이지입니다. 그림 3-2를 웹브라우져의 "소스보기' 메뉴를 이용해서 HTML소스를 확인해보면 다음과 같습니다.
========================================================
<HTML>
<BODY> 
   메세지 : 안녕하세요 jakehong님!
</BODY>
</HTML>
========================================================
그럼 이번에는 그림3-1 화면에서 굵은폰트속성을 나타내는 HTML 태그를 사용하여 "안녕하세요 <B>jakehong</B>님!"이라고 입력해 본다면 결과가 어떻게 나올것 같나요? XSS취약점에 대한 대비가 안되어있는 cgi프로그램이라면 대부분 아래와 같이 "jakehong" 부분이 굵은 글씨로 출력된 페이지를 보게됩니다.
사용자 삽입 이미지
그림 3-3 : jakehong부분이 굵은폰트로 출력된 화면

이 화면의 HTML소스를 보면 다음과 같습니다.
========================================================
<HTML>
<BODY> 
   메세지 : 안녕하세요 <B>jakehong</B>님!
</BODY>
</HTML>
========================================================
사용자가 입력한 "안녕하세요 <B>jakehong</B>님!" 문자열을 입력한 그대로 출력하고자 한다면 "안녕하세요 &lt;B&gt;jakehong&lt;/B&gt;님!" 라고 출력해야 하지만 그 부분에 대한 처리를 해주지 않은것입니다.
그럼 이번에는 입력란에 "<SCRIPT>alert("까꿍!");</SCRIPT>"라고 입력해 보면 아래 그림과 같이 "까꿍!" 이라고 써진 다이얼로그박스가 나타납니다.
사용자 삽입 이미지
그림 3-4 : 입력란에 <SCRIPT>태그를 입력한 결과
HTML소스를 보면
========================================================
<HTML>
<BODY> 
   메세지 : <SCRIPT>alert("까꿍!");</SCRIPT>
</BODY>
</HTML>
========================================================
예상한대로 웹브라우져는 이 입력값을 스크립트라고 해석해 다이얼로그창을 보여줍니다. 예제에서는 단지 다이얼로그창을 띄운거지만 이 외에도 모든 script를  삽입하는것이 가능할 것입니다.
이처럼 웹페이지에 사용자가 임의의 script를 삽입시킬수 있는 문제가 있기 때문에 이를 XSS(Cross Site Scripting)라고 합니다.
예제는 자신이 입력한 스크립트를 자신이 실행하는것이지만 약간만 응용하면 다른사람에 의해 작성된 스크립트를 강제로 실행하게끔 하는것이 가능합니다.
그림 3-4에서 "확인"을 누른후 윈도우창 상단의 URL입력란을 보게되면

사용자 삽입 이미지
그림 3-5 : 그림 3-4 에서 "확인"을 누른후 URL란 확인
 
그림의 글씨가 좀 작아서 다시 쓰겠습니다.
====================================================================================
====================================================================================
이 URL encode 스트링(빨간글자)을 decode하면 이전 페이지에서 사용자가 입력한 <SCRIPT>alert("까꿍!");</SCRIPT>이란 글자가 됩니다.
즉, 이 cgi프로그램은 사용자가 입력한 문자열을 URL뒤에 인자로 추가하여 cgi프로그램에 전달되어 cgi프로그램이 이를 읽어 출력화면의 일부로 웹브라우져에 표시를 하는것입니다.
조금만 더 응용해 보겠습니다. 이번엔 XSS 취약점이 있는 웹싸이트에 다음과 같은 웹페이지를 하나 만듭니다.
===========================================================
<HTML>
<BODY bgcolor="black" link="white">
<A HREF='http://공격자사이트/text_r.asp?str=<script>alert("Merong~") ;</script>'>
여기를 클릭 </A>
</BODY>
</HTML>
===========================================================
사용자 삽입 이미지
그림 3-6 : 다른싸이트에 있는 script를 수행하는 예제
만일 사용자가 해커가 만들어논 이 페이지를 클릭하게 되면
=============================================================================
=============================================================================
해커가 사전에 만들어논 공격자싸이트의 cgi프로그램이 수행되면서 위에서 언급한 스크립트가 실행되는것입니다.
이처럼 공격대상싸이트에 공격자싸이트를 크로스(걸쳐서)시켜서 공격하기 때문에 XSS(Cross Site Scripting)이라고 합니다.