6. Web security

Background

민감한 업무가 Web을 통해서 이루어짐에 따라 Web은 공격 타겟이 되가고 있다. 다음의 여러 공격 유형이 있다.

• Session hijacking
• Cross site scripting
• Cross site request forgery
• SQL injection
• Information leakage

 

 

Web browser and network

브라우저의 request에 네트워크는 reply로 반응한다.

Reply에는 response page 뿐만 아니라, code도 포함될 수 있다. Attack에 사용될 여지는 충분하다.

 

 

Web security / Privacy issues

여러 이슈가 있다.

• Secure communication : HTTPS (HTTP + SSL)
• User authentication : Cookie
• Session management : Cookie
• Active contents from different websites : Browser의 자원 보호
• Web application security
• Webiste authentication : anti-phishing
• Privacy concerns

 

 

HTTP : HyperText Transfer Protocol

Browser → Server : HTTP request

Server → Browser : HTTP response

 

HTTP request는 3가지 method로 나뉜다.

• GET - resource 얻기
• POST - form 주기
• HEAD

 

HTTP는 stateless request, response protocol이다. Stateless라는 말은 상태가 유지되지 않는다는 것으로 각 request가 과거의 request와는 독립 관계임을 의미한다. Stateless는 application의 구현과 디자인에 많은 영향을 준다. (상태를 저장할 수 없으니까)

 

 

Cookies

Website가 name-value pair를 생성해서 브라우저에게 전달하면, 브라우저는 해당 정보를 컴퓨터에 저장한다. 저장된 정보를 쿠키라고 하며, 브라우저는 매 request마다 쿠키를 함께 보내, 자신을 인증한다. 자신을 인증한다는 것은 자신의 상태(인증된 상태)를 쿠키게 저장한다는 것을 의미하기도 한다.

 

HTTP : stateless

Cookie : state

 

쿠키 정보에는 여러 정보가 포함되며, 다소 민감한 정보도 포함된다. 대신 인증과정이나 상태가 유지됨으로 편리성이 증가한다. 구체적으로 포함되는 정보는 다음과 같다.

• Name : session_token
• Content : "abasdjklxcnv09i3qrjdfklms..."
• Domain : .dgist.ac.kr
• Path : /
• Send For : Any type of connection
• Expires : Mon, Sep 08, 2043 7:23:14 PM

 

쿠키는 보통 authentication, tracking, maintaining special information of user를 위해 사용된다. 민감한 정보가 포함되지만, 쿠키는 오직 쿠키를 생성한 website만 읽을 수 있다.

 

 

Web authentication vi Cookies

HTTP는 stateless로 로그인 기록을 저장할 수 없지만, 쿠키를 사용하면 가능하다. 과정은 다음과 같다.

• 유저가 성공적으로 인증되면 서버는 authenticator를 생성하여 쿠키로 사용한다.
  (ex. access token)
• 클라이언트는 쿠키를 위조할 수 없다.
• 브라우저는 매 request마다 쿠키를 함께 보낸다.
• 서버는 쿠키를 보고 사용자를 인증한다.

 

 

A typical session with Cookies

클라이언트는 쿠키를 위조할 수 없으며 쿠키는 장기간이나 세션 단위로 유지된다. 어떻게 위조가 안되고 tamper-proof하게 만들 수 있을까?

 

이후 내용이 위 질문에 대한 답이다.

• Cross Site Scripting
• Cross Site Request Forgery
• SQL Injection

 

 

Cross Site Scripting

Web site에는 dynamic content(code) 삽입이 가능하다. 대표적으로는 Javascript, Java applets, 브라우저 확장 프로그램이 있다.

 

브라우저는 content를 받아서 HTML을 보여주고 script를 실행한다. 이로써 다음의 동작이 가능해진다.

• Client-side host의 local file read / write
• 브라우저에 의해 유지되는 web resource 탈취할 수 있다. 대표적으로 쿠키, DOM object가 있다.
  • DOM object 탈취로 가능한 내요은 다음과 같다.
    개인정보 훔치기
    User가 보는 화면 조작
    User 흉내내기

 

