This is a good article. Click here for more information.

교차부위누출

Cross-site leaks

인터넷 보안에서 XS-leaks라고도 하는 사이트 간 유출은 공격자가 다른 웹 사이트와의 사용자 상호 작용에 대한 중요한 정보에 액세스할 수 있도록 하는 공격의 한 종류입니다. 웹 브라우저는 동일한 출처 정책이라고 하는 일련의 규칙을 통해 다른 웹 사이트가 이 정보를 볼 수 없도록 합니다. 그러나 사이트 간 유출은 다른 웹 사이트에 대한 정보를 드러내는 기술을 사용하여 이러한 규칙을 회피합니다. 이러한 공격은 종종 사용자가 공격자의 웹 사이트를 방문하도록 유도하여 시작됩니다. 방문 시 공격자는 웹사이트의 악성 코드를 사용하여 다른 웹사이트와 상호 작용합니다. 공격자가 웹 사이트에서 사용자의 이전 작업에 대해 학습하는 데 사용할 수 있습니다. 이 공격의 정보는 공격자에 대한 사용자를 고유하게 식별할 수 있습니다.

이러한 공격은 2000년부터 문서화되었습니다. 이 주제에 대한 최초의 연구 논문 중 하나는 퍼듀 대학의 연구원들에 의해 발표되었습니다. 이 논문에서는 웹 캐시가 웹 사이트에 대한 정보를 수집하기 위해 악용되는 공격에 대해 설명했습니다. 그 이후로 사이트 간 누출은 점점 더 정교해졌습니다. 연구원들은 다양한 웹 브라우저 구성 요소를 대상으로 한 새로운 유출을 발견했습니다. 이러한 기술 중 일부의 효과는 다양하지만, 새로운 기술이 지속적으로 발견되고 있습니다. 일부 오래된 방법은 브라우저 소프트웨어 업데이트를 통해 차단됩니다. 인터넷에서 기능을 도입하고 제거하면 일부 공격이 효과적이지 않게 됩니다.

사이트 간 유출은 다양한 형태의 공격이며, 이러한 공격에 대한 일관된 분류가 없습니다. 여러 출처는 정보 유출에 사용되는 기술에 따라 사이트 간 유출을 분류합니다. 잘 알려진 교차 사이트 유출 중에는 웹 브라우저 내의 타이밍 이벤트에 따라 달라지는 타이밍 공격이 있습니다. 오류 이벤트는 데이터를 공개하기 위해 이벤트의 유무를 사용하여 다른 범주를 구성합니다. 또한 캐시 타이밍 공격은 정보를 공개하기 위해 웹 캐시에 의존합니다. 2023년부터는 운영체제와 웹 브라우저 제한을 이용해 정보를 유출하는 새로운 공격도 발견되고 있습니다.

2017년 이전에는 교차 사이트 유출에 대한 방어가 어려운 것으로 여겨졌습니다. 사이트 간 유출 공격으로 악용되는 정보 유출 문제 중 상당수가 웹 사이트 작동 방식에 내재되어 있었기 때문입니다. 이러한 종류의 공격에 대한 대부분의 방어는 2017년 이후 하이퍼텍스트 전송 프로토콜(HTTP)의 확장 형태로 도입되었습니다. 이러한 확장 기능을 통해 웹 사이트는 브라우저에 다른 웹 사이트에서 오는 특정 종류의 상태 정보 요청을 허용하지 않거나 주석을 달도록 지시할 수 있습니다. 브라우저가 구현한 가장 성공적인 접근 방식 중 하나는 SameSite 쿠키입니다. 동일 사이트 쿠키를 사용하면 웹 사이트에서 다른 웹 사이트에서 중요한 쿠키에 액세스하고 보내지 못하도록 하는 지침을 설정할 수 있습니다. 또 다른 방어는 HTTP 헤더를 사용하여 특정 사이트를 포함할 수 있는 웹 사이트를 제한하는 것입니다. 캐시 파티셔닝은 또한 교차 사이트 유출에 대한 방어 기능을 수행하여 다른 웹 사이트가 웹 캐시를 사용하여 데이터를 유출하는 것을 방지합니다.

배경

추가 정보: 동일원천정책

웹 애플리케이션(웹 앱)에는 웹 브라우저와 하나 이상의 웹 서버라는 두 가지 주요 구성 요소가 있습니다. 브라우저는 일반적으로 HTTP(Hyper Text Transfer Protocol) 및 WebSocket 연결을 통해 서버와 상호 작용하여 웹 애플리케이션을 제공합니다.[note 1] 웹 응용 프로그램의 특정 부분은 사용자 입력 또는 다른 클라이언트 측 로직에 반응해야 합니다. 이것은 HTML 또는 CSS를 렌더링하거나 웹 사이트를 제공하는 과정의 일부로 자바스크립트를 실행함으로써 수행됩니다.[2] 이러한 사용자 상호 작용은 종종 웹 앱이 장기간에 걸쳐 서버에 여러 번 요청해야 합니다. 이러한 요청을 추적하기 위해 웹 앱은 종종 현재 세션 또는 사용자 계정을 통해 특정 사용자와 연결된 영구 식별자를 사용합니다.[3] 이 계정 또는 세션은 사용자의 웹 앱에 대한 이전 상호 작용을 반영하여 연령 또는 액세스 수준과 같은 특정 식별 가능한 속성을 갖습니다. 이러한 식별 가능한 속성이 다른 웹 사이트에 노출되면 사용자의 익명성을 해제할 수 있습니다.[4]

