# The HTTP Protocol - HTTP là giao thức truyền thông cốt lỗi được sử dụng để truy cập World Wide Web và được tất cả các ứng dụng web ngày nay sử dụng. - HTTP sử dụng mô hình máy khách(client) gửi yêu cầu (request) đến máy chủ (server) để trả về phản hồi (response). Về bản chất HTTP là không kết nối (connectionless)-không nhớ trạng thái giao dịch trước đó. - Bản thân HTTP không nhớ trạng thái giao dịch trước đó (sau khi request/response TCP có thể bị đóng và một TCP mới sẽ được mở vào lần request tiếp theo) - Nhược điểm server không tự nhớ người dùng cần có `Cookie`, `Session`, `Token` để quản lý phiên làm việc. - HTTP sử dụng TCP làm cơ chế truyền tải, những mỗi lần request-response là một giao dịch độc lập và lần request tiếp theo HTTP sử dụng một TCP khác. - HTTP là giao thức tầng ứng dụng -> trao đổi thông tin(request/response) giữa `Client-Server` - HTTP/1.0: mỗi request/response là một TCP riêng biệt -> rất tốn tài nguyên. - HTTP/1.1: hỗ trợ persistent connection (keep - alive) nhiều request có thể dùng lại nhiều TCP. - TCP(transmission control protocol) là giao thức tầng vận chuyển -> đảm bảo dữ liệu truyền đi an toàn, đúng thứ tự, không mất mát. - Kết nối có trạng thái: tạo kết nối ổn định giữa `Client-Server`. - Đảm bảo độ tin cậy: gói tin đến nơi phải đúng, đủ. - Ba bước bắt tay(3-way handshake): thiết lập kết nối `SYN -> SYN-ACK -> ACK`. # HTTP Request - HTTP Request bao gồm một hoặc nhiều header, mỗi header nằm trên một dòng riêng; một dòng trống bắt buộc (blank line); và body (tùy chọn). - Dòng đầu tiên được gọi là request line(start-line) `<Method> <Request URI> <http-version>` VD: `GET /auth/488/YourDetails.ashx?uid=129 HTTP/1.1` - Phương thức `GET` được sử dụng phổ biến nhất, có chức năng truy xuất một tài nguyên từ máy chủ web, GET request không có phần thân nên sẽ không có dữ liệu nào theo sau blank line. - The requested url thường đóng vai trò như tên của tài nguyên được yêu cầu kèm theo chuỗi truy vấn(query string) tùy chọn chứa các tham số mà client truyền cho tài nguyên đó. Query string bắt đầu bằng kí tự ? trong url(tham số uid có giá trị 129 trong ví dụ) - `HTTP-Version`: HTTP/1.0 và HTTP/1.1 còn được sử dụng rộng rãi trên internet và hầu hết web hiện nay mặc định HTTP/1.1. Điểm khác biệt của hai phiên bản thường gặp khi tấn công web là HTTP/1.1 có header host là bắt buộc. - Header `Referer`: được dùng để chỉ ra url để yêu cầu được gửi đi. - Header `User-Agent`: cung cấp thông tin về client đã gửi yêu cầu.(đa số các web đều thêm tiền tố Mozilla) - Header `Host`: xác định tên miền(hostname) xuất hiện trong url mà client muốn truy cập. Header host bắt buộc trong HTTP/1.1 để có thể chạy nhiều web trên một server. - Header `Cookie`: dùng để gửi lại cho server các tham số bổ sung mà server đã cấp cho client trước đó để duy trì trạng thái(state) giữa nhiều request độc lập(một cơ chế quan trọng). ``` GET /auth/488/YourDetails.ashx?uid=129 HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwaveflash, */* Referer: https://mdsec.net/auth/488/Home.ashx Accept-Language: en-GB User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E; FDM; .NET CLR 1.1.4322) Accept-Encoding: gzip, deflate Host: mdsec.net Connection: Keep-Alive Cookie: SessionId=5B70C71F3FD4968935CDB6682E545476 ``` # HTTP Responese ## Cấu trúc dòng đầu tiên của response - Dòng đầu tiên (status line) gồm 3 phần, cách nhau bởi đấu cách: - Phiên bản HTTP đang được sử dụng. - Mã trạng thái (status code) là một số thể hiện kết quả của response - `200` là mã phổ biến nhất, nghĩa là response thành công và tài nguyên được trả về. - Cụm từ mô tả (reason phrase) mô tả ngắn gọn về trạng thái phản hồi (chỉ mang tính chất hiển thị, các web hiện nay không dùng để xử lý logic). ## Một số điểm đáng chú ý trong phản hồi - `Server` header: chứa thông tin phần mềm máy chủ đang được sử dụng (Microsoft-IIS/6.0), đôi khi kèm chi tiết như hệ điều hành hoặc module cài đặt những thông tin này có thể không đúng vì server có thể ẩn hoặc giả. - `Set-Cookie` header: dùng để gửi cookie mới từ server về trình duyệt. Trình duyệt sẽ lưu `cookie` và tự động gửi trong header `cookie` của các request tiếp theo trên cùng máy chủ. - Trình duyệt gửi yêu cầu đầu tiên → chưa có `Cookie`. - Server phản hồi và gửi cookie qua header `Set-Cookie`. - Trình duyệt lưu cookie đó lại (gắn với `Domain`, `Path`, thời gian sống...). - Từ các request sau, trình duyệt tự động gửi cookie trở lại server qua header `Cookie`. - Server dùng cookie để nhận biết người dùng hoặc duy trì phiên đăng nhập (`Session`). - `Pragma` và `Expires` headers: - `Pragma: no-cache` yêu cầu trình duyệt không lưu phản hồi này vào bộ nhớ đệm (cache). - `Expires: thu, 01 jan 1970 00:00:00 GMT` cho biết nội dung đã hết hạn trong quá khứ nên không được cache. - -> hai header thường được dùng cho nội dung động (dynamic content) để đảm bảo trình duyệt luôn tải phiên bản mới nhất. - `Contnet-Type` header: cho biết định dạng nội dung trong body của phản hồi. - `Content-Type: text/html; charset=utf-8`. - -> body chứa tài liệu HTML và được mã hóa `utf-8`. - `Content-Length` header: xác định độ dài ( số byte) của phần thân phản hồi, trình duyệt dùng thông tin này để biết khi nào dữ liệu kết thúc. ``` HTTP/1.1 200 OK Date: Tue, 19 Apr 2011 09:23:32 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc X-AspNet-Version: 2.0.50727 Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1067 <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http:// www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”><html xmlns=”http:// www.w3.org/1999/xhtml” ><head><title>Your details</title> ... ``` >[!Note] >Hầu như tất cả phản hồi HTTP đều có body - nội dung thật mà server trả về (HTML, JSON, hình ảnh,...) và nó nằm sau dòng trống kết thúc header. >``` > Status line → Phiên bản + Mã trạng thái + Mô tả > Headers → Thông tin điều khiển, cookie, cache, định dạng dữ liệu > (blank line) → Dấu hiệu kết thúc phần headers > Body → Nội dung thực tế (HTML, JSON, hình ảnh…) # HTTP Methods - Khi tấn công ứng dụng web, gần như chỉ kàm việc với hai phương thức được dùng phổ biến nhất `GET`, `POST`. ## GET - Được thiết kế để truy xuất tài nguyên. - Gửi tham số tới tài nguyên thông qua chuỗi truy vấn (query string) trong `URL`. - Giúp người dùng đánh dấu (bookmark) một `URL` cho tài nguyên động để tái sử dụng sau này hoặc người dùng khác có thể truy xuất tài nguyên tương đương vào lần sau. - `URL` được hiển thị trên màn hình và được ghi lại ở nhiều nơi như lịch sử trình duyệt và log truy cập của máy chủ web, chúng cũng được gửi trong header `Referer` đến các trang khác khi người dùng bấm liên kết ngoài. >[!Warning] >Vì những lý do trên, không nên dùng query string để truyền thông tin nhạy cảm. - Ví dụ: - GET Request: ``` GET /search?q=iphone&page=2 HTTP/1.1 Host: example.com User-Agent: MyClient/1.0 Accept: text/html Connection: close ``` - GET Response: ``` HTTP/1.1 200 OK Date: Wed, 08 Oct 2025 10:00:00 GMT Server: nginx/1.24.0 Content-Type: text/html; charset=utf-8 Content-Length: 37 <html><body>Hello World</body></html> ``` - `content-length: 37` cho biết số byte của phần thân. - Trình duyệt sẽ dùng header và phần thân để hiển thị trang. ## POST - Được thiết kế để thực hiện hành động. - Có thể gửi tham số cả trong `query string` của `URL` và trong body của thông điệp. - `URL` vẫn được bookmark như bên `GET`, nhưng body sẽ không nằm trong bookmark và đồng thời cũng sẽ không lưu trong log URL hay header `Referer`. Vì `POST` được dùng để thực hiện hành động. - Nếu người dùng quay lại một trang đã truy cập bằng `POST`, trình duyệt không tự động gửi lại yêu cầu thay vào đó nó cảnh báo người dùng về hành động sắp thực hiện, giúp ngăn người dùng vô tình thực hiện hành động nhiều lần. >[!Note] >Vì vậy nên luôn dùng `POST` cho những thao tác gây tác động (actions). - Ví dụ: - POST Request: ``` POST /submit HTTP/1.1 Host: example.com User-Agent: MyClient/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 23 status=ok&message=Saved ``` - POST Response: ``` HTTP/1.1 200 OK Date: Wed, 08 Oct 2025 10:01:00 GMT Server: example-server/1.2 Content-Type: application/json; charset=utf-8 Content-Length: 25 {"result":"ok","id":123} ``` - Server trả JSON xác nhận; `content-length` là kích thước của body JSON. - Thay vì 200 ok, server cũng có thể tar `201 created` (nếu tạo tài nguyên mới) hoặc `302 found/303 see other` ## Ngoài `GET` và `POST`, HTTP còn hỗ trợ nhiều `Methods` khác được tạo cho những mục đích cụ thể. ### HEAD - `HEAD` hoạt động giống như `GET`, ngoại trừ Server không trả về phần thân trong phản hồi. - Không trả phần thân trong phản hồi vì server cần cung cấp thông tin về tài nguyên mà không phải truyền toàn bộ nội dung, giúp tiết kiệm băng thông và thời gian. - Ví dụ: - HEAD Request: ``` HEAD /images/logo.png HTTP/1.1 Host: example.com ``` - HEAD Response: ``` HTTP/1.1 200 OK Date: Wed, 08 Oct 2025 10:00:00 GMT Server: nginx/1.24.0 Content-Type: image/png Content-Length: 23456 Last-Modified: Tue, 07 Oct 2025 12:00:00 GMT Cache-Control: max-age=86400 ``` ### TRACE - Được thiết kế cho mục đích chẩn đoán. - Khi `Client` gửi một yêu cầu, theo đặc tả server nên phản hồi bằng chính xác nội dung `Request` mà nó nhận được (start-line và các header) trong body của `Response`, đồng thời trả status line và headers bình thường. - Mục đích cho phép: `Client` thấy `Request` "đã tới server trông như thế nào" sau khi đi qua các `proxy`/`gateway`/`ngăn xếp trung gian`. Nếu một `proxy` thay đổi `Request` (thêm/xóa/sửa header,mã hóa khác,..) `Client` sẽ phát hiện được nhờ nội dung trả về do `TRACE` - Gỡ lỗi khi nghi ngờ `request` bị thay đổi trên đường đi. - Xác thực hành vi của mạng/ứng dụng trong môi trường phát triển. - Ví dụ: - TRACE Request: ``` TRACE /some/path HTTP/1.1 Host: example.com User-Agent: MyTestClient/1.0 Cookie: session=ABC123; theme=dark X-Debug: probe ``` - TRACE Response: ``` HTTP/1.1 200 OK Date: Wed, 08 Oct 2025 10:00:00 GMT Server: example-server/1.2 Content-Type: message/http Content-Length: 123 TRACE /some/path HTTP/1.1 Host: example.com User-Agent: MyTestClient/1.0 Cookie: session=ABC123; theme=dark X-Debug: probe ``` ### OPTIONS - Yêu cầu server báo cáo các phương thức `HTTP` khả dụng cho một tài nguyên cụ thể. Thường server sẽ trả về header `Allow` liệt kê các phương thức được hỗ trợ. - Ví dụ: - OPTIONS Request: ``` OPTIONS /api/users HTTP/1.1 Host: example.com User-Agent: curl/8.0 ``` - OPTIONS Response: ``` HTTP/1.1 200 OK Date: Wed, 08 Oct 2025 10:15:00 GMT Allow: GET, POST, PUT, DELETE, OPTIONS Content-Length: 0 ``` - Với tài nguyên `api/users` được phép dùng 5 phương thức trên. ### PUT - `PUT` cố gắng tải lên tài nguyên được chỉ định lên server, dùng nội dung trong phần thân của `request`. Nếu phương thức này được bật, có thể bị lợi dụng để tấn công. - Ví dụ: - PUT Request: ``` PUT /uploads/shell.php HTTP/1.1 Host: example.com Content-Type: application/x-php Content-Length: 123 <?php system($_GET['cmd']); ?> ``` - PUT Response: ``` HTTP/1.1 201 Created Location: https://example.com/uploads/shell.php ``` - Nếu file được upload vào `webroot` và server thực thi `.php`, attacker có thể truy cập `https://example.com/uploads/shell.php?cmd=whoami` để chạy lệnh - web shell. ### DELETE - Khi client gửi request `DELETE` đến một URL cụ thể, nó yêu cầu server xóa tài nguyên tương ứng. - Ví dụ: - DELETE Request: ``` DELETE /api/users/42 HTTP/1.1 Host: example.com Authorization: Bearer abc123token Content-Type: application/json ``` - DELETE Response: ``` HTTP/1.1 204 No Content ``` - Xóa thành công, không có nội dung trả về. ``` HTTP/1.1 200 OK Content-Type: application/json { "message": "User deleted successfully", "deleted_id": 42 } ``` - Xóa thành công, có nội dung trả về. ``` HTTP/1.1 404 Not Found Content-Type: application/json { "error": "User not found" } ``` - Lỗi không tìm thấy. ### PATCH - Thực hiện partial update - chỉ thay đổi những trường/thuộc tính được chỉ định cảu tài nguyên, thay vì ghi đè toàn bộ như `PUT`. - Ví dụ: - PATCH Request: ``` PATCH /api/users/42 HTTP/1.1 Host: example.com Content-Type: application/merge-patch+json Content-Length: 37 Authorization: Bearer tokenxyz {"email":"new@example.com","name":"Thắng"} ``` - PATCH Response: ``` HTTP/1.1 200 OK Content-Type: application/json Content-Length: 85 { "id": 42, "name": "Thắng", "email": "new@example.com", "role": "user" } ``` ### CONNNECT - Thiết lập tinnel TCP thô qua một HTTP proxy tới một host và port đích. Sau khi tunnel được thiết lập, proxy chỉ chuyển byte giữa client-server, thường dùng để thiết lập kết nối HTTPS qua proxy. - Ví dụ: - Client -> Proxy: ``` CONNECT example.com:443 HTTP/1.1 Host: example.com:443 Proxy-Authorization: Basic base64credentials ``` - Proxy -> Client: ``` HTTP/1.1 200 Connection Established Proxy-Agent: my-proxy/1.0 [Tiếp theo là luồng TCP thô — client bắt đầu TLS handshake với example.com] ``` ## Bảng Tóm Tắt | Method | Mục đích chính | Idempotent | Safe | | ------- | ------------------------------- | ----------------- | ------ | | GET | Lấy tài nguyên | Có | Có | | HEAD | Lấy header của tài nguyên | Có | Có | | POST | Gửi dữ liệu/thực hiện hành động | Không | Không | | PUT | Tạo/ghi đè tài nguyên | Có | Không | | DELETE | Xóa tài nguyên | Có | Không | | PATCH | Cập nhật một phần | Thường không | Không | | OPTIONS | Hỏi phương thức/CORS | Có | Có | | TRACE | Chẩn đoán (echo) | Có (nhưng rủi ro) | Vấn đề | | CONNECT | Tạo tunnel TCP | N/A | N/A | # URL (Uniform Resource Locator) - Là định danh của một tài nguyên web và dùng để truy xuất tài nguyên đó. ``` protocol://hostname[:port]/[path/]file[?param=value] ``` - Một vài thành phần trong định dạng trên có thể được bỏ qua như `port`, `path`, `file`, hoặc `?param=value`. - Số cổng (port) thường chỉ được ghi khi nó khác với cổng mặc định của giao thức đang được sử dụng. - Ví dụ: - HTTP mặc định là cổng 80 - HTTPS mặc định là cổng 443 &rarr; Nếu sửu dụng HTTP thì không cần ghi 80 - Dạng tuyệt đối (absolute) có đầy đủ địa chỉ -> có thể dẫn đến bất kì web nào. ``` https://mdsec.net/auth/488/YourDetails.ashx?uid=129 ``` - Ngoài ra còn có dạng tương đối (ralative) so với một host cụ thể hoặc một đường dẫn cụ thể trên host đó. Chỉ hoạt động được trong một trang web do thiếu địa chỉ ``` /auth/488/YourDetails.ashx?uid=129 ``` ``` YourDetails.ashx?uid=129 ``` >[!note] >URL là con của URI. >URI có thể định danh bất kì tài nguyên nào. # HTTP Headers ## General Header - Là các header mô tả cách dữu liệu được truyền đi và xửu lý, không phụ thuộc vào request/response. ### Connection - Cho biết kết nối TCP sau khi truyền dữ liệu đang được đóng hay mở. - `Connection: keep-alive` -> mở. - `Connection: close` -> đóng. -HTTP/1.1 mặc định là mở. ### Content-Encoding - Chỉ ra kiểu mã hóa áp dụng lên nội dung trong body. ``` Content-Encoding: gzip ``` ### Content-Length - Chỉ ra độ dài (byte) của nội dung trong body -> khi nào kết thúc dữ liệu. ``` Content-Length: 1024 ``` ### Content-Type - Xác định kiểu dữ liệu trong body. ``` Content-Type: text/html ``` ### Tranfer-Encoding - Chỉ ra kiểu mã hóa được áp dụng khi truyền body qua HTTP. Thường được dùng để mã hóa dạng chunked (chia nhỏ từng khối). ``` Tranfer-Encoding: chunked ``` ## Request Headers ### Accept - Cho server biết kiểu nội dung mà client chấp nhận. ### Accpet-Encoding - Cho server biết kiểu mã hóa nội dung mà client có thể xử lý được. ### Authorization - Gửi thông tin xác thực (credentials) đến server, dùng cho các cơ chế xác thực HTTP có sẵn như Basic Auth, Digest Auth, Bearer Token. ### Cookie - Gửi cookie đến server các giá trị mà server đã cấp cho client trước đó (duy trì phiên làm việc hay ghi nhớ trạng thái đăng nhập). ### Host - Chỉ định tên miền (hostname) xuất hiện tring URL đầy đủ mà client đang yêu cầu. ### If-None-Match - Gửi kèm entity tag (Etag) là một định danh duy nhất cho phiên bản của tài nguyên do server cấp. Giúp server biết tài nguyên có thay đổi không. ### If-Modified-Since - Chỉ ra thời điểm trình duyệt lần cuối nhận được tài nguyên được yêu cầu. Nếu tài nguyên chưa thay đổi server phản hồi để yêu cầu trình duyệt dùng bản cache cũ. ### Origin - Được dùng trong các yêu cầu Ajax giưuã các miền (croos-domain) để chỉ rõ tên miền gốc mà yêu cầu được gửi đi. Giúp server xác định nguồn gốc của request nhằm kiểm soát bảo mật CORS. ### Referer - Chỉ ra URL cảu trang web đã tạo ra yêu cầu hiện tại. ### User-Agent - Cung cấp thông tin về trình duyệt hoặc phần mềm client đang gửi yêu cầu. Để có thể tùy chỉnh phản hồi cho phù hợp với thiết bị hoặc ứng dụng. ## Response Header ### Access-Control-Allow-Origin - Chỉ định tên miền nào được phép truy cập tài nguyên thông qua yêu cầu Ajax giưuã các miền (cross-domain Ajax requests). Đây là thành phần cốt lỗi trong cơ chế CORS (Cross-Origin Resource Sharing) để kiểm soát bảo mật khi chia sẻ tài nguyên giưuã các website khác nhau. ### Cache-Control - Truyền các chỉ thị điều khiển bộ nhớ đệm (cache directives) cho trình duyệt. ### ETag - Chỉ định `entity tag` một mã định danh duy nhất cho phiên bản hiện tại của tài nguyên. Có thể gửi lại `ETag` trong các yêu cầu sau thông qua header `If-None-Match` để hỏi server xem tài nguyên có thay đổi không. ### Expires - Cho biết thời điểm hết hạn của nội dung trong phản hồi. ### Location - Được dùng trong các phản hồi chuyển hướng (redirection) những phản hồi có mã trạng thái bắt đầu bằng 3xx. Header này chỉ định URL mới mà client nên truy cập. ### Pragma - Cũng được dùng để truyền các chỉ thị cache cho trình duyệt tương tự như `Cache-Control`. ### Server - Cung cấp thông tin về phần mềm máy chủ web đang được sửu dụng. ### Set-Cookie - Dùng để gửi `cookie` mới từ server về cho trình duyệt. Sau đó, trình duyệt sẽ tự động gửi lại `cookie` này trong các yêu cầu tiếp theo uqa header `cookie`. ### WWW-Authenticate - Được dùng trong phản hồi có mã trạng thái `401 Unauthorized`. Header này thông báo cho client biết loại xác thực (authentication) mà server yêu cầu. ### X-Frame-Options - Quy định phản hồi hiện tại có được hiên thị trong thẻ `<iframe>` của trình duyệt không. Giúp ngăn chặn tấn công Clickjacking. # Cookie - `Cookie` là một phần quan trọng của giao thức HTTP mà hầu hết ứng dụng web dựa vào. - Chúng thường bị lợi dụng để khai thác lỗ hổng. - Cho phép server gửi dữ liệu tới client - client lưu và gửi lại cho server. - `Cookie` tự động được gửi lại trong mỗi request tiếp theo mà không cần hành động gì thêm từ ứng dụng hay người dùng. Server &rarr; Client ``` Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc ``` Client &rarr; Server ``` Cookie: tracking=tI8rk7joMx44S2Uu85nSWc ``` - Server có thể phát nhiều `cookie` bằng cách dùng nhiều header `set-cookie` trong phản hồi, trình duyệt sẽ gửi lại tất cả `cookie` đó lại trong một header `cookie` được ngăn cách bởi `;`. - `Set-Cookie` có thể kèm các thuộc tính sau để kiểm soát cách trình duyệt xử lý `cookie`: - `expires`: đặt ngày hết hạn. Được lưu vào bộ nhớ bền (persitent) và được tái sử dụng qua các phiên trình duyệt đến khi hết hạn, nếu không đặt `cookie` chỉ tồn tại trong phiên trình duyệt hiện tại. - `domain`: tên miền mà cookie hợp lệ cho nó. - `path`: đường dẫn URL mà cookie hợp lệ. - `secure`: cookie chỉ được gửi trong các request HTTPS. - `HttpOnly`: cookie không thể truy cập trực tiếp bằng JS phía client. >[!note] >Mỗi thuộc tính này đều ảnh hưởng đến bảo mật ứng dụng. # Status Codes - Mỗi HTTP response phải chứa status code ở dòng đầu tiên, cho biết kết quả của yêu cầu. - **Các mã trạng thái phổ biến** - 100 Continue: được gửi khi client gửi yêu cầu có phần body. - 200 ok: yêu cầu thành công. - 201 created: dùng cho `PUT` hoặc `POST` trong RESt API, thông báo tài nguyên đã được tạo thành công trên server. - 301 moved permanently: chuyển hướng vĩnh viễn đến URL mới. - 302 found: chuyển hướng tạm thời đesn URL mới. - 304 not modified: cho client biết tài nguyên chưa thay đổi so với bản đã lưu trong cache, thông qua `if-modified-since` hoặc `if-none-match`. - 400 bad request: request không hợp lệ. - 401 unauthorized: server yêu cầu xác thực (authentication) mới được truy cập. - 403 forbidden: tài nguyên bị cấm truy cập, mọi người đều không được phép. - 404 not found: tài nguyên được yêu cầu không tồn tại trên server. - 405 method not allowed: phương thức HTTP không được phép dùng cho URL này. - 413 request entity too large: dữ liệu gửi lên body quá lớn, vượt giớn hạn server cho phép. - 414 request URI too long: URL quá dài, server không xử lý được. - 500 internal server error: server gặp lỗi khi xử lý yêu cầu. - 503 servvice unavailable: server hoạt động bình thường, nhứng ứng dụng phía sau không phản hồi. # HTTPS - Là giao thức tầng ứng dụng như HTTP nhưng đươc truyền qua cưo chế truyền tải an toàn gọi là `Secure Sockets Layer (SSL)`. - `SSL` bảo vệ tính riêng tư và toàn vẹn dữ liệu truyền qua mạng, giảm khả năng xảy ra các cuộc tấn công nghe lén không xâm nhập. >[!note] >- SSL thực tế đã được thay thế bởi Transport Layer Security (TLS), những vẫn được gọi là SSL. >- request/response vẫn hoạt động bình thường trên HTTPS. >- HTTPS đợc mã hóa trên đường truyền, còn HTTP thì không. # HTTP Proxies - Là một máy chủ trung gian điều phối truy cập giữa Client-Server. - Proxy chuyển tiếp các yêu cầu đến các máy chủ web tương ứng và trả lại phản hồi của chúng về cho trình duyệt. - Proxy cũng cung cấp các dịch vụ bổ sung (caching, xác thực và điều khiển truy cập). - Khi trình duyệt gửi một yêu cầu HTTP không được mã hóa đến proxy, nó đặt toàn bộ URL vào yêu cầu. Để chuyển yêu cầu đến đúng máy chủ web đích. - Khi dùng HTTPS, trình duyệt không thể thực hiện bắt tay SSL với máy chủ proxy, vì sẽ phá vỡ kênh an toàn và khiến liên lạc dễ bị chặn. - Thay vào đó, proxy hoạt động như một bộ chuyển tiếp ở mức TCP thô. Để không làm lộ dữ liệu. >[!note] >Có một dạng proxy chuyên dụng đặt giữa trình duyệt và website cho phép chặn và sửa mọi yêu cầu/phản hồi kể cả HTTPS. # HTTP Authentication - Là cơ chế xác thực người dùng đợc tích hợp sẵn trong HTTP, chứng minh danh tính trước khi truy cập tài nguyên. - Có nhiều phương thức xác thực (authentication schemes) khác nhau. ## Basic - Là cơ chế đơn giản, gửi thông tin đăng nhập được mã hóa bằng Base64 trong phần header của request. ## NTLM - Là cơ chế xác thực challenge-response, sử dụng một biến thể cảu giao thức NTLM (NT LAN Manager) của Windows. ## Digest - Cũng là cơ chế challenge-response nhưng thay vì gửi mật khẩu trực tiếp, nó gửi một giá trị băn (MD5) được tính từ NONCE (một chuỗi ngẫu nhiên do server gửi) và thông tin đăng nhập của người dùng.