*DOM? 우리가 보는 웹 페이지는 object로 구성되어 있다.

 

 

Browser as OS

유저는 여러 웹 사이트를 방문하게 된다. 브라우저는 여러 domain에서 web page를 불러오게 된다. 이 과정에서 untrusted entity의 program을 실행하게 되는데, 이런 code는 위험성이 높다. 또한 이런 domain으로부터 생성 및 유지되는 쿠키도 공격에 사용될 여지가 충분하다.

 

브라우저는 다음의 대안을 사용하고 있다.

 

→ 브라우저는 sandbox(제한)로 스크립트가 local resource에 접근하지 못하도록 막는다.

→ 브라우저는 security policy를 사용한다.

     브라우저가 유지하는 resource의 관리 및 보호, untrusted script간의 separation이 가능해진다.

 

 

Sandbox

Separating / Limitating running program

 

Program이 요구하는 resource를 명확하게 파악하고 그 외 resource의 접근은 제한한다. 다음의 방법으로 구현이 가능하다.

• OS-level virtualization
• VIrtual Machine monitor
• Java applets

 

 

Same Origin Policy, SOP

브라우저의 가장 기초적인 security model이다. 다른 origin에서 받은 스크립트나 resource를 격리시키는 정책이다.

 

ex) digist.ac.kr의 스크립트는 kaist.ac.kr resource에 접근하지 못한다.

 

쉽게 말해, Origin이 security principal이 된다. Origin의 구성요소는 다음과 같다.

• Scheme (protocol)
• Host (domain)
• Port

 

3가지가 모두 같아야 SOP를 만족한다. 같은 SOP에서는 다음의 작업이 가능하다.

• 브라우저 윈도우 조작
• XmlHttpRequest로 URL 요청 가능
• frame 조작
• document 조작
• cookie 조작

 

 

Problems with SOP

• 일부 오래된 브라우저에서는 잘 동작하지 않는다.
• 웹 페이지가 unrelated하지만, SOP에 의해 서로 접근이 가능한 경우 문제가 된다.
  • naver.com/account/
  • naver.com/other account/
• Usability 측면 ; cross-origin resource 공유가 필요하지만, SOP에 의해 제한된다.

 

 

Browser architecture ; One process vs Multiple processes 

중간에 갑자기 들어가는 내용

대부분의 Web 브라우저는 one process이다. 여러 web page를 렌더링하는 경우, multiple threads가 이용된다.

 

다만 chrome은 multiple processes를 이용한다. 각 프로세스는 browser, renderer, plug-in을 사용한다. 다음의 장점을 가진다.

• OS protection mechanism
  Process간의 resource 접근을 제한해준다.
• Reliability
  하나의 웹 페이지에 렌더링 중 에러가 발생해도 다른 페이지에는 영향을 주지 않는다.
• Security
  렌더링 중 취약점이 발생해도 다른 페이지에 영향을 주지 않는다.

 

 

Cross-site scripting, XSS

스크립트를 이용해 공격하는 방법이다. 일부 application은 유저의 input을 web page의 part로서 사용하기 때문에 가능한 공격이다. 공격과정은 다음과 같다.

• Web page 내부 스크립트가 브라우저에 의해 실행
• 스크립트로 쿠키 접근이 가능
  → 개인정보 유출
• 스크립트로 DOM object 조작 가능
  → 유저가 보는 화면 조작(링크 변경)

 

 

XSS on Blog

댓글로 공격을 수행한다.

• 공격자가 malicious comment를 스크립트 형식으로 작성하여 댓글 작성
  (local authentication 인증서를 읽고 이를 공격자에게 보내는 코드)
• Blog post를 보는 사람은 local authentication 쿠키를 가지고 있을 수 있음
• 브라우저는 악성코드를 확인하지만, 종종 실패함
• 브라우저에 버그가 있으면, 공격 성공

 

 

