Err Blocked By Xss Auditor

출처

크롬에서 Cross Site Scripting (XSS) 에 대한 테스트를 하면, ERR_BLOCKED_BY_XSS_AUDITOR라는 에러 메시지를 보게된다. 이는 웹브라우저에 탑재된 XSS Auditor가 블랙리스트에 등록된 스크립트를 발견했을 때 발생시키는 에러다.

페이지가 작동하지 않습니다.
Chrome이 이 페이지에서 비정상적인 코드를 감지했으며 개인정보(예: 비밀번호, 전화번호, 신용카드) 보호를 위해 차단했습니다.
사이트의 홈페이지를 방문해 보세요.
ERR_BLOCKED_BY_XSS_AUDITOR

XSS Auditor는 크롬과 사파리에 탑재되어 있고, 기본 동작하도록 설정되어 있다. XSS Auditor의 동작은 X-XSS-Protection이라는 HTTP Response 헤더에 의해 결정된다.

HTTP/1.1 200 OK
Date: Sun, 12 Mar 2017 15:06:42 GMT
Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.6.28
X-Powered-By: PHP/5.6.28
Expires: Tue, 23 Jun 2009 12:00:00 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
X-XSS-Protection: 0
Content-Length: 4923
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=utf-8

위의 8번 라인에서 X-XSS-Protection 헤더가 0으로 설정된 것을 볼 수 있다. 이는 XSS Auditor를 사용하지 않겠다는 의미이다. 이 X-XSS-Protection 헤더가 설정되어 있지 않거나 값이 1로 설정되어 있으면, XSS Auditor를 사용하겠다는 의미이다. 다시 말해, 우리는 실제 환경에서 X-XSS-Protection 헤더를 볼 수 있는 기회가 거의 없을 것이다. XSS를 테스트하는데 XSS Auditor가 방해가 된다면, 그냥 파이어폭스를 사용하자. 크롬의 경우 실행할 때 인자로 –disable-xss-auditor를 전달하면 XSS Auditor가 동작하지 않는다는 글이 있으나, 이제는 적용되지 않는 듯 하다. 프록시를 설정하고 X-XSS-Protection 헤더를 추가하는 방법을 소개하는 동영상도 있었으나, 차라리 위의 HTTP Response처럼 웹서버에서 X-XSS-Protection 헤더를 추가하도록 하는 편이 편리할 것 같다.

https://www.virtuesecurity.com/blog/understanding-xss-auditor/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

출처