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

요즘은 점점 더 스마트 기기를 이용하여 Game을 즐기는 사람들이 늘어나고 있다.

Pc와는 다르게 Mobile에서는 session이 끊기는 일이 자주 발생하며

이러한 특징에 의해서 Mobile Game Server는 PC Game Server와는 다른 특이사항들이 존재한다.

이중 하나가 바로 HandOver인데 HandOver가 어떤것인지 알아보자.

수집형 RPG 모바일 게임등의 경우 실시간 동기화가 아닌 비동기식으로 게임을 진행하는 경우가 많다.

예를 들자면, 카드 수집형 RPG의 경우 전투를 시작할 시 전투 시작정보를 server와 통신한 후

실제 전투는 Server와 통신없이 진행된 후 마지막에 결과정보만 Server에 전달하는 식이다.

이러한 때문에 짧은순간만 Server와 통신을 해도 게임 진행이 가능하다는 특징이 있다.

그러나 이러한 특징과 모바일 기기의 특징이 만나면 PC와는 다른 예외상황들을 고민해야한다.

전투 시작 전 Session과 와이파이로 바뀐후에 전투결과를 Server로 보낸경우 동일 유저임을 어떻게 판단할 것이며

그에 따른 처리는 어떻게 진행해야 하는가등을 고려해야 하는 상황이 된것이다.

이러한 문제를 해결하기 위해서 Client는 Server에 접속할 시 SessionKey 등의 특정 식별값을 받는다.

그 후 실제 재접속이 이루어질 때 해당 SessionKey를 전달하여 재접속 처리를 진행한다.

(예를 들면 유저가 대기화면에서 Handover 발생시 Session이 접속해있던 LobbyServer로 연결을 다시 해준다거나 등등)

참고 : http://elky.tistory.com/318

LockFree에 대해서 검색하던 중 알게된 용어.

Convoying이란 MultiThread 구현 시 무분별한 Lock의 사용으로 인해서

MultiThread의 장점을 활용하지 못하고 특정 Thread가 작업 시 다른 Thread는 Lock에 걸린채로 대기하는 문제를 말한다.

즉, 특정 Lock에 대하여 여러 Thread가 접근하려고 할때 획득하지 못한 Thread들을 모두 기다릴 것이다.

이러한 상황에서 불필요한 ContextSwitching이 발생하며 비용이 발생할 수 있다.

Convoying을 해결하기 위해서는 LockFree 알고리즘을 활용하는 것도 좋은 방법이다.

위키에서는 Convoying을 이렇게 표현하더라

In computer science, a lock convoy is a performance problem that can occur when using locks for concurrency control in a multithreaded application.

