Điểm:0

NginX: cách viết lại nội dung phản hồi và tiêu đề?

lá cờ in

Bối cảnh

Tôi có một bộ sưu tập các trang HTML tĩnh (~10 nghìn trang) được tạo bởi một số ứng dụng mà tôi không có quyền kiểm soát. Các trang này được phục vụ bởi NginX từ một địa điểm chặn.

Các trang có thể chứa dữ liệu nhạy cảm. Tôi muốn có thể chặn hiển thị trang tùy thuộc vào danh tính người dùng và "cờ" trong trang.

Những cờ này có thể được thực hiện bởi một <meta name=keyword content="flag1 flag2 flagn"> thành phần. Khi có một yếu tố như vậy, "thông tin xác thực" sẽ được kiểm tra.

Ý tưởng của tôi là quét phản hồi yêu cầu trước khi trả lại cho người dùng. Đối với điều này, tôi cần

  • một cách để chuyển toàn bộ phản hồi (tiêu đề + nội dung) cho một số mã tùy chỉnh để có thể phân tích cú pháp phần tử <head> Nếu không có cờ, phản hồi được trả về không thay đổi
    Nếu có cờ và người dùng không có thông tin đăng nhập, anh ta được yêu cầu xác định danh tính của mình
    Nếu có cờ và người dùng có quyền xem, phản hồi sẽ được trả về không thay đổi
    Nếu có cờ và người dùng không có quyền xem, một trang lỗi sẽ được trả về thay vì phản hồi


    Cuối cùng, lá cờ <meta> phần tử bị xóa để tránh rò rỉ gợi ý bộ lọc.

  • một cách nào đó để chuyển đến mã người dùng này thông tin về thông tin đăng nhập hiện tại (tên người dùng, giá trị thử thách, bất kỳ thông tin hữu ích nào như dấu thời gian nhận dạng, â¦)

Mã người dùng sẽ dựa trên một "cơ sở dữ liệu" (thuật ngữ này không nhất thiết ám chỉ việc sử dụng một công cụ DB thực sự) chứa các đặc quyền của người dùng và triển khai chức năng hết thời gian chờ.

Mã người dùng có thể được triển khai dưới dạng tập lệnh FastCGI không? Nếu vậy, các chỉ thị để vượt qua phản hồi đầy đủ là gì?

thử nghiệm sơ bộ

Hiện tại nhận dạng người dùng không thể có điều kiện: khi auth_basic được kích hoạt trong một địa điểm, người dùng phải tự xác định danh tính, ngay cả khi truy cập các trang công khai. Tôi có thể giảm thiểu điều này bằng cách có khách/người dùng khách/mật khẩu nhưng tôi không thể có trang cảnh báo trước khi yêu cầu thông tin xác thực.

Vì vậy, xác thực luôn được yêu cầu. Sau đó, một Ủy quyền: Cơ bản some_hash tiêu đề được gửi cùng với yêu cầu. Hàm băm này cần được ghi lại khi xác thực xảy ra để truy cập trong tương lai vào các thuộc tính đặc quyền của người dùng.

Tôi làm nó như thế nào?

Tôi biết rằng ở trạng thái hiện tại, thông số kỹ thuật này hoàn toàn không cung cấp bảo mật thực sự (dễ bị tấn công lại giữa các cuộc tấn công khác). Tôi muốn tạo ra một bằng chứng về khái niệm trước khi đi xa hơn. Mục tiêu của tôi có hợp lý không?

Có cách nào đơn giản hơn để xử lý không? XSLT? (mặc dù thông tin đăng nhập của người dùng hiện tại phải được đưa vào các mẫu)

djdomi avatar
lá cờ za
ngay cả khi câu hỏi hay, tôi tin rằng nó không phù hợp với serverfault.com, tôi nghĩ trang web dành cho nhà phát triển web mà tôi không quen thuộc sẽ phù hợp hơn với bạn
Điểm:1
lá cờ us

Tôi nghĩ cách duy nhất để thực hiện điều này là sử dụng một số bộ điều khiển giao diện người dùng để kiểm tra các yêu cầu logic truy cập, sau đó gửi các tệp HTML từ đĩa.

Bạn sẽ không sử dụng bất kỳ xác thực chỉ thị từ nginx. Quá trình xác thực sẽ được xử lý bởi bộ điều khiển giao diện người dùng.

Bộ điều khiển giao diện người dùng có thể được triển khai theo nhiều cách, ví dụ như ứng dụng Node.JS, PHP, Ruby on Rails và Python.

ajlittoz avatar
lá cờ in
Đây là những gì một người bạn đã đề xuất: xử lý yêu cầu thông qua một "tập lệnh" (Perl, Python, C, â¦) để truy xuất trang tĩnh, quyết định xem thông tin xác thực có cần thiết hay không và trả về một "trang" (trang được yêu cầu hoặc một 401 trang). Tôi hy vọng trả lại mã 401 là đủ để kích hoạt hộp thoại nhận dạng trình duyệt sẽ gửi tiêu đề `Xác thực:`. Tiêu đề này sẽ được sử dụng để lưu trữ thông tin "trực tiếp" trong máy chủ và có thể bỏ qua các tiêu đề khác `Xác thực:`. Tất cả tóm lại là gửi lại cookie một lần không rõ ràng cho các yêu cầu tiếp theo.
lá cờ us
Vâng, đó là cách tiếp cận. Và mã trạng thái HTTP yesm 401 sẽ kích hoạt cửa sổ xác thực trong trình duyệt.
ajlittoz avatar
lá cờ in
Tôi đã thực hiện một thử nghiệm: Tôi gửi tiêu đề `Trạng thái: 401 trái phép` mà không có tải trọng (nhưng việc gửi một khối `` hoàn chỉnh không có gì khác biệt) và điều này không kích hoạt hộp thoại xác thực trong trình duyệt. Tôi nên làm cái gì sau đó?
ajlittoz avatar
lá cờ in
Để kích hoạt lời nhắc xác thực, hãy gửi tiêu đề `WWW-Authenticate: xxx`.
ajlittoz avatar
lá cờ in
Nhưng `xxx` phải là `basic` để có tác dụng và NginX chặn xác thực một cách rõ ràng vì yêu cầu có tiêu đề `Authentication:` không bao giờ đến được tập lệnh của tôi.
lá cờ us
Bạn cần đảm bảo nginx không có bất kỳ chỉ thị xác thực nào trong cấu hình của nó.
ajlittoz avatar
lá cờ in
Do thiếu thông tin chi tiết trong tài liệu về quá trình xử lý `WWW-Authenticate:` và tương tác giữa trình duyệt và máy chủ nên tôi đang cân nhắc việc tự mình xử lý giai đoạn xác thực này. Tôi hiện đang tập trung vào các biện pháp bảo mật để ngăn chặn các cuộc tấn công lặp lại và tạo mã thông báo xác thực giả mạo. Mối quan tâm chính của tôi là thiết kế một trao đổi sao cho cùng một người dùng/mật khẩu, thông báo không bao giờ giống nhau trong các lần thử liên tiếp.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.