태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

 -zdnet 게재 컬럼입니다.

과연 인터넷 웹 서비스는 안전한가? 

일상적으로 접속해 정보를 상호 소통을 하는 중요한 매개체로 자리잡은 웹서비스는 그만큼의 신뢰도를 가지고 있다고 할 수 있을까?

여기 보려 하지 않고 외면 하고자 하는 불편한 진실이 있다. 이미 오래된 이야기지만 지금까지도 진행형 이고 앞으로도 심각성이 더 높아 질 수 밖에 없는 불편한 진실이다. 아직도 많은 이들의 관심 밖에서 이뤄지는 현실이 여기있다.

안전한 웹 서비스로 가는 길은 멀고도 험하다. 그러나 대부분이 쉽게 생각한다. 공격자들은 항상 그 빈틈을 노리고 끊임없이 공격한다. 일반 인터넷 사용자들은 자신의 아이디와 패스워드가 노출 되어 금전적인 손실이 발생 하거나 피해를 입었을 경우에만 민감하게 반응한다.

 

개인 PC에 설치된 악성코드의 문제를 개인 사용자의 부주의로 돌리는 것은 잘못된 것이다. 이제는 기본적인 보안 대책을 철저하게 실천한다해도 악성코드로부터 안전하지 않다.

어떤 접속 도구를 이용하던 웹 서핑을 하면서 자료를 확인 하고 정보를 공유하는 지금의 시대에 안전한 상태로 개인 PC를 유지 하려면 인터넷을 하지 말아야하는 수준이다. 사용자PC의 안전한 설정은 가능성을 조금 줄이는 옵션일 뿐이다.

왜 이런 상황까지 전개가 된 것일까?

일단 기본 설명에 대한 이해를 참고 하도록 한다.

대규모(Mass) SQL 인젝션(Injection)에 관련된 설명은 다음을 참고 한다.
Mass sql injection 대응과 현실 -
http://p4ssion.com/200
SQL Injection 공격 변화 -
http://p4ssion.com/207 

본시 SQL 인젝션 공격은 2005년 무렵부터 자동화된 도구를 이용하여 처음 시작이 되었다. 이전에는 공격자의 수작업에 의한 소위 타켓팅한 공격만이 있었다. 자동화된 도구에 의한 공격은 한국이 최초의 테스트 베드가 됐고 그 시작은 2005년부터다.

자동화된 도구를 이용한 SQL 인젝션 공격은 2007년을 지나면서 다른 양상으로 전개 되기 시작한다. 단일 사이트에 대한 자동화된 공격을 벗어나 대규모 도메인에 대한 자동화된 공격으로 전이가 된 것이다. 차이점은 자동화된 공격 도구의 대상을 단일 도메인으로 지정하는 것이 아니라 대규모 도메인 혹은 구글과 같은 검색엔진을 통한 무차별적인 공격으로 방향을 전환 했다는 점이다.

단일 서비스에 대한 공격으로 한정이 될 때는 공격자도 그만큼 많은 노력을 기울여서 여러 사이트를 반복해서 공격 할 수 밖에 없었지만 수집된 도메인 리스트에 기반한 공격과 검색엔진을 동원한 공격은 국가와 지역의 차이를 넘어서 무차별적인 서비스 공격으로 나타나고 있다.

서비스를 공격한 후에는 웹 서비스에 악성코드를 유포하는 URL을 삽입한다. 물론 데이터베이스안에 있는 내용은 관심 밖이다. 이미 가져갈 만큼 다 가져 갔는데 또 가져갈 필요성이 있을까? 이젠 데이터베이스에 저장된 내용이 아닌 방문자의 정보가 필요할 뿐이다.

웹 사이트 방문자의 PC에는 웹 사이트에 방문 할 때 마다 악성코드가 다운로드가 되고 조금 신경을 쓰면 방문자의 PC 운영체제에 따른 공격이 발생되게 된다.

이제 개인 사용자가 금융거래 사이트 또는 인터넷 서비스에 접근 할 때 마다 사용자가 입력하는 키입력 정보는 공격자에게로 전송된다. 때론 봇넷 에이전트를 동원해 분산서비스거부(DDoS) 공격을 하기도 하고 협박을 하기도 한다. 공격자들은 유출된 개인정보를 이용해 블로그나 카페, SNS 매체에 광고를 하는 등 다양한 방식으로 금전적인 이득도 추구하고 있다.

