'분류 전체보기'에 해당되는 글 438건

※ 오늘의 문장 : 난 오늘부터 영어 공부를 열심히 하기로 다짐했어

1. 처음 생각 : I decided english study hard since today

 → 카카오 번역 : 오늘 이후로 영어 공부를 열심히 하기로 결정했어요

2. 나의 최종 문장 : I decided study English hard since today.

 → English는 고유명사이기 때문에 앞 스펠링을 대문자로 하는 것이 좋고, study와 hard 사이에 공부할 명사가 들어온다.

3. 카카오 문장 : I decided to study English hard from today.

 → 동사 2개가 동시에 사용될 수 없으므로 decide와 study 사이에 to 혹은 ing를 써야한다. decide는 to와 사용하는 동사이므로 익숙해지자. 또한 오늘부터를 since가 아닌 from을 사용한다는 것도 파악!

4. 구글 문장 : From today, I decided to study English hard.

 → 카카오와 다르게 오늘부터를 뒤가 아닌 앞에도 사용할 수 있음을 파악!

1. Question

이번 포스팅을 시작하기에 앞서 먼저 질문을 드리겠습니다.

아래 코드에서 TEST를 눌렀을 때와 TEST2를 눌렀을 때 결과가 어떻게 될 것이라 예상하시나요?

TEST를 클릭했을 때는 당연히 123이 출력이 될 것입니다.

그렇다면 TEST2를 클릭했을 때는?

123')+alert('Hacked 이라는 문자열이 출력될 것이라 예상하시나요?

정답은 [그렇지 않다] 입니다.

TEST2를 클릭하게 되면 123이 출력되고 이후 Hacked라는 문자열이 출력됩니다. 

즉, <a onclick="alert('123&apos;)+alert(&apos;Hacked')">TEST2</a> 이라는 문장이

<a onclick="alert('123')+alert('Hacked')">TEST2</a>처럼 작동을 한다는 것이죠

2. Why?

이것은 왜 그럴까요?

대부분 XSS의 대응방안으로 싱글쿼터('), 더블쿼터(") 등을 HTML Entity로 인코딩하는 것으로 알고 계실겁니다.

사용자가 입력한 문자열이 자바스크립트 영역이나 HTML 영역에 포함이 되었다면 위와 같은 특수문자를 HTML Entity로 인코딩하여 대응이 가능합니다.

하지만, 위와 같이 사용자의 입력값이 Event Handler에 속하게 될 경우 브라우저가 이를 렌더링하여 원래 문자열로 변경하여 실행시키기 때문에 서버 측에서 사용자의 입력값을 HTML Entity로 변경하여도 실행이 되는 것입니다.

3. How?

그렇다면 위와 같이 사용자의 입력값이 이벤트 핸들러에 포함되는 경우 어떻게 대응을 해야할까요?

사용자가 입력한 값을 태그가 아닌 단순 문자열로 출력해주는 기능을 활용하면 됩니다.

JSP 언어 기준으로는 JSTL의 c:out이 있습니다.

c:out 태그의 escapeXml 옵션을 false로 지정하면 해당 스크립트가 실행이 되지만 true로 지정할 경우에는 값을 문자열 그대로 출력하기 때문에 스크립트 실행이 되지 않습니다.

◎ escapeXml=false

◎ escapeXml=true

따라서 만약 사용자로부터 입력받는 것을 단순히 ${input}이라고 지정했다면 c:out을 이용하여 아래와 같이 수정하면 됩니다.

(참고)

https://needjarvis.tistory.com/51

https://webcoding.tistory.com/entry/JSP-JSTL-cout-%ED%83%9C%EA%B7%B8-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

0.개요

브라우저는 어플리케이션에 속한 스크립트와 제3자가 악의적으로 주입한 스크립트를 구분하지 못한다. 그래서 이것을 이용한 공격이 있는데, 그것은 바로 XSS(Cross Site Scripting) 취약점이다. 

해당 취약점에 대한 공격의 위험과 영향을 줄여주기 위해 브라우저에게 신뢰할 수 있는 데이터에 대한 허용 목록을 클라이언트에게 알려주는 CSP(Content Security Policy)에 대해 알아보도록 하겠다.

1. 소스 허용 목록

Content-Security-Policy HTTP 헤더를 통해 신뢰할 수 있는 데이터의 허용 목록을 클라이언트에 알려준다.

예를 들어 자기 자신과 rootable.tistory.com에서는 신뢰할 수 있는 컨텐츠가 제공될 것이라 믿을 경우, 다음과 같은 csp를 통해 코드의 출처가 다음 두 가지 소스 중 하나일 때만 스크립트 실행을 허용할 수 있다.

2. 다양한 리소스 정책

csp가 스크립트 리소스에 대해 허용 목록을 제공하기 위해 만들어진 것이지만, 스크립트 뿐만 아니라 다양한 리소스에 대한 제어 정책 지시문도 제공하고 있다.

대표적으로 default-src 지시문을 통해 -src로 끝나는 모든 지시문에 대해 정책을 정의할 수 있다.

예를 들어 다음과 같은 정책이 있다고 가정해보자.

만약 위와 같이 정책이 설정되어 있을 때 img-src, media-src를 따로 지정하지 않는다면 https://rootable.tistory.com에서만 이미지 로드, 미디어 로드가 가능하다.

이외에도 다음과 같은 지시문들이 더 존재한다.

위 표는 많이 사용되는 것들 몇개만 나열한 것이므로, 자세한 것은 다음 사이트를 참고하길 바란다.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

3. 소스 목록

3.1 직관적인 소스 목록

지시문에서 정의하는 소스는 단순히 나열할 수 있고, 각 지시문은 세미콜론( ; )을 통해 구분을 한다.

1) 스크립트 지시문 소스 나열

