---
# System prepended metadata
title: HTTP Host header attacks
tags: [Web]
---
# What is the HTTP host header?
`HTTP Host header` là một header yêu cầu bắt buộc kể từ `HTTP/1.1`. Nó chỉ định tên miền mà client muốn truy cập. Ví dụ, khi người dùng truy cập `https://portswigger.net/web-security`, trình duyệt tạo một request có header Host như sau:
```
GET /web-security HTTP/1.1
Host: portswigger.net
```
Trong một số trường hợp, chẳng hạn khi yêu cầu được chuyển tiếp qua một hệ thống trung gian, giá trị Host có thể bị thay đổi trước khi đến thành phần back-end dự kiến.
## What is an HTTP Host header attack?
`HTTP Host header attacks` khai thác những website dễ bị tổn thương khi xử lý giá trị của header Host một cách không an toàn. Nếu server tin tưởng vào `Host header` và không xác thực hoặc escape giá trị đó đúng cách, kẻ tấn công có thể lợi dụng đầu vào này để chèn các payload độc hại nhằm thao túng hành vi phía server. Các tấn công chèn payload trực tiếp vào Host header thường được gọi là **"Host header injection"**.
Các ứng dụng web đóng gói sẵn (off-the-shelf) thường không biết trang mà chúng được triển khai trừ khi tên miền được chỉ định thủ công trong file cấu hình khi cài đặt. Khi cần biết domain hiện tại, ví dụ để tạo URL tuyệt đối được chèn vào email, chúng có thể lấy domain từ Host header:
```html
Contact support
```
Giá trị header cũng có thể được sử dụng trong nhiều tương tác giữa các hệ thống khác nhau trong hạ tầng của website.
Host header có thể do người dùng điều khiển. Nếu đầu vào không được escape hoặc xác thực đúng, Host header trở thành vector tiềm năng để khai thác nhiều lỗ hổng khác, nổi bật nhất là:
* Web cache poisoning
* Sai sót logic nghiệp vụ trong một số chức năng cụ thể
* SSRF dựa trên định tuyến (routing-based SSRF)
* Các lỗ hổng cổ điển phía server, ví dụ SQL injection
## Nguyên nhân:
**Nguyên nhân lỗ hổng HTTP Host header:**
* Giả định sai rằng Host header không thể bị người dùng kiểm soát → server tin tưởng mù quáng.
* Không xác thực hoặc escape giá trị Host header.
* Host có thể bị ghi đè bằng các header khác (do cấu hình server).
* Cấu hình sai hoặc thiếu hiểu biết khi tích hợp công nghệ bên thứ ba.
**Tóm lại:** Lỗ hổng thường không phải do code, mà chủ yếu do **cấu hình sai và thiếu kiểm soát Host header**.
# Testing for vulnerabilities
## Supply an arbitrary Host header
Khi kiểm tra lỗ hổng injection tiêu đề Host, đầu tiên hãy thử gửi một tên miền không xác định thông qua tiêu đề Host.
Một số proxy lấy trực tiếp địa chỉ IP từ tiêu đề Host, khiến việc kiểm tra trở nên bất khả thi vì mọi thay đổi sẽ chuyển hướng request đến IP khác. Tuy nhiên, Burp Suite tách biệt rõ ràng giữa tiêu đề Host và địa chỉ IP đích, cho phép bạn tuỳ ý sửa đổi tiêu đề Host mà vẫn đảm bảo request gửi đến đúng target.
**Mẹo:** URL đích được hiển thị ở đầu `panel` (Burp Repeater và Proxy) hoặc tab "`Target`" (Burp Intruder). Bấm biểu tượng bút chì để chỉnh sửa thủ công.
Trong một số trường hợp, bạn vẫn có thể truy cập website dù dùng tiêu đề Host bất thường, có thể do máy chủ được cấu hình mặc định cho các tên miền không nhận diện được. Nếu website đích của bạn trùng với mục mặc định này, bạn có thể nghiên cứu cách ứng dụng xử lý tiêu đề Host và khả năng khai thác.
Ngược lại, do tiêu đề Host là thành phần cốt lõi, việc giả mạo nó thường khiến bạn không thể truy cập ứng dụng đích. Máy chủ `front-end` hoặc `load balancer` có thể không biết chuyển tiếp request đi đâu, dẫn đến lỗi "`Invalid Host header`" - đặc biệt khi target sử dụng CDN.
## Check for flawed validation
Thay vì nhận được phản hồi **"Invalid Host header"**, bạn có thể thấy request bị chặn do một biện pháp bảo mật nào đó.
Hiểu cách website phân tích (parse) Host header, điều này đôi khi hé lộ những kẽ hở có thể dùng để bypass. Ví dụ, một số thuật toán parser sẽ loại bỏ phần port khỏi Host header, nghĩa là chỉ phần tên miền được xác thực. Nếu bạn cũng có thể cung cấp một port không phải số, bạn có thể để phần tên miền nguyên vẹn để chắc chắn tới được ứng dụng mục tiêu, đồng thời tiềm năng chèn payload qua phần port:
```
GET /example HTTP/1.1
Host: vulnerable-website.com:bad-stuff-here
```
Một số trang khác sẽ áp dụng logic khớp cho phép các subdomain tùy ý. Trong trường hợp này, bạn có thể vượt qua việc xác thực hoàn toàn bằng cách đăng ký một tên miền tùy ý kết thúc bằng cùng chuỗi ký tự như tên miền được whitelist:
```
GET /example HTTP/1.1
Host: notvulnerable-website.com
```
Hoặc bạn có thể lợi dụng một subdomain ít an toàn hơn mà bạn đã chiếm quyền điều khiển:
```
GET /example HTTP/1.1
Host: hacked-subdomain.vulnerable-website.com
```
## Send ambiguous requests
Để khai thác lỗ hổng tiêu đề Host, bạn có thể tạo các yêu cầu được diễn giải khác nhau bởi các thành phần hệ thống khác nhau:
**1. Tiêu đề Host trùng lặp**
```
GET /example HTTP/1.1
Host: website-an-toan.com
Host: payload-doc-hai
```
Nếu front-end và back-end xử lý khác nhau (ưu tiên tiêu đề đầu vs tiêu đề cuối), bạn có thể vừa định tuyến đúng target vừa chèn payload.
**2. URL tuyệt đối + Host header**
```
GET https://website-an-toan.com/ HTTP/1.1
Host: payload-doc-hai
```
Mâu thuẫn giữa URL tuyệt đối (trong request line) và tiêu đề Host có thể tạo ra sự khác biệt trong xử lý.
**3. Thụt lề tiêu đề**
```
GET /example HTTP/1.1
Host: payload-doc-hai
Host: website-an-toan.com
```
Thụt lề một tiêu đề Host có thể khiến front-end bỏ qua nó (chỉ thấy tiêu đề sau) nhưng back-end vẫn xử lý, từ đó bỏ qua validation.
Các kỹ thuật này khai thác sự khác biệt trong cách xử lý tiêu đề Host giữa các thành phần hệ thống (front-end/back-end, proxy/server,...).
## Inject host override headers
Trong kiến trúc có hệ thống trung gian (như load balancer hoặc reverse proxy), máy chủ back-end thường nhận tiêu đề Host chứa tên miền của hệ thống trung gian. Để giải quyết vấn đề này, front-end có thể chèn tiêu đề **X-Forwarded-Host** chứa giá trị Host gốc từ client. Nhiều framework sẽ ưu tiên sử dụng tiêu đề này khi nó tồn tại.
Bạn có thể lợi dụng **X-Forwarded-Host** để tiêm payload độc hại mà vượt qua validation trên tiêu đề Host:
```
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: bad-stuff-here
```
Ngoài X-Forwarded-Host, có thể thử các tiêu đề thay thế khác:
- `X-Host`
- `X-Forwarded-Server`
- `X-HTTP-Host-Override`
- `Forwarded`
**Lưu ý:** Nhiều website hỗ trợ các tiêu đề này một cách không chủ đích do được kích hoạt mặc định trong các công nghệ third-party.
# Exploiting vulnerabilities
## Password reset poisoning
### Lab: Basic password reset poisoning
Khi quên mật khẩu sẽ được cung cấp link để reset lại password:
Thay đổi host và tham số `username=carlos`
Vào check log
Dùng token để reset lại password của carlos và đăng nhập lại.
### Lab: Password reset poisoning via middleware
https://hackmd.io/VNhGRFS1QISdu2RyBlolmw#Lab-Password-reset-poisoning-via-middleware
### Lab: Password reset poisoning via dangling markup
Forgot password:
```
Sent: 2025-10-02 03:11:14 +0000
From: no-reply@0a01004103d1eb698385c3e3007c00dd.web-security-academy.net
To: wiener@exploit-0aed00a603ebeb188313c209010c00bf.exploit-server.net
Subject: Account recovery
Hello!
Please click here to login with your new password: JcaLPBFXw2
Thanks,
Support team
This email has been scanned by the MacCarthy Email Security service
```
Nếu ứng dụng không dùng token đặt lại và thay vào đó gửi mật khẩu mới trực tiếp trong body email,ta có thể khai thác điều này bằng cách chèn `HTML` vào `header Host` để phá vỡ cấu trúc `markup` và làm rò rỉ toàn bộ nội dung tới server độc hại của bạn thông qua một yêu cầu `GET`.
Ví dụ đổi password `wiener`
Tương tự đổi tên thành `carlos`, thêm html vào `port` và `View raw` để xem password
## Web cache poisoning
Khi thăm dò tấn công qua tiêu đề Host, ta thường thấy các hành vi dễ bị tổn thương nhưng không khai thác trực tiếp được. Ví dụ: tiêu đề Host có thể được reflected trong mã phản hồi mà không được mã hóa HTML, hay dùng trực tiếp trong script. Các lỗ hổng phía client như XSS thường không khai thác được qua tiêu đề Host vì không thể buộc trình duyệt gửi host sai.
Tuy nhiên, nếu mục tiêu dùng bộ nhớ đệm web, ta có thể biến lỗ hổng reflected này thành lỗ hổng lưu trữ nguy hiểm bằng cách đầu độc bộ nhớ đệm để nó phân phát phản hồi độc cho người dùng khác.
Để tấn công đầu độc bộ nhớ đệm web:
1. Yêu cầu máy chủ phản hồi chứa mã độc
2. Giữ nguyên khóa bộ nhớ đệm để ánh xạ tới request của người dùng khác
3. Lưu phản hồi độc vào bộ nhớ đệm
Bộ nhớ đệm độc lập thường dùng tiêu đề Host làm khóa, nên kỹ thuật này hiệu quả nhất với bộ nhớ đệm tích hợp trong ứng dụng.
### Lab: Web cache poisoning via ambiguous requests
## Exploiting classic server-side vulnerabilities
Mọi header HTTP đều có thể là vector để khai thác các lỗ hổng phía máy chủ cổ điển, và header Host không phải ngoại lệ. Ví dụ, bạn nên thử các kỹ thuật dò tìm SQL injection thông thường thông qua header Host. Nếu giá trị của header này được đưa vào một câu lệnh SQL, nó có thể bị khai thác.
## Bypassing authentication
### Lab: Host header authentication bypass
## Virtual host brute-forcing
Các công ty đôi khi mắc sai lầm khi đặt các website công khai và các site 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 khai và IP riêng (private). Vì tên host nội bộ có thể phân giải về địa chỉ IP riêng, tình huống này không luôn luôn phát hiện được chỉ bằng cách xem bản ghi DNS:
```
www.example.com: 12.34.56.78
intranet.example.com: 10.0.0.132
```
Trong một số trường hợp, site nội bộ thậm chí có thể không có bản ghi DNS công khai nào liên quan. Tuy nhiên, kẻ tấn công thường có thể truy cập bất kỳ virtual host nào trên máy chủ mà họ tiếp cận được, miễn là họ đoán đúng tên host. Nếu họ đã phát hiện được tên miền ẩn bằng các cách khác, như rò rỉ thông tin, họ chỉ cần gửi yêu cầu trực tiếp tới tên đó. Nếu không, họ có thể dùng các công cụ như Burp Intruder để brute-force các virtual host bằng một wordlist đơn giản gồm các tên miền phụ khả dĩ.
## Routing-based SSRF
Đây là dạng tấn công SSRF khai thác tiêu đề **Host**. Khi các thành phần trung gian như proxy được cấu hình không an toàn, chúng có thể bị lừa chuyển hướng yêu cầu đến bất kỳ hệ thống nào mà kẻ tấn công chỉ định, kể cả các server nội bộ.
**Cách thực hiện:**
1. **Phát hiện:** Dùng công cụ (như Burp Collaborator) đặt vào Host header. Nếu nhận được phản hồi, lỗ hổng tồn tại.
2. **Khai thác:** Tìm và tấn công vào các địa chỉ IP nội bộ (thông qua rò rỉ, quét tên miền hoặc brute-force các dải IP private như 192.168.0.0/16).
### Lab: Routing-based SSRF
Thay host của Burp Collaborator's
Chuyển request `GET` sang intruder:
Copy response và mở lại ở trình duyệt:
### Lab: SSRF via flawed request parsing
Vào intruder bruteforce:
## Connection state attacks
Vì lý do hiệu suất, nhiều website thường tái sử dụng kết nối cho nhiều request từ cùng một client. Một số máy chủ HTTP được triển khai kém có giả định sai lầm rằng các thuộc tính như Host header sẽ giống nhau cho mọi request HTTP/1.1 trên cùng kết nối. Điều này tạo ra nhiều lỗ hổng bảo mật.
Ví dụ, có server chỉ validate kỹ request đầu tiên trên kết nối mới. Kẻ tấn công có thể gửi một request vô hại trước, rồi gửi request độc hại tiếp theo trên cùng kết nối để bypass validation.
Nhiều reverse proxy dùng Host header để định tuyến request. Nếu chúng cho rằng mọi request trên kết nối đều gửi đến cùng host như request đầu, sẽ dẫn đến các lỗ hổng như SSRF, password reset poisoning và cache poisoning.
### Lab: Host validation bypass via connection state attack
## SSRF via a malformed request line
Các proxy tùy chỉnh đôi khi không xác thực dòng yêu cầu một cách chính xác, cho phép kẻ tấn công cung cấp các đầu vào bất thường và có định dạng sai, dẫn đến những hậu quả không mong muốn.
Ví dụ, một reverse proxy có thể lấy đường dẫn từ dòng yêu cầu, thêm tiền tố `http://backend-server` vào và chuyển hướng yêu cầu đến URL upstream đó. Cách này hoạt động bình thường nếu đường dẫn bắt đầu bằng ký tự `/`, nhưng nếu nó bắt đầu bằng ký tự `@` thì sao?
```
GET @private-intranet/example HTTP/1.1
```
URL upstream kết quả sẽ là `http://backend-server@private-intranet/example`, mà hầu hết các thư viện HTTP diễn giải thành một yêu cầu truy cập vào `private-intranet` với tên người dùng `backend-server`.
# References
https://portswigger.net/web-security/host-header
https://viblo.asia/p/http-host-header-attack-tan-cong-tieu-de-host-trong-giao-thuc-http-phan-1-GyZJZ3NNLjm