😢 회개
최근에 새로운 개념들 위주로 도전하고 찾아보다보니 기초가 부족해졌음 느꼈다.
나의 다음 목표는 jest와 알고리즘이었는데 여기에 추가하여서 CS 지식도 다시 한번 돌아보며 복기해야겠다.
🕵️♀️ URL 구성 이해하기
URL의 주요 구성 요소인 Scheme, Host, Port, Path, Query, Fragment에 대해 보자
-
Scheme:
- URL의 Scheme은 자원에 접근하기 위해 사용되는 프로토콜을 나타냅니다.
- 가장 일반적인 예로는
http,https,ftp등이 있습니다. - 예:
https://example.com에서https가 Scheme입니다.HTTP (HyperText Transfer Protocol): 웹 페이지를 전송하기 위한 가장 기본적인 프로토콜입니다.
HTTPS (HTTP Secure): HTTP에 보안이 추가된 버전으로, 데이터가 암호화되어 전송됩니다.
FTP (File Transfer Protocol): 파일 전송에 사용되는 프로토콜입니다.
-
Host:
- Host는 인터넷상의 서버를 가리키는 도메인 이름이나 IP 주소를 의미합니다.
- 예:
https://www.example.com에서www.example.com이 Host입니다.
-
Port:
- Port는 서버 내에서 특정 서비스에 접근하기 위한 '문'과 같은 역할을 합니다.
- 웹 서비스는 일반적으로 HTTP가 80번 포트, HTTPS가 443번 포트를 사용합니다.
- Port는 URL에서 선택적으로 명시됩니다. 예:
https://www.example.com:443에서443이 Port입니다.
-
Path:
- Path는 서버 내에서 자원의 위치를 지정합니다.
- 경로는 "/" 문자로 구분되며, 해당 경로에 위치한 문서나 자원을 가리킵니다.
- 예:
https://www.example.com/index.html에서/index.html이 Path입니다.
-
Query:
- Query는 서버에 전송되는 추가적인 정보를 포함하는 선택적인 부분입니다.
- 주로 키-값 쌍으로 구성되며, 데이터 검색이나 필터링에 사용됩니다.
- 예:
https://www.example.com/search?q=example에서q=example이 Query입니다.
-
Fragment:
- Fragment는 URL의 일부로, 페이지 내의 특정 섹션을 가리킵니다.
- URL에서
#으로 시작하며, 서버로 전송되지 않고 브라우저에서만 사용됩니다. - 예:
https://www.example.com/index.html#section1에서#section1이 Fragment입니다.
이러한 구성 요소들은 URL을 통해 웹 자원의 정확한 위치와 방식을 지정하는 데 사용한다.
🕵️♀️ URI, URL, 그리고 URN 이해하기
URI, URL, URN: 웹 자원 식별의 차이점
URI (Uniform Resource Identifier)
- 정의: 웹 자원을 식별하는 전체적인 문자열.
- 구성: 프로토콜(Scheme), 서버 위치(Host), 경로(Path), 질의(Query), 조각(Fragment).
URL (Uniform Resource Locator)
- 정의: 웹 자원의 실제 위치를 가리키는 URI.
- 특징: 모든 URL은 URI의 구체적 형태로, 항상 Scheme과 Host를 포함합니다.
URN (Uniform Resource Name)
- 정의: 자원의 위치와 독립적인 유일한 이름.
개념 요약
- URI: 가장 넓은 범위로, 자원의 이름이나 위치를 식별합니다.
- URL: 자원의 위치를 특정합니다.
- URN: 위치에 상관없이 자원을 이름으로 식별합니다.
이 세 가지 용어는 웹 상의 자원을 찾고 식별하는 방법에 대한 이해를 돕습니다.
👨💻 HTTP, HTTPS
HTTP와 HTTPS는 웹 페이지와 기타 웹 콘텐츠를 안전하게 전송하기 위한 프로토콜로, 보안에 있어 중요한 차이를 갖는다.
HTTP (HyperText Transfer Protocol)
- 정의: 클라이언트와 서버 간 정보 교환을 위한 프로토콜.
- 보안: 암호화되지 않아 데이터 무결성이나 신원 보증이 이루어지지 않습니다.
- 취약점: 데이터 탈취나 변조가 가능한 중간자 공격에 취약합니다.
- 사용: 주로 보안이 중요하지 않은 정보를 전송할 때 사용합니다.
HTTPS (HyperText Transfer Protocol Secure)
- 정의: HTTP에 데이터 암호화를 추가한 프로토콜.
- 보안: SSL/TLS를 통해 전송되는 데이터를 암호화합니다.
- 데이터 무결성: 데이터가 변조되지 않고 전송됨을 보장합니다.
- 신원 보증: SSL/TLS 인증서를 통해 서버의 신원을 확인할 수 있습니다.
- 사용: 개인 정보와 금융 거래 등 민감한 데이터를 다루는 모든 웹사이트에서 필수적으로 사용됩니다.
HTTPS는 데이터 암호화를 통해 정보의 기밀성을 유지하며, 무결성 검사를 통해 데이터가 송신과 수신 과정에서 변조되지 않았음을 확인합니다. 또한, 인증서를 통해 웹사이트의 신원을 보증하고, 사용자가 의도한 정확한 서버와 통신하고 있음을 보장합니다. 이러한 기능들로 인해 오늘날 웹 보안의 표준이 HTTPS로 자리 잡았습니다.
🍪 쿠키 (Cookies)
개념
- 쿠키는 웹사이트가 사용자의 브라우저에 저장하는 작은 데이터 조각입니다.
- 웹사이트를 방문할 때 생성되며, 사용자의 세션 정보, 사용자 설정 등을 기억하는 데 사용됩니다.
기능
- 세션 관리: 로그인 상태, 프로필 정보, 구매 장바구니 등을 유지합니다.
- 개인화: 사용자 선호도 및 테마 설정을 저장하여 개인화된 경험을 제공합니다.
- 추적: 사용자의 웹사이트 방문 및 활동 내역을 추적하여 타겟 광고 등에 활용합니다.
🛡️ HttpOnly 쿠키 (HttpOnly Cookies)
개념
- HttpOnly 쿠키는 클라이언트 측 스크립트가 쿠키에 접근하는 것을 금지합니다.
- 이는 쿠키를 서버와의 HTTP(S) 통신을 통해서만 접근하게 하여 보안을 강화하는 설정입니다.
보안
- XSS 방지: HttpOnly 플래그가 설정된 쿠키는 자바스크립트를 통한 직접 접근이 차단되므로, XSS 공격으로부터 쿠키 정보를 보호하는 데 도움이 됩니다.
- 데이터 보호: HttpOnly 쿠키는 개인 식별 정보나 인증 토큰 등의 민감한 정보를 보호하는 데 효과적입니다.
✨ XSS (Cross-Site Scripting)
- XSS는 공격자가 웹 페이지에 악의적인 스크립트를 삽입하여 사용자의 브라우저에서 실행되게 하는 보안 취약점입니다.
- 이러한 스크립트는 사용자의 세션 토큰이나 쿠키 정보를 탈취할 수 있습니다.
사용
- 웹 어플리케이션은 사용자의 로그인 정보나 인증 토큰을 HttpOnly 쿠키에 저장하여, 클라이언트 측 스크립트가 이를 사용할 수 없게 함으로써 보안을 강화할 수 있습니다.
- 이 설정은 쿠키를 생성할 때
Set-CookieHTTP 헤더에HttpOnly속성을 추가함으로써 적용됩니다.
쿠키는 사용자의 웹 경험을 개선하는 데 필수적이지만, 적절한 보안 조치 없이는 사용자의 개인 정보를 위험에 노출시킬 수 있습니다. 따라서, HttpOnly 쿠키와 같은 보안 기능을 사용하여 쿠키의 안전한 사용을 보장하는 것이 중요합니다.
👨💻 SOP (Same-Origin Policy)
개요
Same-Origin Policy (SOP)는 웹 브라우저가 자바스크립트와 같은 스크립트 내에서 실행할 때, 페이지가 다른 출처의 리소스와 상호 작용하는 것을 제한하는 보안 정책입니다.
작동 원리
- 웹 페이지는 오직 같은 출처(도메인, 프로토콜, 포트 모두 일치)에서만 리소스를 요청할 수 있습니다.
- 예를 들어,
http://example.com페이지에서http://api.example.com의 API를 호출하려면 SOP 때문에 이 요청은 기본적으로 차단됩니다.
보안
- SOP는 사용자의 데이터를 보호하기 위해 중요합니다.
- XSS 공격과 같은 취약점으로부터 사용자를 보호하는 데에 SOP가 핵심적인 역할을 합니다.
🕵️♀️ CORS (Cross-Origin Resource Sharing)
개요
- CORS는 다른 출처의 리소스에 안전하게 접근할 수 있게 하는 웹 보안 메커니즘입니다.
- 이는 서버가 다른 출처(도메인, 프로토콜, 포트)의 웹 페이지에서 자신의 리소스에 대한 접근을 허용할지 결정할 수 있게 해줍니다.
작동 방식
- 서버는
Access-Control-Allow-Origin헤더를 통해 특정 출처의 요청을 허용합니다. - 이 헤더를 통해 서버는 어떤 출처의 요청이 자신의 리소스에 접근할 수 있는지 명시적으로 지정할 수 있습니다.
🚦 프리플라이트 요청 (Preflight Request)
정의
- 프리플라이트 요청은 복잡한 HTTP 요청을 서버에 보내기 전에 브라우저가 자동으로 수행하는 검증 요청입니다.
목적
- 요청이 서버의 보안 정책에 부합하는지 확인합니다.
- 특히, 요청이 다른 출처에서 온 것이라면, 이는 서버에 잠재적 위험을 가할 수 있기 때문에 이를 사전에 검증합니다.
동작 방식
- 브라우저는
OPTIONS메소드를 사용하여 프리플라이트 요청을 서버에 보냅니다. - 이 요청에는 실제 요청의 메소드(
POST,PUT,DELETE등)와 헤더가 포함됩니다. - 서버는 이 요청을 검토하고, 허용되는 메소드, 헤더, 출처 등에 대한 정보를 응답으로 반환합니다.
👩💻 마무리
기초를 모르는 것을 부끄러워하고,
이를 바로 잡아야겠다.
새로운 기술도 중요하지만 주기적으로 반복해서 기초를 바로 잡겠다.
출처 :
https://www.elancer.co.kr/blog/view?seq=74
https://velog.io/@wlwl99/URL%EC%99%80-URI-IP%EC%99%80-PORT-%EB%8F%84%EB%A9%94%EC%9D%B8%EA%B3%BC-DNS
