programing

AntiXss의 차이점은 무엇입니까?HtmlEncode 및 HttpUtility.htmlEncode?

padding 2023. 9. 25. 22:23
반응형

AntiXss의 차이점은 무엇입니까?HtmlEncode 및 HttpUtility.htmlEncode?

사이트 간 스크립팅을 피하기 위해 AntiXss 라이브러리를 제안하는 질문을 우연히 발견했습니다.msdn 블로그를 읽어보면 흥미롭게 들리는데, 그것은 단지 htmlEncode() 메서드를 제공하는 것 같습니다.하지만 저는 이미 HttpUtility를 사용하고 있습니다.HtmlEncode().

AntiXss를 사용하려는 이유는 무엇입니까?HttpUtility를 통한 HtmlEncode.htmlEncode?

사실 이 질문을 한 것은 제가 처음이 아닙니다.그리고, 실제로 구글은 주로 몇가지 답변을 내놓습니다.

  • 블랙리스트 방식 대신 화이트리스트 방식
  • 0.1ms 성능 향상

좋아요, 근데 그게 저한테 어떤 의미일까요?저는 0.1ms의 성능에 대해 크게 신경 쓰지 않고, 이미 가지고 있는 기능에 대해 라이브러리 의존성을 다운로드하여 추가하고 싶은 생각이 들지 않습니다.

AntiXss 구현을 통해 HttpUtility 구현을 통해 공격을 방지할 수 있는 사례가 있습니까?

HttpUtility 구현을 계속 사용하면 위험이 있습니까?'벌레'는 어떻습니까?

당신의 질문에 대한 구체적인 답변은 없지만, 화이트리스트 대 블랙리스트 접근 방식이 단순히 "착하다"는 것이 아니라는 점을 지적하고 싶습니다.그것은 중요합니다.아주 중요합니다.보안에 관한 한 모든 작은 것이 중요합니다.사이트 간 스크립팅 및 사이트요청 위조를 통해 사이트가 중요한 데이터를 표시하지 않더라도 해커가 javascript를 주입하여 사이트를 감염시키고 이를 사용하여 다른 사이트에서 중요한 데이터를 가져올 수 있습니다.따라서 제대로 하는 것이 중요합니다.

OWASP 지침은 화이트리스트 접근법을 사용하여 명시합니다.PCI 컴플라이언스 지침은 OWASP 지침을 참조하므로 코딩 표준에도 이를 명시합니다.

또한 AntiXss 라이브러리의 최신 버전에는 다음과 같은 새로운 기능이 있습니다.데이터베이스에 HTML을 저장하고 사용자에게 HTML로 표시하려는 경우에 적합한 GetSafeHtmlFragment()입니다.

또한 "버그"의 경우, 코딩을 제대로 하고 있고 모든 보안 지침을 준수하고 있다면 매개 변수화된 저장 프로시저를 사용하고 있으므로 인용문 하나가 올바르게 처리됩니다. 제대로 코딩하지 않으면 쉘프 라이브러리를 완전히 제거하지 못할 것입니다.AntiXss 라이브러리는 지식을 대체할 수 있는 도구가 아니라 사용할 수 있는 도구입니다.도서관에 의지하여 제대로 작업을 해낸다면, 훌륭한 화가 없이도 정말 좋은 그림 붓이 좋은 그림을 그려낼 것을 기대할 수 있을 것입니다.

편집 - 추가됨

질문에 나온 것처럼, 안티xss가 사용자를 보호하고 HttpUtility가 보호하지 않는 곳의 예는 다음과 같습니다.

HttpUtility.HtmlEncode 및 Server.HtmlEncode가 사이트 간 스크립팅을 방지하지 않음

하지만 그것은 저자의 말에 의하면.개인적으로 테스트해 본 적은 없습니다.


보안 지침을 잘 알고 계신 것처럼 들리므로, 이 내용은 제가 말씀드릴 필요가 없을 수도 있습니다. 하지만 경험이 부족한 개발자가 이 글을 읽고 있을 경우를 대비하여 화이트리스트 접근 방식이 중요하다고 말씀드리는 이유는 이것 때문입니다.

지금, 오늘, HttpUtility.HtmlEncode 는/를(를)할 수 있습니다.<그리고.> 몇몇 "으로 안전하지 는 항상 다 은"만,몇.알려진 안전한(화이트리스트) 콘텐츠만 허용하는 것은 공격자가 사용자에게 던질 수 있는 모든 가능한 안전하지 않은 입력을 생각하는 것보다 훨씬 쉽습니다(블랙리스트 접근 방식).

하나를 다른 하나보다 더 사용하는 이유에 관해서, 안티엑스가SS 라이브러리는 ASP보다 자주 릴리즈됩니다.NET 프레임워크 - David Stratton이 말한 것처럼, 누군가 AntiX를 제안할 때, '누군가는 항상 새로운 침입 방법을 생각하려고 노력합니다.SS 라이브러리는 이를 방어하기 위해 업데이트된 릴리스를 얻을 가능성이 훨씬 높습니다.

의 .Microsoft.Security.Application.AntiXss.HtmlEncode그리고.System.Web.HttpUtility.HtmlEncode메소드:

  1. 안티 XSS는 사이트 간 스크립팅(XSS) 공격에 대한 보호를 제공하기 위해 포함 원칙이라고도 불리는 화이트리스트 기술을 사용합니다.이 방법은 먼저 유효한 문자 집합 또는 허용 가능한 문자 집합을 정의하여 작동하며, 이 집합 외부의 모든 것(유효하지 않은 문자 또는 잠재적 공격)을 인코딩합니다.System.Web.HttpUtility.HtmlEncode및 해당 네임스페이스의 다른 인코딩 방법은 제외 원칙을 사용하고 <, >, &' 문자와 같이 잠재적으로 위험한 문자로 지정된 특정 문자만 인코딩합니다.

  2. Anti-XSS Library의 흰색(또는 안전한) 문자 목록은 12개 이상의 언어(그리스어, 콥트어, 키릴어, 키릴어, 아르메니아어, 히브리어, 아랍어, 시리아어, 아랍어, 아랍어, 타나어, NKo 등)를 지원합니다.

  3. 안티 XSS 라이브러리는 XSS 공격을 완화하기 위해 특별히 설계되었지만,HttpUtilityASP를 보장하기 위해 인코딩 메소드가 생성됩니다.NET 출력은 HTML을 깨지 않습니다.

  4. 성능 - 사이의 평균 델타AntiXss.HtmlEncode()그리고.HttpUtility.HtmlEncode()트랜잭션당 +0.1밀리초입니다.

  5. 안티 XSS 버전 3.0은 개발자가 XSS 유효성 검사와 성능 테스트를 모두 실행할 수 있는 테스트 하니스를 제공합니다.

대부분의 XSS 취약성(실제로는 모든 유형의 취약성)은 기존 보안이 특정 문제가 발생할 것을 "예상"하지 못했다는 사실에 전적으로 기반합니다.화이트리스트 전용 접근 방식은 기본적으로 이러한 시나리오를 처리하기 쉽습니다.

우리는 마이크로소프트의 윈도우 라이브 사이트에 화이트리스트 방식을 사용합니다.우리가 아직 생각하지 못한 보안 공격이 많을 것이기 때문에 편집증적 접근이 더 편합니다.블랙리스트가 화이트리스트가 노출하지 않은 취약점을 노출한 사례가 있었던 것으로 짐작되지만 자세한 내용은 말씀드리지 못했습니다.

언급URL : https://stackoverflow.com/questions/1608854/what-is-the-difference-between-antixss-htmlencode-and-httputility-htmlencode

반응형