Lý do xử dụng get thay vì post

Yêu cầu GET không an toàn hơn một chút so với yêu cầu POST. Không cung cấp "bảo mật" thực sự của chính nó; sử dụng các yêu cầu POST sẽ không làm cho trang web của bạn an toàn trước các cuộc tấn công độc hại với số lượng đáng chú ý. Tuy nhiên, sử dụng các yêu cầu GET có thể làm cho ứng dụng an toàn không an toàn.

Câu thần chú mà bạn "không được sử dụng các yêu cầu GET để thực hiện thay đổi" vẫn còn rất nhiều giá trị, nhưng điều này ít liên quan đến hành vi độc hại . Các hình thức đăng nhập là những hình thức nhạy cảm nhất để được gửi bằng cách sử dụng loại yêu cầu sai.

Tìm kiếm nhện và trình tăng tốc web

Đây là lý do thực sự bạn nên sử dụng các yêu cầu POST để thay đổi dữ liệu. Nhện tìm kiếm sẽ theo mọi liên kết trên trang web của bạn, nhưng sẽ không gửi biểu mẫu ngẫu nhiên mà chúng tìm thấy.

Trình tăng tốc web kém hơn trình tìm kiếm, vì chúng chạy trên máy của khách hàng và "nhấp" vào tất cả các liên kết trong ngữ cảnh của người dùng đã đăng nhập . Do đó, một ứng dụng sử dụng yêu cầu GET để xóa nội dung, ngay cả khi yêu cầu quản trị viên, sẽ vui vẻ tuân theo các mệnh lệnh của trình tăng tốc web (không độc hại!) Và xóa mọi thứ mà nó nhìn thấy .

Phó tấn công bối rối

Một cuộc tấn công phó nhầm lẫn (trong đó phó là trình duyệt) có thể xảy ra bất kể bạn sử dụng yêu cầu GET hay POST .

Trên các trang web do kẻ tấn công kiểm soát, GET và POST đều dễ gửi như nhau mà không cần tương tác của người dùng .

Kịch bản duy nhất mà POST ít nhạy cảm hơn là nhiều trang web không thuộc quyền kiểm soát của kẻ tấn công (giả sử diễn đàn bên thứ ba) cho phép nhúng hình ảnh tùy ý (cho phép kẻ tấn công thực hiện yêu cầu GET tùy ý), nhưng ngăn chặn tất cả cách tiêm một yêu cầu POST tùy tiện, cho dù là tự động hay thủ công.

Người ta có thể lập luận rằng các trình tăng tốc web là một ví dụ về tấn công phó nhầm lẫn, nhưng đó chỉ là vấn đề định nghĩa. Nếu bất cứ điều gì, một âm mưu tấn công không kiểm soát này, vì vậy nó hầu như không một cuộc tấn công , ngay cả khi phó bối rối.

Nhật ký proxy

Các máy chủ proxy có khả năng ghi nhật ký toàn bộ URL NHẬN, mà không tước chuỗi truy vấn. Các tham số yêu cầu POST không được ghi lại bình thường. Cookies không có khả năng được đăng nhập trong cả hai trường hợp. (thí dụ)

Đây là một lập luận rất yếu ủng hộ POST. Thứ nhất, lưu lượng chưa được mã hóa có thể được ghi lại toàn bộ; một proxy độc hại đã có mọi thứ nó cần. Thứ hai, các tham số yêu cầu được sử dụng hạn chế cho kẻ tấn công: thứ chúng thực sự cần là cookie, vì vậy nếu thứ duy nhất chúng có là nhật ký proxy, chúng không có khả năng tấn công URL GET hoặc POST.

Có một ngoại lệ cho các yêu cầu đăng nhập: chúng có xu hướng chứa mật khẩu của người dùng. Lưu cái này trong nhật ký proxy sẽ mở ra một vectơ tấn công không có trong trường hợp POST. Tuy nhiên, dù sao thì việc đăng nhập qua HTTP đơn giản là không an toàn.

Bộ đệm proxy

