공격 유형

클릭재킹은 사용자가 생각하는 것과 다른 링크, 버튼 등을 클릭하도록 사용자를 속이는 행위입니다. 예를 들어 로그인 자격 증명을 훔치거나 멀웨어를 설치하기 위해 사용자도 모르게 권한을 얻는 데 사용할 수 있습니다. (클릭재킹은 때때로 "사용자 인터페이스 교정"이라고 하지만 이는 "교정"이라는 용어를 오용한 것입니다.)

교차 사이트 스크립팅(XSS)은 공격자가 웹 사이트에 악성 클라이언트 측 코드를 주입할 수 있는 보안 공격입니다. 이 코드는 피해자에 의해 실행되며 공격자가 접근 제어를 우회하고 사용자를 가장할 수 있습니다. Open Web Application Security Project에 따르면 XSS는 2017년에 7번째로 가장 흔한 웹 앱 취약점이었습니다.

이러한 공격은 웹 앱이 충분한 유효성 검사 또는 인코딩을 사용하지 않는 경우 성공합니다. 사용자의 브라우저는 악의적인 스크립트가 신뢰할 수 없는지를 감지할 수 없으므로 쿠키, 세션 토큰 또는 다른 중요한 사이트별 정보에 대한 접근 권한을 가져가거나 악의적인 스크립트로 HTML 내용을 다시 쓸 수 있습니다.

일반적으로 교차 사이트 스크립팅 공격은 1) 데이터가 신뢰할 수 없는 소스(대부분 웹 요청)를 통해 웹 앱에 입력되거나 2) 악성 콘텐츠에 대한 유효성 검사 없이 동적 콘텐츠를 웹 사용자에게 전송될 때 발생합니다.

악성 콘텐츠에는 보통 JavaScript가 포함되지만 가끔 HTML, Flash 또는 브라우저에서 실행할 수 있는 기타 코드가 포함되기도 합니다. XSS를 기반으로 하는 공격의 종류에는 거의 제한이 없지만, 일반적으로 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 보내거나, 공격자가 제어하는 웹 페이지로 피해자를 리다이렉션하거나, 취약한 사이트를 가장하여 사용자의 컴퓨터에서 다른 악의적인 작업을 수행하는 것이 포함됩니다.

XSS 공격은 저장(영구라고도 함), 반사(비영구라고도 함) 또는 DOM 기반의 세 가지 범주로 나눌 수 있습니다.

저장된 XSS 공격

삽입된 스크립트는 대상 서버에 영구적으로 저장됩니다. 그런 다음 피해자는 브라우저가 데이터 요청을 보낼 때 서버에서 이 악성 스크립트를 검색하게 됩니다.

반사된 XSS 공격

사용자가 속아서 악성 링크를 클릭하거나 특수 제작된 양식을 제출하거나 악성 사이트를 탐색하면 삽입된 코드가 취약한 웹 사이트로 이동합니다. 웹 서버는 오류 메시지, 검색 결과 또는 요청의 일부로 서버에 전송된 데이터를 포함하는 기타 응답과 같이 주입된 스크립트를 사용자의 브라우저에 다시 반사합니다. 브라우저는 응답이 사용자가 이미 상호 작용한 "신뢰할 수 있는" 서버에서 온 것으로 생각하기 때문에 이 코드를 실행합니다.

DOM기반 XSS 공격

페이로드는 원본 클라이언트 측 스크립트가 사용하는 DOM 환경(피해자의 브라우저에서)을 수정한 결로 실행됩니다. 즉, 페이지 자체는 변경되지 않지만 DOM 환경에 대한 악의적인 수정으로 인해 페이지에 포함된 클라이언트 측 코드가 예기치 않은 방식으로 실행됩니다.

CSRF(XSRF라고도 함)는 관련 클래스의 공격입니다. 공격자는 사용자의 동의나 인지 없이 사용자의 브라우저가 웹사이트의 백엔드에 요청을 수행하도록 합니다. 공격자는 XSS 페이로드를 사용하여 CSRF 공격을 할 수 있습니다.

위키백과에 CSRF에 대한 좋은 예제가 있습니다. 이 상황에서는 누군가가 실제 이미지가 아닌 이미지를 삽입합니다(예: 필터링되지 않은 채팅 또는 포럼에). 대신 이 이미지는 은행 서버에 돈을 인출하라는 요청입니다.

<img
  src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />

이제 은행 계좌에 로그인되어 있고, 쿠키가 여전히 유효한 경우라면(다른 확인이 없는 경우) 이 이미지가 포함된 HTML을 로드하는 즉시 송금이 진행됩니다. POST 요청이 필요한 엔드포인트 경우, 페이지가 로드될 때 프로그래밍 방식으로 <form> 제출(보이지 않는 <iframe>에서)을 트리거할 수 있습니다.

<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob" />
  <input type="hidden" name="amount" value="1000000" />
  <input type="hidden" name="for" value="mallory" />
