[Study] 네트워크 스터디 6회차 : 네트워크 보안, 인증
이 포스팅은 예상 질문과 그에 대한 제 답변으로, 오류가 있다면 알려주세요!
네트워크 보안, 인증
질문과 답변
쿠키에 대해 설명해주세요.
쿠키(Cookie)란 웹사이트가 사용자의 브라우저에 저장하는 작은 텍스트 파일입니다. 사용자가 해당 웹사이트를 방문할 때마다 생성되어 사용자의 컴퓨터나 모바일 기기에 저장됩니다. 쿠키를 통해 사용자가 해당 웹사이트를 다시 방문할 때 이전 상태를 기억하게 해줍니다.
쿠키는 사용자의 로그인 정보, 웹사이트 설정, 사용자 인증 등과 같은 정보를 저장할 수 있습니다. 웹사이트는 쿠키를 사용하여 사용자가 웹사이트에서 어떤 작업을 수행하는지 추적하고, 이를 기반으로 보다 개인화된 경험을 제공할 수 있습니다.
하지만 당사자 뿐만 아니라 제 3자의 쿠키 조회가 가능하므로 사용자의 개인정보 보호와 관련된 문제가 있을 수 있습니다. 일부 웹 사이트는 사용자의 쿠키 정보를 수집하여 광고나 기타 목적으로 사용하기도 합니다. 이에 대해 사용자는 쿠키를 삭제하거나 브라우저 설정에서 쿠키 수집을 제한하는 등의 조치를 취할 수 있습니다.
세션에 대해 설명해주세요.
| 세션은 로그인 여부 등 사용자와 서버의 관계가 기억되어 보존되고 있는 상태를 말합니다. |
세션(Session)은 네트워크 상에서 상호작용하는 두 개체(클라이언트와 서버) 사이에서 유지되는 일종의 상태 정보를 의미합니다. 세션은 클라이언트가 서버에 접속한 후 일정 시간 동안 유지되며, 이 동안에는 클라이언트와 서버 간의 상호작용이 일어납니다.
예를 들어 로그인을 할 때 서버에서 클라이언트에게 세션 ID(보통 알파벳, 숫자가 혼합된 형식)를 발급하고, 메모리에 아이디 사본을 어떤 클라이언트의 것인지 적어서 보관합니다. 클라이언트는 이후의 모든 요청에 이 세션 ID를 함께 전달합니다. 서버는 세션 ID를 사용하여 클라이언트가 로그인한 상태인지 확인하고, 로그인한 사용자만이 접근할 수 있는 기능에 대한 요청을 처리합니다.
세션은 보안과 관련된 중요한 정보도 저장하고 있을 수 있으므로, 세션 관리는 중요한 보안 고려 사항 중 하나입니다.
서버는 요청마다 함께 달려오는 세션 IP를 메모리에 보관하는데, 이 방식은 빠르게 데이터를 확인 할 수 있다는 장점이 있지만 공간이 한정되어 있다는 단점이 있어, 서버에 동시 접속하는 클라이언트가 많아지면 오버헤드가 발생할 수 있습니다. 이 대안으로 세션 ID 대신 토큰을 발급하는 방식이 있습니다.
CORS가 뭘까요?
CORS는 Cross-Origin Resource Sharing의 약어로, 웹 브라우저에서 다른 도메인에 있는 리소스에 접근할 때 발생하는 보안 정책을 위한 메커니즘입니다. 일반적으로, 웹 브라우저는 보안상의 이유로 스크립트에서 다른 도메인에 있는 리소스에 직접 접근을 제한하고 있습니다. 하지만 CORS를 사용하면, 다른 도메인의 리소스에 접근하는 것이 가능해집니다.
CORS는 HTTP 헤더를 사용하여 브라우저와 서버 간에 통신하는 동안 리소스에 대한 액세스를 허용하거나 거부합니다. 이를 통해 다른 도메인에서 제공되는 리소스에 대한 보안상의 이슈를 해결하고, 브라우저에서 다양한 도메인의 리소스에 쉽게 접근할 수 있도록 도와줍니다.
CORS는 보안상의 이유로 기본적으로 활성화되어 있으며, 서버 측에서 HTTP 응답 헤더를 사용하여 허용되는 도메인과 HTTP 메서드를 지정할 수 있습니다. 이를 통해 서버는 악성 요청을 거부하거나, 필요한 경우 인증을 요구하여 보안성을 강화할 수 있습니다.
REST에 대해서 설명해주세요.
REST(Representational State Transfer)는 웹 아키텍처 스타일 중 하나로, 클라이언트와 서버 간의 통신 방식을 정의합니다. RESTful은 REST 아키텍처 스타일을 따르는 웹 서비스를 구현한 것을 말하며, REST API는 이러한 RESTful 웹 서비스를 제공하는 인터페이스를 의미합니다.
RESTful 웹 서비스는 HTTP 프로토콜을 기반으로 하며, URL을 통해 자원을 식별하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 이용해 해당 자원을 조작합니다. 이를 통해 클라이언트와 서버 간의 통신을 단순화하고, 확장성과 유지보수성을 향상시킬 수 있습니다.
RESTful 웹 서비스는 다양한 언어와 플랫폼에서 쉽게 사용할 수 있으며, 인터넷에서 가장 많이 사용되는 웹 서비스 아키텍처 중 하나입니다.
XXS가 뭘까요?
XXS는 Cross-Site Scripting의 약자로, 웹 애플리케이션에서 발생하는 보안 취약점 중 하나이며, 공격자가 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되도록 하는 것입니다. 이 스크립트를 통해 공격자는 사용자의 쿠키, 세션 등을 탈취하거나 악성 웹 사이트로 리디렉션하거나 기타 공격을 수행할 수 있습니다.
- 공격자가 직접 웹 어플리케이션에 엑세스하는 것이 아닌, 함정을 이용해 사용자가 공격 코드를 실행하도록 유도하는 수동적 공격
SQL Injection 공격이 뭘까요? 어떻게 대비할 수 있을까요?
SQL Injection(또는 SQL 삽입)은 웹 어플리케이션에서 발생하는 보안 취약점 중 하나입니다. 해커가 입력 폼 등을 이용하여 SQL 명령어를 주입하는 공격으로, 주로 사용자 인증 우회, 데이터 변조, 데이터베이스 서버의 노출 등을 목적으로 하며 공격자가 데이터베이스에 저장된 데이터를 열람, 수정, 삭제 할 수 있게 됩니다. 방지하기 위해 웹 어플리케이션에 입력값에 대한 검증, SQL Injection 대응 코드 등의 보안 대책을 적용할 수 있습니다.
- 공격자가 직접 웹 어플리케이션에 엑세스하여 공격 코드를 보내므로 능동적 공격
토큰에 대해 설명해주세요.
토큰(token)은 컴퓨터 네트워크에서 인증 및 권한 부여를 위해 사용되는 암호화된 문자열입니다. 일반적으로 사용자 인증 후 발급되며, 이를 사용하여 클라이언트는 서버에 요청을 보내고 요청에 필요한 권한을 부여받을 수 있습니다. 일정 시간이 지나면 만료되며, 이를 통해 토큰 정보를 탈취당할 가능성을 줄일 수 있습니다. 즉, 보안성을 높일 수 있습니다.
해당 서버만이 만들 수 있는 토큰을 발급함으로써 상태를 저장하지 않고도 사용자의 로그인 여부를 파악할 수 있도록 합니다. 사용자의 상태를 저장하지 않으므로 서버 부하가 감소합니다.
URL, URI, URN 차이가 뭘까요?
URL, URI, URN은 모두 인터넷에서 자원을 찾을 수 있도록 하는 식별자이지만, 각각의 용어는 다른 의미를 가지고 있습니다.
URI (Uniform Resource Identifier - 통합자원식별자)는 인터넷에서 자원을 고유하게 식별하기 위해 사용되는 범용 식별자입니다. URI는 인터넷에서 사용되는 모든 자원에 대해 고유한 이름을 제공하고 위치를 지정합니다. 예를 들어, “mailto:user@example.com”은 이메일 주소를 나타내는 URI입니다. 이러한 URI에는 URL, URN 두 가지 형태가 있습니다.
URL (Uniform Resource Locator - 통합자원지시자)은 인터넷에서 자원의 위치를 식별하기 위해 사용되는 식별자로 URI의 가장 흔한 형태입니다. URL은 프로토콜, 호스트, 포트, 경로, 쿼리 문자열, 프래그먼트 식별자 등으로 이루어져 있는데 이를 통해 리소스가 정확히 어디에 있고 어떻게 접근할 수 있는지를 지시합니다.
- 예를 들어, “https://www.example.com/index.html”은 HTTPS 프로토콜을 사용하여 example.com 호스트에서 index.html 파일을 요청하는 URL입니다.
URN (Uniform Resource Name - 유니폼리소스이름)은 URI의 또다른 형태로, 인터넷에서 자원을 이름으로 식별하는 데 사용됩니다. URN은 자원의 위치에 대한 정보를 제공하지 않습니다. 대신, URN은 유일한 이름을 제공하여 자원을 식별합니다. 즉, 해당 자원의 위치에 영향 받지 않는 유일무이한 이름 역할을 합니다. 예를 들어, “urn:isbn:0451450523”은 ISBN 번호를 사용하여 책을 식별하는 URN입니다. URL 사용시 자원의 위치가 변경되면 해당 URL을 더 이상 사용할 수 없다는 한계에서 등장했습니다.
즉, URL은 자원의 위치를 식별하고, URI는 자원을 고유하게 식별하는 일반적인 식별자이며, URN은 자원의 이름으로 식별합니다.
웹 캐시에 대해서 설명해주세요.
웹 캐시(Web Cache)는 인터넷에서 자주 요청되는 웹 페이지나 그래픽 등의 데이터를 저장해두고, 동일한 요청이 있을 경우 저장해둔 데이터를 제공함으로써 인터넷 사용자들이 더 빠르고 효율적으로 정보를 얻을 수 있도록 도와주는 기술입니다.
웹 캐시는 웹 서버와 클라이언트 사이에서 동작하며, 클라이언트가 웹 페이지에 접속할 때 웹 캐시는 자신이 가지고 있는 데이터를 우선적으로 제공합니다. 이렇게 되면 웹 페이지를 불러오기 위한 시간과 대역폭이 줄어들어 빠른 인터넷 이용이 가능해집니다.
웹 캐시는 다양한 방법으로 구현될 수 있으며, 대표적인 웹 캐시 서버로는 Squid와 Varnish가 있습니다.
- 참고: 하드웨어 환경에서도 메모리 내의 데이터를 더 빨리 꺼내올 수 있도록 하는 CPU 캐시 등 존재
웹 프록시에 대해서 설명해주세요.
웹 프록시(프록시 서버)는 클라이언트와 서버 간의 통신을 대리로 처리하는 서버입니다. 클라이언트가 서버에 접근하려고 할 때, 클라이언트는 먼저 웹 프록시에 요청을 보내고, 프록시는 요청을 대신 서버에 전달합니다.
이를 통해 클라이언트는 직접 서버와 통신하지 않아도 되므로 보안상의 이점이 있습니다. 이 때, 서버에 대해서는 개인정보가 보호되지만 프록시 서버에는 클라이언트의 기록이 남습니다. 어느 IP에 얼마나 접속해 있었는지 등 로그 기록을 통해 알 수 있으며, 프록시 서버가 방문할 수 있는 웹사이트를 제한할 수도 있습니다. 프록시 서버 자체를 방화벽으로 사용하기도 합니다.(프록시 방화벽)
또한 웹 프록시는 캐싱을 통해 빠른 속도와 대역폭 감소를 제공합니다. 요청 내용을 프록시 서버에 저장해 뒀다가 동일한 요청에 대해서 서버에 따로 접속하는 과정 없이 저장된 내용을 되돌려줍니다.
프록시 서버는 다음과 같이 여러대를 연결시킬 수 있습니다.
클라이언트 → 프록시 서버1 → 프록시 서버2 → 서버
위와 같이 여러 프록시 서버를 경유하여 클라이언트의 IP주소를 숨기는 것을 Proxy Chaining이라고 합니다.
웹 프록시에서 데이터를 암호화 하지는 않음
웹 프록시 (프록시 서버) 의 종류 by 위치
- Forward Proxy
- 클라이언트가 인터넷에 직접 접근하는게 아닌 프록시 서버가 요청을 받고 인터넷에 연결하여 결과를 클라이언트에 전달
- 클라이언트가 인터넷에 직접 접근하지 않음
- Reverse Proxy
- 클라이언트가 인터넷에 데이터를 요청하면 프록시 서버가 이 요청을 받아 내부 서버에서 데이터를 받은 후 클라이언트에 전달
- 클라이언트가 인터넷에 직접 접근
- 클라이언트는 내부 서버에 대한 정보를 알 필요 없이 프록시 서버에만 요청
- Forward Proxy
회고
비전공자로 개발 공부를 하다보니 CS가 아쉽다고 느꼈었다. 그래서 정처기도 준비하고 추천 받은 관련 도서들도 읽어보며 어느정도 감을 잡다가 해당 스터디를 시작하게 되었는데, 알고 있는 것과 입 밖으로 내는 것은 또 다른 영역이어서 처음엔 걱정을 했던 것 같다. 결론적으로는 더 체계적으로 개념이 잡히고, 무엇보다 공적인 말하기(면접)에서 나의 장단점을 객관적으로 피드백 받을 수 있어서 좋은 경험이었다. 이걸 토대로 어떻게 성장할지는 나의 몫이니 꾸준히 공부해야겠다.
