소개

이 문서에서는 Microsoft Source Code Analyzer for SQL Injection 도구에 대해 설명합니다. 이 정적 코드 분석 도구를 사용하여 ASP 코드에서 SQL 삽입 공격 취약점을 찾을 수 있습니다.

위로 가기

추가 정보

Microsoft Source Code Analyzer for SQL Injection 도구는 ASP(Active Server Pages) 코드에서 SQL 삽입 공격 취약점을 찾도록 도와주는 정적 코드 분석 도구입니다. 이 문서에서는 이 도구를 사용하는 방법, 도구에서 생성되는 경고 및 도구의 제한 사항에 대해 설명합니다. 자세한 내용은 도구 추가 정보 문서를 참조하십시오.

위로 가기

전제 조건

이 명령줄 도구를 사용하려면 다음 소프트웨어가 필요합니다.
.NET Framework 3.0

위로 가기

ASP 코드의 SQL 삽입 공격 문제

ASP 코드의 Request.Form 또는 Request.Querystring 컬렉션에서 사용자가 제공한 데이터가 데이터 유효성 검사 없이 동적 SQL 문을 만드는 데 사용되는 경우 공격자가 SQL 명령을 SQL 문에 삽입하고 악용할 수 있습니다. 이를 일반적으로 1차 SQL 삽입 공격 취약점이라고 합니다.

한 ASP 페이지를 사용하여 데이터베이스에 저장된 사용자 입력이 데이터베이스에서 검색된 다음 다른 ASP 페이지에서 동적 SQL 문을 만드는 데 사용되는 경우 공격자가 SQL 명령을 SQL 문에 삽입하고 악용할 수 있습니다. 이를 일반적으로 2차 SQL 삽입 공격 취약점이라고 합니다.

이러한 취약점을 줄이려면 매개 변수가 있는 SQL 쿼리를 사용하는 것이 가장 좋습니다. ASP의 SQL 삽입 공격 취약점과 이러한 취약점을 줄이는 방법에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://msdn.microsoft.com/en-us/library/cc676512.aspx (http://msdn.microsoft.com/en-us/library/cc676512.aspx)(영문)
Microsoft Source Code Analyzer for SQL Injection 도구는 이러한 문제 중 일부를 자동으로 찾는 데 도움이 됩니다.

위로 가기

사용법

이 절에서는 이 도구를 사용하는 방법에 대해 설명합니다.

구문

이 도구는 다음 구문을 사용합니다.
msscasi_asp.exe [/nologo] [/quiet] [/suppress=num;..;num] [/GlobalAsaPath=path] [/IncludePaths=path;..;path] /Input=file.asp

설명

이 도구는 ASP 코드를 분석하여 SQL 삽입 공격 취약점을 찾습니다.

매개 변수 목록

매개 변수 옵션 설명
/GlobalAsaPath 경로 Global.asa 파일의 경로를 표시합니다.
/IncludePaths 경로 가상 경로를 사용하여 포함된 파일을 확인하기 위한 세미콜론으로 구분된 경로를 표시합니다.
/input ASP 파일 분석해야 하는 ASP 파일의 절대 경로를 표시합니다.
/suppress warnings 경고가 보고되지 않습니다.
/nologo 도구 로고가 표시되지 않습니다.
/quiet 구문 분석 오류가 표시되지 않습니다. /nologo/quiet 스위치를 사용하는 경우 경고 메시지만 표시됩니다.

예제
MSSCASI_ASP /input="c:\source\logon.asp"
MSSCASI_ASP /GlobalAsaPath="C:\source" /input="c:\source\webitems\display.asp"
MSSCASI_ASP /GlobalAsaPath="C:\source" /input="c:\source\webitems\display.asp" /IncludePaths="C:\virtualdirectory1;C:\virtualdirectory2"
MSSCASI_ASP /input="c:\source\webitems\display.asp" /suppress="80406;80407"

출력 검토

이 도구는 다음과 같은 경고를 생성합니다.
경고 설명
80400 입력 유효성 검사 없이 Request 개체에서 읽은 데이터를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 이러한 경고는 해결해야 하는 버그일 가능성이 큽니다.
80406 데이터 유효성 검사를 수행할 수 있는 알 수 없는 함수 호출을 통해 입력이 전달되는 Request 개체에서 읽은 데이터를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 이러한 경고는 함수 호출 내에서 데이터 유효성 검사가 수행되지 않으면 버그일 가능성이 크며, 그렇지 않으면 가양성(false positives)입니다.
80403 백 엔드 서버에서 제공되는 데이터를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 최종 사용자가 다른 웹 사이트를 통해 데이터를 제어하는 경우 이러한 경고는 버그일 가능성이 큽니다. 그러나 데이터를 신뢰할 수 있는 경우 이러한 경고는 버그가 아닙니다. 심층 방어(defense-in-depth) 전략의 일환으로 이러한 쿼리를 매개 변수화하는 것이 좋습니다.
80407 백 엔드 서버에서 제공되고 알 수 없는 함수 호출을 통해 전달되는 데이터를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 최종 사용자가 다른 웹 사이트를 통해 데이터를 제어하고 이 데이터에 대한 유효성 검사가 수행되지 않는 경우 이러한 경고는 버그일 가능성이 큽니다.
80420 함수 매개 변수를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 이러한 경고는 함수 범위에서 생성되므로 함수 매개 변수 값이 신뢰할 수 있는 곳에서 제공되는 경우 이러한 경고는 가양성(false positives)입니다. 최종 사용자가 매개 변수 값을 제어하는 경우 이러한 경고는 버그일 가능성이 큽니다. 함수 매개 변수에서 __sql_pre_validated 주석을 사용하여 최종 사용자가 이 코드에 접근할 수 있는지 여부를 확인할 수 있습니다.
80421 데이터 유효성 검사를 수행할 수 있는 알 수 없는 함수 호출을 통해 전달되는 함수 매개 변수를 통해 SQL 삽입 공격 취약점이 생성될 수 있습니다. 함수 매개 변수에서 __sql_pre_validated 주석을 사용하고 유효성 검사 함수에서 __sql_validate 주석을 사용하여 최종 사용자가 이 코드에 접근할 수 있는지 여부를 확인할 수 있습니다.
도구에서 생성되는 모든 경고 중에서 80400 경고가 실제 버그를 나타낼 가능성이 가장 큽니다. ASP 웹 개발자는 매개 변수가 있는 쿼리를 사용하여 이러한 버그를 해결해야 합니다. ASP 코드에서 매개 변수가 있는 SQL 쿼리를 사용하는 방법에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://msdn.microsoft.com/en-us/library/cc676512.aspx (http://msdn.microsoft.com/en-us/library/cc676512.aspx)(영문)

제한 사항

이 도구에는 다음과 같은 알려진 제한 사항이 있습니다.
이 도구는 VBScript로 작성된 ASP 코드만 인식하고 Jscript 등의 다른 언어로 작성된 서버 쪽 코드를 분석하지 않습니다.
새로운 ASP 파서가 이 도구 개발 프로세스의 일환으로 개발되었습니다. 그러나 이 파서는 모든 ASP 구문을 처리하지 못할 수 있으므로 구문 분석 오류가 발생할 수 있습니다.

위로 가기

참조