이상적인 시나리오에서는 이러한 사용자 상호 작용과 웹 서버 통신을 수행하여 두 개의 웹 앱이 서로 간섭하지 않도록 합니다. 그러나 웹 초기에 다양한 디자인 선택으로 인해 웹 앱은 정기적으로 상호 작용할 수 있습니다.[5] 이러한 동작의 남용을 방지하기 위해 웹 브라우저는 동일한 출처 정책이라는 규칙 집합을 만들었습니다. 동일 출처 정책은 두 웹 앱 간의 특정 상호 작용만 허용한다고 규정하고 있습니다.[6][7] 예를 들어, 동일 출처 정책은 웹 앱이 다른 웹 앱의 실행 컨텍스트에 임의로 도달하여 상호 작용하는 것을 방지합니다.[8] 그러나 웹 앱은 프레임을 사용하여 다른 웹 앱의 콘텐츠를 내장하거나 교차 출처 요청을 통해 타사 사이트에 요청할 수 있습니다.[9] 그러나 특히 동일한 출처 정책은 교차 출처 자원 공유(CORS) 프레임워크를 통해 명시적으로 허용되지 않는 한 다른 웹 앱이 이러한 교차 출처 요청의 내용을 직접 읽을 수 없도록 합니다.[10]

사이트 간 유출을 통해 공격자는 동일한 출처 정책에 의해 부과된 제한에도 불구하고 정보를 얻을 수 있습니다. 사이트 간 유출은 브라우저에서 과거에 존재했던 정보 유출 문제(사이드 채널)를 활용합니다. 이 유출을 사용하여 공격자는 코드를 실행하여 교차 출처 요청을 통해 또는 공격 웹 앱에 피해 웹 앱을 내장하여 다른 실행 컨텍스트의 현재 상태에 대한 정보를 추론할 수 있습니다.[11] 그런 다음 공격자는 웹 앱과 사용자의 이전 상호 작용에 대한 정보에 액세스할 수 있습니다.[12]

메카니즘

  • In the absence of a third party, the user's browser sends the web server an HTTP request. The server sends a response dependent on the nature of the request.
    제3자가 없는 경우 사용자의 브라우저는 웹 서버에 HTTP 요청을 보냅니다. 서버는 요청의 특성에 따라 응답을 보냅니다.
  • An attacker identifies a vulnerable URL and phishes the user to their website using an email. When the user goes to the attacker's website, the attacker can make malicious requests to the web server using the vulnerable URL.
    공격자는 취약한 URL을 식별하고 전자 메일을 사용하여 사용자를 웹 사이트로 피싱합니다. 사용자가 공격자의 웹사이트에 갈 때 공격자는 취약한 URL을 사용하여 웹 서버에 악의적인 요청을 할 수 있습니다.
  • The attacker is prevented from reading the web server's response. However, other factors like the response time or size can be measured by the attacker, leaking information about the response – a side-channel attack.
    공격자가 웹 서버의 응답을 읽지 못하도록 합니다. 그러나 공격자는 응답 시간이나 크기와 같은 다른 요소를 측정하여 응답에 대한 정보를 유출할 수 있습니다. 즉, 사이드 채널 공격입니다.

사이트 간 유출의 위협 모델은 공격자가 공격자가 적어도 부분적으로 공격자의 통제 하에 있는 악의적인 웹 사이트로 공격자를 유도할 수 있는지 여부에 달려 있습니다. 공격자는 웹 페이지를 손상시키거나, 사용자를 웹 페이지로 피싱하여 임의 코드를 로드하거나, 안전하지 않은 웹 페이지에서 악의적인 광고를 사용하여 이를 수행할 수 있습니다.[13][14]

사이트 간 유출 공격을 수행하려면 공격자가 먼저 웹 사이트가 사용자와 상호 작용하는 방식을 연구해야 합니다. 사이트에서 사용자의 과거 작업을 기반으로 서로 다른 HTTP(Hyper Text Transfer Protocol) 응답을 생성하는 특정 URL을 식별해야 합니다.[15][16] 예를 들어, 공격자가 Gmail을 공격하려고 하는 경우, 공격자는 사용자의 이메일에서 특정 검색어에 대해 발견된 검색 결과 수에 따라 다른 HTTP 응답을 반환하는 검색 URL을 찾으려고 시도할 수 있습니다.[17] 공격자가 특정 URL을 찾으면 웹 사이트를 호스팅하고 의심하지 않는 사용자를 웹 사이트로 피싱하거나 유인할 수 있습니다. 공격자가 공격자의 웹 사이트에 있으면 공격자는 다양한 임베딩 기술을 사용하여 공격자가 식별한 상태 종속 URL에 대한 교차 출처 HTTP 요청을 시작할 수 있습니다.[18] 그러나 공격자가 다른 웹 사이트에 있기 때문에 웹 브라우저에서 부과한 동일한 출처 정책으로 인해 공격자는 취약한 웹 사이트에서 보낸 응답의 일부를 직접 읽을 수 없습니다.[note 2][19]

이러한 보안 장벽을 회피하기 위해 공격자는 브라우저 유출 방법을 사용하여 서로 다른 응답 간의 미묘한 차이를 구별할 수 있습니다. 브라우저 유출 방법은 웹 브라우저의 오랜 정보 유출 문제(사이드 채널)를 활용하여 HTTP 응답에 대한 특정 특성을 드러내는 자바스크립트, CSS 또는 HTML 스니펫입니다.[15][16] Gmail의 경우 공격자는 자바스크립트를 사용하여 브라우저가 검색 결과에 의해 반환되는 HTTP 응답을 파싱하는 데 걸린 시간을 측정할 수 있습니다. 엔드포인트에서 반환된 응답을 구문 분석하는 데 걸리는 시간이 짧으면 공격자는 쿼리에 대한 검색 결과가 없다고 추론할 수 있습니다. 또는 사이트가 더 오래 걸린 경우 공격자는 여러 검색 결과가 반환되었다고 추론할 수 있습니다.[17] 공격자는 이후 이러한 정보 유출을 통해 얻은 정보를 사용하여 중요한 정보를 유출하여 피해자를 추적하고 익명화하는 데 사용할 수 있습니다.[18] Gmail의 경우 공격자는 쿼리를 사용하여 검색 엔드포인트에 요청을 한 후 쿼리가 특정 쿼리 문자열을 포함하는 이메일을 가지고 있는지 여부를 파악하는 데 걸린 시간을 측정할 수 있습니다.[note 3] 응답을 처리하는 데 매우 적은 시간이 걸리는 경우 공격자는 검색 결과가 반환되지 않았다고 가정할 수 있습니다. 반대로 응답 처리에 많은 시간이 소요되는 경우 공격자는 많은 검색 결과가 반환되었다고 추론합니다. 공격자는 여러 요청을 함으로써 피해자 응용 프로그램의 현재 상태에 대한 상당한 통찰력을 얻을 수 있으며, 잠재적으로 사용자의 개인 정보를 노출시켜 정교한 스팸 및 피싱 공격을 시작하는 데 도움이 될 수 있습니다.[20]

