29Jan2020 TIL

TIL

Client and Server + HTTP
API
Browser Security (CORS / XSS / CSRF)

Client and Server

client : web browser 를 사용 사용자 / 이용하는 단말기. 자료 요청을 보내는 편

-> http : client-server 가 통신할 수 있게 하는 통신 규약(protocol)

server : web의 데이터를 저장하는 공간. 요청받은 자료를 넘기는 편

request 와 response 모두 Header 와 Body 로 구성되어 있다. Header는 표제와 같이, http메세지 시작 줄을 포함하여 이런이런 메세지를 보내는 것이라고 알리는 기능을 한다. Body는 전달하고자 하는 본문이다.

HTTP Method

(참고 자료)

Get : Read, 서버에게 자료를 요청
Put : Creat, 서버에 문서를 작성 할 때 (<-> Get)
Post : Update, 서버에 새로운 내용을 input 할 때(HTML form 에서 사용)
Delete : Delete, 해당 자료를 삭제하도록 서버에 요청

API (Application Programming Interface)

Restful API : HTTP의 Method를 활용하여 CRUD 수행.

when a RESTful API is called, the server will transfer to the client a representation of the state of the requested resource.(출처)

Uniform interface :
Client — server separation :
Stateless : 맥락이 없음. 지난 요청과 독립적임.
Layered system : 서버 - 클라이언트 사이에 프록시 서버, 암호 레이어 삽입이 가능
Cacheable
Code-on-demand (optional)

구성 : resource(URL) / verb(HTTP method) / representations (출처)

장점

easy to use as long as following standard HTTP protocol.
Totally seperate between server and client
no need infrastructure

단점

method 가 제한적
명확한 표준이 없다.

CORS(Cross-origin resource sharing)

하나의 웹에서 다양한 서버로 부터 데이터를 받아들일 수 있어야 하는 웹의 복잡성에서 필요성이 나왔다. 웹 브라우저가 항상 호스트 / 포트 / 프로토콜 3박자가 일치할 수 없기 때문이다. CORS standard는 서버의 리소스에 접근하는 대상 Who 뿐만 아니라 접근하는 방법 How를 통제 할 수 있어서 필요하다.

Access-Control-Allow-Origin 이 *일 경우, 이 서버의 리소스에는 모든 도메인이 접근 가능하다. 서버의 리소스에 악영향을 미칠 수 있는 PUT, DELETE,PATCH,OPTION와 같은 HTTP methods는 서버로 부터 사전에 OPTIONs header를 사용하여 접근승인을 받아야 한다. 이는 preflight 요청이며, 실제 이루어지는 요청이 안전한지를 사전에 파악할 수 있다. (참고자료)

XSS (Cross-Site Scripting)

클라이언트가 웹브라우저를 사용할 때, 개발자가 의도하지 않은 악성 코드 및 스크립트를 사용하여 클라이언트에 해를 입히는 공격이다. 브라우저가 업데이트되면서 기본적으로 XSS 공격에 대한 방어기제를 탑재했다. 그러나 개발자는 입력/출력할 때 데이터에 대한 필터를 설치하여 클라이언트를 보호하여야 한다.

일반적으로 .innerHTML()은 해당 공격에 취약하다고 알려져 있다. HTML markup (i.e. <div>, <span>, etc) 가 아닌 text만 가질 수 있는 .textContent()를 사용하면 외부의 script 나 기타 의도하지 않은 엘리먼트 주입 공격으로부터 안전할 수 있다. 때로는 text가 아닌, HTML markup을 포함시켜야 할 때도 있다. 이 블로그에서는 다음과 같은 함수를 사용하여, 코드를 한번 더 인코딩하고, 보완을 유지할 내용을 보이지 않게 하는 방법을 사용한다.

/*!
 * Sanitize and encode all HTML in a user-submitted string
 * (c) 2018 Chris Ferdinandi, MIT License, https://gomakethings.com
 * @param  {String} str  The user-submitted string
 * @return {String} str  The sanitized string
 */
var sanitizeHTML = function (str) {
	var temp = document.createElement('div');
	temp.textContent = str;
	return temp.innerHTML;
};

This works by creating a temporary div and adding the content with textContent to escape any characters. It then returns them using innerHTML to prevent those escaped characters from transforming back into unescaped markup.

CSRF(Cross-site request forgery)

제 3자가 사용자가 의도하지 행동을 하게 하여, 사용자에게 피해를 입히는 공격이다. 해커가 다양한 수단을 통해 사용자를 피싱 사이트로 접근하게 한 후, 사용자의 각종 권한을 빼앗아 도용한 후, 불법적인 행동으로 이득을 취하는 공격을 의미한다. 사용자의 요청을 보낸 페이지의 정보가 담긴 HTTP Referrer header를 확인하여 CSRF 공격을 방지하는 방법이 대표적이다. 그러나 해당 웹페이지가 같은 도메인 페이지 내에서 XSS공격에 취약할 경우, CSRF 공격도 방어하긴 어렵다. 다른 방법으로는 Security Token 의 방법이 있다. 매번 사용자의 요청하면, 비교를 통해 실 사용자가 보낸 요청인지 제 3자가 보낸 요청인지 일일이 비교하는 방법이나 이 역시 XSS에 취약하다면 같은 문제가 발생한다.

일반적으로 CSRF 공격 방어는 조회성(HTTP GET Method) 데이터에는 방어 대상에 두지 않고, 쓰기/변경이 가능한 POST, PATCH, DELETE Method에만 적용하면 됩니다. 물론 정말 중요한 데이터를 조회하거나 GET을 통해 쓰기/변경 등의 동작을 한다면 GET Method에도 방어를 해야할 수 도 있습니다.

서버단에서는 쿠키의 토큰 값와 파라미터의 토큰 값이 일치하는 지만 검사하면 됩니다. 서버에 따로 토큰 값을 저장할 필요가 없어 위에서 살펴본 세션을 이용한 검증보다 개발 공수가 적은 편입니다. 피싱 사이트에서는 도메인이 달라 facebook.com 쿠키에 값을 저장하지 못하므로 (조금 전에 언급한 Same Origin 정책) 가능한 방어 기법입니다. (출처: 덕's IT Story)