ASP.NET 1.1 이후, 양식 제출에 대한 XSS (크로스 사이트 스크립팅 공격)가 있는지 자동으로 확인할 수있는 기능이 도입됩니다. 사용자가 해당 입력을 사용하여 페이지를 반환하기 위해 페이지에 영향을 미치려면 ASP.NET 엔진이 HTTPrequestValidationExceptionin을 트리거합니다. 기본적으로 다음 텍스트가있는 페이지가 반환됩니다.
ASP.NET에서 제공하는 매우 중요한 보안 기능입니다. 많은 프로그래머는 보안에 대해 전혀 모르고 XSS와 같은 공격의 존재를 알지 못하기 때문에,이를 보호하기 위해 주도권을 잡는 사람들이 더 적습니다. 이 시점에서 ASP.NET은 기본적으로 안전합니다. 이를 통해 보안에 대해 잘 모르는 프로그래머는 여전히 특정 보안 보호 기능을 갖춘 웹 사이트를 작성할 수 있습니다.
그러나 httprequestValidationException 또는 잠재적으로 위험한 요청에 대한 검색을 검색 할 때 클라이언트에서 양식 값이 감지되었을 때 대부분의 사람들이 제공 한 솔루션이 ASP.NET 페이지 설명에서 ValidAreRquest = False를 설정하여 비활성화하는 것이 놀랍습니다. 이 기능은 프로그래머 웹 사이트 에이 기능이 실제로 필요하지 않은지 여부는 신경 쓰지 않습니다. 나는 광경에 너무 두려워했다. 보안 인식은 항상 모든 프로그래머의 개념에 대해 얼마나 알고 있든, 적극적인 인식이 마음에 있으면 사이트가 훨씬 더 안전합니다.
많은 프로그래머가 ValidAteRequest를 금지하려는 이유는 무엇입니까? 이것을 말할 필요가 없습니다. 다른 부분은 실제로 사용자가 XSS를 쉽게 유발하는 문자의 입력을 허용하지는 않지만,이 형태의 오류보고를 싫어합니다. 사용자가 아닙니다. 나는 불법적 인 캐릭터를 보았지만 오류를보고하는 것을 방해하는 방법을 몰랐기 때문에 직접 오류를 처리했습니다.
기본 ASP.NET 예외 오류 메시지를 사용하지 않고이 오류 메시지를 잘 처리하려는 프로그래머의 경우 validateRequest = false를 비활성화하지 마십시오.
올바른 방법은 Page_Error () 함수를 현재 페이지에 추가하여 처리하지 않고 페이지 처리 중에 발생하는 모든 예외를 포착하는 것입니다. 그런 다음 사용자에게 법적 오류 메시지를 제공하십시오. 현재 페이지에 page_error ()가없는 경우이 예외는 처리를 위해 global.asax의 application_error ()로 전송되며 일반 예외 오류 처리 기능을 작성할 수도 있습니다. 예외 처리 기능이 두 장소에서 작성되지 않으면이 기본 오류 보고서 페이지가 표시됩니다.
예를 들어,이 예외를 처리하려면 매우 짧은 코드 만 필요합니다. 이 코드를 페이지의 코드-비만 페이지에 추가하십시오.
| 다음은 인용 된 스 니펫입니다. ProtectedVoidPage_error (Objectsender, Eventargse) { ExceptionEx = server.getLasterror (); if (exishttprequestValidationException) { response.write (법적 문자열을 입력하십시오.); Server.ClearError (); // clearerRor ()가 clearError ()가 아닌 경우이 예외는 계속해서 Application_Error ()로 전달됩니다. } } |
이러한 방식 으로이 프로그램은 HTTPRequestValidationException 예외를 가로 채고 프로그래머의 소원에 따라 합리적인 오류 메시지를 반환 할 수 있습니다.
이 코드는 매우 간단하므로 사용자와 같은 문자를 실제로 입력 할 수없는 모든 친구가 예외 처리가 필요한 경우 위의 코드와 유사한 코드를 사용하지 않기를 바랍니다. . 할 수 있다.
이 기능을 명시 적으로 금지하는 프로그래머의 경우 자신이 수행하는 작업을 이해하고 필터링 해야하는 문자열을 수동으로 점검해야합니다. 그렇지 않으면 사이트가 쉽게 크로스 사이트 스크립팅 공격을 유발합니다.
리치 텍스트 편집기가있는 페이지를 어떻게 처리해야합니까?
페이지에 풍부한 텍스트 편집기가있는 컨트롤이 있으면 필연적으로 HTML 클래스 태그가 제출됩니다. 이 경우 validateRequest = false가 필요합니다. 그렇다면 보안을 다루는 방법은 무엇입니까?
Microsoft의 조언에 따르면, 우리는 보안 기반, 명시 적으로 허용되는 정책이라는 정책을 채택해야합니다.
먼저 입력 문자열을 httputility.htmlencode ()로 인코딩하고 HTML 태그를 완전히 금지합니다.
그런 다음 관심있는 보안 태그를 교체하고 대체 ()로 대체합니다. 예를 들어, 레이블을 갖고 싶다면 명시 적으로 대체 할 것입니다.
샘플 코드는 다음과 같습니다.
| 다음은 인용 된 스 니펫입니다. voidsubmitbtn_click (Objectsender, Eventargse) ... { // 모든 HTML 태그가 유효하지 않도록 입력 문자열 인코딩. StringBuildersB = NewstringBuilder ( httputility.htmlencode (htmlinputtxt.text)); // 그런 다음 선택적으로 <b> 및 <i>를 허용합니다 sb.replace (& lt; b & gt;, <b>); sb.replace (& lt;/b & gt;); sb.replace (& lt; i & gt;, <i>); sb.replace (& lt;/i & gt;); response.write (sb.toString ()); } |
이런 식으로, 우리는 일부 HTML 태그를 허용하고 위험한 태그를 금지합니다.
Microsoft가 제공 한 조언에 따르면, 이러한 HTML 태그는 크로스 사이트 스크립팅 공격으로 이어질 수 있기 때문에 다음 HTML 태그를 신중하게 허용해야합니다.
다음은 인용 된 스 니펫입니다.
|
아마도 가장 이해할 수없는 것은 <Img>입니다. 그러나 다음 코드를 읽은 후에는 위험을 이해해야합니다.
| 다음은 인용 된 스 니펫입니다. <imgsrc = javaScript : Alert ( 'Hello');> <imgsrc = java 
 스크립트 : Alert ( 'Hello');> <imgsrc = java 
 스크립트 : Alert ( 'Hello');> |
<Img> 태그를 통해 JavaScript 실행을 일으켜 공격자가 위장하고자하는 모든 것을 할 수 있도록 할 수 있습니다.
<tyle>도 마찬가지입니다.
| 다음은 인용 된 스 니펫입니다. <styletype = text/javaScript> ... 경고 ( 'Hello'); </스타일> |
| 다음은 인용 된 스 니펫입니다. '/YourApplicationPath'응용 프로그램의 서버 오류 잠재적으로 위험한 요청. 형식 값은 클라이언트로부터 감지되었습니다. (txtname = <b>). 설명 : 요청 유효성 검사는 잠재적으로 위험한 클라이언트 입력 값을 감지했으며, 요청 처리가 중단되면이 값이 중단 될 수 있습니다 그러나 Page Directive 또는 Configuration 섹션에서 validatequest = false를 설정하면 응용 프로그램에서 모든 입력을 명시 적으로 확인하는 것이 좋습니다. 예외 세부 사항 : System.Web.httprequestValidationException : 잠재적으로 위험한 요청. 형식 값은 클라이언트에서 감지되었습니다 (txtname = <b>). .... .... |