[21.05.01] XXE, XSS

XXE

XML 엔티티

특정 태그를 제작할 수 있는 기능 제공. 이 태그는 특정 문자열을 다른 문자열로 전환하는 기능을 가짐

• internal entities 내부 엔티티
• external entities 외부 엔티티
• parameter entities 파라미터 엔티티

&[엔티티 명];

XML 파서

: XML 문법을 해석하는 소프트웨어 기본적으로 웹 브라우저에 탑재

XML 소스코드

<?xml version="1.0" standalone="yes" ?>

XML 프롤로그, 필수 코드는 아니지만 맨 위에 위치해야 함. 버전, 인코딩 방식, 외부 참조 여부를 XML 파서에게 알려주는 역할

<!DOCTYPE author [ ]>

DTD 문서의 시작을 알리는 부분

<!DOCTYPE author [ <!ELEMENT author (#PCDATA)> <!ENTITY js "Jo Smith"> ]>

루트 엘리먼트인 "author"에는 #PCDATA 형식의 데이터가 들어가야 된다고 선언

#PCDATA(Parse Character DATA, XML 파서에 의해 분석될 데이터)

엔티티 "js"는 본인이 호출되면 "Jo Smith"라는 글자로 교체될 것이라고 선언됨

<author>&js;</author> XML 문서에서 "js" 엔티티를 호출하는 코드

XXE

XML External Entity

입력되는 XML 구문을 파싱하는 어플리케이션을 대상으로(웹 사이트 등) 하는 공격.

입력받은 XML 데이터가 외부 엔티티(external entity)를 포함하고 있고 이를 취약하게 설정된 XML 파서가 처리할 때 발생.

공격 유형

• 기본: DTD에 외부 엔티티가 포함될 때를 이용한 방식
• 블라인드: 애플리케이션 응답에 에러 등의 반응이 없을 때를 이용한 방식
• 에러: 에러 메시지를 통해 전달되는 정보를 이용하는 방식

<!ENTITY js SYSTEM> 외부 엔티티

현대의 REST 프레임워크

최신의 REST 프레임워크를 사용하는 서버의 경우, 개발자가 생각하지 못한 형태의 데이터(요청 메시지)를 받아들이는 경우도 있다. 이에 따라 JSON 엔드포인트(서버에서 JSON 형식의 데이터를 받아 처리하는 부분)는 XXE 공격에 취약할 수 있다.

REST 프레임워크: 서버용 웹 어플리케이션을 만들 때 사용하는 라이브러리

Billion laughs

파라미터 엔티티

%[엔티티 명];

mitigation

XXE 공격을 방어하기 위해서는, 클라이언트로부터 입력되는 정보들을 충분히 검증해야한다

Java에서는 DTD를 애초에 사용하지 않도록 XML 파서에 설정할 수도 있음

 

Authentication Bypasses

인증 우회:데이터를 변조해서 시스템 요구 조건 만족

-숨겨진 입력: 사용자로부터 숨겨져 있는 입력값 이용

-파라미터 제거: 서버반응 확인

-강제 브라우징: 추측, 자동화 툴 등을 이용하여 링크 등으로 노출되지 않은 곳에 접근하려는 공격, 보호받지 못하고 있는 페이지가 있는 경우

 

JWT

액세스 토큰

JWT(JSON Web Tokens) : 클라이언트가 인증(권한 부여) 후, 주요한 작업을 수행과 관련하여 신원 확인 용도로 사용 Header + Claims+ Signature

Claims 영역+ 신원과 관련된 정보 담아서 전송 + 디지털 서명 ->작업전 매번 서버에 의해서 검증, 상태 비보존형(기록 유지를 통해 정확한 현황 유지)

HMAC: 해시가 사용이 되는 암호화 방식

 

인증과 jWT 획득

1. 계정명/패스워드를 통한 로그인

2. 암호키를 통한 JWT 생성

3. 브라우저를 통한 JWT 제공

4. 인가Authorization 헤더를 통한 JWT 제출

5. JWT 시그니처를 통한 검증 후 사용자 신원 확인

6. 응답 메시지 전송

 

JWT cracking

HMAC +　SHA-2 => 서명, 거명 검증 시 비밀키

암호키 -> 새로운 토큰, 서명 가능 => 강력한 암호키여야

 

리프레시 토큰

: 서버를 대상으로 API 호출(서비스 이용), 수명이 제한된 액세스 토큰이 더 이상 유효하지 않을 때 리프레시 토큰을 제출하면 새로운 액세스 토큰과 리프레시 토큰을 받을 수 있다. 사용자가 재인증을 해야하는 문제를 어느 정도 해결할 수 있다. 메모리나 데이터베이스에 저장.

 

액세스 토큰은 데이터가 다량으로 들어가 있어 리프레시 토큰에 비해 관리부담이 큼. 따라서 리프레시 토큰을 사용하면 관리 부담이 줄어든다.

 

Password reset(패스워드 재설정)

계정 존재여부 확인

보안 질문

패스워드 재설정 링크 생성

-랜덤 토큰을 이용한 고유 링크

-일회용

-일정 시간동안만 유효

 

안전하지 않은 직접 객체 참조

url/user/2000

url/user/2001 이런식으로

 

정보를 열람하거나 삭제하거나 실행하는 그런 것을 다 접근이라고 하는데 이 접근을 통제.

 

인증은 되었지만 인가,허가 되지 않은(우리 측 사용자는 맞지만 권한이 없는) 사용자로부터 공격에 취약

 

보통은 로그인이 인증 수단으로 쓰임

login 안하면 인증이 안된다.

 

동작 및 차이에 대한 관찰

raw(원시)응답과 가시적 응답의 차이.

raw는 드러나지 않는 경우.

 

f12는

burp suite의 http history와 비슷한 기능을 제공함

profile 파일 캐치해서 응답 header 캐치가능

바디를 찾기 위해선 응답데이터로 들어가면 된다.

이곳에서 도착은 했는데 화면에 표시되지 않은 정보들을 볼 수 있다.

 

브라우저가 모든 정보를 받는 것은 맞지만 겉으로 보여지는 것은 일부일 수 있다.

패턴 추측 및 예측

프로필 송 수신시 RESTful 패턴을 따른다.(웬만한 웹서버는 REST아는 설계방식에 사용된 원리 원칙에 대한 가이드(패턴)를 준수한다) 이 방법은 짧게 표현되는 가버운 환경에서 서버가 개발되었다는 뜻으로 사용된다.

권한 상승관련 취약점이 있다.

/profiled 이라는 주소만 사용해서는 개인 프로필 을 볼 수 없다. 인증 데이터를 통해 프로필을 볼 수 있는 형식이 아니기 때문이다.

f12 헤더에서 온 url을 얻어, 프로필 데이터를 확인할 수 있다.

다만 이 프로필에서 모든 사용자의 프로필이 뜨진 않지만 userid가 key처럼 구분할 수 있을 것으로 예측이 된다.

get으로 파라미터에 넣어 볼 방법이나, 디렉토리처럼 /를 사용하여 넣어 볼 방법들을 생각해 볼 수 있다.

 

위의 방식으로 메소드, 경로, 바디 변경해보기.

 

f12사용

파이어폭스는 오류날 시 고쳐서 다시 보내는 burp suite의 프록시와 비슷한 기능을 사용할 수 있다.

이를 통해 찾고자하는 user의 profile을 찾았다.

 

이를 수정해본다.

http method PUT이용

=를 :로 변경, 데이터를 ""로 둘러싼다.

content-type을 json으로 바꾸고

데이터를 바꾸는 방식으로 한다.

안전한 객체 참조(secure object references)

계정의 개수가 늘어날 수록 나중에는 관리 상태가 엉망이 될 수 있다.

이런 것들을 문서화하여 보관해야한다.

수직적 통제

수평적 통제

 

audit

규칙 위반에 대한 기록과 같이 접근 사항에 대한 기록지에 대한 내용이 있다.

 

using indirect references

간접 참조 사용

프로필에 해시함수를 사용하여 임의의 문자열이 만들어지는데 이 문자열을 프로필 대신 사용한다.

덕분에 userid url 숫자를 변조해도 안전해진다.

 

access control & api

jwt 인증, secure token binding

missing function level access control

기능 레벨 접근 통제 누락

 

idor vs missing function level access control

idor은 수직도 하지만 수평적 접근 통제에 대해 초점을 둔다.

후자는 여러 사용자에게 동일 권한을 부여하는 기능노출 등에 초점을 둔다.

 

relying on obscurity

공유기에 자바스크립트를 이용한 관리자 기능을 숨긴다.

 

finding hidden item

주석 찾기

css나 class의 숨겨진 item

 

숨겨진 메뉴를 찾아보자.

account 메뉴

messages 메뉴가 있다.

f12의 검사기 란을 들어간다.

html들이 보이고 element 구간 선택이 된다

이곳에서 선택이 안되는 히든 아이템을 발견 할 수 있다.

display : none;

visibility : hidden; 체크 해제 및 수정 가능.

 

just try it

 

gathering user info

접근 통제 미약으로 인해 유발

많은 단계가 있고 많은 시도가 요구된다.

주석이나 노출된 정보에 초점을 맞춘다.

내 계정의 해시값 찾아보기.

내 계정 (root1234)의 해시값 찾기

비밀번호는 해시함수를 통해 암호화되어 저장되어 있다.

get 요청 변경

ip:8080/Webgoat/users

7개의 유저가 웹고트에 존재한다.

burp suite로 요청메세지를 수정한다.

repeater 이용.

content-type : application/json

조회버튼에 대한 바디는 json 데이터나 text데이터를 넣어서 확인 할 것이라고 유추했기 때문에 넣는다.

 

다른 방법

post method 이용.

 

바디에 내용없다는 response가 온다.

{"username":"id", "password":"pw","role":"WEBGOAT_ADMIN"}

인데 role에 관한 것은 유추를 통해서 시도한다.

-----------------------------------------------------------------------------------------------------------------------------------

XSS

 

CONCEPT

• Cross-Site Scripting(XSS)이 무엇인지와, 이것을 이요하면, 개발자의 본래 의도와 다르게 작업이 어떤식으로 조작 될 수 있는지에 대해서 알아본다.

GOAL

• XSS의 기본적인 동작 원리 이해
• XSS 인젝션 공격을 방어하는 모범사례를 이해한다
• 아래 공격 방법을 구사한다
  1. Reflected XSS Injection : 반사형 XSS 인젝션
  2. Stored XSS Injection : 저장형 XSS 인젝션
  3. Dom-Base XSS Injection : DOM 기반 XSS 인젝션

---

What is XSS

• 웹 브라우저에서 사용자로부터 HTML이나 스크립트가 입력될 때 인코딩이나 안전한 상태로 변경하지 않고 그대로 허용할 때 나타날 수 있는 취약점/결함이다.
• XSS는 유명하면서도 치명적인 웹 어플리케이션 보안 이슈이다.
• 잘 알려진 보호 대책이 있지만, 인터넷에는 여전히 많은 피해 사례들이 보고 되고 있다. 방어 측면에서 보았을 때, 이것은 또한 나름대로의 문제가 있는데, 이를 조금 더 살펴보도록 한다.
• 특히 Rich Internet Application(RIA)가 수가 많아짐에 따라, 자바스크립트와 관련되어, 권한을 다루는 함수들은 위험에 처하고 있다. 만약 적절히 보호되지 않는다면 민감한 데이터(인증용 쿠키)가 탈취 및 악용될 수 있다.
  • Rich Internet Application : Flash, Ajax, HTML5 등의 진보된 기술을 활용하여 기존의 웹 브러우저가 제공하는 것들 외에 추가적인 기능을 제공하는 웹 애플리케이션
• 간단한 예시
  1. 브라우저의 주소 표시줄에 입력해본다.javascript : alert("XSS TEST"); javascript : alert(document.cookie);
  2. 데이터 입력이 가능한 모든 영역은 사실상 인젝션 공격의 위험이 있다.<script> alert("XSS TEST")</test>

실습 1 : XSS-2

• 두 웹 페이지의 쿠키값이 같은 지를 묻는 문제
• 정답 : yes
• WebGoat에서 사용중인 쿠키는 세션 쿠키에 해당하는데, 이는 현재 계정을 로그아웃 할 때까지 유효하며 임의로 저작하지 앟는 한 변동이 없다. 새로운 탭을 열거나 새로운 창을 연다고 해서 바뀌지 않는다. 다만 서로 다른 종류의 브라우저끼리는 쿠키를 공유하여 사용하지 않기 때문에, 다시 로그인을 해야할 것이며, 로그인 후에는 새로운 세션쿠키를 부여받을 것이기에, 기존에 사용하던 브라우저의 쿠키와는 다른 값을 갖는다.

---

XSS 취약점이 발생하는 대표적인 위치

• 검색한 문자열을 다시 사용자에게 보여주는 검색어 필드
• 사용자의 데이터를 노출하는 입력 필드
• 사용자가 입력한 문자열을 반환하는 에러 메시지
• 유저가 입력한 값을 보유하는 숨김 필드
• 유저가 입력한 값을 보여주는 페이지 - 게시판, 댓글
• HTTP 헤더

---

XSS를 조심해야 하는 이유

• XSS 공격은 아래와 같은 결과를 초래할 수 있다.
  1. 세션 쿠키 탈취
  2. 거짓 요청 생성
  3. 인증 정보를 획득하기 위한 가짜 필드 생성
  4. 수상한 사이트로의 연결(리다이렉트)
  5. 정상 사용자인척 가장된 요청 생성
  6. 인증 정보 탈취
  7. (스트립트를 통한) 사용자 시스템에서 악성 코드 실행
  8. 공격 코드 및 부적절한 문자열 삽입GoodYear recommends buying BridgeStone tires...

---

XSS 공격의 유형

Reflected XSS - ?를 사용해서 서버에 데이터를 넘기는 방식

• 공격자의 요청에 포함된 악성코드가 희생자의 브라우저 화면에 노출
• 악성 코드가 해당 페이지에 기록됨
• 사회공학 기법이 요구됨
• 희생자 브라우저의 권한으로 (악성코드가) 실행됨

Dom-Based XSS - #을 사용해서 서버에 데이터를 넘기지 않는 방식

• 공격자가 유발한 악성코드는 희생자 클라이언트 측에서 html 코드를 주입하는데 사용됨
• 리플렉티드 xss와 유사
• 희생자 브라우저의 권한으로 (악성코드가) 실행됨

Stored XSS

• 악성코드는 서버에 기록되며(db, 파일 시스템 및 다른 오브젝트), 추후 희생자의 웹 브라우저에 표시됨
• 사회 공학 기법이 요구되지 않음

---

Reflected XSS 시나리오

1. 공격자는 희생자에게 악성 URL을 전송한다.
2. 희생자는 해당 링크(URL)을 클릭하여 악성 웹 페이지를 로드한다.
3. URL에 심어져있던 악성 스크립트는 희생자의 브라우저에서 실행된다.
   • 이 스크립트는 세션 ID와 같은 민감한 정보를 탈취하여 공격자에게 전송한다.

 

1. 애플리케이션의 XSS 취약점 발견
2. 공격자는 URL에 공격 코드를 담아 희생자에게 전송 → 피싱메일 등이 이용
3. 희생자는 받은 URL을 클릭
4. 이렇게 단순 클릭만으로 공격은 성공(희생자는 인지하지 못함)
5. 그리고 이 공격 코드가 포함된 요청을 받은 서버는 해당 공격 코드를 그대로 반사(Reflect)하여 희생자에게 전달
6. 공격 코드가 희생자 측에서 실행
7. 희생자의 브라우저는 공격자에게 정보 유출

---

실습 2 : XSS-7. Reflected XSS

• 웹 보안 수업 XSS 실습과 유사하다
• 서버측에서 모든 입력값의 유효성을 검사하는 것은 좋은 관행이다. XSS 공격은 검증되지 않은 사용자의 입력 값으로부터 유발될 수 있다. 리플렉티드 XSS 공격에서, 공격자는 URL을 조작하여 공격 코드를 심는데, 이를 특정 웹사이트에 게시하거나 이메일로 전송하거나 혹은 다른 방법을 통해 클릭하도록 만든다.
• Enter your credit card number에 입력 : <script>alert('my javascript here')</script>
• → 동작을 하고, 취약하다는 것을 알 수 있음

---

Self XSS 와 Reflected XSS

• 이전 실습을 통해 스크립트르 실행할 수 있었는데, 이제 이것은 "self XSS"로 분류되어야 한다.

Why is that?

• 그 이유는, XSS 공격을 수행하기 위한 링크가 없기 때문이다. 당신은 어떤 일이 발생하는 지 스스로 테스트 했을 뿐이다. Reflected XSS라고 이야기 하려면 아래 링크 정도는 되어야 한다.

link:http://localhost:8080/WebGoat/CrossSiteScripting/attack5aQTY1=1&QTY2=1&QTY3=1&QTY4=1&field1=<script>alert('my%20javascript%20here')</script>4128+3214+0002+1999&field2=111

---

Reflected XSS 그리고 DOM 기반 XSS

• Dom 기반 XSS는 다른 형태의 리플렉티드 XSS이다. 둘 모두 입력 값을 통해 고의로 만들어진 링크에 의해 시작되어 희생자 브라우저에 반영된다. 그러나 이 둘에는 차이점이 있는데 DOM 기반 XSS의 경우 페이로드가 서버에 도달 하지 않고 오직 클라이언트에 의해서만 처리된다는 점이다.

1. 공격자는 악성 URL을 희생자에게 전송
2. 희생자는 전송 받은 링크를 클릭
3. 라우트 핸들러 : 요청 받은 경로와 관련된 업무를 처리하는 함수, HTML문서를 찾아 응답하는 것은 기초적인 처리
   • #이후에 나오는 값을 어떻게 처리하느냐에 따라 등장할 수도 있다.
4. 만약 연결된 페이지가 악성 웹페이지라면, 취약한 라우트 핸들러를 이용하여 자바스크립트로 제작된 악성 코드를 통해 다른 웹페이지를 공격할 수도 있음
5. 혹은 단순 취약한 웹페이지라면 페이로드를 해석하고 실행하며, 희생자의 정보(문맥)에 접근할 수 있음
6. 공격자의 악성 스크립트는 희생자(로컬 계정)의 권한으로 명령어를 실행할 수도 있음

• 희생자는 공격당했음을 인지하지 못한다. 알림이 있는 코드(alert 등)는 실제 공격에선 사용되지 않기 때문이다
• Reflect XSS와 Dom XSS의 가장 큰 차이는 서버에 정보를 전송하는지 여부이다. 여기서 언급된 DOM(Document Object Model)이란, HTML 문서를 다르는 표준을 의미한다. 예를 들어 <HTML> 태그 내부에는 <HEAD>와 <BODY>가 있어야 된다는 규칙은 DOM에 포함된다.
• HTML 문서를 DOM에 따라 의미있는 문법으로 해석하여 처리하는 것은 서버가 아닌 웹 브라우저 영역이다. 따라서 서버와 관계가 없다는 의미로 dom기반 XSS라는 이름이 사용된다고 인지하면 된다.
• Reflected XSS와 DOM 기반 XSS는 그 형태의 차이도 있는데, 전자는 URL에 물음표를 사용하여 이 기호의 우측 문자열을 서버에 전송하지만, 후자는 URL에서 해시 기호를 사용하여 이 기호의 우축 문자열을 자기 자신에게 전송하여 특정 위치로 이동하거나 자바 스크립트 코드의 동작을 촉발시키는 역할을 한다.

---

실습 3 : XSS-10. Identify Potential for DOM-Based XSS

• DOM 기반 XSS 공격은 일반적으로 클라이언트 측 코드의 경로(URL) 설정과 관련하여 발견되곤 한다. 사용자의 화면에 입력 값이 반영되는(보이는) 웹페이지들을 찾는 것으로부터 공격 가능성을 점검할 수 있다.
• 이번 예시에서는, 어떤 테스트용 코드를 확인하고 싶다고 가정한다. 목표는 해당 (테스트코드가 있는) 경로를 찾아 그것을 악용하는 것이다. 이와 관련하여 최초로 시작할 부분은, 해당 코드의 기본 경로가 무엇인지 찾는 것이다. 예를 들어, 현재 페이지와 URL를 보라. 이렇게 적혀 있을 것이다. /WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9. 여기서의 기본 경로는 /WebGoat/start.mvc#lesson이다. 우측에 붙은 CrossSiteScripting.lesson/9는 자바스크립트 라우트 핸들러에 의해 처리되는 파라미터이다.
• 이제, 소프트웨어 개발 중 이 애플리케이션에 남겨진 테스트 코드의 경로가 무엇인지 찾아 제출하라. 이를 위해서는 자바스크립트 코드를 열어볼 필요가 있다.
• 소스코드를 살펴보면, 오류 메시지를 포함해서 어떤 단서가 될 만한 메시지가 나올 가능성을 두어 링크를 클릭했고, 메시지가 출력된다. → GoatRouter.js
• 입력 : start.mvc#test/

---

실습 4 : XSS-11. DOM-Based XSS

• 일부 공격들은 성공 여부를 확인할 수 없다. 그러나 운 좋게도 스스로 서버를 구동하고 있으므로 성공 여부를 확인할 수 있다. 금방 전 확인한 경로를 이용하여, 경로 내 파라미터의 값이 적절히 필터링 되지 않음으로 인해, WebGoat내 특정 함수가 사용될 수 있는지 확인하라. 당신이 사용해야할 함수는 아래와 같다.
• webgoat.customjs.phoneHome()
• 콘솔이나 디버그를 통하여 호출할 수 있지만 새 탭의 URL을 통해 호출을 시도하라.
• 이 함수가 호출되면 임의 번호가 당신의 브라우저의 콘솔에 출력될 것이다.

 

• 새 탭을 열고 url 창에 http://localhost:8080/WebGoat/start.mvc#test/<script>webgoat.customjs.phoneHome()<%2Fscript> 입력 → 콘솔창에 나타나는 값이 답이 된다.

 

---

Stored XSS

• 페이로드가 (저장되어) 지속 존재하며, 이는 링크를 통해 전달 및 주입하는 과정이 필요한 다른 XSS와는 다르다

1. 공격자는 악성 스크립트를 게시판에 업로드 한다.
2. (업로드 된) 악성 스크립트는 서버의 데이터 베이스에 저장된다.
3. 희생자는 해당 게시글을 열람한다.
4. 게시글에 심어진 악성 스크립트는 희생자의 웹 브라우저에서 실행된다.
   • 이 악성 스크립트는 세션ID와 같은 민감 정보를 탈취하여 공격자에게 전송한다.

• 희생자는 공격이 발생했는지 인지하지 못한다.

---

실습 5 : XSS-13

• 아래 댓글을 확인하라
• 자바스크립트로 만든 페이로드가 포함된 댓글을 달도록 한다. 이 때 다시한번 "webgoat.customjs.phoneHome" 함수를 호출하도록 한다.
• 나는 (공세적 보안 측면에서의) 공격자로서, 대부분의 애플리케이션들은 매번 동일하 방식으로 구축되어 있지 않다는 점을 기억해야 한다. 또한 만은 경우, 당신은 성공적으로 데이터를 추출하기 위해 자바스크립트 코드를 동적으로 불러오는 방법을 찾아야 할 것이다.
• 웹 브라우저의 개발자 모드나 프록시를 활용하라. 이번 챌린지를 크릴어하기 위해서는, 출력 결과에 "phoneHome Response is ..."라는 값이 포함되어 있어야 한다. 한 가지 주의할 점은 "phoneHome"함수는 호출될 때마다 다른 값을 반환하는데, 가장 최근의 값을 제출해야 정답으로 인정한다.
• 댓글 창 : (아무값 입력)<script>webgoat.customjs.phoneHome( );</script>
• 개발자 모드에서 발생된 난수 → 정답

---

XSS Defense

WHY

• 타인의 악성코드가 본인의 브라우저에서 실행되기를 원하지 않는다는 점

WHAT

• XSS 방어의 기본은 신뢰할 수 없는 입력에 대한 인코딩이다. 이것이 더 정교한 공격을 유도할 수도 있지만, 여전히 최선의 방법이다.
• "신뢰할 수 없는 입력값"과 관련해서는 의심되는 모든 것을 신경써서 관리하라( 이미 DB에 입력된 자료도 다시 살필 필요가 있다) 때에 따라 DB의 데이터는 다양한 시스템들에 의해 공유되는데, 당신 것이라고 생각한 데이터가 사실은 당신이나 당신의 팀이 만들지 않았을 수도 있다.

WHEN / WHERE

• 데이터를 (서버에서 보유할 때 말고) 브라우저로 전송하는 시점에 인코딩하라. SPA(Single Page APP)의 경우, 클라이언트(브라우저)에서 인코딩 해야 한다. 이에 대한 일부 정보는 다음 페이지에서도 제공하며, 세부 사항은 관련 프래임워크/라이브러리를 참조하라.

HOW

1. 바디부분에서 (HTML 예약어를) HTML 엔티티로 인코딩한다.
   • HTML 예약어 : < > & 와 같이 HTML 문법용으로 사용되는 문자
   • HTML 엔티티 : 예약어를 해석 없이 화면에 그대로 표시하기 위해 사용되는 문자. 참고로 <는 < 이다.
2. HTML 엔티티로 인코딩한다.
3. 자바스크립트를 통해 사요자의 입력을 출력하느 경우, 자바 스크립트로 인코딩용 코드를 추가하여 인코딩한다.

Don't Do This

'<script>' 같은 문자열을 직접적으로 블랙리스트에 넣지 않는다. 이는 해당 문자열을 간접적으로 표현하는 등, 우회할 수 있는 요소가 많다는 의미로 생각된다.