신입 개발자 인터뷰 대비 - 4. 네트워크 / 보안
신입 개발자 인터뷰 대비 : 4. 네트워크 / 보안
네트워크 / 보안
브라우저에 URL을 입력부터 화면에 내용이 출력되기 까지의 과정을 최대한 설명할 수 있다.
브라우저에 URL을 입력하고 웹 페이지가 화면에 표시되기까지의 과정은 다음과 같이 진행된다.
- URL 해석: 사용자가 브라우저의 주소창에 URL을 입력하면, 브라우저는 이 URL을 해석하여 해당 리소스가 위치한 서버의 주소를 찾아낸다. 이 때 도메인 이름을 IP 주소로 변환하는 DNS 조회 과정이 포함된다.
- 서버 연결: DNS에서 IP 주소를 받으면, 브라우저는 이 IP 주소의 서버와 TCP 연결을 시작한다. HTTPS 프로토콜을 사용하는 경우, 이 단계에서 SSL/TLS 핸드셰이크가 이루어져 암호화된 연결이 설정된다.
- HTTP 요청: 연결이 설정되면, 브라우저는 HTTP 프로토콜을 사용하여 웹 서버에 데이터를 요청한다. 이 요청에는 사용자가 요청한 웹 페이지의 경로, 브라우저 종류, 수락 가능한 컨텐츠 타입 등이 포함된다.
- 서버 응답: 서버는 브라우저의 요청을 받고 처리한 뒤, 요청받은 웹 페이지의 데이터와 함께 HTTP 응답 코드를 브라우저로 보낸다. 응답 코드는 요청의 성공 여부를 나타낸다.
- 콘텐츠 렌더링: 브라우저는 서버로부터 받은 HTML, CSS, JavaScript 파일들을 파싱하여 DOM(Document Object Model) 트리를 구축한다. 스타일 정보는 CSSOM(CSS Object Model) 트리로 변환되며, 두 트리가 결합되어 렌더 트리를 형성한다.
- 스크립트 처리: 페이지에 JavaScript가 포함된 경우, JS 엔진이 스크립트를 실행한다. 이 과정에서 DOM이 동적으로 변경될 수 있으며, 렌더 트리 역시 업데이트된다.
- 화면에 그리기: 렌더 트리가 완성되면, 브라우저는 페이지를 화면에 그린다. 이 과정에서 레이아웃을 계산하고, 각 요소를 픽셀 단위로 변환하여 최종적으로 사용자의 화면에 표시한다.
이러한 전체 과정은 복잡하고 여러 단계를 포함하지만, 대부분의 현대 브라우저는 이를 몇 초 내에 처리하여 사용자에게 신속하게 웹 페이지를 제공한다.
HTTP 프로토콜에 대해 설명이 가능하고, HTTP, HTTPS 가 무엇이 다른지 설명할 수 있다.
HTTP(HyperText Transfer Protocol)는 웹에서 데이터를 주고받기 위한 프로토콜이다. 웹 브라우저(클라이언트)와 서버 간의 통신을 위해 설계되었으며, HTML 문서, 이미지, 파일 등을 주고받는 데 사용된다.
HTTP의 기본 특징
- 비연결성: 한 번의 연결로 하나의 요청과 응답을 처리한 후 연결을 끊는다. 이로 인해 서버 자원의 효율적 사용이 가능하다.
- 무상태성: 각 요청은 독립적이며, 서버는 클라이언트의 이전 상태를 기억하지 않는다. 이는 서버의 간소화와 확장성 증대에 기여하지만, 모든 요청에 모든 정보가 포함되어야 한다는 단점이 있다.
HTTPS(HyperText Transfer Protocol Secure)
HTTPS는 HTTP의 보안 버전으로, 클라이언트와 서버 간의 모든 통신을 암호화한다. 이는 주로 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 구현된다.
HTTP와 HTTPS의 주요 차이점
- 보안: HTTPS는 데이터를 암호화하여 전송하기 때문에 데이터 도청, 정보 변조 및 메시지 위조를 방지할 수 있다. 반면, HTTP는 데이터를 평문으로 전송하여 보안 취약점이 있다.
- 포트 번호: HTTP는 일반적으로 80번 포트를 사용하고, HTTPS는 443번 포트를 사용한다.
- 성능: HTTPS는 암호화 및 복호화 과정으로 인해 HTTP에 비해 약간 느릴 수 있다. 그러나 최근에는 하드웨어 성능의 향상과 최적화 기술로 인해 그 차이가 많이 줄어들었다.
- 비용: HTTPS를 사용하기 위해서는 SSL/TLS 인증서가 필요하며, 이는 구매 비용이 발생할 수 있다. 그러나 많은 인증 기관에서 무료 인증서도 제공하고 있다.
HTTPS의 도입은 웹 보안을 강화하는 데 중요한 역할을 하며, 사용자 데이터 보호와 신뢰성 있는 웹 서비스 제공에 기여한다. 따라서 민감한 정보를 다루는 모든 웹 사이트는 HTTPS를 사용하는 것이 권장된다.
쿠키와 세션, JWT 토큰의 특징, 장단점을 함께 설명할 수 있다.
쿠키, 세션, 그리고 JWT(Json Web Token) 토큰은 웹 개발에서 사용자 인증과 세션 관리를 위해 널리 사용되는 기술들이다.
1. 쿠키 (Cookies)
쿠키는 클라이언트의 브라우저에 저장되는 작은 데이터 조각으로, 서버가 사용자의 브라우저에 저장하도록 요청한다. 쿠키는 사용자가 사이트에 다시 방문할 때마다 브라우저를 통해 서버에 전송된다. 특징:
- 상태 정보를 로컬에서 유지한다.
- 만료 날짜/시간이 설정되어 자동 삭제될 수 있다.
장점:
- 간단한 구현.
- 지속적인 인증 데이터 저장으로 사용자 경험 향상.
단점:
- 보안 취약점이 존재한다(클라이언트 측에 저장되기 때문).
- 사용자의 브라우저에 따라 저장 공간이 제한적일 수 있다.
2. 세션 (Session)
세션은 서버 측에서 사용자 정보를 저장하는 방법이다. 서버는 세션 ID를 생성하고 이를 쿠키를 통해 클라이언트에 전달한다. 클라이언트는 이후 요청마다 이 세션 ID를 서버에 전송하여 사용자를 식별한다. 특징:
- 사용자 정보는 서버에 저장된다.
- 세션 ID는 클라이언트에 저장된다.
장점:
- 사용자 정보가 서버에 저장되므로 보안성이 높다.
- 사용자의 데이터를 서버에서 직접 관리할 수 있다.
단점:
- 서버의 메모리를 사용하므로 대규모 트래픽에서 성능 저하가 발생할 수 있다.
- 서버 기반의 세션 관리는 확장성에 제약을 받을 수 있다.
3. JWT (Json Web Token)
JWT는 JSON 객체를 사용하여 사용자의 인증 정보를 토큰 형태로 인코딩, 암호화하는 방식이다. 이 토큰은 클라이언트와 서버 간에 안전하게 정보를 교환할 수 있게 해준다. 특징:
- 자가 수용적(self-contained)으로, 필요한 모든 정보를 자체적으로 포함한다.
- 토큰은 서명되어 변조를 방지한다.
장점:
- 확장성이 뛰어나다(세션 상태를 서버에 저장할 필요가 없다).
- 여러 플랫폼 및 도메인 간 인증에 용이하다.
단점:
- 토큰 크기가 클 수 있으며, HTTP 요청마다 전송되므로 부하가 증가할 수 있다.
- 토큰이 탈취되면 정보가 노출될 위험이 있다(만료 시간까지 유효).
각 기술은 특정 상황에서 장점을 제공하므로, 애플리케이션의 요구사항과 보안, 성능 필요에 따라 적절히 선택하여 사용하는 것이 중요하다.
TCP, UDP의 차이를 설명하고 각 어디에 사용되는 것이 좋은지 설명할 수 있다.
TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)는 인터넷에서 데이터를 전송하기 위한 두 가지 주요 프로토콜이다. 각각의 프로토콜은 서로 다른 특징과 장단점을 가지며, 그 사용 용도도 다르다.
TCP (Transmission Control Protocol)
특징:
- 연결 지향적: 데이터 전송 전에 연결을 설정하며, 데이터 전송이 완료된 후 연결을 종료한다.
- 신뢰성 있는 데이터 전송: 데이터 패킷의 손실, 중복, 순서 뒤바뀜 등을 관리하며, 오류 발생 시 재전송을 수행한다.
- 흐름 제어 및 혼잡 제어 기능을 제공한다.
장점:
- 데이터의 정확한 전송을 보장한다.
- 데이터의 순서와 무결성을 유지한다.
단점:
- 오버헤드가 크며, UDP보다 속도가 느리다.
- 실시간 통신에는 적합하지 않을 수 있다.
적합한 사용 예:
- 이메일 전송, 웹 페이지 로딩, 파일 전송 등 오류 없이 정확한 데이터 전송이 중요한 애플리케이션에 적합하다.
UDP (User Datagram Protocol)
특징:
- 비연결 지향적: 연결을 설정하지 않고 바로 데이터를 전송한다.
- 최소한의 프로토콜 메커니즘만 제공하여, 오버헤드가 매우 작다.
- 패킷의 손실이나 순서에 대한 처리를 하지 않는다.
장점:
- 전송 지연이 매우 적다.
- 실시간 데이터 전송에 적합하다.
단점:
- 신뢰성이 낮고, 데이터가 손실될 가능성이 있다.
- 데이터의 순서가 뒤바뀔 수 있다.
적합한 사용 예:
- 실시간 비디오나 오디오 스트리밍, 온라인 게임, VoIP(Voice over Internet Protocol) 등 시간 지연에 민감하거나 일시적인 데이터 손실이 허용되는 애플리케이션에 적합하다.
TCP는 신뢰성과 순서를 중시하는 데이터 전송에, UDP는 신속하고 연속적인 데이터 스트림이 필요한 경우에 적합하다.
3-way hanbshaking 과 4-way handshawking 에 대해 설명하시오
TCP/IP 네트워크 프로토콜에서 3-way handshaking과 4-way handshaking은 연결 설정 및 종료 과정에서 사용되는 중요한 메커니즘이다.
3-way Handshaking (연결 설정)
TCP 연결을 시작할 때 사용되는 3-way handshaking 과정은 다음과 같다.
- SYN: 클라이언트가 서버로 SYN(Synchronize Sequence Numbers) 패킷을 보내고 연결 요청을 한다; 이때 클라이언트는 자신의 초기 시퀀스 번호를 보낸다.
- SYN-ACK: 서버는 SYN 요청을 받고 클라이언트에게 SYN과 ACK(Acknowledgment) 패킷을 보내 연결 요청을 수락한다; 서버 역시 자신의 초기 시퀀스 번호를 보낸다.
- ACK: 클라이언트는 서버의 SYN-ACK에 대해 ACK를 보내 연결을 확립한다.
4-way Handshaking (연결 종료)
TCP 연결을 종료할 때 사용되는 4-way handshaking 과정은 다음과 같다.
- FIN: 연결을 종료하고자 하는 호스트가 FIN(Finish) 패킷을 상대방에게 보내 연결 종료 의사를 표시한다.
- ACK: 수신 호스트는 FIN 패킷을 받고 ACK 패킷을 보내어 확인 응답을 한다.
- FIN: 이제 수신 호스트 역시 연결을 종료할 준비가 되면 FIN 패킷을 보낸다.
- ACK: 처음 FIN을 보낸 호스트는 마지막 ACK를 받고 나서 연결을 최종적으로 종료한다.
이 두 과정은 TCP의 신뢰성 있는 데이터 전송을 보장하기 위해 설계되었다. 3-way handshaking은 연결을 안전하게 시작하기 위해, 그리고 4-way handshaking은 양방향으로 데이터 전송이 완료되었음을 확인하고 연결을 청결하게 종료하기 위해 사용된다.
OSI 7 계층에 대해 설명하시오.
OSI(Open Systems Interconnection) 7 계층 모델은 네트워크 통신을 위한 국제 표준 아키텍처로, 데이터 통신 과정을 일곱 단계로 나누어 설명한다. 각 계층은 특정 기능을 담당하며, 하위 계층에서 상위 계층으로 데이터가 이동하면서 각 계층에서 필요한 처리가 이루어진다.
- 물리 계층(Physical Layer):
- 데이터 전송의 기본적인 수준을 담당하며, 케이블, 카드, 전기적 신호 등 물리적인 전송 매체를 통해 비트 단위의 데이터를 전송한다.
- 데이터 링크 계층(Data Link Layer):
- 네트워크 상에서 데이터의 오류 없는 전송을 보장하기 위해 프레임에 주소와 오류 검출 코드를 추가한다. 이 계층은 또한 MAC 주소를 처리하며, 스위치와 브리지 같은 장비가 이 계층에서 작동한다.
- 네트워크 계층(Network Layer):
- 다양한 라우팅 기술을 사용하여 패킷을 목적지까지 전달한다. IP 주소가 이 계층에서 사용되며, 라우터가 주요 네트워크 장비로 활용된다.
- 전송 계층(Transport Layer):
- TCP/IP 모델의 TCP와 UDP 프로토콜이 이 계층에서 작동하며, 신뢰성 있는 데이터 전송을 담당한다. 이 계층은 데이터의 분할, 조립 및 오류 검사와 복구를 책임진다.
- 세션 계층(Session Layer):
- 데이터 교환의 논리적 연결을 관리하고 통신 세션을 구성한다. 이 계층은 세션 설정, 유지, 종료를 책임진다.
- 표현 계층(Presentation Layer):
- 데이터 표현 형식을 관리하며, 암호화 및 압축을 담당한다. 데이터를 네트워크에서 사용할 수 있는 형식으로 변환하거나, 반대로 애플리케이션 형식으로 변환하는 역할을 한다.
- 응용 계층(Application Layer):
- 최종 사용자와 직접적으로 상호작용하는 계층으로, 이메일 클라이언트, 웹 브라우저 등 응용 프로그램이 위치한다. 네트워크 소프트웨어 UI와 같은 사용자 인터페이스와 게이트웨이 서비스가 포함된다.
OSI 7 계층 모델은 네트워크 설계와 문제 해결을 위해 데이터 통신 과정을 이해하는 데 도움을 준다. 각 계층은 다른 계층의 작업을 독립적으로 수행할 수 있어, 네트워크 통신을 효율적으로 관리하고 조정할 수 있다.
RESTful 이란 무엇이며, 이에 대해 설명하시오.
RESTful은 REST(REpresentational State Transfer) 아키텍처를 따르는 웹 서비스를 의미한다. 이 아키텍처는 인터넷에서 컴퓨터 시스템 간에 통신을 용이하게 하기 위해 고안됐다. RESTful 웹 서비스의 주요 특징은 다음과 같다:
- 클라이언트-서버 구조: 서비스는 사용자 인터페이스와 데이터 스토리지를 분리하는 클라이언트와 서버 구조를 가진다. 이로 인해 각 부분이 독립적으로 발전할 수 있다.
- 무상태성(stateless): 각 요청은 독립적으로 처리되며, 서버는 클라이언트의 상태 정보를 저장하지 않는다. 클라이언트는 필요한 모든 정보를 함께 전송해야 한다.
- 캐시 가능(cacheable): 서버는 응답이 캐시 가능한지 여부를 명시해 클라이언트가 응답을 재사용할 수 있게 한다.
- 계층화: 클라이언트는 종단 서버와 직접 통신할 수도 있지만, 중간 서버를 통해서도 데이터에 접근할 수 있다.
- 통일된 인터페이스: REST는 표준 HTTP 메소드(GET, POST, PUT, DELETE 등)를 사용하여 리소스에 접근하므로 인터페이스가 통일되어 있다.
RESTful 서비스는 이러한 원칙을 통해 웹의 확장성을 증대시키고, 다양한 클라이언트에서 원활하게 작동할 수 있도록 돕는다.
CORS란 무엇이며 이에 대해 설명하시오.
CORS(Cross-Origin Resource Sharing)는 웹 페이지가 다른 도메인의 리소스에 접근할 수 있도록 허용하는 보안 메커니즘이다. 웹은 기본적으로 같은 출처 정책(Same-Origin Policy)을 따르는데, 이 정책은 웹 페이지가 다른 도메인의 리소스에 대한 요청을 제한한다. CORS는 이 정책을 완화하여 특정 조건 아래에서 다른 출처의 리소스 접근을 가능하게 한다. CORS의 핵심 요소는 다음과 같다:
- HTTP 헤더 사용: CORS는 웹 서버가
Access-Control-Allow-Origin
과 같은 특정 HTTP 헤더를 사용해, 다른 출처의 리소스 요청을 허용할지 결정한다. - 사전 요청(Preflight Request): 복잡한 요청을 보내기 전에, 브라우저는
OPTIONS
메소드를 사용해 사전 요청을 보낸다. 이는 실제 요청이 안전한지 확인하기 위함이다. - 안전한 리소스 공유: 서버는 특정 출처, 메소드, 헤더 등을 허용하도록 설정할 수 있다. 이렇게 함으로써 리소스가 안전하게 공유될 수 있도록 조치한다.
CORS는 웹 애플리케이션의 상호 운용성을 향상시키고, 다양한 출처의 리소스를 효과적으로 활용할 수 있도록 해준다.
TCP/IP 4계층에 대해 설명해보시오.
TCP/IP 모델은 네트워크 통신을 위해 널리 사용되는 프로토콜 집합이며, 주로 네 계층으로 구성된다. 각 계층은 특정 기능을 수행하며, 상위 계층은 하위 계층의 서비스를 이용한다. TCP/IP의 4계층은 다음과 같다:
- 응용 계층(Application Layer): 사용자와 직접적으로 상호작용하는 응용 프로그램을 포함한다. HTTP, FTP, SMTP 등과 같은 프로토콜이 이 계층에 속한다. 사용자의 요청을 네트워크로 전송하고, 네트워크에서 받은 데이터를 사용자에게 제공한다.
- 전송 계층(Transport Layer): 네트워크 상에서 데이터의 전송을 담당하며, TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)가 주요 프로토콜이다. TCP는 신뢰성 있는 연결을 제공하고 데이터 순서 보장 및 오류 검출 등의 기능을 담당한다. UDP는 연결이 없는 서비스로 빠른 전송을 지원하지만 신뢰성은 낮다.
- 인터넷 계층(Internet Layer): 데이터 패킷이 네트워크 간에 올바르게 라우팅되도록 관리한다. IP(Internet Protocol)는 이 계층의 핵심 프로토콜로, 데이터 패킷을 목적지까지 전달하는 기능을 한다. 또한, IP 주소와 라우팅 기능을 통해 패킷을 적절한 목적지로 보낸다.
- 링크 계층(Link Layer): 네트워크의 물리적 매체를 통해 데이터를 전송하는 하드웨어 수준의 통신을 담당한다. 이 계층은 네트워크 어댑터나 드라이버 같은 요소를 포함하며, 이더넷과 같은 기술이 여기에 속한다.
이러한 계층적 구조는 네트워크 통신의 복잡성을 관리하고, 각 계층이 독립적인 개발과 기능 수행을 가능하게 한다.
웹 서버 소프트웨어 (Apache, Nginx) 는 OSI 7계층에서 어디에서 동작하는가
웹 서버 소프트웨어인 Apache와 Nginx는 OSI 7계층 모델에서 주로 **응용 계층(Application Layer)**에서 동작한다. OSI 7계층 모델에서 응용 계층은 가장 상위 계층으로, 사용자와 직접적으로 상호작용하며 응용 프로그램 간의 데이터 전송을 촉진하는 데 필요한 서비스를 제공한다. 이 계층에서는 네트워크 서비스에 대한 직접적인 사용자 인터페이스를 제공하며, 여기에는 웹 페이지의 호스팅과 같은 기능이 포함된다.
Apache와 Nginx 같은 웹 서버는 HTTP 프로토콜을 사용하여 클라이언트의 요청을 처리하고 응답을 생성하는 기능을 수행한다. 이들은 웹 컨텐츠를 서비스하는데 필요한 로직과 구성을 관리하며, 필요에 따라 보안, 캐시 관리, 로드 밸런싱 등의 추가적인 기능을 제공한다. 따라서 이 소프트웨어들은 응용 계층에서 중요한 역할을 하며, 사용자가 웹을 통해 정보를 요청하고 받아볼 수 있도록 한다.
JWT에 대해 간단히 설명하시오
JWT(JSON Web Token)는 인터넷에서 두 당사자 사이에 정보를 JSON 객체 형태로 안전하게 전송하기 위해 디자인된 컴팩트하고 자가 수용적인 방식의 토큰이다. 이 토큰은 정보를 안전하게 전송하기 위해 디지털 서명되어 있으며, 일반적으로 HMAC 알고리즘을 사용한 서명 또는 RSA를 사용한 공개 키/개인 키 쌍을 이용한 서명 방식을 사용한다. JWT의 주요 특징과 사용법은 다음과 같다:
- 구조: JWT는 세 부분으로 나뉜다. 헤더(Header), 페이로드(Payload), 서명(Signature). 헤더는 토큰의 유형과 사용된 알고리즘을 명시하고, 페이로드는 클레임(즉, 토큰에 담길 정보)을 포함하며, 서명은 토큰이 위변조되지 않았음을 검증하는 데 사용된다.
- 자가 수용성(Self-contained): JWT는 필요한 모든 정보를 자체적으로 갖고 있어, 별도의 상태 저장소가 필요 없다. 이는 사용자 인증 토큰으로 적합하게 만든다.
- 보안: 서명 덕분에 토큰이 변조되지 않았는지 확인할 수 있다. 공개 키 인프라를 사용하면 발신자의 신원 또한 검증할 수 있다.
JWT는 주로 사용자 인증 및 정보 교환에 사용되며, 웹 서비스 간에 간단하고 안전하게 정보를 전송할 수 있는 방법을 제공한다.
비대칭키 암호화, 대칭키 암호화에 대해 설명하시오
비대칭키 암호화와 대칭키 암호화는 데이터를 보호하기 위해 널리 사용되는 두 가지 주요 암호화 방식이다. 각각의 방식은 특정 상황에 적합하도록 설계되어 있으며, 그 특징과 사용법은 다음과 같다:
대칭키 암호화 (Symmetric Key Encryption)
대칭키 암호화에서는 암호화와 복호화 과정에 동일한 키를 사용한다. 이 방식의 주요 특징은 다음과 같다:
- 속도: 대칭키 암호화는 비대칭키 암호화보다 일반적으로 빠르며, 대량의 데이터를 처리하는 데 적합하다.
- 키 관리: 같은 키를 사용하기 때문에, 키의 분배와 관리가 중요한 이슈가 된다. 키가 노출되면 데이터의 보안이 위협 받는다.
- 예시: AES(Advanced Encryption Standard)와 DES(Data Encryption Standard)가 대표적인 대칭키 암호화 알고리즘이다.
비대칭키 암호화 (Asymmetric Key Encryption)\
비대칭키 암호화에서는 두 개의 키, 즉 공개 키와 개인 키를 사용한다. 한 키로 암호화하면 다른 키로만 복호화할 수 있다. 이 방식의 주요 특징은 다음과 같다:
- 키 쌍: 사용자는 공개 키(누구나 접근 가능)와 비공개 키(개인적으로 보관)를 갖는다. 공개 키로 암호화된 데이터는 비공개 키로만, 비공개 키로 암호화된 데이터는 공개 키로만 복호화할 수 있다.
- 보안성: 비대칭키 암호화는 키 분배 문제를 해결하지만, 암호화 및 복호화 과정이 대칭키 방식보다 느리다.
- 사용 예: SSL/TLS에서 데이터 전송 보안, 디지털 서명 생성 및 검증 등에 사용된다.
- 예시: RSA, ECC(타원 곡선 암호)가 비대칭키 암호화 알고리즘으로 널리 사용된다.
대칭키와 비대칭키 암호화는 각각의 장단점이 있으며, 실제 응용에서는 종종 두 방식을 혼합하여 사용한다. 예를 들어, 비대칭키 암호화로 안전하게 키를 교환하고, 이 키를 사용해 대칭키 암호화로 데이터를 암호화하는 방식이다. 이러한 결합은 보안성과 성능을 모두 향상시킨다.
OAuth 에 대해 설명하시오
OAuth는 인터넷 사용자가 외부 서비스에 자신의 정보에 접근할 수 있는 권한을 안전하게 위임할 수 있는 개방형 표준 프로토콜입니다. 이 프로토콜을 통해 사용자는 자신의 중요한 자격 증명을 공개하지 않고도 서비스 간에 안전하게 정보를 공유할 수 있습니다. OAuth는 주로 사용자가 하나의 서비스(예: 페이스북, 구글)의 자격증명을 사용하여 다른 서드파티 애플리케이션(예: 모바일 앱, 웹사이트)에서 로그인할 수 있도록 합니다. OAuth의 주요 특징과 사용 방법은 다음과 같습니다:
- 역할 분리: OAuth에서는
리소스 소유자
(사용자),클라이언트
(사용자가 사용하고자 하는 서드파티 서비스),리소스 서버
(사용자 데이터를 보유한 서비스), 그리고인증 서버
(인증 및 토큰 발급을 담당) 등 네 가지 주요 역할이 구분됩니다. - 접근 토큰: 사용자의 승인을 받은 후, 클라이언트는 리소스 서버에 접근하기 위한 접근 토큰을 받습니다. 이 토큰은 리소스 소유자의 자격 증명을 공유하지 않고도 서비스 간의 정보 교환을 가능하게 합니다.
- 보안: OAuth는 토큰을 통해 인증을 처리함으로써, 실제 사용자의 로그인 정보를 외부에 노출시키지 않습니다. 이는 보안을 강화하며, 불필요한 정보 유출 위험을 줄입니다.
- 권한 위임: 사용자는 자신의 데이터에 대한 특정 부분만을 선택적으로 클라이언트에게 접근 권한을 줄 수 있습니다. 예를 들어, 소셜 미디어 계정에서는 프로필 정보만 공유하고 메시지 접근은 허용하지 않는 등의 세밀한 제어가 가능합니다.
OAuth는 웹, 모바일, IoT 장치 등 다양한 플랫폼에서 광범위하게 채택되어 사용되고 있으며, 사용자 경험을 향상 시키는 동시에 서비스 제공자와 사용자 모두에게 보다 높은 보안을 제공합니다.
JWT와 OAuth 를 비교하고 차이를 설명하시오
JWT(JSON Web Token)와 OAuth는 인증 및 권한 부여에 사용되지만, 목적과 구현 방식에서 중요한 차이가 있습니다. 이들 간의 차이를 정확히 이해하면, 각각을 적절하게 활용할 수 있습니다.
JWT (JSON Web Token)
- 목적: JWT는 정보의 안전한 전송을 목적으로 하는 자가 수용적인 토큰입니다. 인증 후 사용자의 세션을 관리하는 데 주로 사용됩니다.
- 구조: JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분으로 구성되며, 이를 통해 사용자의 정보와 토큰이 유효한지를 검증할 수 있는 서명이 포함됩니다.
- 독립성: JWT는 자체적으로 모든 필요한 정보를 포함하므로 별도의 인증 저장소가 필요 없습니다. 이는 분산 시스템에서의 확장성과 성능 향상에 유리합니다.
- 사용 예: 사용자 로그인 후 세션 관리, 사용자 정보 전송 등에 사용됩니다.
OAuth
- 목적: OAuth는 사용자의 자격증명을 사용하지 않고, 서드 파티 애플리케이션에 사용자의 리소스에 대한 접근 권한을 안전하게 위임하는 것을 목적으로 합니다.
- 역할: OAuth에서는 리소스 소유자(사용자), 클라이언트(서드파티 애플리케이션), 리소스 서버(사용자 데이터를 보유한 서버), 인증 서버(인증 및 토큰 발행을 담당하는 서버) 등 여러 주체가 관련됩니다.
- 프로세스: OAuth는 클라이언트가 사용자로부터 특정 리소스에 대한 접근 권한을 얻고, 이를 인증 서버로부터 발급받은 토큰을 통해 리소스 서버에 접근하도록 합니다.
- 사용 예: 소셜 로그인, 외부 서비스에서의 자원 접근 권한 부여 등에 사용됩니다.
결론
JWT는 정보를 안전하게 전송하고 인증 정보를 토큰 내에 포함시켜 세션 관리 등에 주로 사용되는 반면, OAuth는 사용자의 권한을 안전하게 위임하여 서드파티 애플리케이션에서 사용자의 리소스에 접근할 수 있도록 하는 프로토콜입니다. 따라서, JWT는 인증 수단으로, OAuth는 권한 위임 메커니즘으로 각각 활용됩니다. 이 두 기술은 서로 다른 목적을 가지고 있지만, 보안이 필요한 다양한 웹 기반 서비스에서 함께 사용될 수 있습니다.
SQL Injection 에 대해서 간단히 설명하고, 대처 법에 대해 설명해보시오
SQL 인젝션(SQL Injection)은 악의적인 SQL 코드가 데이터베이스 시스템에 주입되어 실행되게 하는 보안 취약점 공격 방법이다. 이 공격은 애플리케이션의 보안이 취약한 데이터 입력 포인트를 이용하여 데이터베이스에 접근하고, 데이터를 조작하거나 무단으로 조회하는 데 사용될 수 있다. SQL 인젝션의 주요 특징과 대처 방법은 다음과 같다:
SQL 인젝션의 특징
- 데이터 손상: 공격자는 SQL 인젝션을 통해 데이터를 삭제하거나 변조할 수 있다.
- 정보 유출: 사용자 정보, 중요 기업 데이터 등이 유출될 위험이 있다.
- 시스템 접근: 공격자는 데이터베이스 관리자 권한을 얻어 시스템 전반에 접근할 수 있는 경우도 있다.
대처 방법
- 입력 값 검증: 사용자로부터 받은 모든 입력 데이터에 대해 엄격하게 검증해야 한다. 특히 SQL 명령어가 포함되어 있는지 체크하는 것이 중요하다.
- 준비된 명령어 사용(Prepared Statements): SQL 쿼리를 실행할 때 변수를 직접 쿼리에 삽입하는 대신, 준비된 명령어(예: PreparedStatement in Java)를 사용한다. 이 방법은 SQL 인젝션 공격을 방지하는 데 효과적이다.
- 저장 프로시저 사용: 데이터베이스에서 지원하는 저장 프로시저를 사용하면, SQL 코드가 미리 컴파일되어 실행되기 때문에 외부에서 임의의 SQL 코드를 주입하기가 더 어려워진다.
- 최소 권한 원칙 적용: 데이터베이스 계정은 필요한 최소한의 권한만을 가지도록 설정한다. 예를 들어, 읽기 전용 데이터에 대한 접근이 필요한 경우, 해당 계정에는 쓰기 권한을 주지 않는다.
- 오류 메시지 관리: SQL 쿼리 실행 실패 시, 구체적인 데이터베이스 오류 내용을 사용자에게 보여주지 않고, 로그 파일에만 기록해야 한다. 이는 공격자가 시스템 구조를 유추하는 것을 방지한다.
이러한 방법들을 종합적으로 적용함으로써, SQL 인젝션 공격으로부터 시스템을 보호하고 데이터의 안전성을 유지할 수 있다.
XSS에 대해서 설명하시오
XSS(Cross-Site Scripting)는 웹 애플리케이션 보안의 취약점을 이용한 공격 유형 중 하나로, 악의적인 스크립트가 웹 페이지에 삽입되어 사용자의 브라우저에서 실행되는 현상을 말한다. 이 공격은 사용자의 세션 쿠키, 세션 토큰 등을 탈취하거나, 사용자를 가장하여 악의적인 행동을 수행하게 할 수 있다. XSS의 주요 유형과 대처 방법은 다음과 같다:
XSS의 유형
- 반사형 XSS(Reflected XSS): 사용자로부터 받은 입력값이 서버에서 처리된 후 즉시 웹 페이지에 반영되어 사용자의 브라우저로 되돌아갈 때 발생한다. 대개 링크를 통해 악의적인 스크립트가 전달된다.
- 저장형 XSS(Stored XSS): 악의적인 스크립트가 웹 서버에 저장되었다가, 다른 사용자의 요청에 의해 해당 스크립트가 포함된 데이터가 웹 페이지에 출력될 때 발생한다.
- DOM 기반 XSS(DOM-based XSS): DOM(Document Object Model)의 구조나 속성을 조작하여 발생하는 XSS로, 클라이언트 사이드에서 스크립트가 실행된다.
대처 방법
- 입력값 검증 및 적절한 처리: 사용자 입력값에 대해 HTML, JavaScript 등이 포함되지 않도록 필터링하거나 적절히 이스케이프 처리하는 것이 중요하다.
- 콘텐츠 보안 정책(CSP): CSP는 웹 페이지에서 실행할 수 있는 스크립트의 출처를 제한함으로써 XSS 공격을 막는 데 도움을 준다. CSP를 통해 외부 스크립트, 인라인 스크립트, eval() 사용 등을 제한할 수 있다.
- HTTPOnly와 Secure 플래그 사용: 쿠키에 HTTPOnly와 Secure 플래그를 설정하면, 쿠키 정보가 JavaScript를 통해 접근되지 않도록 하여, 스크립트가 사용자의 세션을 탈취하는 것을 방지할 수 있다.
- 사용자 입력을 동적으로 생성된 DOM에 안전하게 추가: 사용자 입력을 DOM에 직접 삽입할 경우, 텍스트 노드로 처리하거나, 적절히 새니타이즈하도록 한다.
XSS 공격은 웹 애플리케이션에서 흔히 발견되는 보안 취약점이기 때문에, 개발 초기 단계부터 보안을 고려하는 것이 중요하다. 이러한 기본적인 방어 기술들을 통합하고 엄격히 적용함으로써 웹 애플리케이션을 보호할 수 있다.
CSRF에 대해 설명하시오
CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)는 웹 애플리케이션 보안의 취약점을 이용한 공격 유형 중 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 웹 애플리케이션에서 실행하게 만드는 공격을 말한다. 이 공격은 사용자가 이미 인증된 세션을 가지고 있을 때 특히 위험하다.
CSRF의 특징
- 사용자의 세션을 이용: 공격자는 사용자의 브라우저가 이미 인증받은 상태를 이용해 악의적인 요청을 만들어내며, 이는 사용자가 로그인한 상태에서 무심코 악의적인 링크를 클릭하거나 방문함으로써 발생할 수 있다.
- 사용자는 무의식적으로 요청: 사용자는 공격이 일어나고 있다는 것을 전혀 인지하지 못하는 상태에서 공격자가 설정해 놓은 행동(비밀번호 변경, 송금 등)을 수행할 수 있다.
- 악의적인 요청: 이 요청은 이미지 태그, 숨겨진 폼, 자바스크립트 XMLHttpRequest 등 다양한 방법으로 실행될 수 있다.
대처 방법
- CSRF 토큰 사용: 각 폼 요청에 고유한 CSRF 토큰을 포함시켜 서버에서 그 토큰을 검증하게 함으로써, 요청이 정당한 페이지에서 발생했는지를 확인할 수 있다.
- SameSite 쿠키 속성 사용: 최신 브라우저는 쿠키에
SameSite
속성을 지원하여, 쿠키가 같은 도메인의 요청에만 사용될 수 있도록 제한한다. 이 속성을 사용하면 CSRF 공격을 막을 수 있다. - 사용자 인증 요청: 중요한 행동을 수행할 때마다 사용자의 비밀번호를 재확인하거나 2단계 인증을 요구하는 것이다.
- Referer 검증: HTTP 헤더의 Referer를 검증하여 요청이 신뢰할 수 있는 도메인에서 발생했는지 확인할 수 있다.
CSRF 공격은 사용자가 자신도 모르게 중요한 행동을 수행하게 만들 수 있으므로, 웹 애플리케이션을 설계할 때 이를 고려하여 보안 조치를 적용해야 한다. 이러한 방어 기술들은 애플리케이션의 보안을 강화하고 사용자의 데이터를 보호하는 데 중요한 역할을 한다.