쿠키와 세션
쿠키와 세션은 둘 다 서버와의 통신에 필요한 데이터라는 점에서는 같지만, 쓰이는 맥락이 좀 다릅니다.
HTTP 서버는 Stateless와 Connectionless 한 성질을 가지고 있는데요, 이 때문에 서버에서 클라이언트를 기억하기 위한 데이터가 필요합니다. 쿠키와 세션은 이러한 HTTP의 한계를 보완하기 위한 데이터라고 할 수 있습니다.
먼저 쿠키는 클라이언트(브라우저)가 소지하고 있는 작은 양의 데이터로, 서버와 통신할 때 쓰입니다. 처음에 클라이언트가 접속할 때 서버는 쿠키에 데이터를 담아 보내고, 브라우저가 앞으로 해당 주소로 요청하게 될 때에는 자동적으로 쿠키를 같이 보내게 됩니다. Cookie, Set-Cookie 헤더에 실립니다.
또한 맥시멈 용량은 4KB 정도, 도메인 당 20개, 클라이언트 당 300개의 제한이 있습니다.
시간도 설정할 수 있는데, 시간이 설정되면 브라우저를 닫아도 남아있게 됩니다.
클라이언트에 저장되기 때문에, 민감한 정보는 보통 저장하지 않고 보통 쿠키는 팝업 체크나 장바구니 등에 많이 쓰입니다.
반면 세션은 일정 기간 동안 같은 클라이언트로부터 들어오는 요구클 유지시키도록 만든 것입니다.
한 클라이언트 당 한 세션 id를 부여해서 클라이언트가 일정 시간 이내에 요청이 들어오게 되면 해당 id로 조회한 정보를 사용하는 것입니다. 이때 쿠키가 쓰이는데, 쿠키에 클라이언트 id를 저장해서 보내게 됩니다.
클라이언트는 오직 Session id를 가지고 있고, 그 세션 아이디로 데이터 베이스에서 실제 데이터를 조회해서 정보를 처리합니다.
따라서 쿠키와 달리 용량의 제한에서 비교적 자유롭게 데이터 베이스의 용량에 따라 설정하면 됩니다.
또한 백엔드에서 정보를 가지고 있고 브라우저가 닫히면 사라지기 때문에, 쿠키보다 보안적 측면에서 더 낫다고 할 수 있습니다. 보통 로그인 혹은 민감한 정보를 처리할 때 쓰입니다.
JWT 토큰
JWT 토큰 Json Web Token의 약자로, 보통 사용자를 인증 할 때 사용합니다.
JWT 토큰은 헤더, 페이로드, 서명 부분으로 나눠집니다.
헤더에는 토큰의 유형, 알고리즘을 명시합니다. 페이로드는 사용자의 데이터가 담깁니다. 서명 부분은 헤더와 페이로드가 비밀키로 서명되어 저장됩니다.
JWT의 특징은, 세션 방식에 비해 비용이 적고 확장성이 높습니다. 서버에 별도 저장을 하지 않기 때문에, 서버가 늘어나도 세션 공유가 필요 없고 단순 검증만 하면 되기 때문에 쉽게 사용할 수 있습니다.
또한 서명이 되어 있는 JWT 토큰 서버에서만 유효성을 검증할 수 있지만, 페이로드에 담긴 사용자 데이터는 쉽게 디코딩될 수 있기 때문에, 민감한 정보를 넣어서는 안됩니다.
보안적으로는 JWT 토큰이 공격자에 의해 탈취되어도 서버는 알아채지 못합니다. 따라서 토큰의 유효기간을 짧게 설정하고, 토큰을 재발급받을 수 있는 별도의 refresh token을 두기도 합니다.
헤더 & 페이로드 : Base64URL로 encoding 한 UTF-8 스트링 (Base64(Url Safe))
서명 : secret key를 포함해 암호화 (RSA256 Base64url safe)
AccessToken - RefreshToken 보안
https://velog.io/@park2348190/JWT%EC%97%90%EC%84%9C-Refresh-Token%EC%9D%80-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%9C%EA%B0%80
SOP와 CORS
SOP는 Same Origin Policy의 약자로, Same origin 안에서만 문서나 스크립트를 불러올 수 있는 것입니다. 여기에서 Same Origin이라는 것은 프로토콜, 포트번호, 호스트가 같은 것을 의미합니다.
제 3자의 스크립트나 리소스와 상호작용할 수 있는 것을 방지하는 보안 정책입니다.
하지만 웹이 발전함에 따라 클라이언트와 서버를 분리하고, 외부 API도 사용해야 할 일이 많아졌습니다. 따라서 개발자들은 이러한 정책을 우회하는 부적절한 방식을 사용하게 되었고, 따라서 웹 표준인 CORS를 만들어 교차 출처 자원 교환 정책을 만들게 된 것입니다.
CORS는 Cross Origin Resource Sharing의 약자로, Access-Control-Allow-Origin 헤더에 접근할 수 있는 주소를 명시하면 해당 주소에서 요청하면 요청 출처가 다르더라도 리소스를 받을 수 있는 것입니다.
서버는 해당 헤더에 특정 출처를 입력해 해당 출처에서 자원을 요청할 경우 응답을 받을 수 있도록 합니다.
* 를 사용해 와일드 카드 형태로 모든 접근을 허용할 수는 있지만, 그렇게 되면 SOP를 사실상 무력화시키는 것이기 때문에 권장하지 않습니다.
CORS 요청에는 방법에는 일반 요청이 있고 preflight 요청, Credential 요청이 있는데, 일반 요청은 브라우저에서 해당 요청 후 서버의 응답이 들어오면 Access-Control-Allow-Origin 헤더를 확인해서 브라우저의 주소가 없으면 응답을 폐기해버리는 방법입니다.
그리고 preflight 요청이 있는데, 이 방법은 실제 원하는 요청 전에 OPTIONS 메서드를 사용해 요청을 보내는 것입니다. 이것은 CORS 확인이 브라우저에서 처리되기 때문인데, POST나 PUT 등의 메서드는 서버의 상태를 바꾸는 요청입니다.
해당 요청이 들어가고 서버의 응답을 받아서 브라우저에서 응답이 폐기된다고 해도 서버의 상태가 이미 바뀌어버리기 때문에 이런 안전성이 없는 메서드 앞에 OPTIONS 메서드를 보내서 CORS 정책을 위반하지 않는다면 그때 실제 요청을 하는 것입니다.
마지막으로 Credential 요청은 인증 정보와 함께 보내는 것을 말합니다.
클라이언트 개발자 입장에서 보통 개발을 하다 보면 CORS에러를 빈번하게 마주하는데, 해결 방법은 크게 2가지가 있습니다.
CORS는 서버 - 클라이언트에서 클라이언트 단에서 체크를 하기 때문에, 서버와 서버가 소통할 때에는 일어나지 않습니다. 따라서 프록시를 사용해 CORS에러를 해결할 수 있습니다.
또한 백엔드 개발자에게 Access-Control-Allow-Origin에 클라이언트 출처를 넣어달라고 요청할 수 있습니다.
SOP가 웹 보안의 기본적인 원칙으로서 중요한 역할을 수행하는 반면, CORS는 현대 웹 어플리케이션의 다양한 요구 사항을 충족시키기 위해 필수적인 메커니즘입니다. 서버와 클라이언트 간의 자원 공유를 가능하게 하는 CORS의 구현은 보안과 접근성의 균형을 맞추는 데 중요한 역할을 합니다.
REST란? Restful API란?
REST란 Representational State Transfer의 약자로, 자원을 이름으로 구분해 해당 자원의 상태를 주고 받는 형식을 의미합니다.
REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이라고 할 수 있습니다.
HTTP URI를 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD을 적용하는 것을 의미합니다.(자원, 행위, 표현)
Restful API는 이러한 REST의 형식을 가진 API라고 할 수 있습니다.
REST 제약 조건에 대해 설명해주세요.
- 균일한 인터페이스(Uniform Interface)
리소스에 균일하고 통일된 인터페이스를 제공해야 합니다. 이를 통해 파악하기 쉽고 균일한 아키텍처를 가질 수 있습니다. - 클라이언트-서버 분리(Client - Server Separation)
클라이언트와 서버가 분리되어야 합니다. 서버와 클라이언트는 서로 의존하지 않고 각자의 역할을 해야 합니다. - 무상태(Stateless)
서버에서 클라이언트의 상태를 기억하지 않고, 들어오는 요청에 대해서만 처리하는 것입니다.
이는 HTTP에서의 무상태성의 장점, 단점을 그대로 가집니다. - Cacheable(캐시 처리 가능)
HTTP에서 서버 부하를 낮추기 위한 기능으로 쓰이는 캐시를 사용할 수 있습니다. 헤더를 통해 구분합니다. - 계층형 구조(Layered System)
서버는 여러 계층으로 구현될 수 있으며, 각각의 계층은 독립적으로 분리되어 확장성과 모듈성을 가질 수 있습니다. - 온디맨드 코드(Code-on-demand)
클라이언트는 서버에서 자바스크립트 실행 코드를 전송받아 실행할 수 있습니다.
이 제약 조건은 선택 가능합니다.
URL, URI, URN 차이가 뭘까요?
URL는 Uniform Resource Locator의 약자로, 인터넷에서 웹 페이지, 이미지, 비디오 등의 리소스의 위치를 가리키는 문자열입니다. 웹 주소 또는 링크라고 흔히 부르는 것이 URL입니다.
URN Uniform Resource Name의 약자로 URI의 표준 포맷 중 하나로, 리소스를 유일하게 이름으로 식별하는 것이지만 인터넷 상의 위치는 알려주지 않습니다.
즉, URL이 어떻게 리소스를 얻을 것이고, 어디에서 가져와야하는지에 대해 명시하는 URI라면, URN은 리소스를 어떻게 접근할 것인지를 명시하지 않으며 경로와 리소스 자체를 특정하는 것을 목표로 하는 URI입니다.
URI는 Uniform Resource Identifier 의 약자로, 이러한 URL과 URN을 포함하는 넓은 개념으로, 인터넷 상의 리소스를 고유하게 식별하는 방식입니다.
URI는 리소스를 식별하는 광범위한 방식을 나타내며, URL은 그 리소스의 구체적인 위치를 가리키는 URI의 한 형태입니다. 모든 URL은 URI이지만, 모든 URI가 URL은 아닙니다. 예를 들어, urn:isbn:0451450523은 URN으로서, 특정한 책을 유일하게 식별하지만 위치를 제공하지는 않으므로 URL은 아니지만 URI에 해당합니다.
모든 URL과 URN은 URI이며, 모든 웹 주소(URL)는 URI(Uniform Resource Identifier)의 일종입니다. 이는 웹 주소가 리소스를 식별하기 위한 표준 방법을 따르며, 리소스의 위치를 명확하게 지정하기 때문입니다. 웹 개발에서는 이러한 원칙을 이해하고 활용함으로써, 리소스를 효과적으로 관리하고 참조할 수 있습니다. 예를 들어, 웹 페이지, 이미지 파일, 스타일시트 등의 위치를 지정하는 데 URL을 사용하며, 이는 모두 URI의 구체적인 예시가 됩니다. 따라서, 웹 개발을 할 때는 이러한 개념의 차이를 정확히 이해하고 있어야 효율적으로 리소스를 관리하고 사용할 수 있습니다.
XSS 공격과 방어하는 방법
XSS(크로스 사이트 스크립트)공격은 공격자가 외부 스크립트를 소스코드에 삽입해 공격하는 방식입니다.
form tag, innerHTML에 삽입하는 방식이 있을 수 있습니다.
쿠키는 웹 브라우저에서 접근이 가능하기 때문에 XSS공격에 취약한데요,이를 방지하기 위해 httpOnly 속성을 사용합니다.
httpOnly 속성은 웹브라우저에서 접근하지 못하고, 서버와 통신을 주고받는 HTTP 통신일 때에만 사용하도록 하는 속성입니다.
또한 secure속성은 네트워크를 직접 감청해서 쿠키를 가로챌 수도 있는데, 이를 막기 위해 암호화된 통신, 즉 HTTPS 프로토콜을 사용해야지만 쿠키를 전송할 수 있도록 하는 것입니다.
이런 식으로 쿠키의 보안 취약점을 보완해 세션 id나 쿠키 정보들을 지킬 수 있습니다.
CSRF 공격, 방어하는 방법을 설명해주세요.
CSRF 공격은 Cross-Site-Request-Forgery의 약자로, 사용자가 자신의 의지와 무관하게 공격자의 의도에 따라 요청을 하도록 하는 것입니다.
보통 사용자에게 악성 스크립트가 작성된 페이지를 링크 등을 통해 전파하며, 해당 페이지에 접속하면 서버에게 악의적인 요청을 보내도록 설계하는 것입니다.
해결 방법으로 GET, POST 방식을 구분해 POST방식으로만 데이터를 처리할 수 있도록 막을 수 있습니다. 또한 요청 헤더의 Referrer필드를 체크해 host와Refferer 헤더 값이 같은지 확인합니다. 또한 CAPTCHA와 같은 별도의 인증 방식도 사용할 수 있습니다.
또한 CSRF 토큰을 사용할 수 있습니다. CSRF 토큰은 사용자의 세션에 임의의 고유 값을 할당하고, 이 값을 폼 데이터 또는 요청 헤더에 포함시켜 서버로 전송하는 방식이다. 서버는 요청을 받을 때마다 이 토큰을 검증하여, 요청이 실제 사용자의 의도한 것인지 확인한다.
SQL Injection 공격, 방어하는 방법
SQL Injection은 SQL 구문을 서버에 보내서 서버가 해당 SQL 구문을 실행해서 데이터를 조작하는 행위입니다.
PreparedStatement를 쓰면 SQL Injection을 막을 수 있습니다.
PreparedStatement는 입력된 인자를 사용하기 전의 쿼리를 DBMS가 미리 컴파일하여 대기하므로, 이후 인자에 대해서는 쿼리가 아닌 단순 문자열로 인식하기 때문에 안전합니다. 또한 쿼리를 캐싱하기 때문에 같은 쿼리문을 재사용할 때 속도가 빨라집니다. 따라서 성능 측면에서도 이점이 있습니다.
또한 에러처리를 통해 테이블 정보를 사용자들에게 공개하지 않도록 해야 합니다. 테이블 정보 노출 및 컬럼 노출로 sql쿼리 작성이 가능하기 때문입니다.
Input Validation과 Input Sanitizing
https://bito.ai/resources/sanitize-input-javascript-javascript-explained/
웹 캐시
웹 캐시란, 웹에서 사용자가 리소스를 요청할 때, 리소스를 저장해놓고 중복 요청이 들어오면 실제 서버가 아닌 다른 저장소에서 리소스를 응답하는 것입니다.
캐시가 저장되는 장소는 다양한데, 브라우저 캐시, 포워드 프록시 캐시, 리버스 프록시 캐시 등이 있습니다. 이를 통해 서버 부하를 감소시키고, 응답 속도도 향상시킬 수 있습니다.
프록시 서버
클라이언트와 서버 간 통신에서 특정 처리를 대리로 수행해주는 것입니다. 보통 보안성, 성능, 안전성을 향상시키기 위해 사용합니다. 크게는 포워드 프록시, 리버스 프록시가 있으며, 캐싱, 로드벨런싱 등 다양한 작업을 수행할 수 있습니다.
포워드 프록시
클라이언트 - 서버 간에서 클라이언트 바로 뒤에 놓여있는 프록시 입니다. 같은 내부 망 에 존재하는 클라이언트의 요청을 받아, 인터넷을 통해 외부 서버에서 데이터를 가져와 클라이언트에게 응답해줍니다.
즉 클라이언트가 서버에 접근하고자 할 때, 클라이언트는 타겟 서버의 주소를 포워드 프록시에 전달해, 포워드 프록시가 인터넷으로 요청된 내용을 가져오는 방식입니다.
Next.js 프레임워크를 통해 개밸할 때 Next.js 서버를 포워드 프록시로 사용하기도 합니다.
다양한 기능을 수행할 수 있는데, 먼저 보안을 위해 사용할 수 있습니다.사용자들이 특정 사이트에 접속하는 것을 프록시를 통해 막을 수 있습니다.
또한 사용자들의 요청을 프록시 서버가 처리해서 백엔드 서버로 보내기 때문에 사용자들의 ip를 감춰주는 효과를 낼 수도 있습니다.
또한 프록시 서버에서는 서버의 응답을 캐싱할 수 있습니다. 클라이언트가 똑같이 해당 페이지에 접근하거나 똑같은 요청을 보낼 때, 캐시된 정보를 반환해 서버의 부하를 줄일 수 있고 응답도 빠르게 줄 수 있습니다.
리버스 프록시
리버스 프록시는 웹 서버 또는 WAS 앞에 놓여 있는 것입니다. 클라이언트가 웹 서비스에 접근할 때 웹 서버에 요청하는 것이 아닌 프록시 서버로 요청하게 되고, 프록시가 서버로부터 테이터를 가져오는 방식입니다.
보통 보안상으로 리버스 프록시 서버를 내부나 외부 서비스 모두 접근 가능한 곳에 배치해두고, 실제 서버는 내부망에 두는 것이 일반적입니다.
리버스 프록시를 사용하면 먼저, 로드밸런싱을 할 수 있습니다. 로드밸런싱은 서버의 부하가 일어나지 않도록 여러 대의 서버로 분산하는 것인데, 리버스 프록시를 여러 개의 서버 앞에 두면 요청을 분산시켜 트래픽이 급증하는 상황에서도 안정적으로 서비스를 제공할 수 있습니다.
또한 서버 측 보안을 위해 사용합니다. 리버스 프록시를 사용하면 본래의 서버 IP를 노출시키지 않습니다.
마지막으로 포워드 프록시의 캐싱과 같이 리버스 프록시를 사용해도 응답을 캐싱할 수 있습니다. 마지막으로 SSL 암호화 할 때에도 사용하는데, 본 서버에서 일일이 SSL 작업을 해주지 않아도 되므로 서버의 부하를 줄여줄 수 있습니다.
L7 로드 밸런서
L7 스위치라고도 하며, 서버의 부하를 분산하는 기기 입니다.
클라이언트로부터 오는 요청을 뒤쪽의 여러 서버로 나누는 역할을 하며, 시스템이 처리할 수 있는 역할을 하며 시스템이 처리할 수 있는 트래픽 증가를 목표로 합니다.
L7 로드밸런서는 URL, HTTP 헤더, 캐시, 쿠키들을 기반으로 트래픽을 분산합니다. 또한 바이러스, 불필요한 외부 데이터 등을 걸러내는 필터링 기능 또한 가지고 있으며, 응용 프로그램 수준의 트래픽 모니터링도 가능합니다.
만약 장애가 발생한 서버가 있다면 이를 트래픽 분산 대상에서 제외해야 하는데, 이는 정기적으로 헬스 체크를 이용하여 감시하면서 이루어집니다.
로드밸런서로는 L7 스위치 뿐 아니라 L4 스위치도 있습니다.
L4 스위치는 메시지를 기반으로 인식하지 못하고 IP와 포트를 기반으로 트래픽을 분산합니다.반면 L7 로드벨런서는 IP 포트 이외에도 URL, HTTP 헤더, 쿠키 등을 기반으로 트래픽을 분산합니다.
클라우드 서비스에서 L7 스위치를 이용한 로드밸런싱은 ALB 컴포넌트로, L4 스위치를 이용한 로드밸런싱은 NLB 컴포넌트로 합니다.
커넥션 타임아웃과 리드 타임아웃
connection Timeout은 종단 간 TCP 연결을 하는데 소요되는 최대 시간입니다.간단히 말하면, Three Way handShake가 일어나는데 걸리는 최대 시간입니다.
Read Timeout은 종단 간 데이터를 주고 받을 때 소요되는 최대 시간입니다. 주로 클라이언트가 서버에게 자원을 요청하고 응답받는 최대 시간입니다. 이 시간을 넘기게 되면 데이터를 받을 수 없는 것으로 판단하고, 에러가 발생합니다.
두 타임아웃 모두 네트워크 연결과 데이터 전송 과정에서 중요한 역할을 하며, 네트워크 지연이나 서버 과부하 등의 상황에서 클라이언트가 무한정 대기하지 않도록 합니다. 적절한 타임아웃 값을 설정함으로써 사용자 경험을 개선하고, 서버 자원의 효율적인 관리가 가능해집니다
적절한 타임아웃 값 설정하기.
https://alden-kang.tistory.com/20
