2002년 9월 17일
채팅 진행자_Stephen_D:
사이트간 스크립팅 및 SQL 코드 주입에 대한 채팅입니다. 초대 손님의 자기 소개를 부탁합니다.
초대 손님_Erik_MS:
안녕하세요, 저는 Erik Olson입니다. 저는 ASP.NET 팀의 프로그램 매니저입니다.
초대 손님_David_MS:
안녕하세요, 저는 David Ross입니다. 저는 Microsoft Secure Windows Initiative Attack Team의 구성원으로서 클라이언트 쪽 보안 작업에 참여한 적이 있습니다.
초대 손님_Tom_MS:
안녕하세요! 저는 Microsoft Office 보안 팀의 Tom Gallagher입니다.
초대 손님_Andres_MS:
안녕하세요, 저는 Secure Windows Initiative의 구성원인 Andres De Vivanco입니다. 저는 SQL 관련 취약점을 조사하고 있습니다.
초대 손님_PeterTorr_MS:
안녕하세요, 저는 Microsoft의 모든 스크립트 제품(JScript, VBScript, WSH, JScript .NET, VSA 등)을 작성하는 Programmability 팀에서 일하고 있습니다.
채팅 진행자_Stephen_D:
그런데... 저는 SQL Server Communities PM인 Stephen Dybing입니다. 오늘 이렇게 모두 한 자리에 모이게 되어 반갑습니다!
채팅 진행자_Jerry_B:
안녕하세요, 저는 Jerry Bryant입니다. Security Communities PM이고요. 이렇게 와주셔서 감사합니다!
채팅 진행자_Stephen_D:
초대 손님께 질문할 내용은 쓰기방에 입력하실 수 있습니다. 본 채팅은 여러 질문을 읽고 답변할 질문을 선택하는 방식으로 진행됩니다. 질문과 대답은 읽기방에 게시됩니다.
채팅 진행자_Stephen_D:
시작합시다! 초대 손님께 질문을 하십시오.
채팅 진행자_Stephen_D:
Q: Adi: 이건 채팅에 관한 질문입니다. 영어가 모국어가 아니어서 그러는데, 나중에 다시 읽어볼 수 있도록 채팅이 끝난 후 내용을 원고로 받을 수 있을까요?
채팅 진행자_Stephen_D:
A: 원고는 다음 주에 게시할 것입니다. 왼쪽 탐색 창을 보면 채팅 원고로 연결되는 링크가 있습니다.
초대 손님_David_MS:
Q: Roger: 스크립팅 중복을 방지하려면 코드를 어떻게 써야 하나요? A: 조금 까다로운 문제입니다. 출력뿐 아니라 입력 시에도 문자를 필터링할 수 있으나, 바로 "이것이다"라고 할 만한 해결책을 제시하는 건 쉽지 않네요. www.owasp.org/ 
에 도움이 되는 정보가 많이 들어 있는데 원하시면 이 정보를 자세히 알려드릴 수는 있습니다.
초대 손님_David_MS:
Q: Cipher24: 사용자가 제공하는 데이터를 제어하기 위해 브라우저 출력을 필터링하는 방법을 아시는 분이 혹시 있습니까?
초대 손님_David_MS:
Q: Cipher24: 현재 제가 유지 관리하고 있는 사이트에서는 이미 사용자가 제공하는 모든 입력을 포괄적으로 필터링하고 있습니다. 우리 팀이 부딪치는 문제는 2바이트 문자를 사용하는 언어 때문에 생깁니다.
초대 손님_David_MS:
Q: Cipher24: 문제가 없는 문자와 중요한 사용자 데이터를 제거하지 않는 방안으로, 출력을 필터링하는 아이디어가 나왔지요.
초대 손님_David_MS:
A: 정말로 나중에 속을 썩일지 모르는 HTML이나 스크립트까지 포함된 오류가 있는데 이를 단번에 한 페이지로 몰아 넣고 싶다면, 속성을 security=restricted로 준 frame/iframe을 사용해볼 만합니다.
초대 손님_David_MS:
A: 하지만 플랫폼간의 문제도 해결해야 할 거예요.
초대 손님_Tom_MS:
Q: XSS : XSS 공격을 모두 잡아내지 못하는 Server.HtmlEncode 말고 이러한 공격을 막는 데 쓸 만한 개발 도구로 Microsoft에서 제공하는 게 뭐 있나요?
초대 손님_Tom_MS:
A: 모든 XSS 공격을 막는다는 건 어려운 문제예요. 개발자로서 결과 문서 중 그러한 공격이 발생하는 곳을 어떻게 처리하고 있는지 꼼꼼하게 살펴보아야 할 거예요. 꺾쇠 괄호나 큰따옴표 없이도 공격이 발생하는 경우가 많으므로 HTML 인코딩이 도움이 될 수 있어요. 의심스러워 보이는 문자를 필터링하는 데 URL 스캔이 다소 도움이 될 것입니다.
초대 손님_David_MS:
A: XSS 질문에 대한 보충 답변: .NET Server 및 XP SP1의 새 HTTPOnly 쿠키를 살펴보는 것도 괜찮을 거예요.
초대 손님_David_MS:
A: XSS 질문에 대한 보충 답변: HTTPOnly 쿠키 기능을 사용하면 서버에서 특정 쿠키를 페이지의 개체 모델에 사용할 수 없도록 지정할 수 있어요. 예를 들면 document.cookie 같은 거죠.
초대 손님_David_MS:
A: XSS 질문에 대한 보충 답변: 그럴 경우 사이트에 XSS 허점이 있어도 쿠키를 도난당할 위험은 줄어들지요.
초대 손님_David_MS:
A: XSS 질문에 대한 보충 답변: spoofing 같은 다른 공격을 막지 못해 XSS 허점이 드러날 수는 있겠지만요.
초대 손님_Erik_MS:
A: 같은 질문에 대한 보충 답변입니다. Tom이 지적했듯이, 이 문제를 일반적으로 처리하는 것은 매우 어려운 일입니다. 앞으로 나올 ASP.NET 릴리스에서는 들어오는 데이터에서 위험한 구조를 검색, 발견하면 예외를 발생시켜 이러한 문제를 다소 해결할 수 있을 겁니다. 이 기능이 정말 의도하는 바는 데이터의 유효성을 엄격하게 검사하거나 적절하게 인코딩하여 이러한 기능을 사용하지 않아도 되게끔 개발자가 코드의 보안을 확실하게 하자는 데 있지요. 데이터의 종류와 용도를 알면 데이터의 유효성 검사를 더 잘할 수 있지요. <이상>
초대 손님_David_MS:
A: HTTPOnly 쿠키에 대한 자세한 정보는 다음 사이트에서 참조할 수 있습니다. http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp
채팅 진행자_Jerry_B:
A: 이 기사에 대한 자세한 정보를 얻을 수 있는 링크가 여러 개 있습니다.
초대 손님_Andres_MS:
Adi: SQL 주입에 대한 특정 질문이 있습니까?
초대 손님_David_MS:
A: Michael Howard와 David LeBlanc이 만든 WSC v2에는 XSS와 SQL 주입에 대한 유용한 정보가 많이 들어 있습니다.
초대 손님_David_MS:
A: http://www.amazon.com/exec/obidos/tg/detail/-/0735617228/qid=1032283640/sr=8-2/ref=sr_8_2/104-3901087-4034345?v=glance&s=books&n=507846
초대 손님_David_MS:
A: 앞서 말씀 드렸듯이 OWASP (www.owasp.org)가 많은 도움이 될 겁니다.
초대 손님_Andres_MS:
Q: Adi: 실제로는 다릅니다. 저도 이 문제에 대해서는 많은 것을 읽었습니다. 제가 이에 관해 발표할게요. 지금도 좀더 많은 정보를 구하고 있는 중입니다. 제가 생각치 못했던 것들이 많이 있는데, 여기에서 아이디어를 얻을 수 있을 거라는 생각이 드네요. 아이디어는 또한...
초대 손님_Andres_MS:
Q: Adi: 서버 보호에 대한 개선책 같은 걸 말해주세요.
초대 손님_Andres_MS:
A: Adi: SQL 주입 공격을 막을 수 있는 최상의 방법은 사용자의 입력에서 직접 SQL 쿼리를 작성하지 않고 저장된 프로시저를 쓰는 것입니다.
초대 손님_Andres_MS:
A: Adi: 그리고 나서 입력 값을 저장된 프로시저로 전달하여, 거기에서 유효성 검사를 철저히 할 수 있지요.
초대 손님_David_MS:
Q: GTodd: 저는 XSS보다는 David Litchfield가 작성한 자료인 SQL 주입에 관해 더 많은 걸 읽었는데. 누가 XSS가 무엇인지 제게 간단하게 알려주겠어요?
초대 손님_David_MS:
A: XSS는 데이터가 악의적인 소스에서 들어왔을 때 서버가 클라이언트의 정보를 재생하는 경우 발생하게 되는 공격의 유형을 설명하지요.
초대 손님_David_MS:
A: 공격 시나리오를 가지고 생각하면 아주 쉽게 이해할 수 있을 거예요. 1) 피해자가 악의적인 웹 페이지를 찾아본다.
초대 손님_David_MS:
A: 2) 악의적인 웹 페이지가 피해자 서버를 탐색하거나 폼을 보낸다. (XSS 공격에는 실제 두 가지 피해 대상이 있다.)
초대 손님_David_MS:
A: 3) 피해자 클라이언트가 악의적인 클라이언트 쪽 스크립트가 포함된 피해자 서버에서 작성된 웹 페이지를 받는다.
초대 손님_David_MS:
A: 4) 악의적인 클라이언트 쪽 스크립트가 클라이언트 쪽에서 피해자 서버의 보안 컨텍스트로 실행된다.
초대 손님_David_MS:
A:이에 관해 생각할 수 있는 다른 방법으로 URL을 이용하는 XSS를 보면서 어떤 결과가 벌어지는지를 상상해볼 수 있습니다. 제 서버의 페이지에서 "안녕 Dave"라고 말하는 웹 페이지가 있는 http://www.myserver.com/whatever.asp?name=Dave에 응답하는 경우, 제가 다음 URL을 탐색하다면 어떤 결과가 일어날까요? http://www.myserver.com/whatever.asp?name=<script>alert(document.cookie)</script>
초대 손님_David_MS:
A: 쿠키는 myserver.com의 쿠키가 되나, 스크립트는 URL을 만든 소스의 스크립트입니다.
초대 손님_David_MS:
A: 그리고 스크립트가 페이지 탐색을 통해 쿠키를 다른 서버로 쉽게 보냈을 것입니다.
초대 손님_Tom_MS:
Q: XSS : 클라이언트 플랫폼 프로그래머는 어느 정도로 사이트간 스크립팅에 신경을 써야 하나요?
초대 손님_Tom_MS:
A: 클라이언트 프로그래머는 사이트간 스크립팅, XSS에 대해 확실히 신경을 써야 합니다. 종종 클라이언트 응용 프로그램이 Internet Explorer의 렌더링 엔진 trident - MSHTML.DLL을 호스트하고 내 컴퓨터 영역에서 실행되거나, 아니면 로컬 하드 디스크의 로컬 html 파일에 스크립트가 있을 때가 있지요. 다음 두 가지 경우 모두 침입자가 내 컴퓨터 영역으로 코드를 가져갈 위험이 큽니다. 분명치 않은 점은 해시, 검색 문자열 등 URL을 통해 입력을 받고 문서 쓰기나 다른 출력을 수행하는 하드 디스크 상의 문서가 XSS 취약점이 될 수 있다는 점입니다. 이러한 XSS 취약점 때문에 침입자가 내 컴퓨터 영역에서 코드를 실행할 수 있습니다. Windows XP SP1에서는 Internet Explorer가 인터넷 영역에서 내 컴퓨터 영역으로의 리디렉션을 차단하여 로컬 콘텐트에서 XSS를 완화하고 있습니다.
채팅 진행자_Stephen_D:
Q: XSS: Microsoft는 SQL 주입 문제를 해결할 "만능 큰따옴표" 기능에 대한 계획이 있나요?
채팅 진행자_Stephen_D:
A: 우리는 SQL 주입 공격을 방지하는 데 있어서 응용 프로그램 개발자를 도울 수 있는 방법을 연구 중입니다. 어떤 의미에서 이러한 방법은 이미 sp_executesql와 QUOTENAME에서 구현되고 있다고 할 수 있습니다. 그러나 이 문제를 진정으로 완화하려면 응용 프로그램 수준에서 사용자 입력의 유효성을 제대로 검사해야 합니다. 이를 도울 수 있는 지원 솔루션으로 완전히 결정된 것이 아직은 없는 실정입니다.
초대 손님_PeterTorr_MS:
Q: JimG : 저는 FrontPage를 사용하여 전에 보낸 적이 있는 전자 메일 주소로 보내는 폼을 만들고 있습니다. 제 경우에도 XSS에 대해 신경을 써야 하나요? A: 전자 메일 폼을 만든다면 FrontPage 보트(bot)로 대부분의 이러한 문제를 처리해야 합니다. A: 주요 문제는 다음과 같은 경우 발생합니다.
초대 손님_PeterTorr_MS:
A: 주요 문제는 폼을 서버에 전송하고 그리고 나서 서버에서 폼이 잘못된 데이터가 포함된
초대 손님_PeterTorr_MS:
A: 정보를 다시 클라이언트로 다시 보낼 때 발생합니다.
초대 손님_PeterTorr_MS:
A: 그러나 전자 메일 클라이언트가 오래되었거나 "제한된" 영역에서 실행하지 않으면,
초대 손님_PeterTorr_MS:
A: 사람들이 폼을 통해 악의적인 콘텐트를 전자 메일로 보낼 수 있지요. (그리고 다시
초대 손님_PeterTorr_MS:
A: 누가 보냈는지 모르게 당신에게 직접 전자 메일을 보낼 수가 있습니다.}
초대 손님_Andres_MS:
Q: GTodd: "위험한" 저장 프로시저를 삭제하는 것이 SQL 주입으로 제기되는 위험을 줄일 수 있는 좋은 방법이라는 제안을 읽은 적이 있습니다. 이 방법에 부정적인 측면이 있나요?
초대 손님_Andres_MS:
A: GTodd: SP를 삭제하기 전에 삭제할 SP를 호출하는 기능이 없는지를 확인해야 합니다.
초대 손님_Andres_MS:
A: GTodd: 예를 들어, xp_cmdshell을 삭제하면 복제가 중지됩니다.
초대 손님_Andres_MS:
A: GTodd: 대부분의 SP에는 뛰어난 사용 권한 확인 기능이 있는데, 클라이언트가 권한이 낮은 계정을 사용하여 로그인하는 경우에는 결함이 없어야 하죠.
초대 손님_PeterTorr_MS:
Q: Adi: "만능 큰따옴표"는 무엇입니까?
초대 손님_PeterTorr_MS:
A: 그건 Perl의 옵션인데, 게시된 폼 데이터에 큰따옴표를 자동으로 이스케이프 문자로 처리합니다. http://www.onlamp.com/pub/a/php/2001/02/15/php_admin.html 에 이에 대한 정보가 들어 있습니다.
초대 손님_PeterTorr_MS:
Q: Teckno : 읽기 및 쓰기 권한만 있는 디렉터리를 공유할 수 있나요? 사용자가 서버에서 파일을 복사할 수 있는 것을 제한할 수 있는지 알고 싶네요.
초대 손님_PeterTorr_MS:
A: 사용자가 당신의 서버에 대한 읽기 권한이 있다는 건 그들이 데이터를 읽고 복사할 수 있다는 걸 의미하지요.
초대 손님_PeterTorr_MS:
A: 다른 사람들이 데이터를 복사하지 못하게 하는 유일한 방법은 먼저 데이터를 읽지 못하게 하는 겁니다.
초대 손님_David_MS:
Q: GTodd: XSS는 클라이언트 쪽 문제와 거의 같습니다. 서버 또는 쿠키가 이러한 공격에 개입하지 못하도록 관리자가 할 수 있는 일이 있나요?
초대 손님_David_MS:
A: 이 문제는 두 가지 방법으로 논의할 수 있다고 생각합니다. 한편으로는 클라이언트만이 자신이 스크립트로 해석하는 것을 안다고 말할 수 있습니다. 이것이 정확한 말입니다.
초대 손님_David_MS:
A: 다른 한편으로, 서버는 서버의 보안 컨텍스트에서 표시되는 콘텐트에 대한 문제를 처리해야 합니다.
초대 손님_David_MS:
A: 서버의 관점에서 볼 때, 최상의 방법은 입력 및/또는 출력을 필터링하는 것입니다.
초대 손님_David_MS:
A: 그 다음으로 할 수 있는 부차적인 일로는 HTTPOnly 쿠키 사용과 코드 페이지를 알려진 것에 강제하는 것을 들 수 있습니다.
초대 손님_David_MS:
A: 그러나 가장 중요한 일은 서버 쪽 필터링으로서, 특히 적절한 문자는 허용하고 그 밖에 다른 모든 것은 거부하는 것입니다.
초대 손님_Tom_MS:
Q: JimG : 데이터베이스로 보내기와 같은 기타 FP 구성 요소는 어떻습니까? FP가 자동으로 보호 기능을 수행합니까, 아니면 제가 직접 확인을 해야 합니까?
초대 손님_Tom_MS:
A: FrontPage에서 마법사나 보트(bot)를 사용하는 경우, FrontPage가 만드는 SQL 쿼리가 안전하기 때문에 문제가 없습니다. FrontPage에서 사용자 지정 코드를 직접 쓰는 경우, 안전성은 작성자에 달려 있습니다.
채팅 진행자_Stephen_D:
벌써 채팅을 마칠 때가 되었네요. 마지막으로 질문할 분이 계십니까?
채팅 진행자_Stephen_D:
오늘 저희와 함께 해 주셔서 감사합니다! 여러 가지 유익한 질문들이 나왔다고 생각하며, 아쉽지만 마치겠습니다.
초대 손님_David_MS:
감사합니다!
초대 손님_Erik_MS:
참석하셔서 감사합니다!
초대 손님_Andres_MS:
감사합니다. 다음에 또 뵙죠!
초대 손님_Tom_MS:
감사합니다. 응용 프로그램 보안에 많은 관심을 가지시길.
채팅 진행자_Jerry_B:
공용 뉴스 그룹에 후속 질문들을 게시해주세요.
채팅 진행자_Jerry_B:
http://www.microsoft.com/technet/newsgroups/NodePages/security.asp
채팅 진행자_Jerry_B:
또는
채팅 진행자_Jerry_B:
OE 사용자의 경우, http://www.microsoft.com/communities .
채팅 진행자_Jerry_B:
감사합니다.
