javascript 크로스사이트 - CSP를 사용하여 자동 클릭 링크 XSS 공격 방지





스크립트 테스트 (4)


CSP는 XSS로 인한 피해를 줄이는 방법 중 하나이지만 XSS 취약점으로 인한 모든 문제를 해결하는 마법의 지팡이는 결코 아닙니다. 이 목적이 아닌 것도 CSP 사양 에 명시 적으로 나열되어 있습니다.

콘텐츠 보안 정책 (CSP)은 콘텐츠 삽입 취약점에 대한 첫 번째 방어 수단이 아닙니다. 대신 CSP는 컨텐츠 삽입 공격으로 인한 피해를 줄이기 위해 심층적 인 방어책으로 사용하는 것이 가장 좋습니다. 컨텐츠 삽입에 대한 첫 번째 방어선으로서 서버 운영자는 입력 내용의 유효성을 확인하고 출력을 인코딩해야합니다.

JavaScript 코드를 실행해야하지만 코드를 신뢰할 수없는 경우 allow-same-origin 플래그가없는 샌드 박스 지시문을 사용하여 페이지를 제공 할 수 있습니다. 이 CSP 지시문을 사용하면 표시되는 출처와 상태 (쿠키, DOM 저장소, 데이터베이스 등)를 공유하지 않는 고유 한 보안 원점에서 페이지가 실행됩니다. 결과적으로, 주입 된 스크립트는 처음부터 정보를 얻을 수 없기 때문에 정보를 유출 할 수 없습니다.

예를 들어 인라인 스크립트를 실행할 수 있지만 같은 출처 데이터에 대한 액세스 권한이없는 경우 다음을 사용하십시오.

default-src 'none'; script-src 'unsafe-inline'; sandbox allow-scripts

1) 항상 메소드를 간과하고 2) JavaScript API를 사용하지 못하게하면 예기치 않은 방식으로 웹 애플리케이션이 손상 될 수 있고 3) 공격자가 손상을 입힐 구멍이 하나뿐이기 때문에 다른 방법으로 제안 된 것처럼 자바 스크립트 메소드를 블랙리스트에 추가하지 마십시오. (사용자 지정) 응용 프로그램에는 공격자가 악용 할 수있는 하나 이상의 메서드가 포함되어있을 수 있습니다.

약간 다른 목적 (sandboxing)으로 CSP를 사용하는 동안 나는 매우 간단한 자동 클릭 링크가 상대적으로 엄격한 CSP를 우회하는 것처럼 보였다. 제가 설명하는 것은 다음과 같습니다 :

콘텐츠 보안 정책 :

default-src 'none'; script-src 'unsafe-inline';

그리고 몸 :

<a href="http://www.google.com">test</a>
<script>
  document.querySelector("a").click();
</script>

분명히 실제 공격에서 href 필드에 쿠키 정보를 먼저 포함시키고 숨겨진 자체 포함 iframe에이 정보를 포함 시키거나 도메인을 사용자가 어디서 왔는지 다시 리디렉션하도록 할 수 있습니다 (잠재적으로 추가 URL 매개 변수를 사용하여 일종의 XMLHttpRequest는 connect-src 우회 함),이 기본적인 예제는 문제를 보여준다.

CSP (자바 스크립트 실행을 여전히 허용)로이를 막을 수있는 방법이 있습니까?

비슷한 공격

다른 탐색 방법으로도 동일한 작업을 수행 할 수 있습니다. 이 방법에 대해 구체적으로 묻는 이유는 실제로 XSS 익스플로잇보다 제 2 차 목표가 더 중요합니다. 어느 쪽이든, 모든 실제 솔루션을 열어보십시오.

관련없는 부연 설명

script-src: 'unsafe-inline' 없더라도 이것이 어떻게 적용될 수 있는지에 대한 모든 혼란 때문에 script-src: 'unsafe-inline' . api.ext 라는 이름의 다음 파일을 상상해보십시오.

print URLParameters.method
[...]

이 파일은 다음과 같이 호출 할 수 있습니다. api.ext?method=<script src='api.ext?method=alert("test")//'></script><!-- 그리고 물건, 이것은 단지 지점을 가로 지르는 것이다). 이런 익스플로잇을 찾는 것은 어렵고 아주 드물지만 connect-src 와 같은 것들이 이러한 경우에도 정보 유출을 막기 위해 존재하는 것 같습니다.




이것은 만족할만한 접근 방법이 될 것 같지 않습니다. 분명 CSP를 기반으로하지는 않지만 실제로 그러한 공격을 막아야하는 경우 유일한 옵션 일 수 있습니다. 이와 같은 것을 사용하기 전에 인라인 스크립트를 비활성화 할 방법이 없는지 확인하십시오 (대부분의 공격을 포함해야 함). 또한 [CSP2] 제목을 사용하여 [email protected] 메일 링리스트에 의견을 보내야합니다.