[ 출처 : https://en.wikipedia.org/wiki/Lock_convoy ]

LockFree 알고리즘이란?

. MultiThread에서의 동기화 기법(lock 등)을 사용하지 않고 다중 호출에 대하여 최소한 1개의 호출이 완료되는 알고리즘

. Game Server에서는 JobQueue등에서 사용할 수 있다.

. 원리는 자료구조에 대하여 변경을 수행할 때 다른 Thread가 접근한 경우 작업 시도를 취소하는 것이다.

LockFree 알고리즘을 사용하는 이유

. 잘못된 MultiThread 사용으로 인한 성능 하락이 없다.

. lock을 사용하지 않고 DeadLock 이슈를 피하기 위해서

. 다른 Thread의 상태와 상관없이 호출이 완료된다.

. non blocking 하면서 원장성을 유지해야 하는 경우

LockFree에서 사용하는 자료구조

. Queue : enqueue, dequeue

. Stack : pop, push

. BinaryTree : insert delete, search

//걍 대충 적은 코드

push(int x)
{
	var e = new Node(x);
    lock(new object())
    {
    	someTail.next = e;
        somTail = e;
    }
}

push_nonBlock(int x)
{
	var e = new Node(x);
    while(true)
    {
    	var t = someTail;
        var next = t.next;
        if(t != someTail)
        	continue;
        if(next == null)
        {
        	if(Interlocked.Compare(t.next, null, e))
        	{
            	Interlocked.Compare(someTail, t, e);
            	return;
        	}
        }
        else
        {
        	Interlocked.Compare(someTail, t, next);
        }
    }
}

LockFree 알고리즘의 단점

. 구현하기가 다소 난해하다.

. 코드가 복잡해져서 버그를 발견하기가 어렵다.

=> 요즘 장비 성능도 좋아지는데 걍 멀티스레드를 잘 활용하는게 좋은듯?

web storage 란? (Wiki 설명)

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

* Dom storage: Document Object Model Storage

​

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

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

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

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

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

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

​

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

​

웹 저장소의 목적

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

​

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

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

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

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

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

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

SQL 쿼리에 있어서 가장 기본적인 쿼리는 아래와 같다

. 삽입 (insert)

. 삭제 (delete)

. 갱신 (update)

. 조회 (select)

DB를 활용함에 있어 위의 4가지 쿼리를 조합하고 활용하며 여러 작업을 할 수 있다.

삽입

INSERT INTO tableA as A (columnName1, columnName2, ...) VALUE (, , ...);

혹은 여러 값을 한번에 삽입

INSERT INTO tableA as A (ColumName1, ColumName2, ...) VALUES (val1, val2, ...), (val1, val2, ...);

혹은 ColumnName을 생략하는 경우 Column 수, 타입에 맞는 value들을 명시해야함

INSERT INTO tableA as A VALUE (val1, val2, ....);

INSERT INTO tableA as A VALUES (val1, val2, ...), ..., (val1`, val2`, ...);

삭제

DELETE FROM tableA as A WHERE ( 조건 )

 -> 조건에 맞는 row들 모두 삭제

갱신

UPDATE tablaA as A SET (ColumnName1 = val1) WHERE ( 조건 )

 -> 조건에 맞는 row들의 columnName1의 값을 val1로 갱신.

조회

SELECT * FROM tableA as A WHERE ( 조건 )

SELECT (columnName1, ColumnName2, ...) FROM tableA as A WHERE ( 조건 )

그 외에도 Procedure 혹은 Join등 여러가지 공부할것들이 존재한다.

우선 Thread에 대해서는 보통 잘 알것이다.

Process에 속하며 같은 Process에 속한 Thread 끼리는 data, code, heap 영역을 공유한다.

그렇다면 C#에서 async, await를 할 때 언급되는 Task와 Thread는 어떠한 차이가 있는것일까?

우선 MSDN 문서 기준으로  Task class는 비동기 작업을 나타낸다고 되어 있다.

즉 Thread의 경우 Process에서의 "실행 흐름"을 나타낸다면

Task는 "비동기적으로 실행되는 단일 작업" 을 의미한다.

Task는 C# .NET Framework4에서 처음 도입된 TAP패턴의 구성요소이다.

Task는 C#이 관리하는 Thread pool을 통해서 실행, 관리되며 Status 속성, IsCancled 등을 통해

외부에서 해당 Task의 작업 현황을 알 수 있다.

C#에서 Task를 생성 및 실행하는 방법은 여러가지가 존재하며 

개인적으로 자주 사용하는 방법은 Task.Factory.StartNew / Task.Run 이 두가지 방법이다.

Task를 생성, 실행한 후 해당 Task에 대해서 await를 앞에 적어주면 Task가 작업을 완료할 때까지 대기하게 된다.

이 때 내부적으로 일어나는 일은 More Effective C#에 자세히 나와있으니 참고할 것.

아 그리고 Task가 비동기적으로 실행되는 작업 단위라고 했지만 Task의 생성 및 실행과 동시에 작업이 완료될 수 있다.

개인적으론 Multi Tasking / MultiThreading 두가지 모두 Server에서 유효하지만

C#이 관리하는 Thread Pool 을 통한 Task단위로 작업을 실행하는 것이 개발자의 실수를 좀더 줄여주지 않을까 싶다.

 -> 단, Task는 현자의 돌이 아니니 사용할 때 개념을 확실히 잡고 사용해야 한다.

HTTP란?

. Hyper Text Transfer Protocol의 약자.

. Internet에서 Data를 주고 받을 때 사용하는 Protocol의 일종

. 비연결성이라는 특징이 있으며 Socket은 TCP socket을 사용한다.

 -> HTTP 통신은 요청 -> 응답 과정이 끝나면 연결이 끊기기 때문.

 -> HTTP 1.1부터 keep-alive header를 통해서 연결을 유지하는 것이 가능해졌다.

. Stateless이다.

 -> 연결을 유지하지 않기 때문에 Server는 Client를 식별하지 못한다.

 -> 이를 해결하는 방법으론 쿠키사용, 세션, OAuth, JWT등 여러 방법이 있다.

. Server와 Client의 통신이 평문(ASCII)으로 이루어 진다.

각 HTTP 요청에 대한 주요 응답 코드는 아래와 같다.

100 ~ 109 : 메세지 정보

200 ~ 206 : 요청 성공

300 ~ 305 : Redirection

400 ~ 415 : Client Erorr

500 ~ 505 : Server Error

HTTP Method의 종류

. POST

 - Server에 Data정보를 입력하는 요청인 경우 주로 사용

. GET

 - Server에 특정 Data에 대한 조회를 요청하는 경우 주로 사용

. PUT

 - Server가 요청을 통해 URI에 따른 Data 생성 혹은 갱신 시 주로 사용

. DELETE

 - Server에 특정 Data, Resource의 삭제를 요청할 때 주로 사용

. HEAD

 - Get과 유사하지만 Server는 응답 시 Header정보만 응답한다.

 - Client가 Header 정보만 필요로 하는 경우 사용