클 라 이언 트 XXX 에서 잠재 적 인 위험 이 있 는 Request. Form 값 - 최종 해결 방안 이 검출 되 었 습 니 다.

4595 단어
원본 링크:https://www.cnblogs.com/smallerpig/p/3646104.html
설명: ASP. NET 은 요청 에서 HTML 태그 나 스 크 립 트 를 포함 할 수 있 기 때문에 잠재 적 인 위험 을 포함 하 는 데 이 터 를 감지 합 니 다.이 데 이 터 는 크로스 사이트 스 크 립 트 공격 과 같은 프로그램의 안전 을 위협 하 는 시도 가 있 음 을 나 타 낼 수 있 습 니 다.이 유형의 입력 이 응용 프로그램 에 적용 된다 면, 명확 하 게 허 용 된 웹 페이지 의 코드 를 포함 할 수 있 습 니 다.자세 한 정 보 는 참고 하 시기 바 랍 니 다.http://go.microsoft.com/fwlink/?LinkID=212874。이상 상세 정보: System. Web. HttpRequestValidationException: 클 라 이언 트 (newsContent = "백 스테이지 테스트 백 스테이지 테스트") 에서 잠재 적 인 위험 이 있 는 Request. Form 값 이 검출 되 었 습 니 다.
 
이 경우 보통 폼 에 html 라벨 을 입력 했 기 때 문 입 니 다.ASP. Net 1.1 이후 제출 폼 에 XSS (크로스 스 크 립 트 공격) 가 있 는 지 자동 으로 검사 하 는 능력 을 도입 했다.사용자 가 페이지 에 영향 을 주 는 입력 을 사용 하여 결 과 를 되 돌려 주 려 고 할 때, ASP. Net 의 엔진 은 HttpRequestValidation Exception 을 일 으 킬 수 있 습 니 다.이것 은 ASP. Net 이 제공 하 는 매우 중요 한 안전 특성 이다.많은 프로그래머 들 이 안전 에 대해 개념 이 없고 심지어 XSS 라 는 공격 의 존 재 를 모 르 기 때문에 주동 적 으로 보호 하 는 것 을 아 는 사람 이 더욱 적다.ASP. Net 은 이 점 에서 기본적으로 안전 합 니 다.이렇게 하면 안전 에 대해 잘 모 르 는 프로그래머 가 일정한 안전 보호 능력 을 가 진 사 이 트 를 쓸 수 있다.
 
그러나 어떤 특수 한 상황 에서 이 라벨 을 입력 해 야 할 때 이 오 류 를 보고 하고 싶 지 않다.
 
그래서 다음 해결 방안 이 나 왔 다.
 
해결 방안 1:    . aspx 파일 헤더 에 이 문장 을 추가 합 니 다: 
1
   ASP. NET MVC 프로젝트 라면 대응 하 는 action 에 추가 합 니 다.
1 [ValidateInput( false )]
  해결 방안 2:    웹. config 파일 수정: 
1 2 3 4 5 < configuration >      < system.web >          < pages   validateRequest="false" />      system.web >

configuration >
 
  vaidate Request 의 기본 값 이 true 이기 때 문 입 니 다.false 로 설정 하면 됩 니 다.
 
ASP. NET 4.0 의 경우 주의해 야 할 것 은 웹. config 파일 의 설정 절 에 다음 과 같은 설정 을 추가 하 는 것 입 니 다.
1 < httpRuntime   requestValidationMode="2.0" />
 
 
또 이런 방법 들 은 문 제 를 해결 할 수 있 지만 최선 의 해결 방안 은 아니다.
 
