AntiXSS 인코더 4.1 베타를 런타임 인코더로 사용하여 중지되는 XSS 취약성의 예를 찾고 있습니다 (system.web/httpRuntime에서 설정). 어쩌면, 나는 ASP.NET 블랙리스트에 의해 얻을 것입니다하지만 AntiXSS 화이트리스트를 통해 그것을 확인하지 않을 무언가를 생각하고 같은ASP.NET 4 <%: %> 또는 Razor 인코딩을 통해 얻지 만 AntiXSS가 캐치하는 XSS 취약점의 예
@AntiXss.JavaScriptEncode(ViewBag.UserName)
로 AntiXss 기능에 대한 명시 적 호출을 필요로하지 않는 것을 선호 대체 문자 세트 또는 인코딩과 관련이 있습니까?
나는 UTF-7 취약점을 테스트했지만 최신 브라우저에는 영향을주지 않는 것으로 보입니다.
어떤이 없습니다. 글쎄, 그건 전혀 사실이 아니야, 그들은 현대의 브라우저에서 동작하는 것이 아니다.
SDL이 요구하는 이유는 안전한 목록을 사용하는 것이 본질적으로 더 안전하다는 것입니다. 따라서 갑자기 누군가가 문제가되는 문자를 발견하면 이미 구성되어있는 안전 목록에 따라 인코딩 될 수 있습니다.
흠 ... 나는 다음과 같지 않습니다 - antixss는 자신의 인코더를 지정하고 턴 오프 할 때 .net 4s 기능을 사용하지 않는 한 명시 적 호출이 필요합니까? 이 경우에는 내가 알고있는이 시점에서 알려진 바가 없습니다. AntiXss는 화이트리스트를 사용하기 때문에 아무런 문제가 없어야합니다. 몇 문자 만 제외하고 모두 인코딩됩니다.
참고하시기 바랍니다 - 로컬 I는 UTF-7은 잘 작동하도록 할 수 있습니다
<HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
감사합니다. ASP.NET 인코더로 사용하는 것에 대해 이야기합니다. 4.1에서는 명시 적으로 호출 할 필요가 없습니다. UTF-7 공격은 흥미 롭습니다.하지만 당신은 지금 그것을 charset으로 지정해야합니다. 그래서 현대적인 브라우저에서는 위협이 아닙니다. –
나는이 시점에서 (다른 대답 3 시간 전에) 알려진 바가 없다는 것과 기본적으로 똑같은 대답을했다. 이것은 대답으로 선택되지 않은 이유는 무엇입니까? 또한 인코딩을 통해 XSS로부터 보호받을 수 있습니다. Internet Explorer 7 (현대인이든 아니든 - 여전히 모든 사용자의 5 % 이상이 ie7에 있습니다 - 공격을하기에 충분 함)은 utf-7 공격에 취약합니다. IE8 +와 마찬가지로 스크립트가 감지되면 인코딩을 변경하지 않습니다. http://msdn.microsoft.com/en-us/library/dd565635%28v=vs.85%29.aspx –
4.1 자동으로이 작업을 수행 할 수 있습니까? 나는 그물을보고 처음에는 아무것도 찾지 못했습니다. –
최신 브라우저에는 인코딩이 utf-7로 지정되어 있습니다. 이 경우 htmlencoding은 많은 차이를 만들지 않으므로 거기에 문제가 있습니다. 페이지를 utf-7로 지정하지 않고 누군가 다른 css 취약점을 통해 페이지에 인코딩 유형을 주입 할 수 있다면 다른 공격 방법입니다. –
예전 브라우저에서는 악센트가있는 S 문자와 같이 끈적해질 수 있습니다. 여기에는 ript 스크립트를 사용할 수 있으며 스크립트 태그로 사용됩니다. – blowdart
처음 4000 바이트 내에서 utf-7을 찾으면 스니핑하여 utf-7을 기본값으로 사용합니까? 그래서 당신이 첫 번째 4000에서 IE7에 utf-7을 주입 할 수 있다면, 그 프로그램은 실행됩니다. ie8 +가이를 차단합니다. –