안녕하세요 !
이번 글에서는 웹 보안에서 웹과 HTTP의 이해에 대해서 글을 써보려고 합니다.
웹이란 ? 웹은 인터넷 위에서 동작하는 서비스 중 하나입니다. 인터넷을 통해서 사람들이 정보를 주고 받을 수 있도록 만든 시스템 입니다. 웹은 전 세계적으로 연결된 하이퍼텍스트 문서로 구성되어 있으며, 이 문서들은 브라우저를 통해서 사용자에게 보여집니다.
1. HTTP 프로토콜
웹에서는 HTTP, SMTP, POP, FTP, Telnet 등 여러 프로토콜이 쓰입니다. 그중에서도 가장 흔히 쓰이는 프로토콜은 HTTP 입니다. HTTP 를 이용하면 다양한 응용 프로그램에 접근해서 텍스트, 그래픽, 애니메이션을 보거나 사운드를 재생할 수 있습니다.
클라이언트가 웹 브라우저를 이용해서 서버에 연결을 요청하면 서버는 클라이언트에 대해서 서비스를 준비한다.
그래서 서버가 준비가 되면 클라이언트는 읽고자 하는 문서를 서버에 요청한다. 서버는 웹 문서 중에서 요청받은 것을 클라이언트에 전송하고 연결을 끊는다.
그래서 HTTP는 클라이언트 ( 보통 웹 브라우저 ) 와 서버 간에 데이터를 주고받는 규칙 ( 프로토콜 ) 입니다. 웹 브라우저가 서버에 웹 페이지를 요청하면 HTTP를 통해서 요청 ( Request ) 가 전송되고 서버는 이 요청을 받아서 해당 웹 페이지를 브라우저에 응답 ( Response ) 으로 보내줍니다.
1) HTTP 의 주요 개념 :
- 클라이언트 : 웹 브라우저처럼 서버에 요청을 보내는 주체입니다.
- 서버 : 요청을 받아들이고 처리해서 응답을 반환하는 주체입니다.
- 요청 ( Request ) : 클라이언트가 서버에게 특정 리소스를 요청하는 메시지입니다. 주로 GET, POST, PUT, DELETE 등의 HTTP 메서드가 사용된다.
GET : 데이터를 서버에서 가져올 때 사용된다. 웹 페이지를 요청할 떄 많이 사용된다.
POST : 서버에서 데이터를 전송할 때 사용된다.
- 응답 ( Response ) : 서버가 클라이언트의 요청에 대해 보내는 데이터 입니다. 응답에는 상태 코드가 포함되어 있습니다. 요청이 성공했는지 실패했는지 알려줍니다.
- 상태 코드 예시 :
200 ok : 요청이 성공적으로 처리되었음을 의미합니다.
404 Not Found : 요청한 리소스를 찾을 수 없음을 의미한다.
500 Internal Server Error : 서버 내부에서 문제가 발생했음을 의미합니다.
2. HTTP 의 작동 원리
HTTP 는 클라이언트 - 서버 모델을 기반으로 동작합니다.
1) 사용자가 웹 브라우저에서 특정 웹 페이지의 URL 을 입력하면 브라우저는 그 URL 을 통해서 서버에 HTTP 요청을 보냅니다.
2. 서버는 요청을 받아서 그에 맞는 웹 페이지나 리소스를 찾고, 이것을 HTTP 응답으로 브라우저에 전송합니다.
3. 브라우저는 서버에서 받은 응답 ( HTML, 이미지, CSS 파일 등 ) 사용자가 볼 수 있는 형태로 렌더링 합니다.
3. HTTP 와 HTTPS 의 차이
HTTPS 는 HTTP에 SSL / TLS 암호화를 추가한 프로토콜로 데이터를 안전하게 전송할 수 있도록 보호해줍니다. 즉, HTTP는 데이터를 암호화하지 않고 전송하는 반면, HTTPS는 데이터를 암호화하여서 클라이언트와 서버 간의 통신을 보호합니다. 웹 페이지 URL이 "https://" 로 시작하면 해당 사이트는 HTTPS 를 사용하고 있다는 의미입니다.
4. 웹과 HTTP의 중요성
- 웹의 연결성 : 웹은 전 세계적으로 연결된 정보의 네트워크로 하이퍼텍스트와 HTTP 프로토콜 덕분에 사람들이 어디에서나 정보를 쉽게 찾고 탐색할 수 있게 합니다.
- HTTP 의 유연성 : HTTP는 웹 상에서 문서뿐만 아니라 이미지, 동영상, API 등을 주고 받는 중요한 역할을 한다. 현대 웹 애플리케이션의 기반이 된다.
5. GET 방식
GET 방식은 가장 일반적인 HTTP Request 형태로 다음과 같은 요청 데이터의 인수를 웹 브라우저의 URL 을 통해서 전송한다. GET 방식의 경우 각각의 이름과 값을 &로 결합하고 글자 수는 255자로 제한한다. 메신저로 받은 URL 을 클릭하면 특정 웹 페이지를 똑같이 확인할 수 있는데 이것은 GET 방식이 사용된 예시이다.
1) GET 방식의 특징
- 데이터 전송 위치 : GET 방식은 데이터를 URL 의 쿼리 문자열에 포함해서 서버로 전송한다. 예를 들자면 https://example.com/search?query=apple 에서 query=apple 은 서버에 전송되는 데이터이다. 이 데이터는 URL 끝에 ? 로 시작하는 쿼리 매개변수 형태로 추가됩니다.
- URL 의 길이 제한 : GET 방식은 URL 을 통해서 데이터를 전송하는데 URL 의 길이에 제한이 있다. 이 제한은 브라우저와 서버에 따라서 다르지만, 일반적으로 2048자 정도로 제한합니다. 따라서, 많은 양의 데이터를 GET 방식으로 전송하는 것은 적합하지 않습니다.
- 캐싱 : GET 요청은 보통 브라우저에서 캐시할 수 있습니다. 즉, 동일한 GET 요청을 여러 번 하면 서버에 다시 요청하지 않고 캐시에 저장된 데이터를 가져올 수 있습니다, 캐시 덕분에 GET 요청은 반복되는 요청에 대해 성능이 향상 될 수 있습니다.
- 안전성과 멱등성 :
안전성은 GET 요청은 서버의 상태를 변경하지 않는 안전한 요청으로 간주됩니다. 서버에서 데이터를 가져오기만 하고 수정하거나 삭제하지 않기 때문에 안전합니다.
멱등성은 GET 요청은 몇 번을 반복해서 호출하더라도 결과가 동일해야 합니다. 예를 들어, 동일한 페이지에 대해 여러 번 GET 요청을 보내도 항상 같은 데이터를 반환합니다.
- 북마크 기능 : GET 방식으로 요청된 UEL은 브라우저에서 쉽게 북마크할 수 있다.
8. GET 요청의 구조
GET /path/resource?param1=value1¶m2=value2 HTTP/1.1
Host: http://www.example.com
User- Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36
Accept: text/html
이 예시를 들어보겠습니다.
- GET : 요청 방식을 나타낸다.
/path/resource?param1=value1¶m2=value2 : 이 부분은 요청할 리소스와 쿼리 문자열이다. 이 부분에 서버가 처리할 데이터가 포함됩니다.
- HTTP/1.1: 사용 중인 HTTP 프로토콜 버전을 나타냅니다.
- Host : 요청할 서버의 호스트 이름입니다.
- User-Agent : 클라이언트 ( 웹 브라우저 ) 의 정보이다.
- Accept : 클라이언트가 응답에서 수락할 수 있는 콘텐츠 유형을 지정합니다.
9. GET 방식의 장단점
1) 장점 :
- 빠름 : GET 요청은 캐싱이 가능하고 서버의 상태를 변경하지 않으므로 빠른 처리와 응답을 보장할 수 있습니다.
- 단순함 : URL 에 데이터를 포함하므로 요청의 구믄이 단순하고 명확합니다.
- 북마크 및 공유 가능 : GET 요청은 URL에 데이터를 포함하므로 쉽게 북마크 할 수 있고 다른 사람과 공유할 수 있습니다.
2) 단점 :
- 보안 문제 : URL에 데이터가 포함되기 때문에 중요한 정보를 GET 방식으로 전송하는 것은 보안상 문제가 될 수 있다. 예를 들자면, 비밀번호나 개인 정보는 GET 요청을 통해서 보내지 않는 것이 좋습니다. UEL 은 브라우저 히스토리, 서버 로그에 남을 수 있기 때문입니다.
- 데이터 양 제한 : URL 에 전송할 수 있는 데이터 양에 제한이 있어서 많은 데이터를 전송해야 하는 경우 GET 방식은 적합하지 않습니다.
10. GET 방식의 적절한 사용 사례
- 데이터를 조회하는 요청 ( EX : 웹 페이지 로드, 검색 결과 표시 )
- 서버의 상태를 변경하지 않는 안전한 요청이다.
- URL 에 매개변수를 추가해도 문제가 없는 요청
- 데이터를 캐싱해도 괜찮은 요청
GET 방식에 대해서 간단하게 글을 써보았습니다. 중요한 정보를 전달할 때는 POST 방식을 사용하는 것이 좋습니다. POST 방식은 GET과 다르게 데이터를 본문 ( body ) 에 포함하므로 URL에 민감한 정보를 노출시키지 않기 때문이다.
이처럼 GET 방식으로 주로 데이터를 조회하고 서버 상태를 변경하지 않는 요청에서 주로 사용이 됩니다.
11. POST 방식
POST 방식은 URL 에 요청 데이터를 기록하지 않고 HTTP 헤더에 데이터를 전송하기 때문에 GET 방식의 쿼리 부분 같은 부분이 존재하지 않는다. POST 방식은 내부의 구분자가 파라미터를 구분하고 서버가 각 구분자에 대한 내용을 해석하여 데이터를 처리하기 때문에 GET 방식에 비해 처리 속도가 상대적으로 느리다. POST 방식에서는 인수 값을 URL 을 통해 전송하지 않기 때문에 다른 사용자가 링크를 통해서 해당 페이지를 볼 수 없다.
게시판 등에서 파일 업로드는 POST 방식으로만 할 수 있다. 이것은 GET 방식과 다르게 보내려는 데이터가 URL 노출되지 않기 때문에 최소한의 보안성은 갖추고 있다. 일반적으로 게시판의 목록이나 글 보기 화면은 접근 자유도를 부여하기 위해서 GET 방식을 사용하고 게시글을 저장, 수정, 삭제하거나 대용량 데이터를 전송할 때는 POST 방식을 사용한다.
POST 방식은 HTTP 요청 방식 중 하나로 서버에 데이터를 전송하여서 서버 측에서 처리하게 할 때 사용된다. 주로 데이터 생성, 수정, 삭제와 같은 작업을 수행할 때 사용된다.
GET 방식과는 다르게 POST 방식은 데이터를 URL 이 아닌 HTTP 본문 ( body ) 에 포함하여서 전송한다. 이것을 통해서 URL 에 민감한 정보를 포함하지 않고 데이터를 전송할 수 있습니다.
12. POST 방식의 특징
- 데이터 전송 위치 : POST 요청은 데이터를 HTTP 요청의 본문에 포하하여 서버로 전송합니다. 이 때문에 GET 방식과 다르게 URL 에 데이터가 표시되지 않으며, 긴 양의 데이터를 전송할 수 있습니다.
1) URL 길이 제한 없음
POST 방식은 데이터를 URL 이 아닌 본문에 담기 때문에, URL길이의 제한이 없고 많은 양의 데이터를 전송할 수 있습니다.
2) 캐싱하지 않음
POST 요청은 일반적으로 캐시되지 않습니다. 서버에 데이터를 생성하거나 변경하는 작업이므로, 동일한 요청을 반복하더라도 서버에 매번 새로운 요청이 전달된다.
3) 보안성
POST 방식은 URL 에 데이터를 포함하지 않기 때문에 상대적으로 GET 방식보다 보안성이 높다. 예를 들어서 로그인 폼에서 사용자의 아이디와 비밀번호와 같은 민감한 정보를 전송할 때 POST 방식을 사용하는 것이 더 안전합니다. 그러나 본문에 포함된 데이터 역시 네트워크에서 암호화 되지 않는다면 안전하지 않으므로 보안이 중요한 경우 HTTPS 와 함께 사용햐야 합니다.
4) 서버의 상태 변경
POST 요청은 주로 서버의 상태를 변경하는데 사용된다. 새로운 리소스를 생성하거나 데이터를 수정할 때 사용된다. 서버에 영향을 미치는 작업을 수행할 수 있습니다.
13. POST 방식의 사용 예시
POST 방식은 서버의 데이터베이스나 파일 시스템에 변경을 일으키는 작업에 사용된다.
- 폼 데이터 제출 : 로그인, 회원 가입, 파일 업로드 등의 작업에서 사용자가 입력한 데이터를 서버로 전송할 때 POST 요청이 사용된다. 예를 들어서 사용자가 로그인 폼에 아이디와 비밀번호를 입력하면, 이 정보는 POST 방식으로 서버에 전송되어서 서버가 인증 작업을 수행합니다.
- API 요청 : RESTful API 에서 리소스를 생성하거나 업데이트를 할 때, ,POST 요청이 많이 사용된다. 예를 들어서 새로운 계정을 생성할 때 POST 요청을 통해서 해당 사용자 정보를 서버에 전소앟여서 서버에서 해당 계정을 생성합니다.
- 파일 업로드 : 파일을 업로드할 때, POST 요청의 본문에 파일 데이터를 포함시켜서 서버로 전송한다. GET 방식은 URL 에 데이터를 포함하는 구조상 파일 전송이 불가능하지만, POST 방식은 본문에 데이터를 담기 때문에 파일을 전송할 수 있다.
14. POST 요청의 구조
POST /path/resource HTTP/1.1
Host: http://www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
param1=value1¶m2=value2
예시를 들어보겠습니다.
- POST : HTTP 요청 방식을 나타냅니다.
- /path/resource : 서버에서 처리할 리소스의 경로입니다.
- HTTP/ 1.1 : 사용 중인 HTTP 프로토콜 버전을 나타냅니다.
- Host : 요청하는 서버의 호스트 이름입니다.
- Content-Type : 서버에 전송되는 데이터의 유형을 지정합니다. 이 예시에서는 application/x-www-form-urlencoded 로 폼 데이터를 인코딩하여서 전송하는 경우 사용됩니다.
- Content-Length : 전송되는 본문 데이터의 길이를 나타냅니다.
- 본문 ( Body ) 내용 : param1=value1¶m2=value2 형태로 실제로 서버에 전송될 데이터가 본문에 포함됩니다.
15. POST 방식의 장단점
1) 장점 :
- 보안성이 높음 : GET 방식은 URL에 데이터를 포함하므로 보안에 취약할 수 있지만, POST 방식은 데이터를 본문에 포함하므로 상대적으로 보안성이 높다. 중요한 정보를 다룰 때 특히, POST 방식이 선호된다.
- 많은 양의 데이터 전송 가능 : POST 방식은 URL 의 길이 제한이 없으므로, 많은 양의 데이터를 전송할 수 있다. 대용량 데이터, 파일 업로드 등에 적합합니다.
- 서버에 변경을 일으킬 수 있음 : POST 방식은 서버에서 데이터를 생성하거나 수정할 때 사용됩니다. 데이터베이스에 변화를 일으킬 수 있습니다.
2) 단점 :
- 캐싱되지 않음 : POST 요청은 일반적으로 캐싱되지 않으므로, 자주 반복되는 요청을 처리할 때 효율적이지 않을 수 있습니다.
- 복합한 처리 과정 : POST 요청은 GET 요청에 비해서 처리 과정이 다소 복잡할 수 있습니다. 서버는 본문을 파싱해야 하고 데이터 전송 형식에 맞춰서 처리해야 하기 때문입니다.
16. POST 방식의 적절한 사용 사례
1) 서버의 상태를 변경할 떄 : 데이터를 생성하거나 수정하는 작업에서는 POST 방식이 필요하다.
2) 대량의 데이터를 전송할 때 : POST 방식은 URL 길이 제한이 없으므로 많은 데이터를 전송할 수 있다.
3) 민감한 정보를 다룰 떄 : 로그인 정보나 결제 정보 등 중요한 데이터를 서버로 전송할 때는 POST 방식과 HTTPS 를 함꼐 사용하는 것이 적합합니다.
17. GET 방식과 POST 방식의 비교
| 특징 | GET | POST |
| 데이터 전송 위치 | URL 쿼리 스트링에 포함이 되어 있음. | 본문에 포함 되어 있음. |
| 데이터 양 | 제한적 ( URL 길이가 제한이 있음 . ) | 제한 없음. ( 많은 양의 데이터 전송이 가능하다. ) |
| 보안성 | 보안에 취약 ( URL에 데이터 포함됨. ) | 상대적으로 보안이 높다. |
| 캐싱 | 캐싱 가능 | 캐싱 되지 않음. |
| 서버 상태 변경 | 서버의 상태를 변경하지 않음 ( 조회 목적임. ) | 서버의 상태를 변경함. ( 데이터 생성, 수정 ) |
| 사용 예시 | 검색, 조회, 단순 데이터 요청 | 로그인, 회원 가입, 파일 업로드 |
정리하자면 POST 방식은 서버와 상호 작용할 때 데이터를 안전하게 전송하고 서버의 상태를 변경하는 작업을 수행하는데 매우 중요한 역할을 합니다. 이것을 통해 대량의 데이터나 중요한 정보를 전송할 수 있습니다. 서버와 클라이언트 간의 복잡한 상호 작용을 지원하는 중요한 HTTP 메서드 입니다.
18. HTTP Response
HTTP Response 는 클라이언트의 HTTP Request 에 대한 응답 패킷입니다. 서버에서 쓰이는 프로토콜 버전, Request 에 대한 실행 결과 코드 및 간략한 실행 결과 설명문에 대한 내용이 담겨져 있습니다. 전달할 데이터의 형식, 길이 등과 같은 추가 정보가 MIME 형식으로 표현되어 있으며 헤더 정보 뒤에는 실제 데이터가 전달됩니다. 데이터 전달이 끝나면 서버는 연결을 끊는다. HTTP Response 의 주요 실행 결과 코드를 정리할 수 있다.
- HTTP Response 의 주요 실행 결과 코드
| 실행 결과 코드 | 내용 | 설명 |
| 100번대 | 정보 전송 | HTTP 1.0까지는 계열에 대한 정의가 이루어지지 않았기 때문에 실험 용도 외에는 100번대 서버 측의 응답이 없다. |
| 200번대 | 성공 | 클라이언트의 요구가 성공적으로 수신 및 처리되었음을 의미합니다. |
| 300번대 | 리다이렉션 | 해당 요구 사항을 처리하기 위해서 사용자 에이전트가 수행해야 할 추가 동작이 있음을 의미합니다. |
| 400번대 | 클라이언트 측 에러 | 클라이언트에 오류가 발생했을 때 사용합니다. 예를 들자면, 클라이언트가 서버에 보내는 요구 메시지를 완전히 처리하지 못한 경우 입니다. |
| 500번대 | 서버 측 에러 | 서버 자체에서 발생한 오류 상황이나 요구 상황을 제대로 처리할 수 없을 때 사용합니다. |
끝