웹 페이지의 URL에 대한 교차 출처 요청을 시작하는 모든 방법은 모든 브라우저 유출 방법과 결합할 수 있지만, 서로 다른 포함 방법과 브라우저 유출 사이에 종속성이 존재하기 때문에 실제로는 작동하지 않습니다. 일부 브라우저 유출 방법은 성공하려면 특정 포함 기술이 필요합니다.[21] 예를 들어, 브라우저-누출 방법이 요소의 너비 및 높이와 같은 CSS 속성을 확인하는 것에 의존하는 경우, 포함 기법은 크로스-오리진 요청이 유효하지 않거나 다른 크기의 이미지를 반환할 때 변경되는 이미지 요소와 같은 너비 및 높이 속성을 갖는 HTML 요소를 사용해야 합니다.[22][23]

예

다음 진자 템플릿을 사용하여 구현된 검색 엔드포인트 인터페이스가 있는 Python 기반 웹 애플리케이션의 예는 사이트 간 유출 공격이 발생할 수 있는 일반적인 시나리오를 보여줍니다.[23] 

 <html랑그="en"> <몸> <h2>검색결과</h2>    {% 결과 %}     <디바학급="result">         <이그src="/cdn.com/result-icon.png "/>       {% result.desc 설명 %}    </디바>    {% %}에 대해 종료 </몸> </html>

이 코드는 웹 페이지에 검색 결과를 표시하기 위한 템플릿입니다. HTTP 서버 백엔드에 의해 제공되는 결과 모음을 루프하고 각 결과를 다른 웹 사이트에서 로드된 아이콘과 함께 구조화된 디바이 요소 내에 설명과 함께 표시합니다. 기본 응용 프로그램은 요청에 첨부된 쿠키를 기반으로 사용자를 인증하고 GET 매개 변수에 제공된 문자열을 사용하여 사용자의 개인 정보에 대한 텍스트 검색을 수행합니다. 반환되는 모든 결과에 대해 CDN(Content Delivery Network)에서 로드된 아이콘이 결과와 함께 표시됩니다.[13][24]

이 단순 기능은 다음 자바스크립트 스니펫에서 볼 수 있듯이 교차 누출 공격에 취약합니다.[13] 