Effect of XSS attack

공격자가 임의의 스크립트를 실행할 수 있게 된다. 

• DOM object 조작
  링크 바꾸기
  form으로 pw를 치면, 사이트로 연결해줌(pw 탈취)
• Other user 감염
  Domain 감염 → 접속하는 user 감염

 

 

XSS attack ; MySpace.com

유저는 HTML을 포스팅할 수 있었다. 대신 MySpace에서는 <script>, <body>, <a href=javascript://>, onclick을 포함하지 않아야 HTML 포스팅을 할 수 있다.

 

그러나 공격자들은 CSS tag에 javascript 코드를 포함시켜 XSS 공격을 수행하였다.

<div style="background:url('javascript: alert(1)')"/>

 

대표적으로 Samy worm 공격이 수행되었다. MySpace 페이지에 접속하면 Samy를 친구로 추가하는 공격이었다. Samy는 24시간 내 수백만의 친구가 생겼다.(오?)

 

 

PHP, avoiding XSS bugs

Input을 확인하는 것은 어려운 일이다. HTML에 스크립트를 삽입하는 방법은 매우 다양하기 때문이다. 대신 PHP는 유저로부터 input을 preprocessing하는 방법으로 확인한다.

 

PHP, Hypertext Preprocessor : htmlspercialchars(string)

• &   → &amp;
• "    → &quat;
• '    → &#039;
• <   → &lt;
• >   → &gt;   

 

htmlspercialchars("<a herf='test'>TEST<a>")

→ &lt;a href=&#039...

 

 

ASP.NET, avoiding XSS bugs

• PHP처럼 Server.HtmlEncode(string) 함수를 이용해 HTML을 인코딩한다.
• validateRequest를 통해서 HTML을 확인한다.
  • POST에 <script>가 있으면 동작을 안한다.
  • Hardcoded list의 패턴을 참고해 검사한다.
  • Disabled 가능하다.
    <%@ Page validateRequest="false" %>

 

 

Cross Site Request Forgery, CSRF or XSRF

One click attack, Session riding으로도 알려져 있다.

 

Authentication에 session cookie만 사용하는 web applciation을 타깃으로 공격한다. 공격자는 유저의 쿠키 정보를 가지고 다른 웹 어플리케이션에 유저의 인증으로 명령어를 전송하는 공격이다.

 

이 공격이 가능한 이유는 브라우저가 도메인 X에 의해 설정된 쿠키를 도메인 X로 보내지는 요청에 첨부하기 때문이다. 예를 들어서, X 사이트에서 Instagram으로 redirect해주는 경우, 이미 로그인 되어 있으면, 브라우저가 쿠키를 함께 보내준다.

 

 

CSRF

공격 예시를 들어보자면 다음과 같다.

• 유저가 Youtube에 로그인하고 로그아웃하는 것을 까먹는다.
• Session 쿠키가 브라우저에 남아있는다. 다른 웹 사이트에 방문하는 경우, 다음처럼 보내진다.
  
  <from name=F action=https://www.youtube.com/name.php method=POST>
     <input type=hidden name=email value=name@gmail.com> ...
  <script> document.F.submit(); </script>
  
  
• Malicious 웹 페이지는 유튜브에 HTTP request를 보낸다.
• 브라우저는 session 쿠키를 함께 보내준다.
• 유튜브는 request를 수행해준다.

 

브라우저는 누가 request를 보내는지 알 방도가 없다.

 

 

Prevention

서버 측면에서, 유저 측면에서 예방할 수 있다.

Server side	User side
Cookie랑 hidden value로 같이 authentication 수행하기  - hidden value는 예측 불가능, user-specific  - 위조하기 위해서는 hidden value를 예측해야 함 Cookie를 포함하기 위해서는 POST request의 body가 필요함  - 브라우저는 자동으로 쿠키를 보내지 않음  - Malicious는 쿠키를 추가해야 함  - 하지만 malicious는 SOP에 의해서 body에 접근할 수 없음	로그아웃 하기 Request에 session 쿠키를 선택적으로 보내기  - script code에 의한 request에는 쿠키를 보내지 않기

 

 