2) 지시문 나열

3.2 소스 목록의 유연함

각 지시문의 소스 목록은 유연하게 작성할 수 있다.

data: , http: 와 같은 프로토콜 기준으로 소스 지정이 가능하며, 호스트 이름만으로도 가능하고, 포트까지 정의도 가능하다.

게다가 와일드 카드가 허용되지만, 프로토콜이나 포트, 호스트 이름의 맨 왼쪽 위치에서만 허용된다.

허용되는 부분에 와일드 카드를 적용한 것은 다음과 같은 형태이다.

3.3 키워드

소스 목록에서는 다음 4개의 키워드도 허용된다.

◎ 'none' : 아무것과도 일치하지 않음

◎ 'self' : 현재 출처와 일치, 하위 도메인은 일치하지 않음

◎ 'unsafe-inline' : 인라인 자바스크립트 및 CSS 허용

◎ 'unsafe-eval' :  eval과 같은 텍스트-자바스크립트 메커니즘 허용

이 때, 각 키워드는 작은 따옴표가 필요하다.

만약 script-src self로 작성할 경우, self가 키워드로써 작동하는 것이 아니라 self라는 이름의 서버에 존재하는 자바스크립트를 허용하도록 설정된다.

4. 활용 예시

1) 소셜 미디어 위젯

구글의 +1 버튼, Facebook의 Like 버튼, Twitter의 Tweet 버튼을 허용하기 위해서는 다음과 같은 CSP가 적용된다.

2) SSL 전용

모든 리소스를 보안 채널을 통해서만 로드하고 싶을 경우 다음과 같은 CSP로 가능하다.

(참고)

https://developers.google.com/web/fundamentals/security/csp?hl=ko#구현_세부정보

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web

System.currentTimeMIllis()를 이용하여 프로그램 수행 시간을 확인하는 코드이다.

시간이 얼마나 걸릴지 확인하고자 하는 코드의 시작지점과 끝 지점에 System.currentTimeMIllis()를 삽입하여 시간을 체크하고, 그 차이를 이용하여 걸린 시간을 확인할 수 있다.