일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Session Manager
- splunk db connect
- metacode
- 정처기 필기
- 블록체인
- 정처기필기
- web3
- web3 보안
- metacodem
- 보안 그룹
- AWS SSM
- AWS CLI
- 메타코드
- File Upload
- 탈중앙화
- Path Traversal
- 정보처리기사
- 티스토리챌린지
- web security academy
- 스마트컨트랙트
- 오블완
- 메타코드M
- amazon s3 트리거
- 정처기
- web shell
- 스마트 컨트랙트
- systems manager
- aws lambda
- ELB
- aws 트리거
Archives
- Today
- Total
min8282
[공통과정] 웹 해킹/HTTP의 이해 본문
HTTP란?
- 브라우저와 웹 서버 간의 통신을 위한 프로토콜
- HTTP Request : 클라이언트가 서버에게 보내는 요청
- HTTP Response : 서버가 클라이언트에게 보내는 응답
HTTP Response는 요청이 있어야 응답이 올 수 있다. 응답만 있는 경우X
HTTP 구조
- Request Message : 웹 브라우저가 서버에게 요청할 때 보내는 메시지
- Response Message : 웹 서버가 HTTP Request를 받고 응답할 때 보내는 매시지
- 개행문자(\r\n) 라인으로 구분하여 데이터를 식별한다.
- 공백라인은 요청 또는 응답의 메타데이터가 모두 전송되었음을 알리는 빈 줄
HTTP Requset
- 클라이언트가 서버에게 보내는 데이터 패킷(클라이언트 -> 서버)
- HTTP Method : 서버가 수행해야 할 동작
- Path + (Query String) : 주로 URL 또는 프로토콜 등 절대 경로
- HTTP Version : 메시지의 남은 구조 결정, 응답 시 사용해야 할 HTTP 버전을 알려주는 역할
HTTP Method
구분 | 내용 |
GET | 특정한 리소스를 가져오도록 요청 파라미터가 URL에 입력됨 |
POST | 주로 데이터 등록, 수정 시 사용 |
PUT | 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체 |
DELETE | 리소스 제거 시 사용 |
GET vs. POST
구분 | GET | POST |
기록 | 파라미터들은 URL의 일부이기 때문에 브라우저 히스토리에 기록 | 파라미터들이 브라우저 히스토리에 기록되지 않음 |
재전송 | 재실행되더라도 브라우저 캐시에 HTML이 저장되어 있다면 서버에 다시 전송 되지 않음 | 브라우저가 보통 사용자에게 데이터가 다시 전송 되어야 한다고 알려줌 |
파라미터 | URL에 넣을 수 있는 파라미터 데이터 제한 | 서버에 파일 업로드하는 것을 포함하여 파라미터 전송 가능 |
GET은 데이터가 저장된 곳이 Header 부분, POST는 body 부분으로 기억하면 좋다.
HTTP Request(Header)
- 클라이언트의 요청에 대한 부가적인 정보
- 대소문자 구분 없이 문자열 다음에 콜론(:)이 붙으며, 그 뒤에 오는 값은 헤더에 따라 다르게 명시
- Header Field
- Host : 요청하는 호스트에 대한 호스트명 및 포트번호
- User-Agent : 사용자 웹 브라우저 종류 및 버전 정보
- Accept : 클라이언트가 원하는 콘텐츠 타입 및 우선순위 명시
- Connection : 클라이언트와 서버 간 연결에 대한 옵션
HTTP Response
- 클라이언트가 요청한 데이터에 대한 응답(서버 -> 클라이언트)
- Start Line : protocol version, status code, status text
- Response Header : Response 정보
- Response Body : 실제 응답 데이터
HTTP Response(Start Line)
- Version : 프로토콜 버전
- Status Code : 요청의 성공 여부
- Phrase : 상태코드에 대한 설명을 글로 표현하여 HTTP Message 이해 시 도움을 줌
HTTP Response(Header)
- 서버의 응답에 대한 부가적인 정보
- Header Field
- Connection : 현재의 전송이 완료된 후 네트워크 접속 여부
- Keep-Alive : 송신자가 연결에 대한 타임아웃과 요청 최대 개수
HTTP Response(Body)
- 실제 응답 데이터
HTTP Response(Status Code)
구분 | 내용 | |
1XX(Information) | 요청을 받으면 기존 작업 처리 계속 진행 | |
2XX(Successful) | 요청을 성공적으로 받음 | |
3XX(Redirect) | 요청 완료를 위해 추가적인 동작 수행 | |
4XX(Client Error) | 400(Bad Request) | 요청 메시지의 문법 오류 |
403(Forbidden) | 클라이언트 요청에 대한 접근 차단 | |
404(Not Found) | 클라이언트가 서버에 요청한 자료가 존재하지 않음 | |
5XX(Server Error) | 서버가 유효한 요청에 대한 작업 수행 불가 |
HTTPS(HyperText Transfer Protocol over Secure Socket Layer)
- 클라이언트/서버 환경에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜
- 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장
SSL 인증서 발급 과정
SSL 인증서 발급 과정을 서버와 CA(Certificate Authority)를 중심으로 간단하게 설명하면 다음과 같습니다.
1. 키 쌍 생성 (서버 측)
- 비공개 키 (Private Key) 생성: 서버는 비공개 키를 생성합니다. 이 키는 서버에 안전하게 저장되며 절대 외부로 유출되지 않습니다.
- 공개 키 (Public Key) 생성: 비공개 키와 쌍을 이루는 공개 키를 생성합니다. 이 공개 키는 나중에 SSL 인증서에 포함됩니다.
2. CSR (Certificate Signing Request) 생성 (서버 측)
- CSR 생성: 서버는 공개 키와 함께 도메인 정보, 조직 정보 등을 포함한 CSR을 생성합니다. 이 CSR은 CA에게 제출됩니다.
3. CSR 제출 (서버 → CA)
- CSR 제출: 서버 관리자는 생성한 CSR을 CA에 제출합니다. 이 과정은 CA의 웹사이트나 API를 통해 이루어집니다.
4. 검증 (CA 측)
- 도메인 검증: CA는 서버가 소유하고 있는 도메인이 CSR에 명시된 도메인과 일치하는지 확인합니다. 이는 이메일 확인, DNS 레코드 추가, 또는 웹 서버에 파일 업로드 등의 방법을 통해 이루어집니다.
- 조직 검증 (필요시): 특정 인증서 종류(OV 또는 EV)의 경우, CA는 추가로 조직의 존재를 검증합니다. 이 과정은 조직의 법적 서류를 확인하거나 전화 통화를 통해 이루어질 수 있습니다.
5. 인증서 발급 (CA 측)
- 인증서 생성: 검증이 완료되면, CA는 서버의 공개 키와 도메인/조직 정보를 사용하여 SSL 인증서를 생성합니다.
- 인증서 발급: 생성된 SSL 인증서를 서버에 발급합니다.
6. SSL 인증서 설치 (서버 측)
- 인증서 설치: 서버 관리자는 CA로부터 받은 SSL 인증서를 서버에 설치합니다. 이 과정에서 인증서 파일과 CA 번들 파일을 서버 설정에 추가합니다.
- 서버 구성: 서버 설정 파일을 수정하여 SSL/TLS가 활성화되도록 합니다. 예를 들어, HTTPS를 통해 접속을 허용하고 적절한 포트(보통 443)를 사용하도록 설정합니다.
7. SSL 설정 테스트 (서버 측)
- 테스트 및 확인: SSL 인증서가 올바르게 설치되었는지 확인합니다. 이는 웹 브라우저에서 확인하거나 온라인 SSL 도구를 사용하여 테스트할 수 있습니다.
요약
- 서버: 비공개 키와 공개 키를 생성하고, CSR을 만들어 CA에 제출합니다.
- CA: 도메인과 조직을 검증한 후, 서버의 공개 키를 포함한 SSL 인증서를 발급합니다.
- 서버: CA로부터 받은 SSL 인증서를 설치하고, SSL/TLS 설정을 완료합니다.
Proxy
원격 프록시
- 외부에 프록시 서버가 존재
- 클라이언트의 IP 주소를 숨기는 것이 가능
로컬 프록시
- 클라이언트 PC 내에 설치
- 클라이언트와 서버 간의 HTTP 통신을 분석 및 변조할 때 사용 가능
Reference
- 케이쉴드주니어_공통과정_웹 해킹 강의자료
- https://ohcodingdiary.tistory.com/5
- https://joshua1988.github.io/web-development/http-part1/
- https://ko.wikipedia.org/wiki/%EA%B3%B5%EA%B0%9C_%ED%94%84%EB%A1%9D%EC%8B%9C
'K-Shield.Jr' 카테고리의 다른 글
[취약점분석] Integer Overflow, Uninitialized(시스템 해킹 실습 2일차) (0) | 2024.07.18 |
---|---|
[공통과정] 웹 해킹 (1) | 2024.07.15 |
[공통과정] 네트워크 해킹/스니핑(Sniffing)(feat. Spoofing) (1) | 2024.07.14 |
[공통과정] 네트워크 해킹/DoS(Denial of Service) (5) | 2024.07.14 |
[공통과정] 네트워크 해킹/스캐닝(Scanning) (1) | 2024.07.14 |