SQL Injection

대충 설명하면, Query 명령어의 특징을 이용해 Input form에 John" OR 1=1 -- 식의 값을 넣어서 쿼리에서 동작하도록 공격하는 방법이다.

 

공격자는 이 방법을 통해서 새로운 데이터를 데이터베이스에 추가하거나 기존의 정보를 수정하거나 모든 정보를 지우는 등의 작업을 수행할 수 있다. 다만 table 이름은 알고 있어야 한다. 몇 웹 사이트에서는 error문으로 table 이름을 보여줘서 얻는 것이 불가능하지는 않다.

 

Best 방어방법은 bound variable을 사용하는 것이다. 다른 말로는 PreparedStatement를 사용하는 것인데, 내부적으로 Statement의 4단계 과정 중 첫 번째 parse 과정의 결과를 캐싱하고, 나머지 3가지 단계만 거쳐서 SQL문이 실행될 수 있게 한다. 이를 통해서 SQL injection을 방어할 수 있다. 

 

SELET * FROM user WHERE id = ? AND password = ?

쉽게 설명하면 ?에 입력값이 field처럼 들어가기 때문에 수작을 막을 수 있다.

 

그 외에도 escaping string을 " → \"으로 바꿔서 문법 오류를 강제로 발생시키는 방법도 있다. 하지만 이 방법은 "이 없는 input에 대해서는 효과가 없다. 가령 SELECT sth FROM table WHERE id= 23 OR 1=1

 

또 다른 방법으로는 Input의 형식을 체크하여 쿼리문에 들어오기 전에 걸러버리는 방법이다. 대부분의 SQL injection 공격이 긴 string으로 이루어지는 것을 고려해보면, 글자수 제한도 좋은 방법이 될 수 있다.

 

 

Web Privacy Issues

Browser cookie management

SOP for cookies

쿠키는 쿠키를 생성한 웹 사이트만 접근이 가능하다.

 

Cookie의 종류

     |-------- Temporary cookie

                   브라우저를 나가면 삭제된다.

     |-------- Persistent cookie

                   쿠키는 지우거나, 만료되면 삭제된다.

     |-------- Third-party cookie

                   유저가 방문한 페이지에서 생성된 쿠키가 아니라, 다른 웹사이트에서 생성된 쿠키를 말한다.

 

 

Third-party cookies

doubleclick이라는 광고 사이트로 예시를 들어 설명한다.

• merchant.com 접속한다.
  <img src=https://doubleclick.com/abc.gif> 가 포함되어 있다.
  이미지는 doubleclick에서 fetch되었다.
  doubleclick은 유저의 IP주소와 페이지를 알고 있게 된다.
  
  
• doubleclick에서 적절한 광고를 보낸다.
  유저 브라우저는 doubleclick에서 생성한 쿠키를 저장한다.
  
  
• 다음에 doubleclick의 image가 포함된 페이지에 접속하면, 유저의 doubleclick 쿠키가 전송된다.
  doubleclick에서는 유저가 보던 사이트 history를 유지하고 있다가, targeted 광고를 보낸다.
  업데이트된 쿠키도 전송하고 유저 브라우저는 이를 저장한다.
  
  
• doubleclick과 협업하는 사이트에도 doubleclick의 쿠키가 전송될 수 있다.

 

 

Cookie issues

위 예시에서 볼 수 있듯, 쿠키에는 개인의 브라우징 습관이 기록된다. 또한 웹 사이트들은 이 정보를 공유할 수도 있다. 다시 말해 개인정보가 공유된다고 볼 수 있다.

 

 

Browser Fingerprinting

브라우저는 HTTP head에 정보를 포함해서 보낸다. OS정보, 브라우저 정보, 브라우저 플러그인 등의 정보가 포함되며 이는 유저를 tracking하는데 사용될 수 있다.