SXSS 취약점이 악용되기 전에 이를 인식하고 완화하세요
루크 해리슨 저
이 기사는 원래 IBM Developer에 게시되었습니다.
현재 많은 애플리케이션은 웹사이트에서 HTML의 서식 있는 텍스트를 렌더링해야 합니다. 사용자 입력에서 이러한 형식의 텍스트를 생성하기 위해 개발자는 서식 있는 텍스트 편집기 구성 요소를 사용합니다. 문제? 이 기능은 애플리케이션과 데이터 모두 SXSS(저장된 교차 사이트 스크립팅)라는 취약점에 간접적으로 노출될 수 있습니다.
이 기사에서는 SXSS 취약점이 무엇인지 알아보고 애플리케이션이 영향을 받는지 확인하는 데 사용할 수 있는 몇 가지 "코드 냄새"를 검토합니다. 또한 취약한 애플리케이션의 예를 확인하고 이 취약성에 대한 해결 전략을 배우게 됩니다.
저장된 교차 사이트 스크립팅은 공격자가 데이터베이스에 악성 코드를 삽입하기 위해 악용할 수 있는 일종의 취약점입니다. 그런 다음 해당 코드는 프런트엔드 프레임워크에서 가져와 렌더링한 후 피해자의 브라우저에서 실행됩니다.
이 취약점은 공격자가 쿠키를 훔치거나, 리디렉션을 실행하거나, 피해자의 브라우저에서 다양한 위험한 스크립트를 실행할 수 있기 때문에 매우 위험합니다. 익스플로잇을 전파하는 데 공격자는 거의 작업이 필요하지 않습니다. 피해자는 악의적인 링크를 클릭하거나 피싱 사기에 빠질 필요가 없으며 SXSS의 영향을 받는 신뢰할 수 있는 사이트를 사용하기만 하면 됩니다. 크로스 사이트 스크립팅 취약점에 대한 자세한 내용은 페이지 하단의 링크를 확인하세요.
코드 냄새는 더 깊은 문제를 나타내는 코드의 특성일 뿐입니다. 브라우저는 일반적으로 삽입된 스크립트를 자동으로 실행하지 않지만, 개발자가 잠재적으로 위험한 브라우저 API 또는 요소 속성을 사용하는 경우 스크립트가 실행 실행되는 상황이 발생할 수 있습니다.
다음 코드 조각을 살펴보세요.
const someHTML = “<h1>Hello world</h1>“
const output = document.getElementById("rich-text-output");
output.innerHTML = someHTML
이 예에서는 일부 HTML을 변수에 저장하고 DOM에서 요소를 가져온 다음 해당 요소의 innerHTML 속성을 변수에 저장된 콘텐츠로 설정합니다. innerHTML 속성은 다른 HTML 요소 내부의 문자열에서 HTML을 렌더링하는 데 사용할 수 있습니다.
이 속성의 위험한 점은 전달된 모든 HTML 또는 JavaScript를 렌더링한다는 것입니다. 즉, 누군가 속성에 전달된 데이터를 제어할 수 있다면 기술적으로 사용자 브라우저에서 모든 JavaScript를 실행할 수 있다는 의미입니다.
브라우저에서 동적 HTML을 렌더링하는 또 다른 인기 있지만 위험한 방법은 위험하게SetInnerHTML React 구성 요소 속성을 사용하는 것입니다. 이 속성은 바닐라 JavaScript 및 HTML의 innerHTML 속성과 정확히 동일한 방식으로 작동합니다.
다음 예는 React 문서에 나타납니다.
const someHTML = “<h1>Hello world</h1>“
const output = document.getElementById("rich-text-output");
output.innerHTML = someHTML
현재 프런트 엔드 웹 애플리케이션에서 이러한 속성 중 하나를 사용하고 있다면 일종의 교차 사이트 스크립팅 취약점이 있을 가능성이 높습니다. 이 문서의 뒷부분에서 이러한 속성을 어떻게 활용할 수 있는지, 그리고 이러한 문제를 해결하기 위해 취할 수 있는 몇 가지 단계를 살펴보겠습니다.
귀하의 애플리케이션이 SXSS에 취약할 수 있다는 또 다른 징후는 TinyMCE 또는 CKEditor와 같은 서식 있는 텍스트 편집기를 사용하고 있는지 여부입니다.
대부분의 서식 있는 텍스트 편집기는 사용자가 생성한 서식 있는 텍스트를 HTML로 변환하는 방식으로 작동합니다. 추가 보안 조치로 이러한 편집자 중 다수는 잠재적인 악성 JavaScript를 입력에서 제거하기 위해 일종의 삭제 처리를 사용합니다. 그러나 서식 있는 텍스트 콘텐츠를 수신하고 저장하는 서비스에 이와 동일한 삭제 기술을 적용하지 않으면 애플리케이션이 SXSS에 취약해질 가능성이 높습니다.
자신의 사이트에서 콘텐츠를 렌더링하지 않더라도 렌더링하는 애플리케이션에서 이 데이터를 사용할 가능성이 높습니다. 안전한 애플리케이션을 설계하려면 현재와 미래의 데이터 소비자를 고려하는 것이 매우 중요합니다. 귀하의 데이터가 SXSS의 영향을 받는다면 귀하의 데이터를 소비하는 모든 애플리케이션도 마찬가지입니다.
SXSS 취약점이 있는 웹 애플리케이션의 작은 예를 살펴보고 이를 악용해 보겠습니다.
이 애플리케이션을 실행하려면 먼저 이 데모 앱 저장소를 복제하고 readme.md 파일의 "애플리케이션 실행" 지침을 따르세요.
애플리케이션을 실행하고 http://localhost:3000/unsanitized.html로 이동하면 다음과 같은 페이지가 표시됩니다.
이 애플리케이션은 사용자로부터 서식 있는 텍스트 입력을 받아 웹 서버에 저장한 다음 출력 섹션에 렌더링합니다.
SXSS 취약점을 악용하기 전에 잠시 시간을 내어 애플리케이션을 살펴보세요. 위에서 언급한 코드 냄새를 참고하여 코드를 스캔하여 문제가 있는 부분을 찾아보세요. 브라우저에서 네트워크 탭을 열고 서식 있는 텍스트를 입력하고 제출할 때 전송되는 요청을 확인하세요.
unsanitzed.html 파일에는 renderPostByID라는 다음 함수가 표시됩니다.
const someHTML = “<h1>Hello world</h1>“
const output = document.getElementById("rich-text-output");
output.innerHTML = someHTML
이 기능을 주의 깊게 살펴보세요. 앞서 언급한 innerHTML 속성을 사용하여 API에서 HTML 형식으로 가져온 일부 서식 있는 텍스트를 렌더링하고 있음을 알 수 있습니다.
이제 코드의 취약한 부분을 확인했으니 활용해 보겠습니다. 서식 있는 텍스트 편집기 입력을 우회하고 게시물을 웹 서버에 직접 저장하는 API 엔드포인트를 실행하겠습니다. 이렇게 하려면 다음 cURL 명령을 사용할 수 있습니다.
function createMarkup() {
return {__html: 'First · Second'};
}
function MyComponent() {
return <div dangerouslySetInnerHTML={createMarkup()} />;
}
요청에서 보내는 데이터 페이로드를 확인하세요. 이는 경고 대화 상자를 표시하는 일부 JavaScript로 설정된 onerror 속성이 있는 이미지 태그를 포함하는 악의적으로 제작된 HTML입니다. 공격자는 데이터베이스에 저장되기 전에 HTML 요소에서 JavaScript를 제거하는 것을 목표로 하는 제대로 구현되지 않은 삭제 방법을 피하기 위해 이와 같은 트릭을 사용합니다.
위 스크립트를 실행하면 다음과 같은 게시물 ID를 받게 됩니다.
const renderPostByID = async (id) => {
// setting url seach params
let newURL = window.location.protocol + "//" + window.location.host + window.location.pathname + `?post=${id}`;
window.history.pushState({ path: newURL }, "", newURL);
// getting rich text by post id
let response = await fetch(`/unsanitized/${id}`, { method: "GET" });
let responseJSON = await response.json();
console.log(responseJSON);
// rendering rich text
output.innerHTML = responseJSON.richText;
};
이 게시물 ID를 게시물 URL 쿼리 매개변수에 붙여넣고 Enter를 누르세요.
이 작업을 수행하면 사이트가 실제로 SXSS에 취약하다는 것을 확인하는 경고 대화 상자가 화면에 표시됩니다.
이제 SXSS 취약점을 악용하는 방법을 살펴보았으니 이제 SXSS 취약점을 교정할 수 있는 방법을 살펴보겠습니다. 이렇게 하려면 다음 세 가지 위치에서 HTML 기반 서식 있는 텍스트를 삭제해야 합니다.
콘텐츠를 데이터베이스에 저장하기 전과 클라이언트 측에서 렌더링할 때 콘텐츠를 삭제하려는 이유는 분명할 수 있지만, 검색할 때는 왜 삭제합니까? 글쎄, 누군가가 콘텐츠를 데이터베이스에 직접 삽입하는 데 필요한 권한을 얻는다고 가정해 보겠습니다. 이제 그들은 초기 새니타이저를 완전히 우회하여 악의적으로 제작된 일부 HTML을 직접 삽입할 수 있습니다. API 중 하나의 소비자가 클라이언트 측에서도 이러한 삭제를 구현하지 않는 경우 교차 사이트 스크립팅 악용의 희생양이 될 수 있습니다.
그러나 세 위치 모두에 삭제 처리를 추가하면 성능 저하가 발생할 수 있으므로 이 수준의 보안이 필요한지 스스로 결정해야 합니다. 최소한 동적 HTML 콘텐츠를 렌더링하기 전에 클라이언트 측의 모든 데이터를 삭제해야 합니다.
취약한 애플리케이션의 보안 버전에서 삭제를 구현하는 방법을 살펴보겠습니다. 이 애플리케이션은 주로 JavaScript를 사용하여 작성되었으므로 클라이언트 측에는 dompurify 라이브러리를 사용하고 서버 측 삭제에는 isomorphic-dompurify 라이브러리를 사용합니다. 웹 서버 역할을 하는 app.js 프로그램에서 GET 및 POST 구현으로 삭제된 익스프레스 엔드포인트를 찾을 수 있습니다.
const someHTML = “<h1>Hello world</h1>“
const output = document.getElementById("rich-text-output");
output.innerHTML = someHTML
POST 구현에서는 먼저 요청 본문에서 서식 있는 텍스트를 검색한 다음 데이터 객체에 저장하기 전에 isomorphic-dompurify 라이브러리의 sanitize 메서드를 호출합니다. 마찬가지로 GET 구현에서는 데이터 개체에서 서식 있는 텍스트를 검색한 후 소비자에게 보내기 전에 서식 있는 텍스트에 대해 동일한 메서드를 호출합니다.
클라이언트 측에서는 sanitized.html에서 출력 div의 innerHTML 속성을 설정하기 전에 이와 동일한 방법을 다시 사용합니다.
function createMarkup() {
return {__html: 'First · Second'};
}
function MyComponent() {
return <div dangerouslySetInnerHTML={createMarkup()} />;
}
교차 사이트 스크립팅을 방지하기 위해 HTML을 적절하게 삭제하는 방법을 살펴보았으므로 이제 이 애플리케이션의 원래 공격으로 돌아가 이번에는 삭제된 엔드포인트를 사용하여 다시 실행하세요. 이제 SXSS 취약점을 방지하기 위해 적절한 기술을 사용하고 있으므로 더 이상 경고 대화 상자 팝업이 표시되지 않습니다.
XSS 예방을 위한 모범 사례와 기타 기술을 포함한 전체 SXSS 가이드를 보려면 OWASP 교차 사이트 스크립팅 치트 시트를 살펴보세요.
이 기사에서는 일반적인 유형의 웹 애플리케이션 취약점인 저장된 교차 사이트 스크립팅을 방지하여 애플리케이션 보안 상태를 강화할 수 있는 방법을 살펴보았습니다. 이제 자신의 애플리케이션이 취약한지 여부, 검토해야 할 기능, 악의적인 행위자가 이러한 취약점을 악용하기 전에 완화하는 방법을 인식할 수 있습니다.
보안은 기업 개발자에게 가장 중요합니다. 다음 리소스를 사용하여 가능한 취약점에 대한 인식과 보안 태세를 개선할 수 있는 방법을 지속적으로 구축하세요.
위 내용은 귀하의 서식 있는 텍스트는 크로스 사이트 스크립팅 취약점일 수 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
