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에 대한 정보 분석

web storage 란? (Wiki 설명)

web Storage란(이하 웹 저장소) 종종 D.O.M storage라고도 알려져 있다.

* Dom storage: Document Object Model Storage

​

웹 저장소는 웹 브라우저에 있는 데이터를 저장하기 위해 사용되는 프로토콜과

웹 어플리케이션의 Method를 제공합니다.

웹 저장소는 지속성 있는 데이터 저장을 지원합니다.

이는 쿠키(cokkies)와 유사하지만 강화된 용량을 가지며, HTTP 요청 헤더에 아무런 정보도 저장하지 않는 특징을 가졌습니다.

웹 저장소에는 대표적으로 두가지 타입이 존재합니다.

- Local starage, Session Storage 은 각각 영구적인 쿠키, 세션기반 쿠키와 유사하게 작동합니다.

​

모든 메이저 웹 브라우저는 W3C에 의해서 표준화된 웹 저장소를 지원합니다.

​

웹 저장소의 목적

웹 저장소는 클라이언트, 그리고 절대 웹 서버로 전달될 일이 없는 정보를 저장하는 것입니다.

​

웹 저장소는 단순하게 키-값의 구조로 데이터를 저장합니다.

이 때 세션 저장소와 로컬 저장소는 사용 목적이 구분됩니다.

로컬 저장소는 지속 가능한 자동 로그인, 혹은 설정값 등을 저장하며

세션 저장소는 간단한 입력 정보등을 저장합니다.

로컬 저장소는 브라우저에 계속 유지가 되지만(특별히 지우지 않는다면)

세션 저장소의 경우 브라우저 윈도우(탭 또는 새창)이 닫힐 경우 같이 제거됩니다.