< > ' " 이렇게 4개 + 이벤트핸들러 틀어막고, 모든 input(GET, POST 메소드뿐만 아니라 SESSION, FILES 등 클라이언트가 조작가능한 값은 모두)은 출력하기 전에 urlencode해주고, 출력할때 "" 로 묶으면 안전해짐.


문제는 이러면 가용성을 해친다는건데 html을 열어줘야 할 경우에는 script, style, 이벤트핸들러 등 Javascript 사용과 관련된 키워드를 막아가면서 뚫고 뚫리는 싸움을 해야함.


css 관련해서 덧붙이면 최신 웹브라우저에서는 css에서 js 사용이 거의 불가능해졌지만, 보안적인 관점에서 개발자는 구버전 브라우저를 쓰는 사용자를 보호해야할 의무가 있음.


html을 열어주지 않았을때 가용성 저하의 소지가 있는건 urlencode인데 모든값을 urlencode 할 수 없다면 최소한 ' " whitespace tab carriagereturn linefeed 정도는 해줘야함.


가용성을 해치지 않는 범위 내에서 최대한 핵심적인 키워드를 많이 필터하는게 관건임. 


디시처럼 document.c0okie 이딴거 막고있으면 죽빵날려야하는거고.


그리고 공격자가 스크립트 삽입에 성공하더라도 얻어가는걸 최대한 줄이는 방법이 있음.


먼저 세션탈취를 막기위해 세션변수에 로그인시의 ip주소를 박아넣고, 모든 페이지에서 세션에 들어있는 ip주소와 현재 ip주소가 동일한지 체크하는것.


네이버 사용중에 프록시같은걸 타서 ip주소가 바뀌면 재로그인을 요구하는게 이런 이유.


이 방어기법을 우회하는데 쓰이는게 csrf 이고 csrf의 대안책이 csrf토큰, 레퍼러 체크인데 이건 잘 구현해도 특정 케이스 제외하고 우회가 가능함.


공격자를 귀찮게 만든다는데에 의의를 두자.


그 외에 X-XSS-Protection 헤더를 1; mode=block 로 설정해준다거나 하는 몇가지가 더 있고, 여기서 XXN같은 새로운 기법들까지 얽히고 섥힘.


XSS를 막으려면 주워들은것만 가지고 방어기법 덕지덕지 붙이지 말고, 기법을 이해하고 고찰한 후에 하지 말아야 할 행동을 정리해 가이드라인을 만들고 절대적으로 준수해야함.


서버사이드 언어, html, js, css, 웹브라우저 등이 복잡하게 얽혀있는데 땜빵질로 막아질리가 없지.


예를들어 네이버 xss 필터같은거 가져다 써봤자 HTML meta charset을 클라이언트가 지정가능하게 해주는순간 UTF-7 xss 펑 터지는거임.


더 쓰려면 나도 자료 찾아봐야해서 쓰기싫다.


그럼 20000.


=======================================================================


덤으로 길이제한, 정규식도 효과적인 방어기법임.


어느정도 방어를 했으면 우회를 위한 페이로드도 필연 길어지는데 여기서 길이제한을 걸어버리면 꽤 고생시킬 수 있음.


주민등록번호는 숫자 13자리만, 집주소 검색하는데에 non printable characters 입력하는 사람도 없을테니 틀어막고.


길이제한, 정규식은 가용성을 해치지 않는 범위 내에서 빡빡할수록 좋음.