허락하다 아이콘_url = 'https://cdn.com/result-icon.png'; 틀에 박히다.src = 'https://service.com/ ?q=password'; 틀에 박히다.적재 중인 = 비동기의 () => {      콘스트 시동을 걸다 = 성능.지금이다();      기다리다 가지고 오다(아이콘_url);      콘스트 지속 = 성능.지금이다() - 시동을 걸다;      한다면 (지속 < 5) // 캐시에서 로드된 리소스          위로하다.로그.('쿼리에 결과가 있음');      또 다른          위로하다.로그.('질의 매개 변수에 대한 결과 없음'); };

공격자가 제어하는 웹 앱에 내장될 수 있는 이 자바스크립트 스니펫은 iframe 내에서 피해 웹 앱을 로드하고 문서가 로드될 때까지 기다렸다가 CDN에 아이콘을 요청합니다. 공격자는 아이콘의 반환 타이밍을 지정하여 아이콘이 캐시되었는지 여부를 확인할 수 있습니다. 아이콘은 피해 앱이 적어도 하나의 결과를 반환하는 경우에만 캐시되기 때문에 공격자는 피해 앱이 지정된 쿼리에 대한 결과를 반환했는지 여부를 결정할 수 있습니다.[23][24][25]

역사

교차 사이트 유출은 2000년부터 알려져 왔습니다.[26] Purdue University의 그 해의 연구 논문에서는 HTTP 캐시를 사용하여 사용자의 브라우징 습관의 개인 정보를 손상시키는 이론적 공격에 대해 설명합니다.[27] 2007년에 스탠포드 대학의 Andrew Bortz와 Dan Boneh는 교차 사이트 응답의 크기를 결정하기 위해 타이밍 정보를 사용한 공격에 대해 자세히 설명하는 백서를 출판했습니다.[28] 2015년 Bar-Ilan University의 연구원들은 유사한 유출 방법을 사용했지만 응답의 크기를 늘리기 위해 입력을 조작하는 기술을 사용하여 응답을 생성하는 데 걸리는 시간을 비례적으로 증가시켜 공격의 정확성을 높이는 교차 사이트 검색 공격을 설명했습니다.[29]

독립 보안 연구원들은 실제 애플리케이션에 대한 사이트 간 유출 공격을 설명하는 블로그 게시물을 게시했습니다. 2009년, 크리스 에반스는 야후에 대한 공격을 묘사했습니다! 악의적인 사이트가 사용자의 받은 편지함에서 중요한 정보를 검색할 수 있는 메일입니다.[30] 2018년, 루안 헤라라(Luan Herara)는 크롬(Chrome), 앵글(Angle), 스키아 그래픽 엔진(Skia Graphics Engine)과 같은 오픈 소스 프로젝트에서 적극적으로 사용되는 구글 모노레일 버그 트래커(Google Monorail Bug Tracker)의 검색 기능을 사용하여 민감한 보안 문제에 대한 데이터를 유출할 수 있는 보안 악용을 설명했습니다.[31][32] 2019년 폴란드의 보안 연구원인 Terjanq는 구글의 유명 제품 전반에 걸쳐 민감한 사용자 정보를 유출할 수 있는 사이트 간 검색 공격에 대해 설명하는 블로그 게시물을 게시했습니다.[11][25]

오랜 웹 플랫폼 기능을 잘못 사용하는 것에 의존하는 보안 문제를 해결하는 데 더 많은 초점을 맞추기 위해 Google은 2020년에 XSLeaks Wiki를 출시하여 개방형 지식 데이터베이스를 만들고 사이트 간 유출 공격에 대한 정보를 분석하고 컴파일하려고 시도했습니다.[30][33][34]

2020년부터 학계에서는 이러한 공격의 분류를 표준화하는 데 관심이 있었습니다. 2020년 Sudhodanan 등은 사이트 간 유출에 대한 이전 작업을 체계적으로 요약한 최초의 사례 중 하나로, 유출 URL을 탐지하는 데 사용할 수 있는 BASTA-COSI라는 도구를 개발했습니다. [34][35] 2021년에 Knittel 등은 사이트 간 누출을 평가하고 특성화하기 위한 새로운 공식 모델을 제안하여 연구자들이 여러 브라우저에 영향을 미치는 새로운 누출을 찾을 수 있도록 했습니다. [34][36] 2022년 Van Goethem et al. 이러한 공격에 대한 현재 사용 가능한 방어를 평가하고 기존 모델을 확장하여 브라우저 구성 요소의 상태를 모델의 일부로 고려했습니다.[34][16] 2023년에는 Rautenstrauch 등이 발표한 논문으로, 교차 사이트 유출에 대한 이전 연구를 체계화하여 IEEE Symposium of Security and Privacy에서 저명한 논문상을 수상했습니다.[37]

종류들

사이트 간 누출은 확립된 균일한 분류가 없는 매우 다양한 범위의[38] 공격으로 구성됩니다.[39] 그러나 일반적으로 여러 출처에서 이러한 공격을 공격 중에 사용되는 누출 기술에 따라 분류했습니다.[21] 2021년 현재 연구원들은 브라우저의 구성 요소를 대상으로 하는 38개 이상의 유출 기술을 확인했습니다.[13] 웹 사이트가 브라우저에 특정 정보를 조회할 수 있는 자바스크립트 인터페이스인 웹 플랫폼 API의 변화로 인해 일반적으로 새로운 기술이 발견됩니다.[40] 이러한 기술의 대부분은 피해 웹 앱의 상태 변화를 직접 감지하는 것이지만, 일부 공격은 브라우저 내 공유 구성 요소의 변경을 이용하여 피해 웹 앱에 대한 정보를 간접적으로 수집하기도 합니다.[21]

타이밍 공격

타이밍 공격은 여러 응답에 걸쳐 특정 이벤트의 시간을 지정하는 기능에 의존합니다.[41] 이것들은 2007년 스탠포드 대학의 연구원들에 의해 발견되었고, 가장 오래된 것으로 알려진 사이트 간 누출 공격 유형 중 하나입니다.[28]

처음에는 HTTP 요청이 응답을 해결하는 데 걸린 시간을 구별하는 데만 사용되었지만,[28] 2007년 이후에 수행된 연구에서는 웹 앱 상태 간의 다른 차이점을 탐지하는 데 이 누출 기술을 사용하는 것이 입증되었습니다. 2017년 Vila 등은 타이밍 공격이 내장된 컨텍스트에서 교차 출처 실행 시간을 추론할 수 있음을 보여주었습니다. 이는 동시대 브라우저의 사이트 격리 기능이 부족하여 공격 웹 사이트가 공격 대상 웹 앱에 이벤트를 보낼 때 실행되는 자바스크립트 양의 차이로 인해 발생하는 타이밍 차이를 줄이고 증폭할 수 있었기 때문에 가능했습니다.[42][43]

2021년에 Knittel 등은 Performance API가[note 4] 응답에서 리디렉션의 유무를 유출할 수 있음을 보여주었습니다. 이는 성능 API의 버그로 인해 리디렉션이 발생했을 때 사용자에게 표시되는 시간이 음수가 될 수 있기 때문에 가능했습니다. 구글 크롬은 이후 이 버그를 수정했습니다.[45] 2023년 Snyder 등은 타이밍 공격을 사용하여 웹 사이트가 글로벌 할당량을 소진하여 공유 리소스를 차단할 수 있는 풀 파티 공격을 수행할 수 있음을 보여주었습니다. 피해 웹 앱이 이러한 공유 리소스를 사용한 자바스크립트를 실행하도록 한 다음 이러한 실행에 걸린 시간을 측정함으로써 연구원들은 웹 앱의 상태에 대한 정보를 밝힐 수 있었습니다.

오류 이벤트

오류 이벤트는 공격자가 오류 이벤트 핸들러를 등록하고 이를 통해 이벤트를 청취함으로써 여러 응답을 구별할 수 있도록 하는 누출 기술입니다. 다양한 정보를 유출할 수 있는 범용성과 능력으로 인해 오류 이벤트는 전형적인 사이트 간 유출 벡터로 간주됩니다.[47]

사이트 간 유출 공격에서 오류 이벤트에 대한 가장 일반적인 사용 사례 중 하나는 이벤트 핸들러를 연결하여 HTTP 응답을 결정하는 것입니다. onload 그리고. onerror HTML 요소에 대한 이벤트 처리기 및 특정 오류 이벤트가 발생하기를 기다리는 중입니다. 오류 이벤트가 부족하면 HTTP 오류가 발생하지 않았음을 나타냅니다. 반대로 핸들러가 onerror 는 특정 오류 이벤트로 트리거되며 공격자는 해당 정보를 사용하여 HTTP 콘텐츠 유형, 상태 코드 및 미디어 유형 오류를 구별할 수 있습니다.[48] 2019년, TU Darmstadt의 연구원들은 이 기술이 사용자들이 임의의 콘텐츠를 서로 공유할 수 있도록 하는 Dropbox, Google Docs 및 GitHub와 같은 인기 웹 서비스 사용자들에 대한 표적 익명화 공격을 수행하는 데 사용될 수 있음을 보여주었습니다.[49][50]

2019년부터 오류 이벤트의 기능이 확대되었습니다. 2020년 Jan 등은 페치 요청에 대한 리다이렉트 모드를 다음으로 설정하여 보여주었습니다. manual, 웹사이트는 특정 URL이 리디렉션인지 여부에 대한 정보를 유출할 수 있습니다.[51][43] 비슷한 시기에 Jon Masasas와 Luan Herara는 URL 관련 제한을 악용하여 공격자가 URL에 대한 리디렉션 정보를 유출하는 데 사용할 수 있는 오류 이벤트를 트리거할 수 있음을 보여주었습니다.[52] 2021년에 Knittel 등은 웹사이트 로드가 변경되거나 손상되지 않은 하위 리소스를 확인하는 데 사용되는 메커니즘인 하위 리소스 무결성 검사에 의해 생성되는 오류 이벤트를 보여주었고, HTTP 응답의 원시 내용을 추측하고 응답의 내용 길이를 유출하는 데도 사용될 수 있습니다.[53][54]

캐시 타이밍 공격

캐시 타이밍 공격은 웹 플랫폼의 공유 캐시에서 히트와 미스를 추론하는 기능에 의존합니다.[55] 캐시 타이밍 공격의 첫 번째 사례 중 하나는 페이지에 교차 원본 요청을 한 다음 공유 HTTP 및 DNS 캐시에서 요청에 의해 로드된 리소스의 존재를 조사하는 것입니다. 이번 공격에 대해 설명하는 논문은 2000년 퍼듀대학교 연구진이 작성한 것으로, 웹페이지 고유의 리소스가 로드되었는지를 선택적으로 확인하여 사용자의 브라우징 이력의 상당 부분을 유출하는 공격 능력에 대해 설명하고 있습니다.[56][55][57]

이 공격은 점점 더 정교해져 다른 유형의 정보가 유출될 수 있습니다. 2014년 지아 등은 이 공격이 다국적 웹사이트 그룹의 현지화된 도메인을 로드하는 데 걸리는 시간을 측정하여 사람의 위치를 파악할 수 있음을 보여주었습니다.[55][58][59] 2015년 Van Goethem 등은 당시 새로 도입된 애플리케이션 캐시를 사용하여 웹사이트가 피해 웹사이트가 보내는 캐싱 지침을 무시하고 무시하도록 브라우저에 지시할 수 있음을 보여주었습니다. 이 논문은 또한 웹사이트가 캐시 액세스 타이밍을 조정하여 캐시 응답의 크기에 대한 정보를 얻을 수 있음을 보여주었습니다.[60][61]

글로벌 한계

풀 파티 공격이라고도 하는 전역 제한은 피해자 웹 앱의 상태에 직접 의존하지 않습니다. 이 교차 사이트 누출은 2020년 Knittel 등에 의해 처음 발견된 후 2023년 Snyder 등에 의해 확장되었습니다.[46] 글로벌 운영 체제 또는 하드웨어 제한을 악용하여 공유 리소스를 부족하게 만드는 공격입니다.[62] 악용될 수 있는 전역 제한에는 등록할 수 있는 원시 소켓 연결 수와 등록할 수 있는 서비스 작업자 수가 포함됩니다. 공격자는 이러한 전역 제한을 트리거하는 활동을 수행하고 피해 웹 사이트를 로드하지 않고 동일한 활동을 수행할 때 브라우저 동작의 차이를 비교하여 피해 웹 사이트의 상태를 추론할 수 있습니다.[63] 이러한 유형의 공격은 일반적으로 타이밍 사이드 채널도 필요하기 때문에 타이밍 공격으로 간주됩니다.[46]

기타기법

2019년 Gareth Heyes는 웹사이트의 URL 해시를 특정 값으로 설정하고 이후 현재 웹페이지에 대한 초점 손실이 발생했는지 여부를 탐지함으로써 공격자가 피해 웹사이트에 있는 요소의 존재와 위치를 파악할 수 있음을 발견했습니다.[64] 2020년에 Knittel 등은 공격자가 A/S 여부를 유출할 수 있음을 보여주었습니다. Cross-Origin-Opener-Policy 헤더는 에 대한 참조를 얻음으로써 설정되었습니다. window 웹 사이트를 프레이밍하거나 피해 웹 사이트 팝업을 생성하여 피해 웹 사이트의 개체입니다. 공격자는 윈도우 참조를 얻는 동일한 기술을 사용하여 공격자가 피해자 웹 사이트가 다음을 통해 가지고 있는 프레임 수를 계산할 수도 있습니다. window.length 재산[45][65]

새로운 기술이 계속 발견되고 있지만, 월드 와이드 웹 컨소시엄(W3C) 사양의 변경과 브라우저의 업데이트로 인해 사이트 간 유출을 수행하는 오래된 기술은 더 이상 쓸모가 없게 되었습니다. 2020년 12월, 애플은 자사의 브라우저 사파리의 ITP(Intelligent Tracking Prevention) 메커니즘을 업데이트하여 구글의 연구원들이 다양한 사이트 간 유출 기술이 효과가 없음을 발견했습니다.[66][67][68] 마찬가지로 2020년 모든 주요 브라우저에서 캐시 파티셔닝이 널리 도입되면서 캐시 타이밍 공격의 잠재력이 감소했습니다.[69]

디펜스

2000년 이후로 알려졌음에도 불구하고, 교차 사이트 누출에 대한 대부분의 방어는 2017년 이후에 도입되었습니다.[70] 이러한 방어 기능이 도입되기 전에 웹 사이트는 모든 애플리케이션 상태에 대해 동일한 응답이 반환되도록 하여 공격자가 요청을 구별할 수 없도록 함으로써 사이트 간 유출을 방지할 수 있었습니다. 이 접근 방식은 사소하지 않은 웹 사이트에서는 실행할 수 없었습니다. 두 번째 접근 방식은 사용자의 세션 외부에서 작동하지 않는 세션별 URL을 만드는 것이었습니다. 이 접근 방식은 링크 공유를 제한하므로 실행 불가능하고 비현실적입니다.[26][71]

사이트 간 유출에 대한 대부분의 최신 방어는 상태 변경을 방지하거나, 소스 간 요청을 상태 비저장 상태로 만들거나, 여러 소스 간에 공유 리소스를 완전히 격리하는 HTTP 프로토콜의 확장입니다.[69]

공유 리소스 격리

§ 예제에서 설명한 캐시 타이밍 공격의 원시 데이터입니다. 캐시 파티셔닝을 사용하지 않도록 설정하면 캐시된 응답과 캐시되지 않은 응답을 명확하게 구분할 수 있는 반면, 캐시 파티셔닝을 사용하면 두 응답 시간이 겹칩니다.
캐시된 응답
cached이 아닌 반응

사이트 간 유출을 수행하는 가장 초기의 가장 잘 알려진 방법 중 하나는 HTTP 캐시를 사용하는 것이었는데, 이는 피해자의 웹 사이트가 로드했을 수 있는 고유한 리소스를 브라우저 캐시에 쿼리하는 데 의존하는 접근 방식이었습니다. 교차 출처 요청이 공격 웹 사이트를 해결하는 데 걸린 시간을 측정하여 리소스가 캐시되었는지 여부와 캐시된 경우 피해자 앱의 상태를 확인할 수 있습니다.[24][72] 2020년 10월 현재 대부분의 브라우저는 HTTP 캐시 파티셔닝을 구현하여 이 접근 방식의 효과를 크게 저하시켰습니다.[73] HTTP 캐시 분할은 리소스를 요청한 웹 사이트에 따라 각 캐시 요청을 다중 키로 설정하여 작동합니다. 즉, 웹 사이트가 리소스를 로드하고 캐시하는 경우 캐시된 요청은 리소스 URL과 요청 웹 사이트의 리소스 URL을 연결하여 생성된 고유 키에 연결됩니다. 다른 웹 사이트가 동일한 리소스에 액세스하려고 하면 해당 웹 사이트가 이전에 동일한 요청을 캐시하지 않는 한 요청은 캐시 누락으로 처리됩니다. 이렇게 하면 공격 웹 사이트가 리소스가 공격 대상 웹 사이트에 의해 캐시되었는지 여부를 추론할 수 없습니다.[74][75][76]

실행 컨텍스트를 분리할 수 있는 또 다른 개발자 지향 기능은 다음과 같습니다. Cross-Origin-Opener-Policy 원래 브라우저의 Spectre 문제를 해결하기 위해 추가된 COOP(COOP) 헤더입니다.[77][78] 헤더가 다음과 같이 설정되어 있으면 사이트 간 누출을 방지하는 데 유용한 것으로 입증되었습니다. same-origin 이에 대한 응답의 일환으로 브라우저는 origin 교차 웹 사이트가 타사 페이지에서 열렸을 때 방어 웹 사이트에 대한 참조를 보유할 수 없도록 합니다.

사이트 간 유출을 완화하기 위한 노력의 일환으로 브라우저 Chrome, Brave, Microsoft Edge, Firefox 및 Safari의 개발자는 스토리지 파티셔닝을 구현하여 [82]각 웹 사이트에서 사용하는 모든 공유 리소스를 멀티 키로 사용할 수 있도록 하여 웹 앱의 상태를 추론할 수 있는 포함 기술의 수를 크게 줄였습니다.[83]

상태 변경 방지

사이트 간 유출 공격은 악의적인 웹 페이지가 피해자 응용 프로그램으로부터 출처 간 응답을 받는 능력에 따라 달라집니다. 악의적인 응용 프로그램이 교차 출처 응답을 받을 수 없도록 함으로써 사용자는 더 이상 상태 변경 사항이 유출될 위험이 없습니다.[84] 이 접근 방식은 더 이상 사용되지 않는 헤더와 더 새로운 헤더와 같은 방어에서 볼 수 있습니다. frame-ancestors 내용-보안 정책 헤더의 지시문을 사용하면 공격 대상 응용 프로그램이 내장된 프레임으로 포함할 수 있는 웹 사이트를 지정할 수 있습니다.[85] 공격자 앱이 신뢰할 수 없는 컨텍스트에서 웹 사이트의 임베딩을 허용하지 않으면 악의적인 앱은 임베디드 프레임 기법을 사용하여 공격자 앱에 대한 교차 출처 요청에 대한 응답을 더 이상 관찰할 수 없습니다.[86][87]

유사한 접근 방식은 CORB(Cross-Origin Resource Blocking) 메커니즘과 Cross-Origin-Resource-Policy CORP(cross-origin request)를 성공시키되 예상된 내용 유형과 수신된 내용 유형 사이에 불일치가 있는 경우 타사 웹 사이트에서 내용을 로드하는 것을 차단하는 헤더입니다.[88] 이 기능은 원래 Spectre 취약성에[89] 대한 일련의 완화 기능의 일부로 도입되었지만 악의적인 웹 페이지가 응답을 수신하지 못하도록 차단하여 상태 변경을 추론하기 때문에 교차 출처 유출을 방지하는 데 유용한 것으로 입증되었습니다.[86][90][91]

원본 간 요청 상태 비저장

사이트 간 누출을 완화하기 위한 가장 효과적인 방법 중 하나는 다음을 사용하는 것입니다. SameSite 쿠키의 매개 변수. 설정이 완료되면 Lax 또는 Strict, 이 매개 변수는 브라우저가 대부분의 타사 요청에서 쿠키를 보내지 못하게 하여 사실상 요청 상태를 비저장 상태로 만듭니다.[note 5][91] 채택여부 Same-Site 그러나 쿠키는 인증 공급자와 같은 많은 전문 웹 서버가 작동하는 방식에 변화가 필요하기 때문에 속도가 느렸습니다.[93] 2020년 크롬 브라우저 제조업체는 전원을 켤 것이라고 발표했습니다. SameSite=Lax 모든 플랫폼에서 쿠키의 기본 상태입니다.[94][95] 그럼에도 불구하고 여전히 다음과 같은 경우가 있습니다. SameSite=Lax 쿠키는 Chrome과 같이 존중되지 않습니다. LAX+POST 교차 origin 사이트가 다음과 같은 방법을 사용할 수 있도록 하는 완화. SameSite=Lax 페이지를 탐색하는 동안 요청이 전송되고 쿠키가 설정된 후 2분 이내에 발생하는 경우에만 요청 내 쿠키.[92] 이로 인해 이 문제에 대한 우회 및 해결 방법이 발생했습니다. SameSite=Lax 여전히 사이트 간 누출이 발생할 수 있는 제한.[96][97]

다음을 포함하는 메타데이터 헤더 가져오기 Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User 그리고. Sec-Fetch-Dest 또한 요청을 시작한 도메인에 대한 정보, 요청의 시작에 대한 세부 정보 및 요청 대상을 방어 웹 서버에 각각 제공하는 헤더를 사용하여 사이트 간 유출 공격을 완화했습니다.[98] 이러한 헤더를 통해 웹 서버는 합법적인 타사 동일 사이트 요청과 유해한 교차 출처 요청을 구분할 수 있습니다. 이러한 요청을 구별함으로써 서버는 악의적인 타사 요청에 대해 상태 비저장 응답을 보내고 일상적인 동일 사이트 요청에 대해 상태 비저장 응답을 보낼 수 있습니다.[99] 이러한 헤더의 남용을 방지하기 위해 웹 앱은 이러한 헤더를 설정할 수 없으며, 이 헤더는 브라우저에서만 설정해야 합니다.[100][75]

참고 항목

참고문헌

메모들

  1. ^ 웹 브라우저와 웹 서버 간의 상호 작용이 발생할 수 있는 다른 방법(예: WebRTC 프로토콜)이 있지만 사이트 간 유출의 경우 HTTP 상호 작용과 웹소켓 연결만 중요하게 간주됩니다.[1] 이 글의 나머지 부분에서는 HTTP 상호작용과 웹소켓 연결이 웹 브라우저가 웹 서버와 상호작용하는 유일한 두 가지 방법이라고 가정합니다.
  2. ^ 여기에는 상태 코드 및 HTTP 헤더와[19] 같은 응답과 관련된 메타데이터가 포함됩니다.
  3. ^ 이러한 쿼리의 예로는 잘 알려진 은행의 이름이나 사용자가 상호 작용했을 것으로 예상되는 개인 또는 조직의 연락처가 있습니다.[20]
  4. ^ Performance API는 웹 사이트가 웹 성능과[44] 관련된 다양한 메트릭을 검색할 수 있도록 하는 자바스크립트 함수 세트입니다.
  5. ^ 설정하기 Strict 지침은 모든 사이트 간 요청이 상태 비저장 상태임을 보장하는 반면, Lax 브라우저가 상태가 아닌 변경을 위해 쿠키를 보낼 수 있습니다. GET 또는 HEAD) 크로스 origin 페이지에서 다른 페이지로 이동하는 동안 전송되는 요청입니다.