Microsoft Source Code Analyzer for SQL Injection 도구를 다운로드하려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA (http://www.microsoft.com/downloads/details.aspx?FamilyId=58A7C46E-A599-4FCB-9AB4-A4334146B6BA)(영문)
다양한 모범 사례 설명서에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx (http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx)(영문)
ASP에서 SQL 삽입 공격을 방지하는 방법에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://msdn.microsoft.com/en-us/library/cc676512.aspx (http://msdn.microsoft.com/en-us/library/cc676512.aspx)(영문)
SQL 삽입 공격에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx (http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx)(영문)
이 도구에 대한 자세한 내용은 다음 Microsoft 웹 사이트를 참조하십시오.
http://blogs.msdn.com/sqlsecurity (http://blogs.msdn.com/sqlsecurity)(영문)
MSDN SQL 보안 포럼에서 도구에 대해 논의하려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=92&SiteID=1 (http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=92&SiteID=1)(영문)

Posted by onewater
,

Windows 기능을 사용하여 메모리 덤프 파일을 키보드로 생성할 수 있다.

기술 자료 ID : 244139
마지막 검토 : 2008년 5월 22일 목요일
수정 : 19.7

요약

Windows에는 시스템이 응답하지 않도록 하고 메모리 덤프 파일(Memory.dmp)을 생성하는 데 사용할 수 있는 기능이 포함되어 있습니다. 이렇게 하는 경우 다음과 유사한 중지 오류 메시지가 나타납니다.
*** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000)
The end-user manually generated the crashdump.
이 기능을 사용할 수 있도록 설정한 후에 오른쪽 Ctrl 키를 누른 상태에서 Scroll Lock 키를 차례로 두 번 눌러 메모리 덤프 파일을 생성할 수 있습니다. 이 기능은 PS/2 및 USB(범용 직렬 버스) 키보드에서 모두 사용할 수 있습니다. PS/2 키보드는 키보드에 포함된 i8042prt.sys 드라이버를 사용합니다. 그러나 USB 키보드의 경우 Kbdhid.sys 드라이버용 핫픽스를 설치해야 합니다. 이 핫픽스에 대한 자세한 내용은 "추가 정보" 절 끝에 있는 "Windows Server 2003 해결 방법" 하위 절을 참조하십시오.

참고 USB 키보드를 사용하여 메모리 덤프 프로세스를 생성할 수 있도록 하는 Kbdhid.sys 드라이버에는 제한이 있습니다. 컴퓨터가 높은 IRQL(인터럽트 요청 수준)에서 응답하지 않으면 Ctrl+Scroll Lock+Scroll Lock 바로 가기 키가 작동하지 않습니다. 이러한 제한은 Kbdhid.sys 드라이버가 i8042prt.sys 드라이버보다 낮은 IRQL에서 작동하기 때문에 존재합니다. USB 키보드 기능은 Microsoft Windows Server 2003을 실행하는 컴퓨터에서만 작동합니다.

위로 가기

추가 정보