여기 내 (불완전한) 생각 :

function guardMethods(clazz, methodNames, urlGetter, allowFilter, reportViolation) {
    var prototype = clazz.prototype;
    methodNames.forEach(function (methodName) {
        var originalMethod = prototype[methodName];
        if (originalMethod) {
            Object.defineProperty(prototype, methodName, {
                value: function () {
                    var url = urlGetter.apply(this, arguments) || '';
                    if (allowFilter(url)) {
                        return originalMethod.apply(this, arguments);
                    } else {
                        reportViolation(url);
                    }
                }
            });
        }
    })      
}

function allowFilter(url) {
    // todo: implement
}

function reportViolation(url) {
    console.error('Redirection prevented:', url);
}

guardMethods(HTMLAnchorElement, ['click', 'dispatchEvent', 'fireEvent'], function () {return this.href}, allowFilter, reportViolation);

location, location.href, window.open 및 다른 함수 / 속성 / 이벤트에 대해 비슷한 가드를 구현하여 다른 페이지로 리디렉션 할 수 있어야합니다. 하나만 놓치면 여전히 취약합니다. 양식, XHR 및 기타 대부분의 자원은 CSP 자체에서 다루어 질 수 있습니다. 내가 아는 한, 프로토 타입 해킹은 일부 구형 브라우저에서는 작동하지 않습니다.

한 번 더, 나는 이것을 사용하지 않는 것이 좋습니다. 개발자가 실수를하거나 일부 브라우저에서 작동하지 않거나 리디렉션을 위해 활용할 수있는 새로운 API가 추가 될 가능성은 너무 높습니다.




콘텐츠 보안 정책은 페이지 자체의 보안을위한 것입니다. 다른 페이지로 이동하는 것은 바이 패스가 아니며 CSP와 관련된 것입니다. CSP는 귀하의 페이지와 그것이 할 수있는 일에만 관심이 있습니다. 또한 플러그인을 설치하거나 링크를 열 수있는 기능과 같이 최종 사용자를위한 브라우저의 유틸리티를 제한하는 것도 아닙니다.

default-src 'none';

이렇게하면 XHR / 가져 오기 / 웹 소켓 / CSS / 글꼴 / 자바 스크립트 / 플러그인 콘텐츠를 어디에서나 허용하지 않도록 정책을 강화할 수 있습니다. 이것들은 모두 각각의 속성을 갖지만, 부재 상태에서는 기본 속성이 사용됩니다. 당신은 자바 스크립트에서 이들 중 어떤 것도 시도하지 않았습니다.

script-src 'unsafe-inline';

이렇게하면 정책을 완화하여 페이지에 삽입 된 모든 자바 스크립트를 사용할 수 있습니다. 여기에는 onclick / onhover 및 안전하지 않은 속성 전체가 포함됩니다. spec 을 인용하려면 다음을 수행하십시오.

어떤 경우 든 작성자는 정책에서 유효한 소스로 'unsafe-inline'또는 data :를 포함해서는 안됩니다. 두 가지 방법 모두 코드가 문서 자체에 직접 포함되도록함으로써 XSS 공격을 가능하게합니다. 그들은 완전히 피하는 것이 가장 좋습니다.

이 대신에 어떤 이유로 든 문서 자체에 내용을 포함 할 필요가 있다고 느끼면 인라인 스크립트를 허용 목록에 추가하기 위해 정책 문자열에 배치 할 수있는 해시 값과 넌셋 값이 있습니다.




header(...) 를 통해 일부 XSS 관련 HTTP 응답 헤더를 설정할 수도 있습니다.

X-XSS- 보호 "1; mode = 블록"

브라우저 XSS 보호 모드가 활성화되어 있는지 확인하십시오.

콘텐츠 보안 정책 "default-src 'self'; ..."

브라우저 측 콘텐츠 보안을 가능하게합니다. CSP (Content Security Policy) 세부 정보는 다음을 참조하십시오. http://content-security-policy.com/ 특히 인라인 스크립트 및 외부 스크립트 소스를 차단하도록 CSP를 설정하면 XSS에 도움이됩니다.

웹 애플리케이션의 보안과 관련된 유용한 HTTP 응답 헤더의 일반적인 목록은 OWASP를 https://www.owasp.org/index.php/List_of_useful_HTTP_headers . https://www.owasp.org/index.php/List_of_useful_HTTP_headers







javascript xss content-security-policy