국내 금융권의 경우 다단계 보호수단들이 있으나 해외 금융기관들은 보호수단이 없거나 미비한 경우가 많아  피해 금액이나 사례는 국내보다 해외에서 더 큰 문제로 대두되고 있다.

현재의 대규모 SQL 인젝션 공격 동향을 살펴보면 두 가지 유형을 살펴 볼 수 있다. 좀 더 세밀하게 다듬어진 공격과 무차별적인 공격으로 구분 할 수 있는데 그 특징은 다음과 같다.

1. 웹 서비스의 소스를 일부 수정한다. *.js 와 같은 스크립트 유형의 코드를 웹 서비스 소스에 심어 두고 웹 사이트 방문자가 방문 할 때 마다 해당코드가 자동으로 실행 되도록 한다. 스크립트 코드에는 원격에서 사용자의 PC의 권한을 획득하기 위해 악성코드들이 다운로드 되고 실행이 된다.

2. 무차별 공격은 DB 테이블에 악성코드를 다운로드 하는 스크립트를 무작위로 삽입 하는 방식으로 이루어진다. 이 경우 전체적인 공격현황이 검색을 통해 손쉽게 드러난다. 그러나 공격자의 개입 없이도 자동적인 실행과 반복이 가능함으로 대규모 피해가 수반되고 있다. 2와 같은 경우는 많은 웹 서비스들이 데이터베이스에 들어 있는 콘텐츠를 일반 텍스트가 아닌 HTML로 화면상에 전환해 뿌려줌에 따라 자동적으로 실행된다.  텍스트로 읽어 들이는 경우에는 방문자 PC에 있는 브라우저 상에 스크립트 코드 링크들이 중간중간 삽입된 형태로 깨어지는 것을 확인 할 수 있다.

1번과 같은 세밀한 방식은 안티 바이러스 솔루션을 통해서 공격감지가 가능하다. 단 제로데이 공격이 아닐 경우에만 탐지가 가능한 경우다. 하루가 다르게 수많은 애플리케이션에서 취약성이 발견되는 현재에는 탐지 되지 않는 경우가 점차 증가 할 수 밖에 없다. 2번의 경우는 관리자가 손쉽게 데이터베이스 변조 여부를 확인 할 수 있으나 데이터 복구에 시간이 걸리는 문제들이 발견 되고 있다.

현상적으로 발견 할 수 있는 SQL인젝션 공격의 폐해는 무차별적인 공격의 경우 간략하게 검색엔진을 통해서 확인 할 수 있다. 최근까지 발견된 악성코드 유포 링크를 기준으로 검색한 결과는 상상 이상의 웹 서비스들이 해킹을 당하고 악성코드 유포에 이용이 되고 있음을 확인 할 수 있다.

22dnf.com/ff/y.js (국내용) 31,200개
www.dbrgf.ru/script.js (국내외용) 2,810개
mysy8.com/1/1.js (국내용)
s.ardoshanghai.com/s.js (국내용) 1,840,000개
sion.or.kr/iis.swf (국내용) 253,000개
bq346.cn (국내용) 4,930개
mekiller.com/1/1.js (국내외용) 27,500개
*.postfolkovs.ru/js.js (국외용) 125,000개
4589.in/yahoo.js (국외용) 254,000개
s.lbs66.cn/kr.js (국내용) 262,000개
s1.cawjb.com/s.js (국외용) 2,030,000개
s1.cawjb.com/kr.js (국내용) 950,000개
www.adst.ru/ads.js (국외용) 2,280,000개
www.24aspx.com/script.js (국외용) 12,400개
www.dnf666.net/u.js 전체: 530,000 / 국내: 463,000
www.adw95.com/b.js 전체: 61,200 / 국내: 3,940
www.nihao112.com/m.js 전체: 22,000 / 국내: 6
www.update34.com/b.js 전체: 16,500 / 국내: 6
기준 검색 일시: 2010. 7.1

*감염수치는 근사치로 활용이 되어야 하고 각 검색 시점에 따라 다를 수 있다. 또한 수치 확인에는 검색엔진의 검색결과를 이용 하였으므로 중복된 결과도 일부 존재 할 수 있다. 그러나 대강의 상황을 유추 할 수 있다는 점에 있어서 충분한 인용가치는 있다고 본다.