중요 이 절, 방법 또는 작업에는 레지스트리를 수정하는 방법에 대한 단계가 포함되어 있습니다. 그러나 레지스트리를 잘못 수정하면 심각한 문제가 발생할 수도 있으므로 다음 단계를 주의하여 수행해야 합니다. 추가 보호 조치로 레지스트리를 수정하기 전에 해당 레지스트리를 백업하는 것이 좋습니다. 이렇게 하면 문제가 발생하는 경우 레지스트리를 복원할 수 있습니다. 레지스트리 백업 및 복원 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
322756 (http://support.microsoft.com/kb/322756/) Windows XP 및 Windows Server 2003에서 레지스트리를 백업, 편집 및 복원하는 방법


기본적으로 이 기능은 사용할 수 없도록 설정되어 있습니다. PS/2 키보드를 사용하는 컴퓨터에서 이 기능을 사용할 수 있도록 설정하려면 이 문서에 나와 있는 대로 레지스트리를 수정한 다음 컴퓨터를 다시 시작해야 합니다. 컴퓨터를 다시 시작한 후에 Ctrl 키를 누른 상태에서 Scroll Lock 키를 차례로 두 번 눌러 Memory.dmp 파일을 생성할 수 있습니다. 스페이스바 키 오른쪽에 있는 Ctrl 키를 사용해야 합니다. USB 키보드를 사용하는 컴퓨터에서는 컴퓨터를 다시 시작할 필요가 없으며 키보드를 분리하고 다시 연결하기만 하면 됩니다. 그런 다음 Memory.dmp 파일을 생성할 수 있습니다.

PS/2 키보드를 사용하는 컴퓨터에서 이 기능을 사용할 수 있도록 설정하려면 다음과 같이 하십시오.
1. 레지스트리 편집기를 시작합니다.
2. 다음 레지스트리 하위 키를 찾습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
3. 편집 메뉴에서 값 추가를 누르고 아래와 같은 레지스트리 항목을 추가합니다.
이름: CrashOnCtrlScroll
데이터 형식: REG_DWORD
: 1
4. 레지스트리 편집기를 종료한 다음 컴퓨터를 다시 시작합니다.
USB 키보드를 사용하는 컴퓨터에서 이 기능을 사용할 수 있도록 설정하려면 "추가 정보" 절 끝에 있는 "Windows Server 2003 해결 방법" 하위 절에 나와 있는 핫픽스를 설치합니다.

USB 키보드를 사용하는 컴퓨터에서 이 기능이 사용할 수 있도록 설정되어 있는지 확인하려면 다음과 같이 하십시오.
1. 레지스트리 편집기를 시작합니다.
2. 다음 레지스트리 하위 키를 찾습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters
3. 다음 레지스트리 항목이 사용할 수 있도록 설정되어 있는지 확인합니다.
이름: CrashOnCtrlScroll
데이터 형식: REG_DWORD
: 1
4. 레지스트리 편집기를 종료합니다.

위로 가기

메모리 덤프 파일 옵션을 선택하는 방법

세 가지 메모리 덤프 파일을 생성할 수 있습니다. 덤프 파일을 수동으로 트리거하기 전에 하나를 선택합니다. 이렇게 하려면 다음과 같이 하십시오.
1. 내 컴퓨터를 마우스 오른쪽 단추로 누른 다음 속성을 누릅니다.
2. 고급 탭을 누른 다음 시작 및 복구 단추를 누릅니다.
3. 디버깅 정보 쓰기를 누른 다음 전체 메모리 덤프, 커널 메모리 덤프 또는 작은 메모리 덤프 중에서 선택합니다.
메모리 덤프 파일 옵션에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
254649 (http://support.microsoft.com/kb/254649/) Windows Server 2003, Windows XP 및 Windows 2000의 메모리 덤프 파일 옵션에 대한 개요
참고 서버에 일부 Compaq 컴퓨터에 있는 ASR(Automatic System Restart) 기능과 같은 기능이 있으면 해당 기능을 사용할 수 없도록 설정하십시오. 이 기능 때문에 덤프 프로세스가 중단될 수 있습니다. Compaq 컴퓨터에서는 BIOS(기본 입출력 시스템) 설정을 수정하여 ASR 기능을 사용할 수 없도록 설정할 수 있습니다.

참고 RAM이 2GB 이상인 컴퓨터에서는 전체 메모리 덤프를 사용하지 못할 수 있습니다. Windows 2000에서 액세스할 수 있는 메모리를 제한하려면 <MaxMem=2000> 매개 변수를 Boot.ini 파일에 추가하십시오.

Microsoft 기술 자료의 835732 문서에 설명되어 있는 보안 업데이트를 설치했거나 이 보안 업데이트가 포함된 서비스 팩을 설치한 경우 다음 Microsoft 기술 자료 문서를 참조하십시오.
885117 (http://support.microsoft.com/kb/885117/) Windows 2000 또는 Windows Server 2003에서 "커널 메모리 덤프"가 시작 및 복구에 표시되지만 전체 메모리 덤프가 수행된다
자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
835732 (http://support.microsoft.com/kb/835732/) MS04-011: Microsoft Windows용 보안 업데이트

위로 가기

서비스 팩 정보

이 문제를 해결하려면 Windows Server 2003용 최신 서비스 팩을 구하십시오. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
889100 (http://support.microsoft.com/kb/889100/) Windows Server 2003용 최신 서비스 팩을 구하는 방법

위로 가기

핫픽스 정보

지원되는 핫픽스를 Microsoft에서 구할 수 있지만 이 문서에서 설명하는 문제를 해결하기 위한 것일 뿐이므로 이러한 특정 문제가 발생하는 시스템에만 이 핫픽스를 적용하십시오. 이 핫픽스는 나중에 추가 테스트를 받아야 할 수도 있습니다. 따라서 이 문제의 영향이 심각한 경우가 아니면 이 핫픽스가 포함된 다음 소프트웨어 업데이트가 나올 때까지 기다리는 것이 좋습니다.

핫픽스를 다운로드할 수 있는 경우에는 이 기술 자료 문서의 맨 위에 "핫픽스 다운로드 가능" 절이 있습니다. 이 절이 나타나지 않으면 Microsoft 온라인 고객 서비스에 요청을 제출하여 핫픽스를 구하십시오. 핫픽스를 구하기 위한 온라인 요청을 제출하려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://go.microsoft.com/?linkid=6294451 (http://go.microsoft.com/?linkid=6294451)
참고 문제가 추가로 발생하거나 문제 해결이 필요한 경우 별도의 서비스 요청을 해야 할 수도 있습니다. 이 특정 핫픽스로 해결할 수 없는 추가 질문과 문제에 대해서는 지원 비용이 청구됩니다. 별도의 서비스 요청을 하려면 다음 Microsoft 웹 사이트를 방문하십시오.
기술지원 서비스 안내 (http://support.microsoft.com/default.aspx?scid=fh;ko;serviceoverview)
참고 "핫픽스 다운로드 가능" 절과 온라인 요청 양식에는 사용 가능한 핫픽스의 언어가 표시됩니다. 원하는 언어가 표시되지 않으면 해당 언어의 핫픽스를 사용할 수 없습니다.

전제 조건

이 핫픽스를 적용하려면 컴퓨터에 Windows Server 2003 또는 Windows Server 2003 서비스 팩 1이 설치되어 있어야 합니다.

다시 시작 요구 사항

이 핫픽스를 적용한 후에는 컴퓨터를 다시 시작해야 합니다.

핫픽스 대체 정보

이 핫픽스는 다른 핫픽스를 대체하지 않습니다.

파일 정보

이 핫픽스의 영어 버전은 아래와 같거나 그 이상의 파일 특성을 갖습니다. 이 파일의 날짜와 시간은 UTC(Coordinated Universal Time)로 나열되며 파일 정보를 볼 때 로컬 시간으로 변환됩니다. UTC와 로컬 시간의 차이를 보려면 제어판날짜 및 시간 도구에서 표준 시간대 탭을 사용하십시오.
Windows Server 2003 32비트(x86 기반) 버전
파일 이름 파일 버전 파일 크기 날짜 시간 플랫폼 SP 요구 사항 서비스 분기
Kbdhid.sys 5.2.3790.493 16,896 2006-02-28 00:03 x86 없음 RTMQFE
Kbdhid.sys 5.2.3790.2649 17,408 2006-02-28 03:11 x86 SP1 SP1QFE
Windows Server 2003 x64 기반 버전
파일 이름 파일 버전 파일 크기 날짜 시간 플랫폼
Kbdhid.sys 5.2.3790.2649 24,576 2006-04-13 15:59 x64
Windows Server 2003 Itanium 기반 버전
파일 이름 파일 버전 파일 크기 날짜 시간 플랫폼 SP 요구 사항 서비스 분기
Kbdhid.sys 5.2.3790.493 47,104 2006-04-13 15:54 IA-64 없음 RTMQFE
Kbdhid.sys 5.2.3790.2649 49,664 2006-04-13 15:59 IA-64 SP1 SP1QFE
자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
928839 (http://support.microsoft.com/kb/928839/) Virtual Server 2005 게스트 컴퓨터에서 키보드를 사용하여 메모리 덤프 파일을 생성하는 방법

위로 가기

메모리 덤프 파일을 생성하도록 키 구성

메모리 덤프 파일을 생성하도록 다음 레지스트리 하위 키에서 항목을 구성할 수 있습니다.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\crashdump
REG_DWORD 항목은 다음과 같습니다.
Dump1Keys
Dump2Key
Dump1Keys 항목은 사용할 보조 키의 비트맵입니다. 값은 다음과 같습니다.
#define CRASH_R_SHIFT 0x01
#define CRASH_R_CTRL 0x02
#define CRASH_R_ALT 0x04
#define CRASH_L_SHIFT 0x10
#define CRASH_L_CTRL 0x20
#define CRASH_L_ALT 0x40
Dump2Key 항목은 키보드 레이아웃에 대한 스캔 코드 테이블의 인덱스입니다. 드라이버의 실제 테이블은 다음과 같습니다.

참고 84키 키보드의 스캔 코드는 다르기 때문에 인덱스 124(sysreq)는 특수한 경우입니다.
const UCHAR keyToScanTbl[134] = { 

        0x00,0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,

        0x0A,0x0B,0x0C,0x0D,0x7D,0x0E,0x0F,0x10,0x11,0x12,

        0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x00,

        0x3A,0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,

        0x27,0x28,0x2B,0x1C,0x2A,0x00,0x2C,0x2D,0x2E,0x2F,

        0x30,0x31,0x32,0x33,0x34,0x35,0x73,0x36,0x1D,0x00,

        0x38,0x39,0xB8,0x00,0x9D,0x00,0x00,0x00,0x00,0x00,

        0x00,0x00,0x00,0x00,0x00,0xD2,0xD3,0x00,0x00,0xCB,

        0xC7,0xCF,0x00,0xC8,0xD0,0xC9,0xD1,0x00,0x00,0xCD,

        0x45,0x47,0x4B,0x4F,0x00,0xB5,0x48,0x4C,0x50,0x52,

        0x37,0x49,0x4D,0x51,0x53,0x4A,0x4E,0x00,0x9C,0x00,

        0x01,0x00,0x3B,0x3C,0x3D,0x3E,0x3F,0x40,0x41,0x42,

        0x43,0x44,0x57,0x58,0x00,0x46,0x00,0x00,0x00,0x00,

        0x00,0x7B,0x79,0x70 };
이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이러한 제품의 성능이나 신뢰성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.

출처: http://support.microsoft.com/kb/244139/ko/

Posted by onewater
,

Windows Server 2003, Windows XP 및 Windows 2000의 메모리 덤프 파일 옵션에 대한 개요

기술 자료 ID : 254649
마지막 검토 : 2008년 1월 4일 금요일
수정 : 12.3

요약

중지 오류("블루 스크린", 시스템 충돌 또는 버그 확인이라고도 함)가 발생하여 컴퓨터가 예기치 않게 중지되면 세 가지 파일 형식("메모리 덤프" 파일이라고도 함)에 디버깅 정보를 기록하도록 Microsoft Windows Server 2003, Microsoft Windows XP 및 Microsoft Windows 2000을 구성할 수 있습니다. 또한 메모리 덤프 파일에 디버깅 정보를 기록하지 않도록 Windows를 구성할 수도 있습니다. Windows는 다음 세 가지 메모리 덤프 파일 형식 중 하나를 생성할 수 있습니다.
전체 메모리 덤프
커널 메모리 덤프
작은 메모리 덤프(64KB)

위로 가기

추가 정보

전체 메모리 덤프

전체 메모리 덤프는 컴퓨터가 예기치 않게 중지될 때 시스템 메모리의 모든 내용을 기록합니다. 전체 메모리 덤프 옵션을 선택하는 경우 모든 실제 RAM 크기에 1MB를 더한 크기의 페이징 파일이 부팅 볼륨에 있어야 합니다. 기본적으로 전체 메모리 덤프 파일은 %SystemRoot%\Memory.dmp 파일에 기록됩니다.

두 번째 문제가 발생하고 다른 전체 메모리 덤프(또는 커널 메모리 덤프) 파일이 만들어지면 이전 파일을 덮어쓰게 됩니다.

참고 전체 메모리 덤프 옵션은 32비트 운영 체제를 실행하고 있고 2GB 이상의 RAM이 설치된 컴퓨터에서는 사용할 수 없습니다. 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
274598 (http://support.microsoft.com/kb/274598/) Windows 2000은 2GB와 4GB 사이의 메모리를 완전히 덤프할 수 없다

위로 가기

커널 메모리 덤프

커널 메모리 덤프는 커널 메모리만 기록합니다. 컴퓨터가 예기치 않게 중지될 때 로그에 정보를 기록하는 프로세스의 속도가 향상됩니다. 컴퓨터의 RAM에 따라 서버 부하를 기준으로 사용 가능한 페이징 파일 공간이 150MB에서 2GB까지 필요하고 부팅 볼륨에 페이징 파일 공간으로 사용할 수 있는 크기의 실제 RAM이 있어야 합니다.

이 덤프 파일은 할당되지 않은 메모리나 사용자 모드 프로그램에 할당된 메모리는 포함하지 않습니다. 여기에는 Windows 2000 이상에서 커널과 HAL(하드웨어 추상화 계층)에 할당된 메모리와 커널 모드 드라이버 및 기타 커널 모드 프로그램에 할당된 메모리만 포함됩니다. 대개의 경우 이 덤프 파일이 가장 유용합니다. 이 파일은 전체 메모리 덤프보다 상당히 작지만 문제와 관련이 없는 메모리 부분만 생략됩니다. 기본적으로 커널 메모리 덤프 파일은 %SystemRoot%\Memory.dmp 파일에 기록됩니다.

두 번째 문제가 발생하고 다른 커널 메모리 덤프 파일(또는 전체 메모리 덤프 파일)이 만들어지면 이전 파일을 덮어쓰게 됩니다.

위로 가기

작은 메모리 덤프

작은 메모리 덤프는 컴퓨터가 예기치 않게 중지된 이유를 확인할 수 있는 최소한의 유용한 정보를 기록합니다. 이 옵션을 사용하려면 부팅 볼륨에 2MB 이상의 페이징 파일이 있어야 하며 Windows 2000 이상에서 컴퓨터가 예기치 않게 중지될 때마다 새 파일을 만들도록 지정합니다. 이러한 파일의 기록은 폴더에 저장됩니다.

이 덤프 파일 유형은 다음 정보를 포함합니다.
중지 메시지와 매개 변수 및 기타 데이터
로드된 드라이버 목록
중지된 프로세서에 대한 프로세서 컨텍스트(PRCB)
중지된 프로세스에 대한 프로세스 정보 및 커널 컨텍스트(EPROCESS)
중지된 스레드에 대한 프로세스 정보 및 커널 컨텍스트(ETHREAD)
중지된 스레드에 대한 커널 모드 호출 스택
이런 유형의 덤프 파일은 공간이 제한되어 있을 때 유용할 수 있습니다. 그러나 포함된 정보가 제한되어 있기 때문에 문제가 발생했을 때 실행 중인 스레드가 직접적인 원인이 아닌 오류는 이 파일을 분석하여 발견할 수 없습니다.

두 번째 문제가 발생하고 두 번째 작은 메모리 덤프 파일이 만들어지는 경우에도 이전 파일은 보존됩니다. 각 추가 파일에는 고유한 이름이 지정됩니다. 데이터가 파일 이름으로 인코딩되어 표시됩니다. 예를 들어, Mini022900-01.dmp는 2000년 2월 29일에 생성된 첫 번째 메모리 덤프입니다. 모든 작은 메모리 덤프 파일 목록은 %SystemRoot%\Minidump 폴더에 저장됩니다.

위로 가기

덤프 유형 구성

시작 및 복구 옵션(덤프 유형 포함)을 구성하려면 다음과 같이 하십시오.

참고 Microsoft Windows 버전이 다양하므로 사용하는 컴퓨터에 따라 아래 단계가 다를 수도 있습니다. 이러한 경우에는 해당 제품 설명서를 참조하여 아래 절차를 완료하십시오.
1. 시작을 누르고 설정을 가리킨 다음 제어판을 누릅니다.
2. 시스템을 두 번 누릅니다.
3. 고급 탭에서 시작 및 복구를 누릅니다.

위로 가기

다양한 덤프 유형에 사용하는 도구

표준 기호 디버거(예: I386kd.exe)를 사용하여 전체 메모리 덤프와 커널 메모리 덤프를 로드할 수 있습니다. I386kd.exe는 Windows 2000 CD-ROM의 지원 도구에 포함되어 있습니다.

Dumpchk.exe를 사용하여 작은 메모리 덤프를 로드합니다. Dumpchk.exe는 Windows 2000 및 Windows XP용 지원 도구에 포함되어 있습니다. Dumpchk.exe를 사용하여 메모리 덤프 파일이 올바르게 만들어졌는지 확인할 수도 있습니다. Windows XP에서 Dumpchk.exe를 사용하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
315271 (http://support.microsoft.com/kb/315271/) Dumpchk.exe를 사용하여 메모리 덤프 파일을 검사하는 방법
Windows 2000에서 Dumpchk.exe를 사용하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
156280 (http://support.microsoft.com/kb/156280/) Dumpchk.exe를 사용하여 메모리 덤프 파일을 검사하는 방법
Windows 디버깅 도구에 대한 자세한 내용을 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)(영문)

위로 가기

정의

부팅 볼륨: 이 볼륨에는 Windows 운영 체제 및 지원 파일이 포함되어 있습니다. 부팅 볼륨은 시스템 볼륨과 같을 수 있지만 반드시 같아야 할 필요는 없습니다.
시스템 볼륨: Windows를 로드하려면 있어야 하는 하드웨어 관련 파일이 들어 있는 볼륨입니다. 시스템 볼륨은 부팅 볼륨과 같을 수 있지만 반드시 같아야 할 필요는 없습니다. Boot.ini, Ntdetect.com 및 Ntbootdd.sys 파일은 시스템 볼륨에 있는 파일의 예입니다.

위로 가기

시작 및 복구를 위한 레지스트리 값

다음 레지스트리 값이 사용됩니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl

CrashDumpEnabled REG_DWORD 0x0 = 없음
CrashDumpEnabled REG_DWORD 0x1 = 전체 메모리 덤프
CrashDumpEnabled REG_DWORD 0x2 = 커널 메모리 덤프
CrashDumpEnabled REG_DWORD 0x3 = 작은 메모리 덤프(64KB)
CrashControl의 추가 레지스트리 값:
0x0 = 사용 안 함
0x1 = 사용

AutoReboot REG_DWORD 0x1
DumpFile REG_EXPAND_SZ %SystemRoot%\Memory.dmp
LogEvent REG_DWORD 0x1
MinidumpDir REG_EXPAND_SZ %SystemRoot%\Minidump
Overwrite REG_DWORD 0x1
SendAlert REG_DWORD 0x1

위로 가기

덤프 파일을 만들 수 있도록 테스트

테스트 목적으로 덤프 파일을 생성하도록 컴퓨터를 구성하는 방법에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
244139 (http://support.microsoft.com/kb/244139/) Windows 기능을 사용하여 메모리 덤프 파일을 키보드로 생성할 수 있다

위로 가기

기본 덤프 유형 옵션

Windows 2000 Professional: 작은 메모리 덤프(64KB)
Windows 2000 Server: 전체 메모리 덤프
Windows 2000 Advanced Server: 전체 메모리 덤프
Windows XP(Professional 및 Home Edition): 작은 메모리 덤프(64KB)
Windows Server 2003(모든 버전): 전체 메모리 덤프

위로 가기

최대 페이징 파일 크기

최대 페이징 파일 크기에 대한 제한은 다음과 같습니다.
x86 x64 IA-64
최대 페이징 파일 크기 4GB 16테라바이트 32테라바이트
최대 페이징 파일 수 16 16 16
총 페이징 파일 크기 64GB 256테라바이트 512테라바이트
참고 x86 기반 프로세서에 대해 PAE(실제 주소 확장) 옵션을 사용하도록 설정한 경우 페이징 파일 크기를 최대 16테라바이트로 설정할 수 있지만 설치된 실제 메모리의 1.5배로 설정하는 것이 좋습니다.

위로 가기

Microsoft Windows의 x64 기반 버전에 대한 기술 지원

하드웨어 제조업체는 Windows의 x64 기반 버전에 대한 기술 지원을 제공합니다. 하드웨어에 Windows의 x64 기반 버전이 포함되어 있기 때문에 지원하는 것입니다. 하드웨어 제조업체에서 고유 구성 요소를 사용하여 Windows의 설치를 사용자 지정했을 수도 있습니다. 고유 구성 요소로는 하드웨어 성능을 최대화하기 위한 옵션 설정이나 특정 장치 드라이버 등이 있을 수 있습니다. Microsoft는 Windows의 x64 기반 버전에 대한 기술적인 도움이 필요할 때 이를 지원하기 위해 합당한 노력을 기울일 것입니다. 그러나 하드웨어에 설치된 소프트웨어를 지원하는 데는 제조업체가 가장 적합하므로 제조업체에 직접 문의하는 것이 좋습니다.

Microsoft Windows XP Professional x64 Edition에 대한 제품 정보를 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://www.microsoft.com/korea/windowsxp/64bit/default.mspx (http://www.microsoft.com/korea/windowsxp/64bit/default.mspx)
Microsoft Windows Server 2003의 x64 기반 버전에 대한 제품 정보를 보려면 다음 Microsoft 웹 사이트를 방문하십시오.
http://www.microsoft.com/korea/windowsserver2003/64bit/x64/default.mspx


출처: http://support.microsoft.com/kb/254649/ko
Posted by onewater
,
최근 국내에 널리 유포되어 있는 것으로 확인된 오픈프락시에 대한 감염여부 확인 및 제거방법입니다.

동 오픈프락시에 감염된 PC는 시스템 시작시 자동으로 TCP 포트(8080/4769)를 통해 오픈프락시 서비스를 시작하므로, 스팸발송 등을 목적으로 한 악성행위에 이용되어 시스템과 네트워크의 불안정 및 속도저하를 유발하게 됩니다.

첨부파일의 설명내용을 참고하여 시스템의 감염여부를 확인한 후 설치되어 있는 오픈프락시를 제거하시기 바랍니다.

출처: 한국정보보호 진흥원 스팸대응팀  김혁준
Posted by onewater
,
블루 스크린은 범인을 알고 있다?

박상옥|마이크로소프트웨어

“서버가 수시로 재부팅되더니 갑자기 다운됐어요!” 다급하게 도움을 요청해 보지만 이내 익숙한(?) 블루 스크린이 나타난다. 시스템 관리자의 가장 큰 골칫거리 가운데 하나인 블루 스크린. 시스템 관리자들은 아무런 이유 없이 수시로 재부팅되는 시스템 앞에서 가슴이 답답해진다. 그러나 수만 가지 가능성 가운데 정확한 원인을 잡아내는 것은 유능한 어드민의 필수조건! 이제 논리적으로 원인을 분석해 해결 방안을 찾는데 한 발 더 다가가보자.

블루 스크린(BSOD, Blue Screen of Death)은 시스템 관리자들의 가장 논쟁적인 테마 가운데 하나다. 원인도 증상도 너무 다양하기 때문이다. 여기서는 블루 스크린의 발생 원인을 이론적으로 살펴보는 대신 IT 관리자들이 실무에서 자주 접하는 상황을 중심으로 이에 대한 대응법을 살펴본다. 블루 스크린에 대한 이론적인 내용은 마이크로소프트(이하 MS)의 관련 웹 페이지(support.microsoft.com/default.aspx?scid=kb;KO;129845)를 참고하기 바란다.
일반적으로 블루 스크린(STOP 에러)이 나타나는 이유는 다음과 같다.

- 잘못되었거나 호환되지 않는 서비스, 응용 프로그램, 장치 드라이버
- 하드웨어 문제
- 디스크 또는 파일 시스템 손상
- 오래되었거나 호환되지 않는 펌웨어 또는 BIOS
- 바이러스

서버가 수시로 재부팅된다면 시스템 관리자는 가장 먼저 메모리 덤프가 기록되었는지 확인하자. 일반적인 시스템은 하드웨어 또는 소프트웨어의 문제가 발생하면 이를 자동으로 감지해 블루 스크린 화면을 띄운 뒤 메모리 덤프 파일을 자동으로 생성한다. 서버가 재부팅되면 <화면 1>과 같이 이벤트 등록 정보를 살펴보자. 버튼으로 정보를 수신할 수 있으며, 기본 파일명은 ‘%SystemRoot%\MEMORY.DMP’이다.

<화면 1> 이벤트 뷰어의 메모리 덤프 정보



윈도우 2000 이상의 운영체제에서 메모리 덤프는 ‘전체 메모리 덤프’, ‘작은 메모리 덤프’, ‘커널 메모리 덤프’ 등 세 가지다. 작은 메모리 덤프는 64KB 크기로 덤프 파일이 생성되며, 크래시에 관한 정보를 거의 얻을 수 없다. 커널 메모리 덤프는 작은 메모리 덤프의 내용을 모두 포함하며, 문제 발생 시점에서 커널 모드 메모리에 로드된 모든 내용을 확인할 수 있다. 그러나 정확하게 문제의 원인을 파악하기 위해서는 전체 메모리 덤프를 사용해야 한다. 전체 메모리 덤프는 시스템에 할당된 물리적인 메모리 크기만큼 덤프 파일이 생성된다.

어떤 메모리 덤프를 사용할 것인가 하는 것은 시스템의 시작 및 복구 옵션에서 설정할 수 있다(<화면 2>). 주의할 것은 전체 메모리 덤프를 설정하면 덤프 파일이 설정된 디스크의 남은 공간이 물리적인 메모리 크기보다 많이 남아 있어야 한다는 점이다.

<화면 2> 디버깅 정보 쓰기 옵션


파일 시스템 오류로 인한 블루 스크린 해결법

<화면 3>은 전형적인 블루 스크린이다. 다음과 같은 에러 메시지가 출력되면서 바이러스와 파일 시스템을 체크하라는 메시지가 나타나면, 디스크 또는 파일시스템의 오류로 인한 부팅 실패일 가능성이 높다.

STOP: 0x0000007B : Bug Check Code
(parameter1, parameter2, parameter3, parameter4)

이럴 때는 먼저 운영체제 CD로 재부팅한 후 복구 콘솔로 들어가 ‘chkdsk /f /r’ 명령으로 체크 디스크를 실행하면 정상적으로 부팅할 수 있다. 해당 하드디스크를 정상적인 시스템에 슬레이브(Slave) 하드디스크로 연결한 후 chkdsk를 실행하거나 바이러스 체크를 하는 방법도 있다.

<화면 3> 블루 스크린



때로는 시스템 부팅시 로드되는 시스템 파일이 손상되거나 해킹으로 인해 파일이 삭제돼 블루 스크린이 나타나는 경우도 있다.

Bug Check 0x6F: SESSION3_INITIALIZATION_FAILED
(parameter1, parameter2, parameter3, parameter4)

실제로 필자는 해킹을 당해 시스템 세션 매니저 파일인 smss.exe 파일이 삭제돼 부팅이 되지 않는 사례가 있었는데, 이 때는 정상적인 시스템의 smss.exe 파일을 손상된 시스템의 System32 폴더 하위에 복사해 해결할 수 있었다.

덤프 파일을 ‘제대로’ 읽자

블루 스크린이 나타난 후 정상적으로 시스템이 부팅되고 Memory.DMP 파일이 생성됐다면 이제 해당 덤프파일을 근거로 문제의 원인을 파악해야 한다. 보통 이런 증상의 원인은 잘못되었거나 호환되지 않는 서비스나 응용 프로그램, 장치 드라이버나 하드웨어의 문제 등을 의심할 수 있다. 이제 덤프 파일을 분석해 원인을 파악해야 하는데 어디서부터 어떻게 시작해야 할까.

해법은 의외로 가까운 곳에 있다. 가지고 있는 윈도우 CD에서 SUPPORT 폴더를 검색해보자. 하위에 SUPTOOLS.MSI라는 윈도우 서포트 툴이 있는데 이를 설치하면 DumpChk.exe 프로그램을 사용할 수 있다. 이는 덤프 파일을 분석하는 툴로, 간단한 조작만으로도 덤프의 기본 정보를 얻을 수 있다.

<화면 4> dumpchk를 이용한 덤프 파일 분석




그러나 더 세밀한 분석을 위해서는 윈도우 디버깅 툴을 사용해야 한다. 설치된 운영체제의 i386 폴더(즉 OS CD의 I386) 파일과 Symbols 파일, 디버깅 툴, Memory.dmp 파일 등이 필요한데, MS 웹 사이트(www.microsoft.com/whdc/devtools/debugging/default.mspx)에서 관련 정보를 얻을 수 있다. 여기서 Install Debugging Tools for Windows 32-bit Version 메뉴와 Download Windows Symbol Packages 메뉴를 통해 디버깅 툴과 Symbol 파일을 다운로드할 수 있다. 이제 해당 파일을 차례로 서버에 설치하면 Crash Dump 파일을 분석할 준비를 마친 것이다. 설치를 마치면 명령 프롬프트에 다음과 같이 입력해 디버깅을 한다.

C:\Program Files\Debugging Tools for Windows> windbg -y SymbolPath -i ImagePath -z DumpFilePath
C:\Program Files\Debugging Tools for Windows> kd -y SymbolPath -i ImagePath -z DumpFilePath

이렇게 하면 Windbg는 GUI(Graphical User Interface)로 결과를 출력하며, KD는 커맨드 라인(Command Line)에서 결과를 보여준다.

C:\Program Files\Debugging Tools for Windows> windbg -y SRV*c:\winnt\symbols*http://msdl.microsoft.com/download/symbols -i d:\i386 -z d:\dump\Memory.DMP

C:\Program Files\Debugging Tools for Windows> kd -y SRV*c:\winnt\symbols*http://msdl.microsoft.com/download/symbols -i d:\i386 -z d:\dump\Memory.DMP

덤프 파일을 실제 디버깅한 결과는 ‘이달의 디스켓’으로 제공한다. 특히 주목해야 할 부분은 Probably caused by : v3engine.sys (v3engine+14fc) 부분이다. 이는 V3 백신의 드라이버 파일로, 해당 프로그램으로 인해 블루 스크린이 나타난 것임을 알 수 있다. 이 사례에서는 V3 백신 프로그램 제거해 시스템을 정상적으로 구동할 수 있었다. 이밖에 kd> 프롬프트 상태에서 확인할 수 있는 옵션 명령어는 매우 다양하다. 자세한 내용은 디버깅 도움말에서 확인하기 바란다.

한편 블루 스크린의 하드웨어적인 문제는 그 원인을 찾기가 더욱 어렵다. IBM, hp, 델 등 주요 벤더 제품이라면 업체가 제공하는 하드웨어 진단 툴을 이용하면 된다. 한 가지 주의할 것은 BIOS나 펌웨어의 버전이 낮을 경우 진단 툴로 문제를 인식하지 못하는 경우가 흔하니 반드시 이를 업그레이드한 후 점검하기 바란다. 점검 결과 하드웨어의 문제로 판명나면 해당 업체에 A/S를 의뢰하자.

지금까지 덤프 파일을 분석하는 방법을 살펴봤다. 시스템 어드민에게 있어 블루 스크린처럼 보기 싫은 것도 없다. 그러나 영화 ‘공공의 적’에서 나온 대사처럼 ‘현장은 범인을 알고 있다’. 윈도우 서버 시스템의 문제는 블루 스크린과 덤프 파일에 모든 증거가 담겨 있으므로 자신있게 다가서자.

디버깅 툴의 보너스 툴

앞서 언급한 윈도우용 디버깅 툴을 서버에 설치하면 응용 프로그램을 디버깅할 수도 있다. 실제로 현업의 시스템관리자들은 IIS(Internet Information Server)의 문제를 호소하는 경우가 많은데, 대표적인 증상이 IIS에서 구동되는 주 스크립트인 ASP 페이지가 제대로 작동하지 않는 것이다. 즉 html과 같은 정적인 페이지는 정상적으로 로딩되지만 ASP 동적 스크립트는 많은 사용자가 동시에 접속하면 응답이 없거나 사이트가 느려지는 것이다.

대부분 IIS에서 ASP 문제는 잘못된 스크립트 코드에서 시작된다. 이럴 때 어디서부터 손을 대야할 지 막막한 상황이라면 앞서 언급한 디버깅 툴로 IIS에 대한 덤프를 만들어 보자. 해당 툴이 설치된 폴더 하위에 보면 ADplus.VBS란 파일이 있는데, 이를 이용하면 현재 IIS의 문제에 대한 덤프 파일을 만들 수 있다.

C:\Program Files\Debugging Tools for Windows>cscript adplus.vbs -crash -iis
C:\Program Files\Debugging Tools for Windows>cscript adplus.vbs -hang -iis

해당 덤프 파일이 생성되면 블루 스크린의 메모리 덤프를 디버깅한 것처럼 IIS의 덤프 파일을 디버깅해 문제의 원인을 찾는 힌트를 얻을 수 있다. 덤프 파일은 디버깅 툴의 기본 폴더인 C:\Program Files\Debugging Tools for Windows 하위에 생성된다. 이와 관련된 기술 정보는 MS 웹 페이지(support.microsoft.com/default.aspx?scid=kb;kr;286350)를 참고하기 바란다.

제공 : DB포탈사이트 DBguide.net
Posted by onewater
,

http://cafe.naver.com/sqlmaster.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=1755

인젝션공격 으로 인해서 모든 테이블에 아래와 같은 스크립트들이 입력되어 있는 경우가 있습니다.
전체테이블들의 스크립트를 삭제하는 커서를  만들었습니다.

-- 스크립트의
--<script src=http://www.encode72.com/b.js></script>
--<script src=http://www.win496.com/b.js></script>
--<script src=http://www.sslput4.com/b.js></script>
--<script src=http://www.rundll841.com/b.js></script>
--<script src=http://www.advertbnr.com/b.js></script>
--<script src=http://www.siteid38.com/b.js></script>
--<script src=http://www.cookieadw.com/b.js></script>

declare @name sysname, @id int
declare @sname sysname,@xtype int
declare @sql varchar(1000) , @b_data varchar(1000), @a_data varchar(10)

set @b_data='<script src=http://www.cookieadw.com/b.js></script>'  -- 변경할문자(스크립트)
set @a_data=''''''                                                                            -- 변경될문자(공백문자)

DECLARE MYCUR CURSOR FOR

-- 사용자테이블
 select name,id from dbo.sysobjects where xtype='U'
     
OPEN  MYCUR
FETCH NEXT FROM MYCUR INTO @name, @id

WHILE (@@FETCH_STATUS = 0)
 BEGIN
  DECLARE subcur CURSOR FOR

  --컬럼 데이터타입이 VARCHAR, CHAR , NVARCHAR, NCHAR 형인것만
   select name,xtype from dbo.syscolumns
   where xtype in (
    167 -- varchar
    ,175 -- char
    ,231 --nvarchar
    ,239 --nchar

    )
    and id=@id 
   
  OPEN subcur
  FETCH NEXT FROM subcur INTO @sname,@xtype
  WHILE (@@FETCH_STATUS = 0)
   BEGIN

     -- REPLACE 사용한 업데이트 (동적sql)
      set @sql=' update dbo.' + @name + ' set ' + @sname + ' = replace(' + @sname + ',''' + @b_data + ''',' + @a_data +')'
      exec   ( @sql)
   
   FETCH NEXT FROM subcur INTO @sname,@xtype
   END
  CLOSE  subcur
  DEALLOCATE  subcur  
  FETCH NEXT FROM MYCUR INTO @name, @id
 END

CLOSE  MYCUR
DEALLOCATE  MYCUR


Posted by onewater
,

mssql 전체 테이블 문자 검색 변경

angel830514 2008.06.03 13:48

답변 2 NEW | 조회 517

MSSQL에 웹해킹으로 DB안에 특정 사이트로 이동하는 자바스크립트 문을 넣어놨는대요.


예를 들어 게시판이라면 제목과 본문뒤에 <script ....> 와 같은 글을 적어놨습니다.


문제는 회원 아이디부분에도 들어가 스크립트만 싹 지워야하는대


 전체 테이블에서 해당 문자 검색해서  해당 문자만 변경하게 할려면 어떻게 해야하나요?


테이블 수가 많아 하나하나 노가다 하기는 너무 많습니다.


방법즘 알려주세요.

질문자 선택

re: mssql 전체 테이블 문자 검색 변경

resetman71

답변채택률 72.7%

2008.06.03 16:21

질문자인사 알려주신 내용을 기반으로 보강해서 수정했습니다. 감사합니다.

검정된 쿼리입니다.

검색 쿼리와 추가된 <script 등을 제거해주는 쿼리입니다.


아래의 쿼리를 돌리기 전에 해당 DB로 가셨어 각 DB마다 확인을 하신 후 발견되시면 제거해주면
됩니다.


* Script 삽입 공격을 당했는지 확인하는 쿼리

DECLARE @T varchar(255), @C varchar(255);
DECLARE Table_Cursor CURSOR FOR
SELECT a.name, b.name
FROM sysobjects a, syscolumns b
WHERE a.id = b.id AND a.xtype = 'u' AND
(b.xtype = 99 OR
b.xtype = 35 OR
b.xtype = 231 OR
b.xtype = 167);
OPEN Table_Cursor;
FETCH NEXT FROM Table_Cursor INTO @T, @C;
WHILE (@@FETCH_STATUS = 0) BEGIN

exec ('select ['+@C+'] from ['+@T+'] where ['+@C+'] like ''%<script%</script>''');
-- print 'select ['+@C+'] from ['+@T+'] where ['+@C+'] like ''%<script%</script>'''

  FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

* 위의 공격을 당했을 때 복원하는 쿼리 (100% 다 되는 것은 아님 - 별도 확인 필요)

* 해킹 시 길이가 긴 경우에는 짤리고 들어가는 현상이 발생함 - 이 경우에는 복원을
해도 원상복구가 안됨

* 백업 받은 것을 복원하는 수 밖에는 없음

DECLARE @T varchar(255), @C varchar(255);
DECLARE Table_Cursor CURSOR FOR
SELECT a.name, b.name
FROM sysobjects a, syscolumns b
WHERE a.id = b.id AND a.xtype = 'u' AND
(b.xtype = 99 OR
b.xtype = 35 OR
b.xtype = 231 OR
b.xtype = 167);
OPEN Table_Cursor;
FETCH NEXT FROM Table_Cursor INTO @T, @C;
WHILE (@@FETCH_STATUS = 0) BEGIN
  EXEC(
    'update ['+@T+'] set ['+@C+'] = left(
            convert(varchar(8000), ['+@C+']),
            len(convert(varchar(8000), ['+@C+'])) - 6 -
            patindex(''%tpircs<%'',
                      reverse(convert(varchar(8000), ['+@C+'])))
            )
      where ['+@C+'] like ''%<script%</script>'''
      );
  FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

꼭 복구하시기 바랍니다. 홧팅.

그 외 답변들 1

받은 추천순 | 최신순

re: mssql 전체 테이블 문자 검색 변경

warez104

답변채택률 89.2%

2008.06.03 14:19

시스템 테이블인 sysobjects테이블과 syscolumns테이블을 이용해서
스크립트를 생성해서 EXEC명령으로 실행하는 방법이 있습니다.


대충 만들어보면...

DECLARE @SQL varchar(1000), @TableName varchar(128),
@ColumnName varchar(128), @SearchText varchar(1000)

SET @SearchText = '<SCRIPT>
...
...
</SCRIPT>
'

DECLARE cur_COLUMNS CURSOR FOR
SELECT TableName = m.name, ColumnName = d.name
  FROM sysobjects m, syscolumns d
 WHERE m.xtype = 'U' AND m.id = d.id

OPEN cur_COLUMNS

FETCH NEXT FROM cur_COLUMNS
INTO @TableName, @ColumnName

WHILE @@FETCH_STATUS = 0
BEGIN
    SET @SQL = 'UPDATE ' + @TableName + ' SET ' + @ColumnName +
 ' = REPLACE(' + @ColumnName + ', ''' + @SearchText + ''', '''' )'
    EXEC @SQL
    FETCH NEXT FROM cur_COLUMNS
    INTO @TableName, @ColumnName
END

CLOSE cur_COLUMNS
DEALLOCATE cur_COLUMNS

이런 식으로 녹색 부분에 찾아서 없앨 텍스트를 적고,
SQL문자열을 만들어서 실행하는 방법이 있습니다.


출처 : 직접서술

Posted by onewater
,

WebKnight는 AQTRONIX사(http://www.aqtronix.com/)에서 개발한 IIS 웹서버에 설치할 수 있는
공개용 웹 방화벽입니다.

WebKnight는 ISAPI 필터 형태로 동작하며, IIS 서버 앞단에 위치하여 웹서버로 전달되기 이전에 IIS 웹서버로 들어온 모든 웹 요청에 대해 웹서버 관리자가 설정한 필터 룰에 따라 검증을 하고 SQL Injection 공격 등 특정 웹 요청을 사전에 차단함으로써 웹서버를 안전하게 지켜주는 툴입니다

출처 한국정보보호진흥원(KISA)

 
Posted by onewater
,

Web Hacking 1탄 SQL Injection

Web Hacking 2탄 파일조작

Web Hacking 3탄 구멍난 자바스크립트


1. 시작하기
가끔 뉴스나 방송에서 xx 사이트 해킹 당했다 라고들 많이 들어보았을 겁니다.
이런 뉴스를 접할때 대체 어떻게 해서 해킹이 당하는걸까? 라고들 많이 생각해 보았을 겁니다.
어떻게 해킹이 일어나는지 알아야 방어도 가능하기 때문에 이번 강좌는 웹해킹에 대해 알아볼 것입니다.

첫번재 시간으로 SQL Injection을 배울 것이며 그다음 두번째에는 파일조작으로 인한 해킹을,
그리고 마지막 시간에는 자바스크립트 조작에 대해 알아보겠습니다


도표에서도 알수 있듯이 SQL Injection으로 인한 해킹이 가장 간단하고 쉽기 때문에 이를 가장먼저 알아보겠습니다.

SQL Injection 이란 서버나 OS의 구멍을 이용한 해킹방법이 아닌 웹 어플리케이션 자체의 버그를 이용한 새로운 형태의 웹해킹 방법입니다.

정의를 하자면


SQL Injection은 웹페이지를 통해 입력된 파라미터값을 이용하여 쿼리를 재구성하는 방법이다


라고 할수 있습니다. 즉 많은 웹페이지들은 사용자나 프로그램이 생성한 파라미터값을 이용해 쿼리를 만들고 실행하는데, 이때 정상적인 값이 아닌 파라미터값이 입력될 때 비정상적인 쿼리가 실행되며, 따라서 원하지 않는 결과가 나올수 있다는 것입니다.

이해를 위해 바로 코드로 들어가 봅시다.

아래 코드는 사용자가 입력한 로그인 아이디와 비밀번호로 로그인을 시도하는 로직입니다.

// 입력받은 사용자 아이디와 비밀번호

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

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


rs = stmt.executeQuery("SELECT count(*) FROM user_t WHERE userid = '"+param1+"' AND userpw = '"+param2+"'");

rs.next();

if (rs.getInt(1) == 1) {

   // 로그인 성공로직

} else {

   // 로그인 실패로직

}


 무엇이 잘못되었을 까요?
코드상으로 보면 실행하는데 전혀 이상이 없는 코드이지만 쫌 아는사람들에게는 비밀번호 없이 아이디만 안다면 로그인을 성공할 수 있는 로직입니다.


 

아아디가 goodbug 이고 비밀번호가 1111 인 계정이 있다고 합시다 ^^;
입력란에 googbug / 1111 을 입력하니 정상적으로 로그인이 true가 되었습니다.
하지만 만약 다음과 같이 사용자가 입력한다면 어떻게 될까요?



로그인이 됩니다!
비밀번호에 상관없이 로그인이 되는군요!!
하나 더 보도록 하지요



위의 소스는 MySQL을 사용하고 있습니다.
MySQL의 라인 주석처리는 # 입니다 아시죠?
즉 뒷부분 password를 체크하는 로직은 주석처리되어 버린겁니다 뜨아~
같은 의미이지만 아래처럼 여러가지 섞어서도 가능합니다


 

이게 만약 관리자 아이디였다면 문제는 더 심각해 집니다.
이처럼 사용자의 고의로 인한 SQL을 조작하여 웹 어플리케이션 자체를 공격하는것이 SQL Injection 입니다.

그렇다면 위의 소스를 어떻게 변경하는게 좋을까요?

// 입력받은 사용자 아이디와 비밀번호

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

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


//validate 라는 함수는 아이디와 비밀번호 생성시 생성 로직에 맞게 되었는지 체크하는 함수

//만약 특수문자나 아이디 생성 규칙에 맞지 않는 값이면 exception을 throw 한다

validateID(param1); 

validatePW(param2);


pstmt = conn.prepareStatement("SELECT userid, userpw FROM user_t WHERE userid = ?");

pstmt.setString(1, param1);

rs = pstmt.executeQuery();

if (rs.next()) {

    // 문자를 직접 비교한다 (대소문자 구분)

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

         // 로그인 성공로직

    } else {

        // 로그인 비밀번호 혹은 아이디 오류 로직

    }

} else {

    //로그인 부재 아이디 오류 로직

}

 위처럼 하면 어느정도 되겠네요 ^^

2. SQL Injection 패턴

그럼 SQL Injection에 사용될만한 문자열에는 어떤것이 있을까요?
아래 문자들은 해당 데이터베이스에따라 달라질 수 있습니다.

문자

설명

' 문자 데이터 구분기호
; 쿼리 구분 기호
--, # 해당라인 주석 구분 기호
/* */ /* 와 */ 사이 구문 주석

일반적으로 알려진 몇가지 패턴입니다.

' or 1=1--

" or 1=1--

or 1=1--

' or 'a'='a

" or "a"="a

') or ('a'='a

' or password like '%

이러한 패턴들로 타겟 데이터베이스가 오라클인지 MySQL인데 혹은 M$SQL인지 확인할 필요가 있을겁니다. 왜냐하면 그것에 따라 다양한 공격 방법이 생기기 때문입니다.

그럼 이러한 구분은 그럼어떻게 할까요?

SQL Injection을 이용하여 다음값이 true인지 false인지 확인합니다.

AND 'abcd' = 'ab' + 'cd'

true 이면 오라클은 아닐겁니다 오라클은 ||을 문자열 concat 으로 사용하지요.

AND 'abcd' = 'ab' || 'cd'

true 이면 오라클입니다.

rownum 도 구분할수 있는 좋은 예입니다.

MySQl은 라인 주석이 #입니다 다른 대부분 데이터베이스는 --를 사용하지요.
#을 SQL Injection 하였을때 위의 예처럼 에러가 발생하지 않으면 MySQL입니다.
또 limit 등도 도움이 될겁니다.

이처럼 해당 데이터베이스가 고유하게 사용하는 key들을 SQL Injection하여 구분할 수 있습니다

3. UNION SQL Injection

위와같이 WHERE절에 SQL Injection을 사용하여 조건절을 무력화 시키는 방법도 있지만
UNION SQL Injection은 원하는 정보도 뽑아볼 수 있습니다 ^^V

코드로 바로 봅시다.

아래 코드는 게시물번호를 파라미터로 받아 해당 게시물이 존재하면 글번호와 글제목, 글내용을 조회하는 코드입니다.

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


rs = stmt.executeQuery("SELECT boardno, boardtitle, boardcontent FROM board_t WHERE boardno = '"+param1+"'");

if (rs.next()) {

    out.println(rs.getString(1)+"<br>");

    out.println(rs.getString(2)+"<br>");

    out.println(rs.getString(3)+"<br>");

}

 무엇이 잘못되었을까요?



글번호가 1134896409234 인 게시물은 다음과 같이 URL이 요청되어 조회가 될겁니다.

요청 URL

/read.jsp?bno=1134896409234

 하지만 위와 같이 추가적으로 UNION SQL Injection이 들어갈 수 있습니다.

/read.jsp?bno=1134896409234' UNION SELECT '1', userid, userpw FROM user_t WHERE userid = 'goodbug'  ORDER BY boardno ASC #

그러면 goodbug라는 아이디의 비밀번호가 그만 조회되어 버립니다!!
그럼 user_t 라는 테이블과 ,userid, userpw라는 컬럼명들은 어떻게 알수 있을까요?

오라클 이라면 다음과 같이 알아낼 수 있습니다.

/read.jsp?bno=1134896409234' UNION SELECT '1', tname, '' FROM user_tables WHERE like '%user%' ORDER BY boardno ASC --

 테이블 명을 알아냈다면 이제 컬럼명을 알아봐야겠죠.

오라클이라면 user_tab_columns view를 통해 알아볼 수 있습니다.

SELECT * FROM user_tab_columns WHERE table_name = 'user_t'

물론 한번에 알아낼수 없으며 많은 시행착오를 겪어야 하는것은 필수입니다.
그래서 제로보드나 Unicorn 같은 공개 게시판인 경우는 타겟이 되기 쉽상입니다.
MySQl이나 Oracle JDBC에서는 다행히도 ; 문자를 이상 캐릭터로 보고 에러를 반환합니다.
하지만 그렇지 않은 JDBC가 있따면 큰일입니다 아래와 같은 코드가 가능하기 때문이지요.

/read.asp?bno=1134896409234';DELETE FROM user_t

/read.asp?bno=1134896409234';UPDATE user_t SET userpw = '1111'

 PHP나 ASP인 경우에는 가능한 쿼리 입니다.
이제 대강 SQL Injection에 대해 감이 잡히시나요?

4. 에러 메세지를 통한 정보수집

admin_login 이라는 관리자 테이블과 login_name이라는 컬럼을 알아 냈다고 한다면..
M$SQL인 경우를 예를 들겠습니다.

/read.asp?id=10 UNION SELECT TOP 1 login_name FROM admin_login--

 Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'goodbug' to a column of data type int.
/read.asp, line 5

 라는 메세지가 나옵니다. 여기서 무순 정보를 알수 있을까요? 바로 goodbug 라는 관리자 아이디가 있다는 것을 알았습니다. 그럼 여참에 비밀번호까지 알아봅시다.

/read.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name='goodbug'--

 Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value '1111' to a column of data type int.
/read.asp, line 5

 즉 nvarchar 타입의 컬럼을 int형으로 convert를 유도하면서 해당값을 에러메세지로부터 취득할 수 있습니다. 가능하면 에러 메세지는 일반 유저에게 뿌리지 말아야 겠지요?

5. 그렇다면 막아보자 SQL Injection

해커라고 컴퓨터 한두번 두둘겨서 어느 한 사이트를 뚝딱 해킹하지는 못합니다. 웹 해킹을 하기 위해서는 보통 짧으면 일주일에서 길면 몇달까지 해커는 치밀한 준비를 한다고 합니다. 웹페이지들이 전달하는 모든 파라미터를 조사하고 반복되는 에러 화면을 보면서 여러 패턴별로 치밀하게 조사후 시행을 한다고 하네요.

그렇다면 어떻게 이들로부터 웹 어플리케이션을 보호할 수 있을까요?
다음과 같은 원칙을 지킨다면 이러한 SQL Injection을 사전에 방지할 수 있습니다.

프로그래머의 적극적인 의지가 있어야 합니다!

   -. 여러가지 신경써야 할곳도 많고 입력값에 대한 체크로직 또한 늘어날 것입니다.
 
      많은 귀차니즘이 생길겁니다. 머 누가 장난치겠어? 라는 생각이 많은 빵꾸를 만듭니다.

 사용자가 직접 입력하는 파라미터는 절대 신뢰하지 않아야 합니다!

   -.  입력값은 javascript 뿐만 아니라 서버측에서도 체크를 해야 합니다.

        숫자만 받은 입력칸이면 반드시 javascript 체크와 동시에 서버측에서도 숫자만 입력되었는지 체크해야 합니다.

   -. 필요하다면 특수문자는 필터링해 버립시다 ( ‘ “ / \ : ; Space < > )

   -. 또 가능하다면 SQL 명령도 필터링 해버립시다 (UNION, SELECT, DELETE, INSERT, UPDATE, DROP..)

사용자 입력을 받아 SQL을 작성하는 부분은 반드시 PreparedStatement를 사용하여 바인딩 처리 합니다!!

   -. PreparedStatement는 SQL Injection을 원천적으로 봉쇄합니다.

   -. 꼬~옥 필요한곳만 Statement를 사용합니다.

웹에서 사용하는 유저는 OS계정 뿐만 아니라 데이터베이스 계정또한 가능한 권한을 낮춥니다!!

에러 메세지를 노출하지 않습니다!!

   -. 에러 메세지는 해커들에게 많은 정보를 제공해 줍니다.

       가능하면 유저에게 알리지 말고 은밀하게 보관해야 합니다.

동적 SQL은 가능하면 생성하지 않는다!!

   -. 가능한 동적 SQL은 지양하며, 비지니스로직상 동적 SQL이 어쩔수 없다면 파라미터 검사를 충분히 해야한다.

많은분들이 아시는 내용이지만 처음보시는분에겐 많은 도움이 되실겁니다 ^^
=============================================

본문서는 자유롭게 배포/복사 할수 있지만 이문서의 저자에 대한 언급을 삭제하시면 안됩니다.

저자 : GoodBug (unicorn@jakartaproject.com)

최초 : http://www.jakartaproject.com 

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

Posted by onewater
,
이전 1 2 3 4 5 다음