1. 쿠키와 세션에 대해서 설명해주세요.
쿠키는 HTTP 서버가 클라이언트를 식별할 수 있도록 하기 위해서 사용되는 것 입니다.
클라이언트가 웹 서버에 처음 접속하면, 서버는 쿠키를 생성에서 클라이언트에게 줍니다.
이후 클라이언트는 서버에 요청을 보낼때 자신의 정보가 들어있는 쿠키를 같이 보냅니다.
그러면 서버는 쿠키를 통해 클라이언트를 식별할 수 있습니다.
쿠키는 클라이언트 단에 저장되기 때문에 쿠키에 들어있는 사용자 정보가 유출될 수 있는 단점이 있습니다.
"쿠키는 클라이언트에 저장되는 작은 데이터로, 서버와 클라이언트 간의 상태를 유지하는 데 사용됩니다.
서버가 클라이언트에게 응답할 때, Set-Cookie 헤더를 사용하여 쿠키를 생성하고 클라이언트에게 전송합니다.
이후 클라이언트가 서버에 요청을 보낼 때마다, 해당 쿠키는 자동으로 요청과 함께 전송됩니다.
반면, 세션은 서버 측에 사용자 정보를 저장하고 클라이언트에는 고유한 세션 식별자를 전달합니다.
이러한 식별자를 쿠키 등을 통해 클라이언트에 저장하고, 이를 통해 클라이언트가 서버에 요청을 보낼 때마다 서버는 세션 식별자를 확인하여 해당 사용자의 상태를 유지합니다.
주로 로그인 정보, 장바구니 등과 같은 데이터를 저장하여 사용자의 상태를 관리할 수 있습니다."
2. JWT 토큰에 대해서 설명해주세요.
토큰은 클라이언트 인가하는 방법 입니다.
토큰에는 서버가 비밀키로 만들어둔 서명이 있는데,
서버는 공개키로 서명을 검증해서 클라이언트를 인가할 수 있습니다.
세션과 달리 토큰은 그 자체를 공개키로 검증만 하면 되기 때문에
서버에 부하를 주지 않고, 여러 서버에 사용할 수 있는 확장성이 있습니다.
"JWT(Json Web Token)는 정보를 안전하게 전달하기 위한 Json 객체에 정보를 담은 후 비밀키로 서명한 토큰입니다.
헤더, 페이로드, 서명으로 이루어져 있으며, 사용자 인증, 정보 교환, 세션 관리 등 다양한 용도로 활용됩니다. 로그인 후 발급되어 클라이언트에게 전달되며, 서버와 클라이언트 간의 안전한 통신에 기여합니다."
[구조]
1) Header
: 토큰의 타입(typ)과 해싱 알고리즘 정보(alg)를 포함합니다.
2) Payload
: 토큰에 포함되는 클레임(claim) 정보, 즉 사용자에 대한 정보를 담고 있습니다.
3) Signature
: Header, Payload를 더한 뒤, 비밀키로 해싱하여 생성한다.
Header, Payload는 해커가 복호화하고 조작할 수 있지만,
Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없어, 토큰의 위변조 여부를 검증합니다.
[용도]
1) 사용자 인증
: JWT는 사용자가 로그인한 후에 서버에서 발급되어 클라이언트에게 전달되며, 이를 통해 사용자를 식별합니다.
2) 정보 교환
: 클라이언트가 서버에게 특정 권한을 요청하거나 데이터를 전달할 때 사용됩니다.
3) 세션 관리
: 세션을 서버에 저장하지 않고도 상태를 유지할 수 있습니다.
출처
3. SOP와 CORS에 대해서 설명해주세요.
CORS는 클라이언트 브라우저에서 현재 접속한 사이트 외에 다른 도메인에 접근할 수 있도록 처리 해주는 웹 브라우저 표준 기술 입니다.
브라우저에는 크로스 사이트 스크립트 등의 이유로 보안상 스크립트를 사용해서 다른 도메인으로 접근하는 것을 제한 합니다.
이를 Same Origin Plicy라고 하는데, 이러한 정책 제한을 넘어서기 위해 CORS가 필요합니다.
예를 웹 서비스를 프론트와 백으로 완전히 나누고 API로 묶는 방식으로 구현한 경우
백엔드 서버에 프론트엔드에 대한 CORS 설정을 허용해줘서 프론트엔드가 백엔드 API를 사용할 수 있게 해줘야 합니다.
"SOP는 브라우저에서 실행되는 웹 페이지의 보안 정책으로, 동일한 출처 사이에서만 리소스를 공유할 수 있다는 규칙입니다.
하지만 클라이언트에서 제 3자가 제공하는 API를 직접 호출해야 하는 기능들이 늘어났고,
SOP 브라우저 정책에서의 일반적인 방법으로는 불가능했습니다.
이러한 배경으로 CORS가 등장하게 되었습니다.
CORS는 리소스 호출이 허용된 출처를 서버가 명시해놓으면, 출처가 다르더라도 요청과 응답을 주고 받을 수 있도록 합니다.
1) SOP(Same-Origin Policy)
웹 보안을 강화하기 위한 웹 브라우저의 핵심 보안 정책 중 하나입니다.
(스크립트 언어를 사용하는) 웹 페이지를 다른 출처(Origin)로부터의 리소스에 접근할 수 있는 권한이 제한함으로써, 공격을 방지하고 정보 유출을 방어할 수 있습니다.
*Origin : 프로토콜, 도메인, 포트가 동일한 기기
2) CORS(Cross-Origin Resource Sharing)
SOP의 제약을 완화하기 위한 메커니즘으로, 클라이언트 사이드 코드에서 다른 출처로의 HTTP 요청을 보낼 때 발생하는 제약을 해제하기 위한 표준입니다. 서버는 응답 헤더에 허용되는 출처, 메서드, 헤더 등을 명시하여 브라우저에게 허용할 조건을 알려줍니다.
(1) 브라우저는 다른 출처로의 request을 보낼 때 자동으로 HTTP 헤더에 Origin을 추가하여 보낸다.
Origin: https://foo.example
(2) 서버는 response 헤더에 Access-Control-Allow-Origin을 보낸다.
이 헤더에는 허가된 출처 정보가 담겨있다.
Access-Control-Allow-Origin: *
브라우저는 Origin 정보가 Access-Control-Allow-Origin 헤더에 담겨 있으면 해당 요청을 안전하다고 간주하고 응답을 가져온다.
그렇지 않다면, 해당 응답을 파기한다.
+. Preflight 요청
출처
- https://hudi.blog/sop-and-cors/
- https://velog.io/@jesop/SOP%EC%99%80-CORS
- https://jaehyeon48.github.io/web/sop-and-cors/
4. REST에 대해서 설명해주세요. Restful API는 뭘까요?
REST는 자원을 이름으로 구분하고, 해당 자원의 상태를 주고 받는 방법을 의미합니다.
구체적으로는 HTTP URL을 통해 자원을 명시하고, HTTP Method를 통해 해당 자원에 대해 CRUD 연산을 적용하는 것 입니다.
REST의 원리를 따르는 시스템을 RESTful이라고 부르고, REST 형식의 API를 REST API라고 부릅니다.
"REST는 리소스를 표현하고 상태를 전송하는 소프트웨어 아키텍처로,
각 리소스는 고유한 URI를 가지며 HTTP 메서드를 통해 리소스에 수행해야 하는 작업을 서버에 알려줍니다.
주로 JSON이나 XML 형식을 사용하며, Restful API는 이 아키텍처 스타일을 따르는 API를 말합니다."
1) 자원(Resource) : 모든 것을 자원으로 표현하며, 각 자원은 고유한 식별자(URI)를 갖습니다.
2) 행위(Verb) : 자원에 대한 행위는 HTTP 메소드로 표현됩니다.
3) 표현(Representation) : 자원의 상태를 표현하는 형식은 다양할 수 있으나, 주로 JSON / XML 형식을 사용합니다.
출처
- https://aws.amazon.com/ko/what-is/restful-api/
5. REST 제약 조건에 대해 설명해주세요.
REST는 여섯 가지 기본적인 제약 조건이 있습니다.
"REST 아키텍처의 제약 조건에는 고유 식별, 표현과 상태의 분리, 자기 서술적 메시지, HATEOAS, 무상태성, 계층화 등이 포함됩니다.
이러한 제약 조건을 통해 시스템의 단순성, 성능을 향상시키고 상호 운영성을 제공합니다."
1) 자원의 식별
: 각 자원은 고유한 식별자(URI)를 갖고 있어야 합니다.
2) 클라이언트-서버 분리
: 클라이언트와 서버는 서로 독립적이어야 합니다.
클라이언트가 알아야 하는 유일한 정보는 요청하는 리소스의 URI이며,
서버는 응답을 전달하는 것 말고는 클라이언트를 수정하지 않아야 합니다.
3) 무상태성
: 서버는 이전의 모든 요청과 독립적으로 요청을 수행합니다.
클라이언트는 각 요청에서 이에 필요한 정보와 어떻게 처리해야 하는지에 대한 정보를 모두 포함되어야 합니다.
4) 캐시 가능성
: 서버 응답 시간을 개선하기 위해 캐싱을 지원합니다.
6. URL, URI, URN 차이가 뭘까요?
URI는 인터넷 상에서 특정 자원을 가리키는 식별자 입니다.
URI의 두 가지 형태로 URL과 URN이 있습니다.
URL은 특정 시점에서 자원의 구체적인 위치를 나타내는데, 만약 자원의 위치가 변경되면 기존 URL은 더 이상 사용 불가능하다는 단점이 있습니다.
URN은 이러한 URL의 단점을 보완하기 위해 새롭게 정의된 표준인데, URN은 자원에 대해 영속적이고 고유한 식별자를 뜻합니다.
"URL은 리소스의 위치를 가리키는 주소로, 웹 브라우저에서 사용되는 일반적인 형태입니다. URI는 리소스를 식별하는 개념으로, URL과 URN을 포함하며, URN은 리소스의 고유한 이름을 나타냅니다. URN은 주로 리소스의 위치가 변하지 않는 경우에 사용됩니다."
1) URL(Uniform Resource Locator)
웹 주소로, 리소스의 위치를 지정하는 문자열입니다.
프로토콜(ex. http, https), 호스트(도메인), 포트, 경로 등을 포함합니다.
2) URI(Uniform Resource Identifier)
리소스를 식별하고 위치를 지정하는 일반적인 개념입니다.
URI는 URL과 URN을 포함하는데, URL은 리소스의 위치를 지정하고 URN은 리소스의 이름을 지정합니다.
3) URN(Uniform Resource Name)
리소스의 고유한 이름을 나타냅니다.
위치에 독립적이므로 리소스의 위치가 바뀌더라도 여전히 식별할 수 있습니다.
7. XSS 공격이 무엇이고, 방어하는 방법을 설명해주세요.
XSS는 웹 브라우저에 악성 스크립트를 삽입하여 사용자 정보를 탈취하는 공격방식입니다.
웹 브라우저에서 사용자 입력값과 출력값을 철저히 검증해서 XSS를 예방할 수 있습니다.
모든 입력값에 대해 악의적인 스크립트가 있는지 체크하는 validation을 추가하고,
입력값을 출력할때는 특수문자를 이스케이스 하는 처리를 추가해서 예방하는 방법이 있습니다.
"XSS는 악의적인 스크립트를 삽입하여 사용자의 브라우저에서 실행시키는 공격입니다. 방어하기 위해 입력 유효성 검사, 출력 이스케이프 처리, HTTP Only 쿠키, CSP, 보안 헤더 설정 등 다양한 방법을 사용합니다. 이를 통해 사용자의 브라우저를 통한 공격을 어렵게 만들 수 있습니다."
[방어 방법]
1) 입력 유효성 검사
: 모든 사용자 입력 데이터에 대한 적절한 입력 유효성 검사를 수행합니다.
2) 출력 이스케이프 처리
: 사용자 입력이 아닌 모든 데이터를 출력할 때 이스케이프 처리를 해야 합니다.
(HTML 이스케이프를 사용하면 특수 문자가 그대로 텍스트로 출력되므로, 해당 부분에 포함된 스크립트가 브라우저에서 실행되지 않음.)
3) HTTP Only 쿠키 사용
: 민감한 정보를 저장하는 쿠키에 HTTP Only 속성을 부여하여 JavaScript에서의 접근을 제한합니다.
4) 콘텐츠 보안 정책(CSP)
: 웹페이지에서 로드되는 리소스의 출처와 유형을 명시적으로 제어하는 CSP를 사용합니다.
5) 보안 헤더 사용
: 보안 헤더를 사용하여 브라우저에 특정 동작을 제한하도록 지시합니다.
ex. X-Content-Type-Options, X-Frame-Options, X-XSS-Protection 등
8. CSRF 공격이 무엇이고, 방어하는 방법을 설명해주세요.
CSRF 공격은 사용자가 의도하지 않는 악의적인 요청을 보내도록 하는 공격입니다.
이를 방지하기 위해 서버는 CSRF 토큰을 클라이언트에 전달하는 방법으로 해결할 수 있습니다.
"CSRF는 사용자가 의도하지 않은 요청을 공격자가 원격에서 실행하게 하는 공격입니다.
공격 방법은 해커가 먼저 악성 스크립트를 유포하고, 인증된 사용자가 스크립트 파일을 받아오게 되면
사용자 브라우저 쿠키를 기반으로 서버 세션 정보를 획득하여 정보를 탈취합니다.
방어하기 위해 CSRF 토큰 사용, SameSite 쿠키 속성 설정, Referer 검증, Custom 헤더 사용, Anti-CSRF 라이브러리 등의 방법을 사용할 수 있습니다."
[방어 방법]
1) CSRF 토큰 사용
: 서버는 CSRF 토큰을 생성하고 HTTP 세션에 저장합니다.
CSRF 토큰을 이용해서 정상적인 요청 여부를 검증합니다.
일치 여부를 확인한 토큰은 폐기하고, 새로운 뷰 페이지를 발행할 때마다 새로 생성합니다.
2) Referer 검증
: 서버는 요청의 Referer 헤더를 검증하여 요청이 허용된 도메인에서 온 것인지 확인할 수 있습니다.
cf. 기본적으로 요청의 출처를 확인하는 매커니즘으로
일부 브라우저에서는 사용자 개인 정보 보호를 위해 Referer 헤더를 보내지 않거나, 빈 문자열로 설정하는 경우가 있습니다.
3) SameSite 쿠키 속성 설정
: SameSite 쿠키 속성으로 쿠키가 어떤 상황에서 전송될 수 있는지를 제어합니다.
Strict 또는 Lax 설정을 통해 CSRF 공격을 방지할 수 있습니다.
- Strict : 동일한 사이트 내의 요청에서만 쿠키를 전송한다.
- Lax : 동일한 사이트 내의 요청 및 다른 사이트의 GET 요청일 때 쿠키를 전송한다.
- None : 모든 상황에서 전송된다.
4) Custom 헤더 사용
: 사용자 지정 헤더를 요청에 추가하고, 서버에서는 이 헤더의 존재 여부를 확인하여 유효성을 검증하는 방법입니다.
9. SQL Injection 공격이 무엇이고, 방어하는 방법을 설명해주세요.
악의적인 SQL 쿼리문을 삽입하여 데이터베이스를 비정상적으로 조작하는 공격 기법입니다.
웹 브라우저에서 들어오는 입력값에 대해 악성 SQL 패턴에 대한 validation을 추가하고,
데이터베이스에 평소 사용자에 의해 발생하는 SQL 패턴이 아닌 비정상적인 SQL이 발생하는지
주기적으로 모니터링하고 비상 알람을 걸어 두는 방식을 선택할 수 있습니다.
"SQL Injection은 임의의 SQL 문을 주입하고 실행하여, DB가 비정상적인 동작을 하도록 하는 행위입니다. 이를 방어하기 위해 매개변수화된 쿼리 사용, ORM 사용, 입력 유효성 검사, 최소 권한 원칙, 에러 메시지 관리 등의 방법을 사용합니다. 이를 통해 데이터베이스에 대한 무단 접근이나 조작을 방지합니다."
1) 매개변수화된 쿼리 사용
: SQL 쿼리를 동적으로 생성할 때는 매개변수화된 쿼리를 사용합니다.
2) ORM 사용
: ORM을 사용하면 개발자가 직접 SQL 쿼리를 작성하지 않아도 됩니다.
3) 입력 유효성 검사
: 모든 사용자 입력에 대해 적절한 입력 유효성 검사를 수행합니다.
4) 최소 권한 원칙
: 데이터베이스 계정에는 최소한의 권한만 부여하여 필요한 동작만을 수행하도록 합니다.
5) 에러 메시지 관리
: 사용자에게는 일반적인 에러 메시지만을 표시하고, 개발자에게는 자세한 디버그 정보를 기록합니다.
출처
- https://noirstar.tistory.com/264
10. 웹 캐시에 대해 설명해주세요.
웹 캐시는 자주 사용되는 자원의 사본을 자동으로 보관하는 장치입니다.
만약에 어떤 HTTP 요청에 대한 사본이 캐싱되어 있으면, 서버까지 요청이 가지 않고 바로 캐시에서 바로 자원을 제공 받게 됩니다.
캐시를 사용하면
반복되는 요청을 줄여줘서 서버의 부하를 줄여주고
갑작스러운 트래픽을 대처하게 해주고,
네트워크 병목을 줄여주고,
먼 거리로 인한 전송 지연을 줄여줍니다
"웹 캐시는 웹 페이지의 리소스를 임시로 저장하여 사용자의 브라우저에 빠르게 페이지를 제공하는 메커니즘입니다. 브라우저는 서버에서 받은 자원을 캐시에 저장하고, 동일한 페이지를 방문할 때 서버에 재요청하지 않고 캐시된 자원을 사용하여 성능을 향상시킵니다. 이를 통해 서버 부하를 줄이고 대역폭을 절약할 수 있습니다."
동작 원리
1) 서버가 요청에 대한 응답으로 리소스를 제공할 때, 응답 헤더에 캐시 지시자를 포함할 수 있다.
2) 브라우저는 캐시 지시자에 따라 일정 기간 웹 캐시에 저장한다.
3) 동일한 페이지를 방문할 때, 이전에 저장된 웹 캐시를 확인하고 유효기간이 만료되지 않았다면 캐싱된 자원을 사용합니다.
11. 프록시 서버에 대해서 설명해주세요.
프록시 서버는 클라이언트와 서버 사이에 존재하는 중개자 입니다.
그렇기 때문에 프록시는 클라이언트로 동작하기도하고 서버로 동작하기도 합니다.
프록시는
데이터를 필터링 또는 변환 하거나
방화벽을 세우거나
또는 캐시 서버로 동작할 수 있습니다.
"프록시 서버는 클라이언트와 서버 간의 중계자 역할을 하는 서버로, 주로 캐싱과 필터링이나 익명성 제공 같은 보안 기능을 수행합니다. 클라이언트는 직접 서버에 접근하는 대신 프록시를 통해 간접적으로 통신하며, 이를 통해 네트워크의 성능 향상과 보안 강화 등 다양한 이점을 얻을 수 있습니다."
로드 밸런싱 : 여러 서버에 대한 요청을 분산하여 로드 밸런싱을 수행
12. 포워드 프록시에 대해서 설명해주세요.
포워드 프록시는 클라이언트 앞에 위치하는 프록시입니다.
포워드 프록시를 사용해서 익명으로 서버에 접근할 수 있습니다.
"클라이언트는 직접 서버에 요청하는 대신 포워드 프록시를 경유하여 요청하고, 프록시 서버는 클라이언트 대신 실제 서버에 요청을 전달합니다. 이를 통해 클라이언트의 익명성, 캐싱, 보안 등의 이점을 얻을 수 있습니다."
1) 클라이언트의 익명성 제공
: 클라이언트의 실제 IP 주소를 감출 수 있습니다.
2) 접근 제어 및 필터링
: 특정 웹사이트나 콘텐츠에 대한 접근을 제어하거나 필터링할 수 있습니다.
13. 리버스 프록시에 대해서 설명해주세요.
리버스 프록시는 서버 앞에 위치하는 프록시입니다.
실제 서버 앞에 리버스 프록시를 둠으로써 보안을 강화할 수 있습니다.
그리고 리버스 프록시 뒤에 여러대의 서버를 둬서 부하를 분산시킬 수 있습니다.
"클라이언트는 리버스 프록시를 통해 서버에 접근합니다. 서버는 리버스 프록시를 경유하여 클라이언트의 요청을 받고 응답을 클라이언트에게 전달합니다. 이는 서버의 보안, 부하 분산, SSL 암호화 등의 이점을 제공합니다."
1) 보안 강화
: 서버의 실제 IP 주소를 감출 수 있습니다.
웹 애플리케이션 방화벽, 보안 정책 적용 등을 통해 보안을 강화할 수 있습니다.
2) 부하 분산
: 다수의 서버로 요청을 분산하여 부하를 고르게 분배할 수 있습니다.
서버의 성능 향상과 가용성 향상에 기여합니다.
3) SSL 암호화
: SSL 암호화를 담당할 수 있습니다.
14. L7 로드 밸런서에 대해서 설명해주세요.
"L7 로드 밸런서는 OSI 모델의 7계층(Application Layer)에서 동작하는 로드 밸런싱 장치로, 애플리케이션 레이어의 정보를 기반으로 트래픽을 분산합니다. 이는 HTTP 헤더, 쿠키, URL 등의 정보를 활용하여 요청을 적절한 서버로 라우팅하며, 세션 유지, SSL 오프로딩 등의 기능을 제공합니다."
1) HTTP 헤더, 쿠키 기반의 라우팅
: HTTP 헤더, 쿠키 등의 애플리케이션 레이어 정보를 기반으로 트래픽을 분산할 수 있습니다.
ex. 특정 쿠키 값을 확인하여 특정 서버로 라우팅
2) 세션 유지
: 동일한 클라이언트의 요청이 항상 동일한 서버로 전송되도록 할 수 있습니다.
3) SSL 오프로딩
: SSL 암호화를 해제하고 일반 HTTP 트래픽으로 변환하여 서버로 전달할 수 있습니다.
15. 커넥션 타임아웃과 리드 타임아웃에 대해 설명해주세요.
커넥션 타임아웃은 TCP 연결 확립이 수행되는데 걸리는 최대 시간입니다.
리드 타임아웃은 요청과 응답이 수행되는데 걸리는 최대 시간입니다.
"커넥션 타임아웃은 클라이언트가 서버와의 연결을 설정하는 데 걸리는 최대 시간을 나타내며, 리드 타임아웃은 클라이언트가 서버로부터 데이터를 수신하는 데 걸리는 최대 시간을 나타냅니다. 이들은 서버의 응답이나 데이터 수신에 대한 제한 시간으로 사용되어, 연결이나 데이터 전송의 문제를 탐지하고 처리하는 데 활용됩니다."
'CS > 네트워크' 카테고리의 다른 글
| 5주차. 네트워크 레이어 (0) | 2024.02.13 |
|---|---|
| 4주차. UDP, TCP, 신뢰적 데이터 전송 (1) | 2024.01.29 |
| 2주차. 애플리케이션 레이어 HTTP, HTTPS, DNS (0) | 2024.01.17 |
| 1주차. 컴퓨터 네트워크와 네트워크 레이어 (0) | 2024.01.11 |