인용문

  1. ^ Knittel et al. 2021, pp. 1773, 1776.
  2. ^ "How the web works – Learn web development MDN". MDN Web Docs. 24 July 2023. Archived from the original on 24 September 2023. Retrieved 1 October 2023.
  3. ^ Wagner, David; Weaver, Nicholas; Kao, Peyrin; Shakir, Fuzail; Law, Andrew; Ngai, Nicholas. "Cookies and Session Management". UC Berkley CS-161 Computer Security Textbook. Retrieved 24 March 2024.
  4. ^ 수도다난, 호다야리 & 카바예로 2020, 페이지 2-3.
  5. ^ Zaleewski 2011, p. 15.
  6. ^ Schwenk, Niemietz & Mainka 2017, 페이지 713.
  7. ^ 잘류스키 2011, 페이지 16.
  8. ^ Schwenk, Niemietz & Mainka 2017, 페이지 716.
  9. ^ Somé 2018, pp. 13-14.
  10. ^ "Same-origin policy - Security on the web MDN". MDN Web Docs. 20 December 2023. Retrieved 24 March 2024.
  11. ^ a b Knittel et al. 2021, p. 1772.
  12. ^ Van Goethem et al. 2021, p. 1.
  13. ^ a b c d Van Goethem et al. 2022, p. 786.
  14. ^ 수도다난, 호다야리 & 카바예로 2020, 페이지 11.
  15. ^ a b Rautenstrauch, Pellegrino & Stock 2023, p. 2747.
  16. ^ a b c Van Goethem et al. 2022, p. 787.
  17. ^ a b Gelernter & Herzberg 2015, pp. 1399–1402.
  18. ^ a b 수도다난, 호다야리 & 카바예로 2020, 페이지 1.
  19. ^ a b Van Goethem et al. 2016, p. 448.
  20. ^ a b Gelernter & Herzberg 2015, p. 1400.
  21. ^ a b c Van Goethem et al. 2022, p. 788.
  22. ^ Rautenstrauch, Pellegrino & Stock 2023, p. 2745.
  23. ^ a b c Van Goethem et al. 2022, p. 785.
  24. ^ a b c Felten & Schneider 2000, 페이지 26.
  25. ^ a b Terjanq. "Mass XS-Search using Cache Attack – HackMD". GitHub. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  26. ^ a b Rautenstrauch, Pellegrino & Stock 2023, p. 2754.
  27. ^ Felten & Schneider 2000, pp. 25, 26, 27, 31.
  28. ^ a b c Bortz & Boneh 2007, pp. 623–625.
  29. ^ Gelernter & Herzberg 2015, pp. 1394–1397.
  30. ^ a b Walker, James (21 March 2019). "New XS-Leak techniques reveal fresh ways to expose user information". The Daily Swig. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  31. ^ Van Goethem et al. 2021, pp. 1, 6.
  32. ^ Herrera, Luan (31 March 2019). "XS-Searching Google's bug tracker to find out vulnerable source code". Medium. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  33. ^ Van Goethem et al. 2021, p. 10.
  34. ^ a b c d Rautenstrauch, Pellegrino & Stock 2023, p. 2756.
  35. ^ 수도다난, 호다야리 & 카바예로 2020, 페이지 2.
  36. ^ Knittel et al. 2021, p. 1773.
  37. ^ "IEEE Symposium on Security and Privacy 2023". sp2023.ieee-security.org. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  38. ^ Van Goethem et al. 2022, p. 784.
  39. ^ Rautenstrauch, Pellegrino & Stock 2023, p. 2748.
  40. ^ Rautenstrauch, Pellegrino & Stock 2023, 페이지 2755-2756.
  41. ^ Van Goethem et al. 2022, pp. 796, 797.
  42. ^ Vila & Köpf 2017, pp. 851–853.
  43. ^ a b Van Goethem et al. 2022, p. 796.
  44. ^ "Performance - Web APIs MDN". MDN Web Docs. 19 February 2023. Retrieved 11 March 2024.
  45. ^ a b Knittel et al. 2021, p. 1778.
  46. ^ a b c 스나이더 외. 2023, 페이지 7095.
  47. ^ Knittel et al. 2021, p. 1775.
  48. ^ Knittel et al. 2021, pp. 1775, 1785.
  49. ^ Staicu & Pradel 2019, pp. 924, 930.
  50. ^ 자헤리, 오렌 & 커트몰라 2022, 페이지 1505.
  51. ^ Knittel et al. 2021, p. 1785.
  52. ^ Knittel et al. 2021, pp. 1777, 1785.
  53. ^ Knittel et al. 2021, pp. 1778, 1782.
  54. ^ Van Goethem et al. 2022, p. 789.
  55. ^ a b c Mishra et al. 2021, p. 404.
  56. ^ Felten & Schneider 2000, pp. 25, 28, 29.
  57. ^ Bansal, Preibusch & Milic-Frailling 2015, p. 97.
  58. ^ 지아 외. 2015, pp. 1, 2.
  59. ^ Bansal, Preibush & Milic-Frailling 2015, p. 99.
  60. ^ Van Goethems, Joosen & Nikiforakis 2015, pp. 1385, 1386.
  61. ^ Kim, Lee & Kim 2016, 페이지 411-413.
  62. ^ 스나이더 외. 2023, pp. 7096, 7097
  63. ^ Knittel et al. 2021, pp. 1782, 1776–1778.
  64. ^ "XS-Leak: Leaking IDs using focus". PortSwigger Research. 8 October 2019. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
  65. ^ Van Goethem et al. 2022, p. 797.
  66. ^ Ng, Alfred. "Google finds Apple Safari anti-tracking feature actually enabled tracking". CNET. Archived from the original on 11 December 2023. Retrieved 28 December 2023.
  67. ^ Wilander, John (10 December 2019). "Preventing Tracking Prevention Tracking". WebKit. Archived from the original on 16 November 2023. Retrieved 28 December 2023.
  68. ^ Janc, Artur; Kotowicz, Krzysztof; Weichselbaum, Lukas; Clapis, Roberto. "Information Leaks via Safari's Intelligent Tracking Prevention". Google Research. Archived from the original on 28 December 2023. Retrieved 28 December 2023.
  69. ^ a b Knittel et al. 2021, p. 1780.
  70. ^ Van Goethem et al. 2021, p. 16.
  71. ^ 자헤리 & 커트몰라 2021, 페이지 160.
  72. ^ Mishra et al. 2021, p. 399.
  73. ^ 도안 외. 2022.
  74. ^ Kitamura, Eiji (6 October 2020). "Gaining security and privacy by partitioning the cache". Chrome for Developers. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  75. ^ a b Van Goethem et al. 2021, p. 7.
  76. ^ Bannister, Adam (13 October 2020). "Google Chrome partitions browser HTTP cache to defend against XS-Leak attacks". The Daily Swig. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  77. ^ Reis, Moshchuk & Oskov 2019, p. 1674.
  78. ^ Van Goethem, Sanche-Rola & Joosen 2023, 페이지 379.
  79. ^ Van Goethem et al. 2022, p. 792.
  80. ^ "Cross-Origin-Opener-Policy – HTTP MDN". MDN Web Docs. 10 April 2023. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
  81. ^ Kitamura, Eiji. "Making your website "cross-origin isolated" using COOP and COEP Articles". web.dev. Archived from the original on 31 October 2023. Retrieved 31 October 2023.
  82. ^ 스나이더 외. 2023, 페이지 7092.
  83. ^ "State Partitioning - Privacy on the web MDN". MDN Web Docs. 24 July 2023. Retrieved 5 February 2024.
  84. ^ Van Goethem et al. 2022, p. 791.
  85. ^ Calzavara et al. 2020, pp. 684, 685.
  86. ^ a b Van Goethem et al. 2021, p. 5.
  87. ^ "X-Frame-Options – HTTP MDN". MDN Web Docs. 25 July 2023. Archived from the original on 27 October 2023. Retrieved 29 October 2023.
  88. ^ "Cross-Origin Read Blocking (CORB)". Chromium Gerrit. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
  89. ^ Reis, Moshchuk & Oskov 2019, pp. 1665, 1666.
  90. ^ "Cross-Origin Resource Policy (CORP) – HTTP MDN". MDN Web Docs. 10 May 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  91. ^ a b Knittel et al. 2021, p. 1781.
  92. ^ a b 호다야리 & 펠레그리노 2022, p. 1592.
  93. ^ Hodayari & Pellegrino 2022, p. 1590
  94. ^ Hodayari & Pellegrino 2022, pp. 1596, 1600
  95. ^ Compagna et al. 2021, pp. 50-51
  96. ^ "Bypassing SameSite cookie restrictions Web Security Academy". Portswigger Research. Archived from the original on 29 October 2023. Retrieved 29 October 2023.
  97. ^ Hodayari & Pellegrino 2022, 1596–1598 페이지.
  98. ^ Weichselbaum, Lukas. "Protect your resources from web attacks with Fetch Metadata Articles". web.dev. Archived from the original on 7 November 2023. Retrieved 7 November 2023.
  99. ^ 맥주 외 2021.
  100. ^ "Sec-Fetch-Site – HTTP MDN". MDN Web Docs. 25 October 2023. Archived from the original on 29 October 2023. Retrieved 29 October 2023.

원천

추가읽기

외부 링크