Proxy lưu trữ có thể giữ lại phản hồi GET, nhưng không phản hồi POST. Phải nói rằng, các phản hồi GET có thể được thực hiện không lưu trong bộ nhớ cache với ít nỗ lực hơn so với chuyển đổi URL sang trình xử lý POST.

"Người giới thiệu" HTTP

Nếu người dùng điều hướng đến trang web của bên thứ ba từ trang được cung cấp để đáp ứng yêu cầu GET, trang web của bên thứ ba đó sẽ thấy tất cả các tham số yêu cầu GET.

Thuộc danh mục "tiết lộ các tham số yêu cầu cho bên thứ ba", mức độ nghiêm trọng phụ thuộc vào những gì có trong các tham số đó. Các yêu cầu POST hoàn toàn miễn dịch với điều này, tuy nhiên để khai thác yêu cầu GET, hacker sẽ cần chèn một liên kết đến trang web của riêng họ vào phản hồi của máy chủ.

Lịch sử trình duyệt

Điều này rất giống với đối số "nhật ký proxy": Yêu cầu GET được lưu trữ trong lịch sử trình duyệt cùng với các tham số của chúng. Kẻ tấn công có thể dễ dàng có được những thứ này nếu chúng có quyền truy cập vật lý vào máy.

Hành động làm mới trình duyệt

Trình duyệt sẽ thử lại yêu cầu GET ngay khi người dùng nhấn "refresh". Nó có thể làm điều đó khi khôi phục các tab sau khi tắt máy. Bất kỳ hành động nào (giả sử, một khoản thanh toán) do đó sẽ được lặp lại mà không có cảnh báo.

Trình duyệt sẽ không thử lại yêu cầu POST mà không có cảnh báo.

Đây là một lý do chính đáng để chỉ sử dụng các yêu cầu POST để thay đổi dữ liệu, nhưng không liên quan gì đến hành vi độc hại và do đó, bảo mật.

Vậy tôi phải làm sao?

  • Chỉ sử dụng các yêu cầu POST để thay đổi dữ liệu, chủ yếu vì các lý do không liên quan đến bảo mật.
  • Chỉ sử dụng các yêu cầu POST cho các hình thức đăng nhập; làm khác giới thiệu các vectơ tấn công.
  • Nếu trang web của bạn thực hiện các hoạt động nhạy cảm, bạn thực sự cần một người biết họ đang làm gì, bởi vì điều này không thể được đề cập trong một câu trả lời. Bạn cần sử dụng HTTPS, HSTS, CSP, giảm thiểu SQL SQL, tiêm script (XSS) , CSRF và hàng loạt thứ khác có thể dành riêng cho nền tảng của bạn (như lỗ hổng gán khối lượng lớn trong các khung khác nhau: ASP.NET MVC , Ruby trên Rails , v.v.). Không có điều gì duy nhất tạo ra sự khác biệt giữa "an toàn" (không thể khai thác) và "không an toàn".

Qua HTTPS, dữ liệu POST được mã hóa, nhưng URL có thể bị đánh hơi bởi bên thứ 3 không?

Không, họ không thể đánh hơi được. Nhưng các URL sẽ được lưu trữ trong lịch sử trình duyệt.

Sẽ công bằng khi nói cách thực hành tốt nhất là tránh có thể đặt dữ liệu nhạy cảm vào POST hoặc GET hoàn toàn và sử dụng mã phía máy chủ để xử lý thông tin nhạy cảm thay thế?

Phụ thuộc vào mức độ nhạy cảm của nó, hoặc cụ thể hơn, theo cách nào. Rõ ràng là khách hàng sẽ nhìn thấy nó. Bất cứ ai có quyền truy cập vật lý vào máy tính của khách hàng đều sẽ thấy nó. Khách hàng có thể giả mạo nó khi gửi lại cho bạn. Nếu có vấn đề thì có, hãy giữ dữ liệu nhạy cảm trên máy chủ và đừng để nó rời đi.

415 hữu ích 5 bình luận chia sẻ