혼코딩

개발하면서 필수 지식인 REST API에 대해서 정리해보겠습니다.

우선 REST API를 제공하는 웹 서비스를 RESTful 하다고 말할 수 있습니다.

REST란 무엇인가?

REST란 Representational State Transfer의 약자로 웹의 장점을 최대한 활용할 수 있는 아키텍처입니다.

REST는 로이 필딩이라는 컴퓨터 과학자가 2000년도에 박사학위 논문에서 정의하였습니다.

HTTP URL(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE 등)을 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미합니다.

REST 아키텍처의 특징

1. 인터페이스 일관성 : 일관적인 인터페이스로 분리되어야 한다.
2. 무상태(Stateless) : 각 요청 간 클라이언트의 콘텍스트가 서버에 저장되어서는 안 된다.
3. 캐시 처리 가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 캐싱할 수 있어야 한다.
잘 관리되는 캐싱은 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability와 성능을 향상한다.
4. 계층화(Layered System) : 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.
중간 서버는 로드 밸런싱 기능이나 공유 캐시 기능을 제공함으로써 시스템 규모 확장성을 향상하는 데 유용하다.
5. Code on demand (optional) : 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.
6. 클라이언트/서버 구조 : 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.

URI 설계 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
2. 마지막 문자로 /를 포함하지 않는다.
3. CRUD 기능을 나타내는 동사를 사용하지 않는다.
4. 적절한 HTTP Method를 사용한다.
5. 언더바(_) 대신 하이픈(-)을 사용한다.
6. 소문자를 사용한다. (대소문자 구분 못함)
7. URI에 파일 확장자를 포함시키지 않는다.
8. 세션 id, 메소드 명을 쓰지 않는다.
9. 명사에 단수보다는 복수형을 사용한다.

HTTP Method 종류

우리가 잘 아는 GET, POST, PUT, DELETE 외에도 여러 가지 메소드가 존재합니다.

쉽게 비교하기 위해 표로 정리해보았습니다.

• PUT, PATCH 인 경우 동일한 데이터에 대한 업데이트 시도 시 업데이트되지 않습니다. (update_at이 갱신되지 않음)
• GET, HEAD, OPTIONS 메소드는 안전한 메소드로 간주합니다. (읽기 전용인 경우)
• 특정 메소드의 request를 여러 번 하더라도 한번 request 했을 때와 결과가 같다면 멱등하다하고 합니다.
• PUT과 POST는 멱등성의 차이가 있습니다. (PUT은 멱등성을 가지고 POST는 가지지 않음)

참고 문서

https://developer.mozilla.org/ko/docs/Web/HTTP/Methods/POST

https://ko.wikipedia.org/wiki/REST

CSRF(사이트 간 요청 위조)란?

• 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(CRUD)를 특정 웹사이트에 요청하게 하는 공격
• 공격자가 사용자가 의도하지 않은 작업을 수행하도록 유도할 수 있는 웹 보안 취약점이다.
  → 이를 통해서 공격자는 서로 다른 웹 사이트가 서로 간섭하지 못하도록 설계된 SOP을 부분적으로 우회할 수 있다.

💡 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

공격 과정

1. 이용자가 웹사이트에 로그인하여 정상적인 쿠키를 발급받는다.
2. 공격자는 링크를 이메일이나 게시판 등의 경로를 통해 이용자에게 전달한다.
3. 공격용 HTML 페이지는 다음과 같은 이미지 태그를 가진다.
   

   <img src= "https://travel.service.com/travel_update?.src=Korea&.dst=Hell">
   // 이 링크는 클릭시 정상적인 경우 출발지와 도착지를 등록하기위한 링크이다. 위의 경우 도착지를 변조하였다.​

4. 이용자가 공격용 페이지를 열면, 브라우저는 이미지 파일을 받아오기 위해 공격용 URL을 연다.
5. 이용자의 승인이나 인지 없이 출발지, 도착지가 등록됨으로써 공격이 완료됨.