IT's 잡탕찌개 블로그

Get 요청이 Post보다 보안에 안좋은 이유

. request 시 관련 정보가 URL에 노출

. Method를 해킹하는 경우 Post가 Get보다 더 어려움

CSRF 공격 (Cross-Site-Request-Forgery Attack) 

. 특정 WebSite를 분석하거나 WebApp을 구매한 후 분석

. 분석으로 알아낸 취약점, 주소 패턴 등을 파악

. 취약점을 사용하여 게시판 혹은 email을 사용하여 실제 User에게 악성 Link를 전송

 - ex : User가 naver에 login된 상태에서 특정 Link click 시 특정 게시글이 작성 됨

CSRF 공격을 방어하는 방법

. Web 사용 시 남는 흔적인 Referrer를 통해 검증

 - 해당 Backend Server에서 Request에 referrer가 BackEnd Server인지 확인

. CSRF Token을 사용

 - User Session별로 난수 식별자를 저장

 - 그 후 POST요청등에 해당 난수 식별자를 같이 전송하여 실제 유저의 Session 구분

URL

. 단순 인터넷 경로가 아닌 domain, network resource등을 이용하는 모든 형태

. scheme, user id, user password, host name, port, resource path, resource name, param등으로 구성

 - ex : http://naver.com?title=test&no=1#thisisflagment 

URL 문자 집합

. ASCII Code를 사용

 - 이와 관련된 이슈로 Encoding 시에 안전하지 않은 문자들이 존재.

 -> 해당 문자는 %를 앞에 붙힌 후 ASCII Code로 표현되는 16진수 두개로 표현.

 -> 그외에 특정 문자의 경우 예약되어 있으므로 주의 요망

단방향 암호화 알고리즘

. 사용자의 password등은 service 담당자 역시 알수 없어야 함

. 따라서 복호화가 불가능한 암호화를 거쳐 저장

. password의 적합성 여부는 동일한 암호화를 거친 후 결과값이 같은지 여부로 확인

. 일반적으로 SHA256이나 그 이상의 알고리즘을 많이 사용 

Rainbow Attack

. 입력값을 순차적으로 변화시켜 모든 문자열을 입력하여 일치되는 password를 탐색하는 공격 기법

Rainbow Attack 예방법

. Keyslating

 - 입력 받은 password등에 임의의 문자열을 추가로 붙인 후 암호화

. KetStretching

 - 기존 단방향 Hashing의 경우 속도가 매우 빠름

 -> 해커가 시도할 경우 기존에 1초에 수십억번 시도가 가능

 - 따라서 Hashing을 여러번하는 방식으로 방어

 -> 해커가 시도해도 password를 확인하는데 오랜 시간이 소요

SSL

. 기존의 id, password를 이용하지 않고  비대칭키 암호화를 통해서 서로 통신

. 서로 각자의 private key, public key를 생성

 -> A가 B에게 A public key전송 , B가 A에게 B public key 전송

 -> A가 B에게 Data 전송 시 자신의 private key로 암호화

 -> B는 A에게 받은 Data를 A public key로 복호화

Authentication : 인증

Authorizatoin : 권한

OAuth란?

. 기존 WebService 제공자가 해당 User의 개인정보를 보유하던 방식에서 탈피

. 기존 WebService 제공자 역시 보안상의 이슈를 피할 수 있음

. WebService 제공자가 User가 인증 및 권한 요청 시 타  Service를 통해서 해당 User를 검증하는 방식

. 장점으로는 User, WebService는 보안 이슈를 줄일 수 있고 타사의 REST API를 활용 가능

. 현재 OAuth1.0을 거쳐서 OAuth2.0을 사용가능

OIDC (Open ID Connect)

. 기존의 OAuth가 인증(Authentication)과 권한(Authorization)을 모두 제공

. 보통의 Service의 경우 인증(Authentication) 기능만 필요

. 권한(Authorization)에 대한 불필요한 호출을 줄이는 것이 가능

. 구글의 경우 OAuth Token을 얻을 시 OIDC값도 같이 넘겨준다.(작성자가 활용하던 시점 기준)

JWT(Json Web Token)

. Header, payload, signature 세가지 정보로 구성

. Header에는 사용한 암호화 방식등의 data가 존재

. payload에는 전달하려는 data가 존재

