antixss.htmlencode와 httputility.htmlencode의 차이점은 무엇입니까?

https://stackoverflow.com/questions/1608854

05-07-2019
|

문제

방금 크로스 사이트 스크립팅을 피하기 위해 Antixss 라이브러리를 제안하는 답변으로 질문을 진행했습니다. 흥미롭게 들렸다 MSDN 블로그, 그것은 단지 htmlencode () 메소드를 제공하는 것으로 보입니다. 그러나 이미 httputility.htmlencode ()를 사용하고 있습니다.

왜 antixss.htmlencode를 httputility.htmlencode에 사용하고 싶습니까?

실제로, 나는이 질문을 처음으로 물어 본 적이 없습니다. 그리고 실제로 Google이 나타납니다 약간 답변, 주로

흑인 목록 접근 방식 대신 흰색 목록
0.1ms 성능 향상

글쎄, 그것은 좋지만, 그것은 나에게 무엇을 의미합니까? 나는 0.1ms의 성능에 대해별로 신경 쓰지 않으며 이미 가지고있는 기능에 대한 다른 라이브러리 의존성을 다운로드하고 추가하는 것을 실제로 느끼지 않습니다.

ANTIXS 구현이 HTTPutility 구현이 그렇지 않은 공격을 방지 할 경우의 예가 있습니까?

httputility 구현을 계속 사용한다면 위험에 처해 있습니까? 는 어때 이 '버그'?

해결책

나는 당신의 질문에 구체적으로 답변이 없지만, 흰색 목록 대 블랙리스트가 "좋은"것이 아니라 접근한다는 것을 지적하고 싶습니다. 중요합니다. 매우 중요. 보안에 관해서는 모든 작은 것이 중요합니다. 크로스 사이트 스크립팅과 함께 기억하십시오 크로스 사이트 요청 위조 사이트에 민감한 데이터가 표시되지 않더라도 해커는 JavaScript를 주입하여 사이트를 감염시켜 다른 사이트에서 민감한 데이터를 얻을 수 있습니다. 따라서 올바르게하는 것이 중요합니다.

OWASP 지침은 흰색 목록 접근법을 사용하여 지정합니다. PCI 준수 가이드 라인은 또한 코딩 표준에이를 지정합니다 (OWASP 가이드 라인을 참조하기 때문에).

또한 Antixss 라이브러리의 최신 버전에는 새로운 기능이 있습니다. getsafehtmlfragment ()는 데이터베이스에 HTML을 저장하고 HTML로 사용자에게 표시 할 경우에 좋습니다.

또한 "버그"의 경우 올바르게 코딩하고 모든 보안 지침을 따르는 경우 매개 변수 저장 프로 시저를 사용하고 있으므로 단일 따옴표가 올바르게 처리되지 않으면 제대로 코딩하지 않으면 선반 도서관이 당신을 완전히 보호 할 것입니다. Antixss Library는 지식을 대체하지 않고 사용하는 도구입니다. 당신을 위해 도서관에 의존하는 것은 정말 좋은 페인트 브러시가 좋은 예술가없이 좋은 그림을 만들기를 기대할 것입니다.

편집 - 추가

질문에서 묻는 바와 같이, 반 XSS가 귀하를 보호 할 위치의 예는 다음과 같습니다.

httputility.htmlencode 및 서버. htmlencode는 크로스 사이트 스크립팅을 방해하지 않습니다

그러나 그것은 저자에 따른 것입니다. 나는 그것을 개인적으로 테스트하지 않았습니다.

보안 가이드 라인에 올라간 것 같습니다. 그래서 이것은 제가 말해야 할 것이 아닐 수도 있지만, 경험이 적은 개발자 가이 책을 읽는 경우에만, 백인 목록 접근 방식이 중요하다고 말하는 이유입니다. 이거야.

지금, 오늘, httputility.htmlencode는 단순히 모든 공격을 성공적으로 차단할 수 있습니다. < 그리고 > , 다른 "알려진 잠재적 인 안전하지 않은"캐릭터 몇 개도 누군가가 항상 새로운 방법으로 생각하는 방법을 생각하려고 노력하고 있습니다. 입력 공격자가 당신을 던질 수 있습니다 (블랙리스트 접근).

다른 팁

David Stratton이 '누군가가 항상 새로운 방법을 생각하려고 노력하고 있기 때문에 Antixss Library가 ASP.NET 프레임 워크보다 더 자주 출시된다고 생각합니다. 누군가가 하나를 생각해 내면 Antixss Library는이를 방어하기 위해 업데이트 된 릴리스를 얻을 가능성이 훨씬 높습니다.

다음은 차이점입니다 Microsoft.Security.Application.AntiXss.HtmlEncode 그리고 System.Web.HttpUtility.HtmlEncode 행동 양식:

Anti-XSS는 객실 간 스크립팅 (XSS) 공격에 대한 보호를 제공하기 위해 포함의 원리라고도하는 흰색 목록 기술을 사용합니다. 이 접근법은 먼저 유효하거나 허용 가능한 문자 세트를 정의하여 작동 하며이 세트 외부의 모든 것을 인코딩합니다 (잘못된 문자 또는 잠재적 공격). System.Web.HttpUtility.HtmlEncode 해당 네임 스페이스의 다른 인코딩 방법은 제외 원칙을 사용하고 <,>, 및 '문자와 같은 잠재적으로 위험한 것으로 지정된 특정 문자 만 인코딩합니다.
Anti-XSS Library의 흰색 (또는 안전한) 문자 목록은 12 개 이상의 언어를 지원합니다 (그리스어 및 콥트어, 키릴 릭, 키릴 릭 보충제, 아르메니아, 히브리어, 아랍어, 시리아, 아랍어 보충, Thaana, NKO 등)
Anti-XSS 라이브러리는 XSS 공격을 완화하기 위해 특별히 설계되었지만 HttpUtility ASP.NET 출력이 HTML을 깨뜨리지 않도록 인코딩 메소드가 작성됩니다.
성능 - 평균 델타 사이 AntiXss.HtmlEncode() 그리고 HttpUtility.HtmlEncode() 거래 당 +0.1 밀리 초입니다.
Anti-XSS 버전 3.0은 개발자가 XSS 검증 및 성능 테스트를 모두 실행할 수있는 테스트 하네스를 제공합니다.

대부분의 XSS 취약점 (실제로 모든 유형의 취약점)은 기존 보안이 특정 일이 발생하지 않았다는 사실에 기반을두고 있습니다. 화이트리스트 전용 접근 방식은 기본적으로 이러한 시나리오를 처리하는 데 더 적합합니다.

우리는 Microsoft의 Windows Live 사이트에 White-List 접근 방식을 사용합니다. 우리가 아직 생각하지 않은 보안 공격이 많이 있다고 확신합니다. 따라서 편집증 접근 방식에 더 편안합니다. 나는 흑인 목록이 화이트리스트가하지 않은 취약점을 노출 한 사례가 있다고 생각하지만 세부 사항을 말할 수 없었습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow