**Web Application Technologies** - The HTTP Protocol - HTTP Requests - HTTP Responses - HTTP Methods - URLs - HTTP Headers - Cookies - Status Codes - HTTPS - HTTP Proxies - HTTP Authentication # The HTTP Protocol **Hypertext Transfer 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 sử dụng bởi tất cả các ứng dụng web ngày nay. Nó là một giao thức đơn giản ban đầu được phát triển để truy xuất các tài nguyên dựa trên văn bản tĩnh. Kể từ đó, nó đã được mở rộng và tận dụng theo nhiều cách khác nhau để cho phép nó hỗ trợ các ứng dụng phân tán phức tạp hiện đang phổ biến. HTTP sử dụng mô hình dựa trên thông báo trong đó máy khách gửi thông báo yêu cầu và máy chủ trả về thông báo phản hồi. Về cơ bản, giao thức này không có kết nối: mặc dù HTTP sử dụng giao thức TCP có trạng thái làm cơ chế vận chuyển, nhưng mỗi lần trao đổi yêu cầu và phản hồi là một giao dịch tự trị và có thể sử dụng một kết nối TCP khác. # HTTP Requests Tất cả các thông báo HTTP (yêu cầu và phản hồi) bao gồm một hoặc nhiều tiêu đề, mỗi tiêu đề nằm trên một dòng riêng biệt, theo sau là một dòng trống bắt buộc, tiếp theo là nội dung thư tùy chọn. Một yêu cầu HTTP điển hình như sau: ``` 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-shockwave- flash, */* 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 ``` Dòng đầu tiên của mọi yêu cầu HTTP bao gồm ba mục, được phân tách bằng dấu cách: ■ **Phương thức HTTP**. Phương thức được sử dụng phổ biến nhất là GET, có chức năng lấy tài nguyên từ máy chủ web. Yêu cầu GET không có nội dung thư, vì vậy không có thêm dữ liệu nào theo dòng trống sau tiêu đề thư. ■ **URL được yêu cầu**. URL thường hoạt động như một tên cho tài nguyên được yêu cầu, cùng với một chuỗi truy vấn tùy chọn chứa các tham số mà máy khách đang chuyển đến tài nguyên đó. Chuỗi truy vấn được biểu thị bằng ký tự ? trong URL. Ví dụ chứa một tham số duy nhất có tên uid và giá trị 129. ■ **Phiên bản HTTP đang được sử dụng**. Các phiên bản HTTP duy nhất được sử dụng phổ biến trên Internet là 1.0 và 1.1 và hầu hết các trình duyệt đều sử dụng phiên bản 1.1 theo mặc định. Có một vài khác biệt giữa thông số kỹ thuật của hai phiên bản này; tuy nhiên, sự khác biệt duy nhất mà bạn có thể gặp phải khi tấn công các ứng dụng web là trong phiên bản 1.1, tiêu đề yêu cầu Host là bắt buộc. Dưới đây là một số điểm cần quan tâm khác trong yêu cầu mẫu: ■ **Tiêu đề Referer** được sử dụng để chỉ ra URL mà yêu cầu bắt nguồn từ đó (ví dụ: vì người dùng đã nhấp vào một liên kết trên trang đó). Lưu ý rằng tiêu đề này đã bị sai chính tả trong đặc tả HTTP ban đầu và phiên bản sai chính tả đã được giữ lại kể từ đó. ■ **Tiêu đề User-Agent** được sử dụng để cung cấp thông tin về trình duyệt hoặc phần mềm máy khách khác đã tạo ra yêu cầu. Lưu ý rằng hầu hết các trình duyệt bao gồm tiền tố Mozilla vì lý do lịch sử. Đây là chuỗi User-Agent được trình duyệt Netscape thống trị ban đầu sử dụng và các trình duyệt khác muốn khẳng định với các trang web rằng chúng tương thích với tiêu chuẩn này. Cũng như nhiều điều kỳ quặc trong lịch sử máy tính, nó đã trở nên lâu đời đến mức nó vẫn được giữ lại, ngay cả trên phiên bản Internet Explorer hiện tại, phiên bản đã đưa ra yêu cầu được hiển thị trong ví dụ. ■ **Tiêu đề Host** chỉ định tên máy chủ xuất hiện trong URL đầy đủ đang được truy cập. Điều này là cần thiết khi nhiều trang web được lưu trữ trên cùng một máy chủ, vì URL được gửi trong dòng đầu tiên của yêu cầu thường không chứa tên máy chủ. ■ **Tiêu đề Cookie** được sử dụng để gửi các tham số bổ sung mà máy chủ đã cấp cho máy khách. # HTTP Responses Một phản hồi HTTP điển hình như sau: ``` HTTP/ 1.1 200 OK Date: Tue, 19 Apr 2011 09:23:32 GMT Server: Microsof t-IIS/6 . 0 X-Powered-By : ASP.NET Set-Cookie : tracking=tI8rk7 j oMx44S2Uu85nSWc 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/xhtmll/DTD/xhtmll-transitional.dtd" xhtml xmlns= "http://www.w3.org/1999/xhtml">Your details</title> ... ``` Dòng đầu tiên của mọi phản hồi HTTP bao gồm ba mục, được phân tách bằng dấu cách: ■ **Phiên bản HTTP đang được sử dụng.** ■ **Mã trạng thái số cho biết kết quả của yêu cầu.** 200 là mã trạng thái phổ biến nhất; điều đó có nghĩa là yêu cầu đã thành công và tài nguyên được yêu cầu đang được trả lại. ■ **Một “cụm từ” mô tả thêm trạng thái của phản hồi.** Điều này có thể có bất kỳ giá trị nào và không được các trình duyệt hiện tại sử dụng cho bất kỳ mục đích nào. Dưới đây là một số điểm quan tâm khác trong phản hồi: ■ **Tiêu đề Server** chứa biểu ngữ cho biết phần mềm máy chủ web đang được sử dụng và đôi khi là các chi tiết khác như mô-đun đã cài đặt và hệ điều hành máy chủ. Thông tin chứa có thể chính xác hoặc không. ■ **Tiêu đề Set-Cookie** cấp cho trình duyệt một cookie khác; điều này được gửi lại trong tiêu đề Cookie của các yêu cầu tiếp theo tới máy chủ này. ■ **Tiêu đề Pragma** hướng dẫn trình duyệt không lưu trữ phản hồi trong bộ đệm của nó. ■ **Tiêu đề Expires** chỉ ra rằng nội dung phản hồi đã hết hạn trong quá khứ và do đó không được lưu vào bộ nhớ đệm. Các hướng dẫn này thường được đưa ra khi nội dung động được trả lại để đảm bảo rằng các trình duyệt có được phiên bản mới của nội dung này trong những lần tiếp theo. ■ Hầu như tất cả các phản hồi HTTP đều chứa nội dung thư nằm sau dòng trống sau tiêu đề. **Tiêu đề Content-Type** chỉ ra rằng phần nội dung của thư này chứa tài liệu HTML. ■ **Tiêu đề Content-Length** cho biết độ dài của nội dung thư theo bytes. # HTTP Methods Khi tấn công các ứng dụng web, bạn hầu như chỉ xử lý các phương pháp được sử dụng phổ biến nhất: GET và POST. Cần lưu ý một số điểm khác biệt quan trọng giữa các phương pháp này vì chúng có thể ảnh hưởng đến tính bảo mật của ứng dụng nếu bị bỏ qua. **Phương thức GET** Phương thức GET được thiết kế để truy xuất tài nguyên. Nó có thể được sử dụng để gửi tham số đến tài nguyên được yêu cầu trong chuỗi truy vấn URL. Điều này cho phép người dùng đánh dấu một URL cho tài nguyên động mà họ có thể sử dụng lại. Hoặc những người dùng khác có thể truy xuất tài nguyên tương đương trong lần tiếp theo (như trong truy vấn tìm kiếm được đánh dấu trang). Các URL được hiển thị trên màn hình và được ghi lại ở nhiều nơi khác nhau, chẳng hạn như lịch sử trình duyệt và nhật ký truy cập của máy chủ web. Chúng cũng được truyền trong tiêu đề Referer đến các trang web khác khi các liên kết bên ngoài được theo dõi. Vì những lý do này, không nên sử dụng chuỗi truy vấn để truyền bất kỳ thông tin nhạy cảm nào. **Phương thức POST** Phương thức POST được thiết kế để thực hiện các hành động. Với phương pháp này, các tham số yêu cầu có thể được gửi cả trong chuỗi truy vấn URL và trong phần nội dung của thư. Mặc dù URL vẫn có thể được đánh dấu trang nhưng bất kỳ tham số nào được gửi trong nội dung thư sẽ bị loại trừ khỏi dấu trang. Các tham số này cũng sẽ bị loại trừ khỏi các vị trí khác nhau trong đó nhật ký của các URL được duy trì và khỏi tiêu đề Referer. Vì phương thức POST được thiết kế để thực hiện các hành động, nếu người dùng nhấp vào nút Back của trình duyệt để quay lại trang được truy cập bằng phương thức này, thì trình duyệt sẽ không tự động đưa ra lại yêu cầu. Thay vào đó, nó cảnh báo người dùng về những gì nó sắp làm, như trong Hình ảnh dưới đây. Điều này ngăn người dùng vô tình thực hiện một hành động nhiều lần. Vì lý do này, các yêu cầu POST phải luôn được sử dụng khi một hành động đang được thực hiện. Các trình duyệt không tự động phát hành lại các yêu cầu POST do người dùng thực hiện, vì những yêu cầu này có thể khiến một hành động được thực hiện nhiều lần So sánh hai phương thức GET và POST: | |GET|POST| | -------- | -------- | -------- | | Nút BACK/ Reload | Vô hại | Dữ liệu sẽ được gửi lại (trình duyệt sẽ thông báo cho người dùng rằng dữ liệu sắp được gửi lại) | | Bookmarked | Có thể được đánh dấu | Không thể được đánh dấu | | Lưu vào bộ nhớ Cache | Có thể lưu vào bộ nhớ Cache | Không thể lưu vào bộ nhớ Cache | | Loại mã hóa | application/x-www-form-urlencoded | application/x-www-form-urlencoded or multipart/form-data . Sử dụng mã hóa nhiều phần cho dữ liệu nhị phân. | | Lịch sử trình duyệt | Các thông số vẫn còn trong lịch sử trình duyệt | Các thông số không còn trong lịch sử trình duyệt | | Hạn chế về độ dài dữ liệu | Có, khi gửi dữ liệu, phương thức GET sẽ thêm dữ liệu vào URL; và độ dài của URL bị giới hạn (độ dài URL tối đa là 2048 ký tự) | Không hạn chế | | Hạn chế về kiểu dữ liệu | Chỉ kí tự ASCII được cho phép | Không hạn chế. Dữ liệu nhị phân cũng được cho phép | | Bảo mật | GET kém an toàn hơn so với POST vì dữ liệu được gửi là một phần của URL. Không bao giờ sử dụng GET khi gửi mật khẩu hoặc thông tin nhạy cảm khác! | POST an toàn hơn GET một chút vì các tham số không được lưu trữ trong lịch sử trình duyệt hoặc trong nhật ký máy chủ web | | Hiển thị | Dữ liệu hiển thị với mọi người trong URL | Dữ liệu không được hiển thị trong URL | Các phương thức khác Ngoài các phương thức GET và POST, giao thức HTTP hỗ trợ nhiều phương thức khác đã được tạo cho các mục đích cụ thể. Dưới đây là những phương thức khác: **Phương thức HEAD** HEAD hoạt động theo cách tương tự như yêu cầu GET, ngoại trừ việc máy chủ không được trả lại nội dung thư trong phản hồi của nó. Máy chủ sẽ trả về các tiêu đề giống như nó sẽ trả về yêu cầu GET tương ứng. Do đó, phương thức này có thể được sử dụng để kiểm tra xem tài nguyên có tồn tại hay không trước khi thực hiện yêu cầu GET tài nguyên đó. **Phương thức TRACE** TRACE được thiết kế cho mục đích chẩn đoán. Máy chủ sẽ trả lại trong nội dung phản hồi nội dung chính xác của thông báo yêu cầu mà nó nhận được. Điều này có thể được sử dụng để phát hiện ảnh hưởng của bất kỳ máy chủ proxy nào giữa máy khách và máy chủ có thể thao túng yêu cầu. **Phương thức OPTION** OPTIONS yêu cầu máy chủ báo cáo các phương thức HTTP khả dụng cho một tài nguyên cụ thể. Máy chủ thường trả về một phản hồi chứa tiêu đề Allow liệt kê các phương thức khả dụng. **Phương thức PUT** PUT cố gắng tải tài nguyên được chỉ định lên máy chủ, sử dụng nội dung có trong phần thân của yêu cầu. Nếu phương thức này được bật, bạn có thể tận dụng nó để tấn công ứng dụng, chẳng hạn như bằng cách tải lên một tập lệnh tùy ý và thực thi tập lệnh đó trên máy chủ. **Phương thức DELETE** DELETE xóa tài nguyên đã chỉ định. **Phương thức PATCH** PATCH được sử dụng để áp dụng các sửa đổi một phần cho tài nguyên. **Phương thức CONNECT** CONNECT được sử dụng để bắt đầu liên lạc hai chiều (đường hầm) với tài nguyên được yêu cầu. Nhiều phương thức HTTP khác tồn tại không liên quan trực tiếp đến việc tấn công các ứng dụng web. Tuy nhiên, một máy chủ web có thể bị tấn công nếu có sẵn một số phương pháp nguy hiểm. # URLs Bộ định vị tài nguyên thống nhất (URL) là mã định danh duy nhất cho tài nguyên web mà qua đó tài nguyên đó có thể được truy xuất. Định dạng của hầu hết các URL như sau: `protocol://hostname[:port]/[path/]file[?param=value]` Một số thành phần trong chương trình này là tùy chọn. Số cổng thường chỉ được bao gồm nếu nó khác với số mặc định được sử dụng bởi giao thức liên quan. URL được sử dụng để tạo yêu cầu HTTP được hiển thị trước đó như sau: `https://mdsec.net/auth/488/YourDetails.ashx?uid=129` Ngoài dạng tuyệt đối này, các URL có thể được chỉ định liên quan đến một máy chủ cụ thể hoặc liên quan đến một đường dẫn cụ thể trên máy chủ đó. Ví dụ: ``` /auth/488/YourDetails.ashx?uid=129 YourDetails.ashx?uid=129 ``` Các dạng tương đối này thường được sử dụng trong các trang web để mô tả điều hướng trong chính trang web hoặc ứng dụng đó. Chú ý: Bạn có thể gặp thuật ngữ URI (hoặc mã định danh tài nguyên thống nhất) đang được sử dụng thay vì URL, nhưng nó thực sự chỉ được sử dụng trong các thông số kỹ thuật chính thức và bởi những người muốn thể hiện kiến thức sư phạm của họ. # HTTP Headers HTTP hỗ trợ một số lượng lớn các tiêu đề, một số tiêu đề được thiết kế cho các mục đích bất thường cụ thể. Một số tiêu đề có thể được sử dụng cho cả yêu cầu và phản hồi và những tiêu đề khác dành riêng cho một trong các loại thông báo này. Các phần sau đây mô tả các tiêu đề mà bạn có thể gặp phải khi tấn công các ứng dụng web. **General Headers** ■ **Connection** cho đầu kia của giao tiếp biết liệu nó có nên đóng kết nối TCP sau khi quá trình truyền HTTP hoàn tất hay giữ nó mở cho các thông báo tiếp theo. ■ **Content-Encoding** chỉ định loại mã hóa nào đang được sử dụng cho nội dung chứa trong nội dung thư, chẳng hạn như gzip, được một số ứng dụng sử dụng để nén phản hồi nhằm truyền nhanh hơn. ■ **Content-Length** chỉ định độ dài của nội dung thư, tính bằng byte (ngoại trừ trường hợp phản hồi cho yêu cầu HEAD, khi nó cho biết độ dài của phần thân trong phản hồi cho yêu cầu GET tương ứng). ■ **Content-Type** chỉ định loại nội dung chứa trong nội dung thư, chẳng hạn như text/html cho tài liệu HTML. ■ **Transfer-Encoding** chỉ định bất kỳ mã hóa nào đã được thực hiện trên nội dung thư để tạo điều kiện truyền qua HTTP. Nó thường được sử dụng để chỉ định mã hóa khối khi điều này được sử dụng. **Request Headers** ■ **Accept** cho máy chủ biết loại nội dung mà máy khách sẵn sàng chấp nhận, chẳng hạn như loại hình ảnh, định dạng tài liệu văn phòng, v.v. ■ **Accept-Encoding** cho máy chủ biết loại mã hóa nội dung nào mà máy khách sẵn sàng chấp nhận. ■ **Authorization** gửi thông tin đăng nhập tới máy chủ cho một trong các loại xác thực HTTP tích hợp. ■ **Cookie** gửi cookies đến máy chủ mà máy chủ đã cấp trước đó. ■ **Host** chỉ định tên máy chủ xuất hiện trong URL đầy đủ được yêu cầu. ■ **If-Modified-Since** chỉ định thời điểm cuối cùng trình duyệt nhận được tài nguyên được yêu cầu. Nếu tài nguyên không thay đổi kể từ thời điểm đó, máy chủ có thể hướng dẫn máy khách sử dụng bản sao được lưu trong bộ nhớ cache của nó, sử dụng phản hồi có mã trạng thái 304. ■ **If-None-Match** chỉ định thẻ entity, là mã định danh biểu thị nội dung của nội dung thư. Trình duyệt gửi thẻ thực thể mà máy chủ đã cấp cùng với tài nguyên được yêu cầu khi nó được nhận lần cuối. Máy chủ có thể sử dụng thẻ thực thể để xác định xem trình duyệt có thể sử dụng bản sao tài nguyên được lưu trong bộ nhớ cache của nó hay không. ■ **Origin** được sử dụng trong các yêu cầu Ajax tên miền chéo để chỉ ra tên miền mà từ đó yêu cầu bắt nguồn. ■ **Referer** chỉ định URL mà từ đó yêu cầu hiện tại bắt nguồn. ■ **User-Agent** cung cấp thông tin về trình duyệt hoặc phần mềm máy khách khác đã tạo ra yêu cầu. ■ **X-Forwarded-For** xác định địa chỉ IP gốc của máy khách kết nối với máy chủ web thông qua máy chủ proxy. **Response Headers** ■ **Access-Control-Allow-Origin** cho biết tài nguyên có thể được truy xuất thông qua các yêu cầu Ajax tên miền chéo hay không. ■ **Cache-Control** chuyển các chỉ thị bộ nhớ đệm tới trình duyệt (ví dụ: no-cache). ■ **ETag** chỉ định một thẻ entity. Máy khách có thể gửi số nhận dạng này trong các yêu cầu trong tương lai cho cùng một tài nguyên trong tiêu đề If-None-Match để thông báo cho máy chủ phiên bản tài nguyên nào mà trình duyệt hiện đang lưu trong bộ đệm của nó. ■ **Expires** cho trình duyệt biết nội dung của nội dung thư hợp lệ trong bao lâu. Trình duyệt có thể sử dụng bản sao được lưu trong bộ nhớ cache của tài nguyên này cho đến thời điểm này. ■ **Location** được sử dụng trong phản hồi chuyển hướng (những phản hồi có mã trạng thái bắt đầu bằng 3) để chỉ định mục tiêu của chuyển hướng. ■ **Pragma** chuyển các chỉ thị bộ đệm cho trình duyệt (ví dụ: no-cache). ■ **Server** cung cấp thông tin về phần mềm máy chủ web đang được sử dụng. ■ **Set-Cookie** cấp cookies cho trình duyệt mà nó sẽ gửi lại cho máy chủ trong các yêu cầu tiếp theo. ■ **WWW-Authenticate** được sử dụng trong các phản hồi có mã trạng thái 401 để cung cấp chi tiết về (các) loại xác thực mà máy chủ hỗ trợ. ■ **X-Frame-Options** cho biết phản hồi hiện tại có thể được tải hay không và bằng cách nào trong khung trình duyệt. # Cookies Cookies là một phần quan trọng của giao thức HTTP mà hầu hết các ứng dụng web đều dựa vào. Thông thường, chúng có thể được sử dụng như một phương tiện để khai thác các lỗ hổng. Cơ chế cookie cho phép máy chủ gửi các mục dữ liệu đến máy khách, mà máy khách sẽ lưu trữ và gửi lại cho máy chủ. Không giống như các loại tham số yêu cầu khác (những tham số trong chuỗi truy vấn URL hoặc nội dung thư), cookie tiếp tục được gửi lại trong mỗi yêu cầu tiếp theo mà ứng dụng hoặc người dùng không yêu cầu bất kỳ hành động cụ thể nào. Máy chủ phát hành cookie bằng cách sử dụng tiêu đề phản hồi Set-Cookie, như bạn đã thấy: `Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc` Sau đó, trình duyệt của người dùng sẽ tự động thêm tiêu đề sau vào các yêu cầu tiếp theo quay lại cùng một máy chủ: `Cookie : tracking=tl8rk7joMx44S2Uu85nSWc` Cookies thường bao gồm một cặp tên/giá trị, như được hiển thị, nhưng chúng có thể bao gồm bất kỳ chuỗi nào không chứa khoảng trắng. Nhiều cookie có thể được phát hành bằng cách sử dụng nhiều tiêu đề Set-Cookie trong phản hồi của máy chủ. Chúng được gửi trở lại máy chủ trong cùng một tiêu đề Cookie, với dấu chấm phẩy ngăn cách các cookies riêng lẻ khác nhau. Ngoài giá trị thực tế của cookie, tiêu đề Set-Cookie có thể bao gồm bất kỳ thuộc tính tùy chọn nào sau đây, có thể được sử dụng để kiểm soát cách trình duyệt xử lý cookie: ■ **expires** đặt ngày cho đến khi cookie hợp lệ. Điều này khiến trình duyệt lưu cookie vào bộ lưu trữ liên tục và cookie này được sử dụng lại trong các phiên trình duyệt tiếp theo cho đến khi đạt đến ngày hết hạn. Nếu thuộc tính này không được đặt, thì cookie chỉ được sử dụng trong phiên trình duyệt hiện tại. ■ **domain** chỉ định tên miền mà cookie hợp lệ. Tên này phải giống hoặc tên gốc của tên miền mà từ đó cookie được nhận. ■ **path** chỉ định đường dẫn URL mà cookie hợp lệ. ■ **secure** — Nếu thuộc tính này được đặt, cookie sẽ chỉ được gửi trong các yêu cầu HTTPS. ■ **HttpOnly** — Nếu thuộc tính này được đặt, thì không thể truy cập trực tiếp cookie thông qua JavaScript phía máy khách. Mỗi thuộc tính cookie này có thể ảnh hưởng đến bảo mật của ứng dụng. Tác động chính là khả năng kẻ tấn công nhắm mục tiêu trực tiếp vào những người dùng khác của ứng dụng. # Status Codes Mỗi thông báo phản hồi HTTP phải chứa mã trạng thái trong dòng đầu tiên, cho biết kết quả của yêu cầu. Các mã trạng thái được chia thành năm nhóm, theo chữ số đầu tiên của mã: **■ 1xx — Thông tin. ■ 2xx — Yêu cầu thành công. ■ 3xx — Máy khách được chuyển hướng đến một tài nguyên khác. ■ 4xx — Yêu cầu có một loại lỗi nào đó. ■ 5xx — Máy chủ gặp lỗi khi thực hiện yêu cầu.** Có rất nhiều mã trạng thái cụ thể, nhiều mã chỉ được sử dụng trong các trường hợp đặc biệt. Dưới đây là các mã trạng thái mà bạn có nhiều khả năng gặp phải nhất khi tấn công một ứng dụng web, cùng với cụm từ lý do thông thường liên quan đến chúng: ■ **100 Continue** được gửi trong một số trường hợp khi khách hàng gửi yêu cầu có chứa nội dung. Phản hồi chỉ ra rằng các tiêu đề yêu cầu đã được nhận và máy khách sẽ tiếp tục gửi phần thân. Máy chủ trả về phản hồi thứ hai khi yêu cầu đã được hoàn thành. ■ **200 OK** cho biết rằng yêu cầu đã thành công và nội dung phản hồi chứa kết quả của yêu cầu. ■ **201 Created** được trả về để phản hồi yêu cầu PUT để cho biết rằng yêu cầu đã thành công. ■ **301 Moved Permanently** chuyển hướng vĩnh viễn trình duyệt tới một URL khác, URL này được chỉ định trong tiêu đề Location. Khách hàng nên sử dụng URL mới trong tương lai thay vì URL gốc. ■ **302 Found** tạm thời chuyển hướng trình duyệt tới một URL khác, URL này được chỉ định trong tiêu đề Location. Máy khách sẽ hoàn nguyên về URL ban đầu trong các yêu cầu tiếp theo. ■ **304 Not Modified** hướng dẫn trình duyệt sử dụng bản sao được lưu trong bộ nhớ cache của tài nguyên được yêu cầu. Máy chủ sử dụng các tiêu đề yêu cầu If-Modified-Since và If-None-Match để xác định xem máy khách có phiên bản tài nguyên mới nhất hay không. ■ **400 Bad Request** cho biết rằng khách hàng đã gửi một yêu cầu HTTP không hợp lệ. Bạn có thể sẽ gặp phải điều này khi bạn đã sửa đổi một yêu cầu theo một số cách không hợp lệ, chẳng hạn như bằng cách đặt một ký tự khoảng trắng vào URL. ■ **401 Unauthorized** chỉ ra rằng máy chủ yêu cầu xác thực HTTP trước khi yêu cầu được cấp. Tiêu đề WWW-Authenticate chứa thông tin chi tiết về (các) loại xác thực được hỗ trợ. ■ **403 Forbidden** chỉ ra rằng không ai được phép truy cập tài nguyên được yêu cầu, bất kể xác thực. ■ **404 Not Found** cho biết tài nguyên được yêu cầu không tồn tại. ■ **405 Method Not Allowed** chỉ ra rằng phương thức được sử dụng trong yêu cầu không được hỗ trợ cho URL đã chỉ định. Ví dụ: bạn có thể nhận được mã trạng thái này nếu bạn cố gắng sử dụng phương thức PUT ở nơi nó không được hỗ trợ. ■ **413 Request Entity Too Large** — Nếu bạn đang thăm dò các lỗ hổng tràn bộ đệm trong mã gốc và do đó đang gửi chuỗi dữ liệu dài, thì điều này cho thấy phần thân yêu cầu của bạn quá lớn để máy chủ xử lý. ■ **414 Request URI Too Long** tương tự như phản hồi 413. Nó chỉ ra rằng URL được sử dụng trong yêu cầu quá lớn để máy chủ xử lý. ■ **500 Internal Server Error** cho biết máy chủ đã gặp lỗi khi thực hiện yêu cầu. Điều này thường xảy ra khi bạn đã gửi đầu vào không mong muốn gây ra lỗi chưa được xử lý ở đâu đó trong quá trình xử lý của ứng dụng. Bạn nên xem kỹ toàn bộ nội dung phản hồi của máy chủ để biết bất kỳ chi tiết nào cho thấy bản chất của lỗi. ■ **503 Service Unavailable** thường chỉ ra rằng, mặc dù bản thân máy chủ web đang hoạt động và có thể phản hồi các yêu cầu, nhưng ứng dụng được truy cập qua máy chủ không phản hồi. Bạn nên xác minh xem đây có phải là kết quả của bất kỳ hành động nào bạn đã thực hiện hay không. # HTTPS Giao thức HTTP sử dụng TCP đơn giản làm cơ chế vận chuyển của nó, cơ chế này không được mã hóa và do đó có thể bị chặn bởi kẻ tấn công có vị trí phù hợp trên mạng. HTTPS về cơ bản là giao thức lớp ứng dụng giống như HTTP nhưng được tạo đường hầm qua cơ chế vận chuyển an toàn. Lớp cổng bảo mật (Secure Sockets Layer – SSL). Điều này bảo vệ quyền riêng tư và tính toàn vẹn của dữ liệu truyền qua mạng, giảm khả năng tấn công đánh chặn không xâm lấn. Các yêu cầu và phản hồi HTTP hoạt động theo cùng một cách bất kể SSL có được sử dụng để truyền tải hay không. Chú ý: SSL đã được thay thế hoàn toàn bằng bảo mật tầng vận chuyển (TLS), nhưng cái sau thường vẫn được gọi bằng tên cũ hơn. # HTTP Proxies Một HTTP Proxy là một máy chủ làm trung gian truy cập giữa trình duyệt máy khách và máy chủ web đích. Khi một trình duyệt đã được định cấu hình để sử dụng máy chủ proxy, trình duyệt sẽ thực hiện tất cả các yêu cầu của nó tới máy chủ đó. Proxy chuyển tiếp các yêu cầu đến các máy chủ web có liên quan và chuyển tiếp phản hồi của chúng trở lại trình duyệt. Hầu hết các proxy cũng cung cấp các dịch vụ bổ sung, bao gồm bộ nhớ đệm, xác thực và kiểm soát truy cập. Hai điểm khác biệt trong cách thức hoạt động của HTTP khi máy chủ proxy đang được sử dụng: ■ Khi trình duyệt đưa ra yêu cầu HTTP không được mã hóa tới máy chủ proxy, trình duyệt sẽ đặt URL đầy đủ vào yêu cầu, bao gồm tiền tố giao thức http://, tên máy chủ của máy chủ và số cổng nếu đây không phải là tiêu chuẩn. Máy chủ proxy trích xuất tên máy chủ và cổng và sử dụng những thông tin này để hướng yêu cầu đến đúng máy chủ web đích. ■ Khi HTTPS đang được sử dụng, trình duyệt không thể thực hiện bắt tay SSL với máy chủ proxy, bởi vì điều này sẽ phá vỡ đường hầm an toàn và khiến các giao tiếp dễ bị tấn công chặn. Do đó, trình duyệt phải sử dụng proxy như một chuyển tiếp cấp TCP thuần túy, truyền tất cả dữ liệu mạng theo cả hai hướng giữa trình duyệt và máy chủ web đích, với đó trình duyệt thực hiện bắt tay SSL như bình thường. Để thiết lập chuyển tiếp này, trình duyệt tạo một yêu cầu HTTP tới máy chủ proxy bằng phương thức CONNECT và chỉ định tên máy chủ đích và số cổng làm URL. Nếu proxy cho phép yêu cầu, nó sẽ trả về phản hồi HTTP có trạng thái 200, giữ kết nối TCP mở và từ thời điểm đó trở đi hoạt động như một chuyển tiếp cấp TCP thuần túy tới máy chủ web đích. Theo một cách nào đó, mục hữu ích nhất trong bộ công cụ của bạn khi tấn công các ứng dụng web là một loại máy chủ proxy chuyên dụng nằm giữa trình duyệt của bạn và trang web mục tiêu, đồng thời cho phép bạn chặn và sửa đổi tất cả các yêu cầu và phản hồi, ngay cả những yêu cầu và phản hồi sử dụng HTTPS. # HTTP Authentication Giao thức HTTP bao gồm các cơ chế riêng để xác thực người dùng bằng các sơ đồ xác thực khác nhau, bao gồm: ■ **Basic** là cơ chế xác thực đơn giản gửi thông tin đăng nhập của người dùng dưới dạng chuỗi **Base64-encoded** trong tiêu đề yêu cầu với mỗi thông báo. ■ **NTLM** là một cơ chế thử thách -phản hồi và sử dụng một phiên bản của giao thức Windows NTLM. ■ **Digest** là một cơ chế thách thức -phản hồi và sử dụng tổng kiểm tra MD5 của nonce với thông tin đăng nhập của người dùng. Tương đối hiếm khi gặp các giao thức xác thực này đang được sử dụng bởi các ứng dụng web được triển khai trên Internet. Chúng được sử dụng phổ biến hơn trong các tổ chức để truy cập các dịch vụ dựa trên mạng nội bộ. **SỰ THẬT THƯỜNG GẶP** “Xác thực cơ bản không an toàn.” Vì xác thực cơ bản đặt thông tin xác thực ở dạng không được mã hóa trong yêu cầu HTTP, nên người ta thường tuyên bố rằng giao thức này không an toàn và không nên sử dụng. Nhưng xác thực dựa trên biểu mẫu, như được sử dụng bởi nhiều ngân hàng, cũng đặt thông tin đăng nhập ở dạng không được mã hóa trong yêu cầu HTTP. Bất kỳ thông báo HTTP nào cũng có thể được bảo vệ khỏi các cuộc tấn công nghe trộm bằng cách sử dụng HTTPS làm cơ chế vận chuyển, điều này nên được thực hiện bởi mọi ứng dụng có ý thức bảo mật. Liên quan đến nghe trộm, ít nhất, bản thân xác thực cơ bản không tệ hơn các phương pháp được sử dụng bởi phần lớn các ứng dụng web ngày nay.