. signature에는 전달하려는 data를 privateKey를 통해 암호화한 서명(signature)이 존재

. 전체 Token의 경우 Header.Payload.Signature 로 '.'을 이용해 합쳐진 문자열이 된다.

Client - Server Model

. 해당 Model의 경우 Client를 설치 및 실행한 후 Server에 요청을 하면 Server가 응답해주는 Model

. 전통적인 방식이지만 문제가 발생 시 Client를 재배포해야하는 문제가 발생

 - ex : 배틀그라운드, 모바일 게임 등등

HTTP(HyperTextTransfortProtocol)

. Web Service에서 client가 Server에 요청하는 방식의 통신 Protocol

. HTTP에 SSL Protocol을 사용하여 보안을 강화한 후 data를 주고받는 방식이 HTTPS

HTTP의 Method

. GET

 - Server에 Data를 요청하기 위해 특정 URL 경로를 호출하는 방식

 - URL에 사용되는 문자는 오직 ASCII Code만 허가

 - 동일한 GET 요청에 대해서는 Page Caching이 가능

. POST

 - User가 Form등에 입력한 Data를 Server에 전달해줄 때 사용

 - 입력한 Data가 requestbody에 포함되며 URL에 노출되지 않음

 - Post로 넘겨주는 값은 여러 자료형이 가능하다.

 - RESTfull API에서는 특정 Data를 삽입 시 POST를 사용하도록 권장

. HEAD

 - GET과 유사한 방식이지만 요청의 Header data 를 제외하고는 보내지 않음

. PUT

 - 특정 Data의 전체를 갱신하고자 할 때 사용

. PATCH

 - 특정 Data의 일부만 갱신하고자 할 때 사용

. DELETE

 - 특정 Data에 대해서 삭제 요청을 할 때 사용

주요 HTTP 응답 Code

. 100 : Continue

. 200 : Request Success

. 201 : PUT Method에 의한 Data 생성 성공

. 202 : Accepted

. 400 : Bad Request

. 401 : Unauthorization

. 403 : Forbidden Request

. 404 : Not Found

. 405 : Method Not Allowed

. 408 : Request timeout

web server란?

. 하드웨어 측면 : web site의 component들을 저장하는 컴퓨터를 의미한다.

 - HTML, CSS, Image, JavaScript 등등

. 소프트웨어 측면 : Web User들이 Host의 파일들에 접근하는 방식을 관리하는 Server

Web Hosting 및 publishing

. Hosting Server는 항상 실행중인 상태여야 한다.

. 제 3자에 의해서 유지보수 된다.

. 항상 internet과 연결된 상태여야 한다.

Static Web Site

. Web Page의 적정인 부분들

 - CSS, HTML, javascript 등 모든 유저가 동일하게 보는 data들

Dynamic Wewb Site

. Web Page의 동적인 부분들

 - 각 User의 상태, 시간등에 따라 다르게 보이는 data들

SPA(Single Page Application)

. 전통적인 방식의 WebPage와는 다르게 단 하나의 Page로 구성된 Web App

. Servver를 통해서 Html을 다운받지 않고 필요한 data만 server에 요청, 응답을 받는다

. 필요한 경우 Html을 Client가 미리 갖고 있는다.

. web보다는 app에서 좀더 사용하기 좋은 방식

. 장점으로는 전체 Page를 갱신하지 않아서 요청, 응답속도가 빠르다.

. 단점으로는 실행 시 기본적인 Html을 읽어야 하기 때문에 초반에 다소 느릴 수 있고 구현에 있어서 복잡해진다.

Dynamic Web Site 과정

1. User의 HTTP 요청

2. 해당 HTTP 요청에 대한 Data[URL Encoding, Method, cookies]를 확인한다.

3. DB등에 Data를 요청하고 응답을 받는다.

4. 해당 Data를 WebApplication에서 WebServer로 전달한다.

5. Web Server는 HTTP 응답에서 해당 Data들을 포함한 후, 브라우저로 전달한다.

6. 브라우저는 해당 응답을 해석한 후 화면에 표현한다.

Server side에서 할 수 있는 것들

. 효율적이고 필요한 Data를 전달

. User 맞춤형 Data를 전달

. User Session에 따른 특정 권한, Page 제한

. User Session의 상태를 저장

. alter 및 comunication

. User에 대한 정보 분석