XSS 정규식

문자열이 XSS (크로스 사이트 스크립팅) 보안 위험인지 여부를 확인하는 데 사용할 수있는 정규식은 무엇입니까?XSS 정규식

출처

2011-01-06 Phil

상황에 따라 코드 생성 문자열에 Xss로 적합한 텍스트가 포함되어 있는지 확인해야합니다. 나는 웹상에서 몇 가지 예를 보았지만, 빌려줄 수있는 입증 된 정규 표현식을 가진 사람이 있는지 알고 싶습니다. – Phil

해당 문자열이 사용되는 컨텍스트에 따라 다릅니다. 문자열이 HTML 페이지의 한 부분으로 인쇄되는 경우 예를 들어

은 다음 특수 HTML 문자 <는 >, " 및 ' 잠재적 할 수 있습니다 XSS는 위험.

JSON을 통해 전달되는 경우 ' 및 "은 잠재적으로 XSS 위험 요소가 될 수 있습니다.

SQL 문에 포함 된 경우 (실제로는 적어도 직접 매개 변수화 된 쿼리를 사용하지 않아야 함) ; 및 역 따옴표 같은 것이 문제 일 수 있습니다.

등등.

출처

2011-01-06 23:31:34 Amber

XSS가 여전히 문제가되는 모든 작업을 수행한다고해도 유의해야합니다. – rook

사용자 데이터에서 생성 된 html의 인코딩되지 않은 < 문자를 찾습니다. < 문자가 없으면 사이트에 불쾌한 html을 삽입 할 수 없습니다.

사용자가 생성 한 서식을 허용하려면 허용 된 html을 하위 집합으로 제한하십시오. 이것을 정규 표현식으로 검사하는 것은 불가능할 것이므로 좋은 html 파서를 대신 권장합니다.

출처

2011-01-06 23:30:29 marcog

사용자 생성 형식을 활성화하는 표준 방법은 모든 태그를 비활성화 (모든 꺾쇠 괄호를 html 인코딩하여) 한 다음 허용하려는 태그를 "다시 추가"하는 것입니다. @marcog가 제안한 것처럼, 이미 그렇게 할 수있는 프레임 워크가있을 것입니다. 원래는 보이는 것보다 더 어려운 작업입니다. – Andrew

더 좋은 옵션은 Markdown (StackOverflow가 사용하는 것) 또는 BBCode (태그 기반 시스템을 선호하는 경우)와 같이 HTML이 아닌 서식 지정 마크 업을 사용하면 안전하지 않은 HTML 태그에 대해 걱정할 필요가 없습니다. – Amber

@Amber 생성 된 html이 안전하다는 점에 유의해야합니다. 기능에서 인코딩/디코딩/번역 기능으로 바운스하는 것이있을 때, 슬립 업을 찾기가 어려울 수 있습니다. – marcog

xss를 모두 중지 할 수있는 방탄 기능이 없으며 정규식이 최선의 선택이 아닙니다. XSS는 페이지상의 위치와 제한적 변경자 (예 : "'<>)에 대한 의존도가 높지만 포괄적 인 해결책은 아닙니다. 이러한 문자를 멈추었을 때도 MANY other ways of exploiting XSS. 악의적 인 href가 있습니다 : javascript:alert(/xss/) 및 이벤트 처리기 주입 : onload=alert(/xss/), 나열된 4 문자를 필터링하면 그 중 하나가 중지됩니다.

HTMLPurifier은 말 그대로 수천 개의 정규식으로 구성되며 항상 무시됩니다.

출처

2011-01-07 02:26:23 rook

답변

관련 문제