다음은 가장 좋 은 방법 을 말씀 드 리 겠 습 니 다.
 
       올 바른 방법 은 현재 페이지 에 Page 를 추가 하 는 것 입 니 다.Error () 함 수 는 모든 페이지 처리 과정 에서 발생 하 는 처리 되 지 않 은 이상 을 캡 처 합 니 다.그리고 사용자 에 게 합 법 적 인 오류 메 시 지 를 보 냅 니 다.현재 페이지 에 Page 가 없 으 면Error (), 이 이상 은 Global. aax 의 application 로 보 내 집 니 다.Error () 가 처리 합 니 다. 당신 도 거기에서 통용 되 는 이상 보고 오류 처리 함 수 를 쓸 수 있 습 니 다.만약 두 곳 모두 이상 처리 함 수 를 쓰 지 않 았 다 면, 이 기본 오류 페이지 를 표시 할 수 있 습 니 다.
예 를 들 어 이 이상 을 처리 하 는 데 는 아주 짧 은 코드 만 있 으 면 된다.페이지 의 Code - behind 페이지 에 다음 코드 를 추가 합 니 다.
protectedvoid Page_Error(object sender, EventArgs e) {    Exception ex = Server.GetLastError(); if (HttpContext.Current.Server.GetLastError() is HttpRequestValidationException)    {        HttpContext. Current. Response. Write ("합 법 적 인 문자열 [되돌아오다 을 입력 하 십시오]");       HttpContext.Current.Server.ClearError();    } }
이렇게 하면 이 프로그램 은 HttpRequestValidation Exception 이상 을 캡 처 할 수 있 고 프로그래머 의 뜻 에 따라 합 리 적 인 오류 메 시 지 를 되 돌려 줄 수 있다.
이 코드 는 매우 간단 합 니 다. 그래서 저 는 사용자 가 이런 문 자 를 입력 하 는 것 을 허락 하지 않 는 모든 친구 들 이 이 안전 기능 을 함부로 금지 하지 않 기 를 바 랍 니 다. 만약 에 이상 처리 가 필요 하 다 면 위 와 같은 코드 로 처리 하면 됩 니 다.
이 기능 을 명 확 히 금지 한 프로그래머 에 대해 서 는 자신 이 무엇 을 하고 있 는 지 알 아야 하 며, 반드시 수 동 으로 걸 러 야 하 는 문자열 을 검사 해 야 합 니 다. 그렇지 않 으 면 사이트 가 크로스 스 크 립 트 공격 을 일 으 키 기 쉽 습 니 다.
 
 
Rich Text Editor 가 존재 하 는 페이지 는 어떻게 처리 해 야 합 니까?
페이지 에 부 텍스트 편집기 의 컨트롤 이 있 으 면 HTML 탭 을 제출 할 수 밖 에 없습니다. 이 경우 validate Request = "false" 를 사용 해 야 합 니 다. 보안 은 어떻게 처리 합 니까? 이 경우 크로스 스 크 립 트 공격 을 최대한 예방 하 는 방법 은 무엇 입 니까?
마이크로소프트 의 건의 에 따라 우 리 는 안전 상 '기본 금지, 명시 적 허용' 이 라 고 부 르 는 전략 을 취해 야 한다.
우선, 우 리 는 문자열 을 HttpUtility. HtmlEncode () 로 인 코딩 하여 HTML 탭 을 완전히 금지 할 것 입 니 다.
그 다음 에 우 리 는 우리 가 관심 이 있 는 안전 라벨 을 Replace () 를 통 해 교체 합 니 다. 예 를 들 어 우 리 는 '' 태그 가 있 기 를 원 합 니 다. 그러면 우 리 는 '명시 적 교체' 를 원 합 니 다.
void submitBtn_Click(object sender, EventArgs e)  {  //입력 문자열 을 인 코딩 하면 모든 HTML 탭 이 실 효 됩 니 다.     StringBuilder sb =new StringBuilder(HttpUtility.HtmlEncode(htmlInputTxt.Text));  //그리고 우리 의 선택 적 인 허락 과     sb.Replace("", "");     sb.Replace("", "");     sb.Replace("", "");     sb.Replace("", "");     Response.Write(sb.ToString());  }
 
이렇게 해서 우 리 는 일부 HTML 라벨 을 허용 하고 위험한 라벨 도 금지 했다.

좋은 웹페이지 즐겨찾기