내가 이해하는 것처럼 XSS가 GET 요청을 통해 발생하는 것을 방지하기 위해 서버 측 헤더에서 X-XSS- 보호를 비활성화해야합니다.브라우저의 X-XSS- 보호/XSS 감사 기는 XSS를 막기에 충분한가?
예를 들어, 사용자는
http://mysite.com/index.php?page=<script type='text/javascript'> alert("XSS"); </script>
XSS 공격을 막기에 충분합니까? 아니면이 브라우저 보호가 공격자에 의해 우회 될 수 있습니까?
모든 주요 브라우저에서 지원되며 우회 할 수 없다는 의미입니다.
브라우저의 버전과 유형이 항상 예측할 수 없으므로 사용자의 브라우저에 따라 보호 기능을 사용하지 않는 것이 좋습니다. 즉, 서버/애플리케이션 수준에서 XSS (또는 다른 유형의 공격)를 방지하기위한 모든 조치를 취해야합니다.
이 가 XSS 공격을 반영 잡기에 충분 수도 있지만이 짝수 더 유해가 XSS 공격을 지속 방지 할 수있는 방법은 없습니다. 또한 일부 브라우저에는 XSS 보호 기능이 없습니다. 사용자가 출력을 피하기 위해 에만 만 보호하기를 원하십니까? 적절한 장소를 벗어나면 브라우저에 XSS 보호 기능이없는 경우에도 두 유형의 XSS가 모두 수정됩니다.
아니요, 전혀 아닙니다. 클라이언트 측 XSS 필터링은 문제를 해결하기에 충분한 지식이없는 클라이언트 측에서 서버 측 문제 (출력 누락 누락)를 해결하려고합니다. 결코 100 % 작동하지 않으며 항상 오 탐지합니다. 이것은 심층적 인 방어책이며 깊이 의심스러운 조치입니다. 은이 XSS의 솔루션으로 단독으로 의존해서는 안됩니다.
클라이언트 측 XSS 필터링 :
다중 반사 XSS 방어 할 수 없다 (즉, 하나 개의 파라미터 포함하고 옆 출력을 얻는 또 다른 파라미터에 script<);
은 애플리케이션 별 인코딩 레이어 (예 : JSON 형식으로 전송, 이스케이프 처리없이 디코딩 및 표시)를 방어 할 수 없습니다.
은 양식 매개 변수가 아닌 입력 유형을 방어 할 수 없습니다.
다른 내용을 스크립트에 삽입하는 것에 기반한 공격으로부터 스크립트를 보호 할 수 없습니다.
은 CSS와 같이 스크립트를 삽입하는 모호한 방법에 대해 방어적인 역사를 가지고 있습니다.
은 저장된 XSS를 전혀 방어 할 수 없습니다.
은 모든 인기있는 브라우저에서 지원되지 않습니다.
공격자는 공격자가 페이지의 스크립트를 선택적으로 사용 중지하여 방해하는 것을 허용합니다.
이것은 승리가 아닙니다.