2010-10-13 2 views
5

Google은 사용자가 파일을 업로드 할 수있는 저장소 역할을하는 내부 웹 응용 프로그램을 보유하고 있습니다. 이러한 파일은 HTML 페이지를 포함하여 모든 형식이 될 수 있습니다.HTML 다운로드시 XSS를 피할 수 있습니까?

쿠키에 액세스하려고하는 일부 스크립트가 포함 된 HTML 파일을 다운로드하고 다운로드 한 후 "열기"옵션을 선택하면 스크립트가 실행되고 쿠키 정보가 없으므로 IE8에서 테스트했습니다. 전혀 문제가 없습니다.

실제로이 스크립트는 XmlHttpRequest 개체를 사용하여 서버를 호출하고 파일을 다운로드 한 사용자 세션에서 일부 악의적 인 작업을 수행 할 수 있습니다.

이 문제를 방지 할 수있는 방법이 있습니까? 우리는 Chrome과 Firefox 모두 이러한 일이 발생하지 않도록 테스트했습니다. IE8을 포함한 모든 브라우저에서이 문제를 어떻게 피할 수 있습니까?

+2

실제로 "열기"란 무엇입니까? 브라우저에 페이지를 표시 하시겠습니까? 그렇다면 페이지의 URL은 어떻게됩니까? – bzlm

+0

@bzlm : 첨부 파일과 비슷합니다. 브라우저가 다운로드 창 (콘텐츠 처리)을 묻도록 강요하면 열기를 클릭 할 수 있으며 쿠키를로드하는 데 사용 된 URL을 사용하여 열 수 있습니다. 쿠키는 쿠키와 동일한 도메인에 있으므로 분명히 내 제안입니다. 대체 도메인에서 실행 (다운로드). –

+0

@bzlm이 올바른 위치에 있습니다. HTML 파일을 로컬에서 열면 단일 도메인 정책으로 인해 원격 서버에 쿠키에 액세스하거나 Ajax 요청을 발행 할 수 없습니다. 서버에 직접 열리는 경우에만 가능합니다. –

답변

5

비정상 콘텐츠 업로드를 허용하지 마십시오. 그것은 독점적으로 끔찍한 생각입니다.

하나의 잠재적 인 "솔루션"은 쿠키가없는 도메인에서 신뢰할 수없는 업로드 만 호스팅 할 수 있으며 사용자는 어떤 방식 으로든 신뢰를 연결하지 않을 수 있습니다. 이것은 "해결책"일 것이지만, 이상적인 것은 아닙니다.

좀 더 실용적인 옵션은 각 파일이 자동 검토를 거쳐 자동 정리/분석 단계의 수동 확인을 거치는 권한 기반 프로세스 일 수 있습니다.

그러나 모든 사람들이이를 가능케하는 것은 매우 나쁜 생각입니다.

+1

+1 다른 도메인에 업로드를 저장하고 이것이 항상 위험하다는 일반적인 개념 –

+0

다른 도메인에서 파일을 다운로드 할 수있는 옵션을 고려한 다음 시스템에 주시하여 우리가 최종적으로 있는지 확인합니다 위험한 업로드를 거부해야합니다. 도와 주셔서 대단히 감사합니다. –

+0

[GitHub releases] (https://github.com/cirosantilli/test/releases/tag/3.0)는 확장을 허용하고 S3을 통해 도메인 솔루션을 사용하는 것처럼 보입니다. Dropbox는 또한 임의의 파일 유형을 허용합니다. –

1

사용자가 실제로 HTML 파일을 업로드하게하려면이 디렉토리의 HTML 파일이 text/html 또는 유사하지 않고 MIME 유형 text/plain으로 제공되는지 확인해야합니다.

이렇게하면 열려있는 파일이 브라우저에서 스크립트를 실행하지 못하게됩니다. 아파치를 사용하는 경우 AddType 지시어를 참조하십시오.

+0

이것은 좋은 제안이며 트릭을 수행 할 수 있습니다. 나는 여전히 동일한 도메인에서 콘텐츠를 제공하는 것에 대해 우려 할 것이지만, 아마도 이것이 관계없이 수행되어야한다고 생각합니다. –

+0

콘텐츠 스니핑을 조심하십시오. 아파치는 기본적으로 알 수없는 파일에 대해'text/plain'을 제공하기 때문에 브라우저는'text/plain'을 실제 유형을 추측하는 초대장으로 처리해야합니다. – Kornel

4

보안상의 관점에서 보면 정말 나쁜 생각입니다. 그래도 원하는 경우 HTTP 응답 헤더 Content-disposition: attachment을 포함 시키면 브라우저가 파일을 열지 않고 파일을 다운로드하도록합니다. 아파치에서는 .htaccess 파일에 Header set Content-disposition "attachment"을 추가하면됩니다.

대답 중 하나에 언급 된대로 Content-type: text/plain을 추가하는 것은 좋지 않습니다. Internet Explorer에서는 작동하지 않으므로. IE가 text/plain content-type 헤더가있는 파일을 수신하면 MIME 스니퍼가 파일의 실제 내용 유형을 정의하려고 시도합니다 (일부 서버는 text/plain으로 모든 파일을 보내기 때문에). 파일 내에서 HTML 코드를 충족 시키면 브라우저가 text/html로 파일을 제공하고 렌더링합니다.

+0

[이 블로그 게시물] (http://i8jesus.com/?p=64)에서는'Content-Disposition'만으로는 충분하지 않다고 말하지만, 나는 그것이 얼마나 신뢰할 수 있고 여전히 적용되는지에 대해 충분히 알지 못합니다. –

관련 문제