Web Pentest - Bài 5: Host header injection

[bobby13689]

Chào các bạn,

Tiếp tục với chủ đề Web pentest, hôm nay mình sẽ giới thiệu với các bạn về một loại lỗ hổng rất phổ biến mà mình gặp ở nhiều ứng dụng, kể cả những ứng dụng tưởng chừng như rất "xịn xò" về bảo mật, đó chính là các lỗ hổng liên quan đến Host header.


Tuy nhiên, trước khi đi vào các lỗ hổng liên quan đến Host header , chúng ta hãy tìm hiểu xem, Host header là gì, và tại sao chúng ta lại cần đến nó.

1. Host header là gì?
Thông thường, khi xây dựng 1 ứng dụng web, bạn sẽ dựng 1 server lên, đưa code backend lên đó, và "bravo", bạn có 1 ứng dụng web của riêng mình.

Câu chuyện sẽ đơn giản, cho đến khi bạn muốn dựng thêm một hoặc một vài ứng dụng mới, bạn sẽ thuê thêm server tương ứng cho mỗi ứng dụng đó?
Bạn có 5 ứng dụng, bạn có thể mua 5 server, nhưng nếu, bạn có tới 100 ứng dụng, tôi e rằng bạn sẽ khó để mua 100 server, tất nhiên là sẽ ok nếu tiền không phải là vấn đề với bạn.

Một cách khác rất dễ để thực hiện, lại vừa không tốn quá nhiều công sức của bạn, đó chính là Host header.

Bạn có thể đọc thêm thông tin đầy đủ, chi tiết về Host header tại đây: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Host.

Bạn có thể hiểu đơn giản là, ở Host header, bạn nhập ứng dụng nào vào đó, phía backend sẽ đưa HTTP request của bạn đến ứng dụng đó.

Với việc hỗ trợ Virtual hosting, bạn có thể chỉ sử dụng duy nhất 1 server, và sử dụng thông tin ở Host header để điều hướng người dùng đến rất nhiều các ứng dụng khác nhau.

Các bạn có thể tham khảo mô hình sau (server của bạn là vùng được gạch đứt đoạn màu xám):

​

Với 1 server, bạn có thể đưa người dùng đến example.com hoặc intranet-app tuỳ ý. Rất tiện lợi phải không nào?

Vậy thì có vấn đề gì với giải pháp tuyệt vời này nào?

Trước hết, mình sẽ liệt kê cho các bạn một số ví dụ khác về việc sử dụng Host header trong ứng dụng:

• Bạn dựng một ứng dụng nội bộ quan trọng, với Host là youneverknowabouthishost và bạn nghĩ rằng không ai biết nó cả, do đó, không cần phải bắt người dùng đăng nhập.
• Bạn thiết lập tự động điều hướng kết nối đến ứng dụng mà người dùng nhập ở Host header. Redirect người dùng khi truy cập vào những đường dẫn không tồn tại (404).

• Bạn xây dựng tính năng quên mật khẩu, dùng chung cho nhiều ứng dụng và không biết cách để xác định ứng dụng nào đang cần khôi phục mật khẩu, ngoài việc sử dụng Host header.

Và đó là khi mà một loạt lỗ hổng của Host header xuất hiện.

2. Một số lỗ hổng thường gặp với Host header

• Ở ví dụ đầu tiên, mặc dù bạn nghĩ là không ai đoán được, vâng, người tính không bằng máy tính, người không đoán được, nhưng máy thì ... có thể. Chúng ta có thể brute force host header (tham khảo bài 2).
• Ở ví dụ 2, bạn dùng host header để điều hướng người dùng đến 1 trang khác, một kẻ nào đó nếu có thể thay thế Host header của bạn thành attacker.com (với một số điều kiện nhất định mới thay thế được), và xây 1 trang index.html giống y chang ứng dụng của bạn, "nhờ" người dùng nhập username/password, và đoán xem, người dùng có nhập không?
  
  Cũng là một ứng dụng từ một vendor xịn xò mà mình từng phát hiện (đã fix).

​

• Ví dụ 3 khá là phổ biến, và ảnh hưởng lại rất lớn. Khi ứng dụng dùng host header để tạo email khôi phục mật khẩu, sẽ ra sao nếu người dùng nhận được email từ ứng dụng của bạn, nhưng lại có đường dẫn là https://attacker.com/reset-password?token=abczysaksdhfkjahsdfjkhasdfjkhasjdh. Người dùng sẽ truy cập vào link trên, và ... attacker có thể lấy được token để reset password của người dùng.

'​

Những ví dụ trên chỉ là những ví dụ cơ bản nhất của việc sử dụng sai Host header, trên thực tế có rất nhiều trường hợp khác, với nhiều mức độ ảnh hưởng khác nhau.

Ở PortSwigger Academy có rất nhiều ví dụ hay về dạng lỗ hổng này, các bạn có thể "check it out" để đọc và làm thử các ví dụ khác về việc khai thác lỗ hổng liên quan Host header nhé. Mình đánh giá thấy rất hay và sát với thực tế.

Ngoài ra, các ứng dụng chuyên phục vụ việc học pentesting đều có lỗ hổng này cho các bạn luyện tập, các bạn có thể xem bài này để tạo/lấy môi trường luyện tập nhé.

Cảm ơn các bạn đã đọc hết bài này, hẹn gặp lại các bạn trong những bài viết khác nhé!

Thanks.

M.

 

ở ví dụ thứ 2 thì làm thể nào attacker có thể tấn công victim được nhỉ? trừ trường hợp caching ra nha.
Thanks Mạnh

 

ở ví dụ thứ 2 thì làm thể nào attacker có thể tấn công victim được nhỉ? trừ trường hợp caching ra nha.
Thanks Mạnh

Ở ví dụ 2 này, nếu ứng dụng sử dụng HTTP thì có thể dùng Man-in-the-middle để thay đổi trường Host header để điều hướng đến trang của bạn kiểm soát Tuấn nha.
Thanks Tuấn.

 

Ở ví dụ 2 này, nếu ứng dụng sử dụng HTTP thì có thể dùng Man-in-the-middle để thay đổi trường Host header để điều hướng đến trang của bạn kiểm soát Tuấn nha.
Thanks Tuấn.

Cảm ơn Mạnh nha.