현재 검색 할 경우에는 차이가 많음을 확인 할 수 있다. 그러나 수치 차이는 검색엔진에서의 필터링과 대응을 통해 조회 시점의 수치보다 낮아 질 수 밖에 없다. 악성코드 유포 링크들이 여전히 일부 서비스들에 남아 있다는 것은 문제가 발생 된 이후에도 전혀 수정이 안되었음을 의미한다. 많은 서비스들이 공격이 가능했던 근본적인 소스코드 수정은 하지 않고 추가된 악성코드 유포 링크의 제거에만 신경을 쓰고 있는 것이 현실이다. 새로운 SQL 인젝션 패턴이 발생 될 경우에는 또 다시 몇 백 만대의 서비스들에서 악성코드를 유포하는 현황을 앞으로도 손쉽게 살필 수 있을 것이다.

악성코드를 유포하는 링크들의 업데이트 현황 중 일부는 여기에서 (http://securedmz.com/reference.php) 확인이 가능하다. 이 링크도 일부분임을 기억하자. 공격자 몇 명에 의해 생성되는 링크일 뿐이다. 실제 규모는 휠씬 더 심각한 상황 일 수 밖에 없다. 드러난 것은 10% 미만이라고 본다. 또한 검색엔진에 나타나지 않는 세밀한 공격은 통계치의 밖에 있다.


화면 상에 보듯이 검색결과의 차이가 상당함을 볼 수가 있다. 가장 최근에 보고가 된 Mass SQL Injection 공격으로 삽입된 악성코드 링크는 b.js를 포함하는 링크이다. 검색 결과는 다음과 같다.

2010년 8월 현재 152만개의 서비스에서 악성코드 유포 흔적들이 있다고 나타나고 있다. 그러나 이 중에는 정확한 분석 또는 단순 질의도 포함이 되어 있을 수 있다. 그러나 1/3만 유효한 링크라고 잡아도 50만대의 웹서비스에서 악성코드를 유포하는 것이다.

하루 방문자를 최소화 한다고 하여도 50만대의 웹 서비스에 최소 5명씩만 방문 한다고 하여도 250만대의 PC가 (실제는 휠씬 더 많을 수 밖에 없다.) 영향을 받는 것이다. 공격 성공률은 제로데이 (패치가 나오지 않은 공격) 공격일 경우 매우 높을 것임은 명확하다.

단순한 일회성의 공격이 아니다. 공격자들은 새로운 공격코드를 몇 십 만대에 또 다시 넣을 필요 없이 단순하게 악성코드를 다운로드 받는 주소에 있는 악성코드만을 새로운 것으로 바꿈으로 영향력을 가지게 된다.

전 세계의 보안 관련된 회사들을 단지 2~3명 정도의 공격자가 손쉽게 농락 할 수 있는 상황이 된 것이다.

공격방법 및 활용 시나리오를 간략하게 요약하자.

1. 악성코드를 유포할 숙주 도메인을 확보한다. 가급적 여러 개의 도메인을 확보. 위의 예에서는 b.js 파일이 올려진 사이트가 되겠다.

2. 검색엔진 및 리스트를 통해 Mass Sql Injection 공격을 자동으로 진행 하도록 하고 공격 성공 시에는 악성코드 유포 주소를 삽입한다. (소스코드에 링크 추가 또는 데이터베이스 테이블 내용 변경)

3. 이제 웹서비스를 통해 유포되는 악성코드들이 웹서비스 방문자의 PC에 설치 되기만 기다리면 된다.

4. 사용자들은 웹브라우저를 통해 웹사이트에 접근 하는 것 만으로도 악성코드가 다운로드 되고 실행 될 수 있는 환경이 된다. 이후 키입력은 모두 유출되고 PC는 좀비 PC가 된다.

만약 백신 개발업체에서 대응 백신을 개발한다면 공격자들은 초기 b.js 안에 실행되거나 다운로드 되는 악성코드를 변경 한다.

새로운 취약성이 있다면 즉시 활용을 하게 된다. 평균 신규 취약성이 나온 이후 며칠이 걸리던 것에서 이젠 12시간 이내에 새로운 악성코드로 전환 되는 것을 확인 할 수 있다. 개인 사용자가 사용하는 백신이 업데이트 된다 하여도 웹 서비스에 들어 있는 악성코드 링크가 사라지지 않는다면 최소 12시간 이내에 또 다른 공격을 맞이 하게 된다는 이야기 이다.

싸움은 더 이상 신사의 싸움이 아니며 공개적인 영역까지 침범을 당하고 대응하기 어려운 상태에 빠져 있다. 공격은 광범위하고 폭넓게 퍼져 있다. 현재는 asp, aspx + Ms sql 에 대한 대규모 공격도구가 활성화된 상태이지만 다른 개발언어와 데이터베이스를 향한 도구도 이미 일반적이다. 대규모로 확산 되는 것은 시간 문제일 따름이다.

현실은 앞에서 언급 했듯이 엄중한 현실이나 대책은 현실적으로 역부족일 수 밖에 없다. 공격을 당하지 않기 위해 웹 서비스 단위에서 진행 되거나 할 수 있는 대책은 크게 4가지 정도로 볼 수 있다.

웹 방화벽과 소스코드 검사, 모의해킹, 웹 스캐너 도입을 통한 문제점 해결 과 같은 유형이며 개인 사용자를 위한 대책은 오로지 바이러스 백신 외에는 없는 현실이다. 각 대책 별 문제와 이슈는 간략하게 다음과 같다.

각 대책 별 문제
 
전제: 웹 서비스는 잦은 사이트 개편과 갱신이 수시로 발생된다 이 모든 과정에서 보안적인 위험을 걸러낼 수 있어야 하나 현재 보안전문인력을 운영하고 상시적인 검사 프로세스를 갖춘 곳은 국내의 1% 미만의 업체만이 가능한 상태이다. 그 업체의 경우에도 전체 사이트 문제를 수시로 체크 할 수는 없는 상태이며 6개월 혹은 1년 단위로 전체 서비스를 검사하는 정기검진의 형태로만 진행 한다. 웹서비스의 잦은 개편과 갱신을 절대로 따라 갈 수 없는 상태가 된다.

1. 웹 방화벽: 우회 공격에 취약하며 근본 문제 해결이 아님. 비용 및 관리의 문제 발생

2. 소스코드 검사: 시일이 오래 걸리며 전문적인 인력이나 전문업체의 도움을 받아야 됨. 비용과 시간의 문제가 발생됨.

3. 모의해킹: 모의해킹을 통해서는 모든 문제가 발견 되는 것이 아니라 해당 사이트의 권한 획득만을 한 이후 종료 되는 과정이 대부분임. 이후 수정에 대한 피드백 제공 불확실. 비용의 문제 존재

4. 웹스캐너 도입: 상대적으로 고가의 솔루션이며 전문적인 결과가 도출 됨으로 인해 스캐너 결과를 이해 할 수 있는 인력의 도입이 필요하며 스캐너 비용 자체도 외산과 국산 모두 고가의 가격으로 도입에는 부담이 있음. 더불어 즉시적인 검사가 어려움 (개발속도 보다 진단 속도가 늦는 경우가 다수 발생)

이제 대책은 전 세계의 웹 서비스 개발 프로그래머를 일정 수준 이상으로 끌어 올리고 상시적인 점검이 가능한 체계를 어디에서 먼저 구축하느냐에 따라 달려 있다. 상당히 먼 길이 될 것이다.

앞으로의 현실은 오래 전 예상 했던 대로 상상 그 이상의 현실을 보게 될 것이다. -바다란
Posted by 바다란

댓글을 달아 주세요

  1. 이영규 2010.08.24 02:06  댓글주소  수정/삭제  댓글쓰기

    웹을 이용함에 있어 보안의 중요성을 지적하는 것은 정말 중요한 일입니다.
    댓글을 달고자 하는 것은 그 내용이 아니라 글에 나오는 용어 "웹 서비스"에 관한 것입니다.

    일반 사람들은 "웹 서비스"를 그냥 웹에서 이루어지는 서비스로 생걱하나 봅니다.
    그러나 "웹 서비스"는 "룸 서비스"와 같이 이미 국제적으로 정의된 용어로
    위키피디어를 검색해 보면 확인됩니다.
    "Web services are typically application programming interfaces (API) or Web APIs that are accessed via Hypertext Transfer Protocol (HTTP) and executed on a remote system hosting the requested services...."

    요점은 "웹 서비스"는 웹을 통한 컴퓨터간의 소통 수단이지 개인이 웹에서 받는 서비스가 아니라는 접입니다.
    그래서 UDDI, WSDL, WS-*, .. 등 각종 표준을 통해 어마어마한 보안이 유지되고 있습니다.
    현재 REST라든가 여러 이유로 웹 서비스의 정의도 바뀌어 가고 있고,
    향후에는 컴퓨터와 인간을 구별하지 않고 다 포함할지도 모르지만,
    아직은 "웹에서의 서비스"라든가 하여튼 달리 표현하는 것이 오해를 피할 것 같습니다.

    중요한 사항은 아니나 도움이 되고자 댓글을 달아 봤습니다.

  2. 바다란 2010.08.24 10:09 신고  댓글주소  수정/삭제  댓글쓰기

    중요한 말씀 이십니다. 의견 감사 합니다.

    사용자들에게 다가갈 수 있는 용어로 선정을 하다보니 어려움이 있습니다.
    다른 용어를 썼을때는 더 혼선이...

    정확하게는 인터페이스라고 해야 하는데 이걸로는 더 혼선이 있습니다.
    이 영규님의 댓글로 요점을 이해 하시는 분들이 많으셨으면 합니다.

    사용자 관점에서는 웹 서비스라고 봐야 하고 기술적인 관점에서는 웹 인터페이스가 적절 할 것 같은데 그 어느쪽도 양쪽 진영에서는 받아 들이기 어려운 부분이 있습니다. 컬럼이라는 관점에서 대중들에게 인식을 시키기 위한 용도로 사용을 했으니 너른 이해 부탁 드리겠습니다.

    향후에도 관련된 용어를 쓸 일이 있을때는 한번쯤 생각해 보는 계기가 되었네요.
    개인이 받는 서비스라기 보다는 개인의 PC와 서비스 제공 서버간의 웹을 통한 인터페이스 정도로 이해하고 작은 규모의 웹 서비스라고 여겨 주시면 감사 하겠습니다.

  3. 이영규 2010.08.24 15:19  댓글주소  수정/삭제  댓글쓰기

    내용이 중요해서 읽다가 보다 완벽하게 해야 겠다는 의미에서 가벼운 댓글을 달았는데 곧장 응답을 주셨군요.

    사실 용어를 비롯하여 그 어떤 표준도 의미가 없습니다.
    과거에는 몰라도 앞으로는 더욱....
    그 뜻은 용어 정의는 이 순간에 많은 사람들이 공감하고 쓰면 그게 표준이지,
    과거가 어떻고는 참고 사항은 되도 필수 사항은 아니라는 것입니다.
    오히려 과거의 정의가 발전을 저해할 수도 있습니다.

    다만 '웹 서비스'라는 용어는 웹 표준의 무시 못할 기관인 W3C가 표준화하고
    아직도 꼬리를 내리지 않고 권고를 남겨두고 있는 용어라서
    무조건 무시하면 저와 같은 댓글이 달린다는 그런 상황인데
    댓글 단 것 자체는 우리나라 대부분의 댓글이 '잘 봤습니다'수준인 것이 못 마땅해서 해 보자고 한 것이고,
    어느 것이 옳다 그르다 한 것이 아니라
    단지 이런 의견도 있다는 정도이었습니다.

    그리고 W3C는 이미 10년전 상황이라 지금 우리가 무시한다고 문제될 것은 없습니다.
    실제로 많은 곳에서 무시되고 있고요.

    오해를 피하기 위해서 요즘은 '웹 서비스' 보다는 '웹 API'라는 용어도 많이 씁니다.
    관점은 다르지만 웹 API 속에 웹 서비스가 포함되고, 거의 비슷한 용도로 쓸 수 있으니까...

    원래 'Web Service'는 정확한 철자가 'Web Services'로 's'가 붙습니다. [ http://www.w3.org/TR/ws-gloss ]
    우리말에서는 단어에서 단수/복수 구분 변별력이 별로 없지만 영어권에서는 정확히 구분합니다.
    'Contents'는 '목차'이지만 's'를 떼어버린 'Content'는 우리가 잘못 시용하는 '콘텐츠'입니다.
    표준은 'Standards'이고, 바지나 가위도 's'가 붙어야 합니다. 안 붙이면 철자 오류거나 다른 것이지요.
    's'가 붙는 단어는 그 내부가 여러 개 집합이라는 것이지 복수 단어는 아닙니다.

    과거를 아예 모르면 편한데 우리처럼 과거에 집착하는 사람들이 있어서 지장이 많은가 봅니다.
    과거가 옳다거나 회귀, 또는 청산이 아니라, 그런 과거를 지금과 어떻게 조화시키느냐가 관점인데...

  4. 바다란 2010.08.24 18:11 신고  댓글주소  수정/삭제  댓글쓰기

    네 좋은 말씀 감사합니다. 형식에 치우치면 현실이 멀어지고 현실을 따지면 형식이나 지켜 오던 것들이 흔들리고.. 여러모로 어려움이 많습니다.

    과거와 현재의 조화는 지금 있는 사람들의 몫인 것 같습니다.

    앞으로도 좋은 의견이나 조언 해주시면 감사하게 듣도록 하겠습니다.
    저도 고쳐 보도록 노력 하겠습니다. 감사합니다.

  5. 김형채 2010.09.04 15:13  댓글주소  수정/삭제  댓글쓰기

    어제 지인분이 오류를 고쳐달라는 부탁을 해서 오늘 잠깐 시간내서 살펴보니 css파일에서
    문제가 발생한 웹서비스를 살펴보니 http://www.xzjiayuan.com/ad/yahoo.js 파일을 불러들이고 있네요. 호스팅을 받는 계정의 서비스라 해당 파일의 내용을 삭제하는 것 말고는 별다른 조치를 못해주고 정리했습니다.

    이것저것 읽어보다가 이처럼 좋은글을 보게되었네요
    좋은 정보 감사드립니다.

    보안인적자원이 부족하고, 보안의식또한 취약한 상태에서 정말 걱정이 됩니다.
    (사실 이것저것 신경쓰기가 힘듭니다. 중요하지 문제란 없으니까요 ㅎㅎ)

    자주 들러서 좋은이야기 경청하도록 하겠습니다.

  6. 바다란 2010.09.06 10:22 신고  댓글주소  수정/삭제  댓글쓰기

    네. 일반분들이 보시기엔 거의 못 느끼지만 생각보다 더 심각한 상황에 있습니다. 자동화된 도구에 의해서도 자동으로 당하다 보니 심각성은 앞으로 더 크게 나올 것 같습니다.

    근본 문제를 수정해야 하는데 문제가 무엇인지를 모르니 계속 반복되는 상황으로 갈 수 밖에 없습니다.

    이 사이트에 관련된 정보들과 컬럼들을 계속 올릴 예정이니 앞으로도 많은 관심 가져 주세요.
    감사합니다.

안녕하세요. 바다란입니다. 2006년 작성내용입니다.

 

XSS 진단 및 SQL Injection 진단 스크립트를 공개 합니다.

특별한 것은 아니구요.. 지난해에 급하게 작성하여 사용 했던 스크립트이니 참고 하시면 될 것 같습니다.

 

국내에서는 아직도 많은 사이트들이 해킹을 당하고 있는 실정입니다.

지금의 해킹은 페이지 변조가 아닌 내부 침입을 통해 정보를 가져 가거나 악성코드를 심는 형태로 나타나고 있는데 진입점을 막지 못하기 때문에 계속 문제가 될 수 밖에 없습니다.

 

이 스크립트는 완전하지는 않으나 100% 중에서 80% 이상의 문제 발견이 가능하므로 대응에 도움이 될 것입니다. 대기업이나 여력이 있는 기업에서는 상용 스캐너를 통해 문제의 진단 및 수정을 진행 하고 있으나 소규모 사이트들은 그런 여력이 없는 상황입니다.

 

따라서 지난해(2005) 부터 공개를 추진 하였으나 메인 몸이라 힘들었구요.. 1년 이상의 시간이 흘러서 이제는 공개를 해도 되지 않나 하는 생각에 공개 합니다. 허접한 스크립트이고 손을 안 본 상태라 개인 메일 주소만 딸랑 넣어 놨습니다. 

 

실행 시간은 사이트 구조에 따라 오래 걸릴 수 있는데..이럴 경우 1~5Mega 정도의 결과 파일이 생성 되면 Ctrl+c 눌러서 중지 시키고 결과에 나와 있는 문제들을 수정하고 다시 돌리시면 과다한 결과 생성 및 중복 생성 문제가 해결이 됩니다.

 

이름도 감자 입니다. ~~

 

참고하세여.... 국내의 수많은 웹서버들에 도움이 조금 되었으면 합니다.

 

현재 sourceforge에도 project 등록은 되어 있습니다. 향후에는 이쪽에도 일부 업데이트 할 예정입니다.

http://sourceforge.net/projects/gamja

 

Posted by 바다란

댓글을 달아 주세요

안녕하세요. 바다란입니다. -본문서는 2006년 9월에 작성한 내용입니다.

 

지난해에 중국발 해킹 대응 워크샵에서 발표한 자료입니다.

그때 당시에는 문서 공유가 많이 될 줄 알았는데 생각 보다 안되네요.

 

관련 내용중에서 중국발 해킹 내용 부분만 발췌하여 PDF로 컨버젼한 내용입니다.

지금도 여전히 유효한 부분들이여서 부분적으로 참고 하시면 될 것 같습니다.

 

본 블로그에도 올려 놓은 http://blog.naver.com/p4ssion/40015866029 게시물에 게시한 내용과 거의 동일합니다. 사실 지난해에 이런 내용들을 발표하고 난뒤에도 워크샵에만 발표를 하고 할 일을 다 했다는 생각을 가지곤 했습니다.

 

좀 더 적극적으로 하지 않으면 향후에도 여러 위협들이 계속 될 것으로 생각 되어 마인드를 바꾸기로 하였습니다. ^^;

 

SQL Injection 관련 문제 및 [ 각 Web App 스크립트에 모두 문제 있음 ] Validation check 부분이 강화 되어야만 문제가 해결이 됩니다. 흔적들 한번 찾아 보시고 DB 서버에 공격 유사 테이블이 존재 할 경우 Web Application에 대한 코딩 변경 및 탐지 정책들을 변경 하여 적용 하여야 합니다.

 

관련 문서 확인 하시고..최근 들어온 흔적 및 체크 내용등을 주시하여 대책에 도움이 되었으면 합니다. 근 1년 지난 시점에 올리게 되어 죄송 합니다.

 

Posted by 바다란

댓글을 달아 주세요

안녕하세요. 바다란입니다.

 

지난해에 중국발 해킹 대응 워크샵에서 발표한 자료입니다.

그때 당시에는 문서 공유가 많이 될 줄 알았는데 생각 보다 안되네요.

 

관련 내용중에서 중국발 해킹 내용 부분만 발췌하여 PDF로 컨버젼한 내용입니다.

지금도 여전히 유효한 부분들이여서 부분적으로 참고 하시면 될 것 같습니다.

 

본 블로그에도 올려 놓은 http://blog.naver.com/p4ssion/40015866029 게시물에 게시한 내용과 거의 동일합니다. 사실 지난해에 이런 내용들을 발표하고 난뒤에도 워크샵에만 발표를 하고 할 일을 다 했다는 생각을 가지곤 했습니다.

 

좀 더 적극적으로 하지 않으면 향후에도 여러 위협들이 계속 될 것으로 생각 되어 마인드를 바꾸기로 하였습니다. ^^;

 

SQL Injection 관련 문제 및 [ 각 Web App 스크립트에 모두 문제 있음 ] Validation check 부분이 강화 되어야만 문제가 해결이 됩니다. 흔적들 한번 찾아 보시고 DB 서버에 공격 유사 테이블이 존재 할 경우 Web Application에 대한 코딩 변경 및 탐지 정책들을 변경 하여 적용 하여야 합니다.

 

관련 문서 확인 하시고..최근 들어온 흔적 및 체크 내용등을 주시하여 대책에 도움이 되었으면 합니다. 근 1년 지난 시점에 올리게 되어 죄송 합니다.

 

Posted by 바다란

댓글을 달아 주세요