</form>
<script>
  window.addEventListener("DOMContentLoaded", () => {
    document.querySelector("form").submit();
  });
</script>

이러한 일이 발생하지 않도록 하기 위해 사용해야 하는 몇 가지 기술이 있습니다.

• GET 엔드포인트는 멱등적이어야 합니다. 변경 사항을 적용하고 데이터를 검색하지 않는 작업은 POST(또는 다른 HTTP 메서드) 요청을 보내야 합니다. POST 엔드포인트는 쿼리 문자열의 매개변수를 사용하여 GET 요청을 상호 교환적으로 수락해서는 안 됩니다.
• 세션 고유 CSRF 토큰이 서버에서 브라우저로 제공되어야 합니다. 이 토큰은 브라우저에서 양식을 게시할 때마다(<form> 요소의 숨겨진 입력 필드에) 포함될 수 있습니다. 작업을 수행할 가능성이 있는 GET 이외의 모든 요청에 대해 서버는 전송된 토큰을 세션에 저장된 값과 비교합니다. 일치하지 않는 경우 요청이 중단됩니다.
• 이 보호 방법은 사용자에게 할당된 CSRF 토큰을 예측할 수 없는 공격자에 의존합니다. 로그인 시 토큰을 다시 생성해야 합니다.
• (세션 쿠키와 같은) 민감한 작업에 사용되는 쿠키는 SameSite 속성이 Strict 또는 Lax로 설정된 짧은 수명을 가져야 합니다. (위의 SameSite 쿠키 참조). 이는 지원되는 브라우저에서 세션 쿠키가 사이트 간 요청과 함께 전송되지 않도록 하는 효과가 있으므로 요청이 애플리케이션 서버에 대해 효과적으로 인증되지 않습니다.
• CSRF 토큰과 SameSite 쿠키를 모두 제공해야 합니다. 이렇게 하면 모든 브라우저가 보호되고 SameSite 쿠키가 도움이 되지 않는 곳에서도 보호 기능을 제공할 수 있습니다(예: 별도의 하위 도메인에서 시작된 공격).

더 많은 예방 팁은 OWASP CSRF 예방 치트 시트를 참조하십시오.

제3자는 웹 서버와 클라이언트(브라우저) 간의 트래픽을 가로채고 데이터(예: 로그인 자격 증명 또는 신용 카드 정보)를 캡처하기 위해 웹 서버를 가장합니다. 트래픽이 통과될 때 트래픽이 변경될 수 있습니다. 개방형 Wi-Fi 네트워크는 이 공격을 실행하는 일반적인 수단입니다.

세션 하이재킹은 사용자의 인증된 세션에 액세스하고 오용하는 것으로 구성됩니다. 이는 기존 세션의 쿠키를 훔치거나 사용자(또는 브라우저)를 속여 미리 결정된 세션 ID로 쿠키를 설정함으로써 발생할 수 있습니다.

유출 경로는 엄격한 Content-Security-Policy를 배포하여 제한할 수 있습니다.

제3자는 사용자의 세션 식별자를 결정할 수 있으므로(즉, 이를 읽거나 설정하여) 해당 사용자로서 서버와 상호 작용할 수 있습니다. 쿠키를 훔치는 것도 이를 위한 방법 중 하나입니다.

application.example.com과 같은 하위 도메인은 Domain 속성을 다음과 같이 설정하여 example.com 또는 다른 하위 도메인에 대한 요청과 함께 쿠키가 전송되도록 설정할 수 있습니다.

Set-Cookie: CSRF=e8b667; Secure; Domain=example.com

취약한 응용 프로그램을 하위 도메인에서 사용할 수 있는 경우, 세션 고정 공격에서 이 메커니즘을 남용할 수 있습니다. 사용자가 부모 도메인(또는 다른 하위 도메인)의 페이지를 방문하면, 애플리케이션은 사용자 쿠키에 전송된 기존 값을 신뢰할 수 있습니다. 이로 인해 공격자는 사용자가 로그인한 후 CSRF 보호를 우회하거나 세션을 하이재킹할 수 있습니다. 또는 상위 도메인이 includeSubdomains가 설정된 HTTP Strict-Transport-Security를 사용하지 않는 경우, 활성 MitM(아마도 개방형 Wi-Fi 네트워크에 연결됨)의 대상이 되는 사용자는 존재하지 않는 하위 도메인의 Set-Cookie 헤더로 응답을 받을 수 있습니다. 최종 결과는 브라우저가 불법 쿠키를 저장하고 이를 example.com 아래의 다른 모든 페이지로 보내는 것과 거의 동일합니다.

세션 고정은 주로 사용자가 인증할 때 세션 쿠키 값을 다시 생성하고(쿠키가 이미 존재하는 경우에도) CSRF 토큰을 사용자에게 연결하는 것으로 완화해야 합니다.