Bạn có thể vượt qua người dùng / vượt qua để xác thực cơ bản HTTP trong các tham số URL không?

153

Tôi tin rằng điều này là không thể, nhưng một người mà tôi biết đã khăng khăng rằng nó hoạt động. Tôi thậm chí không biết những thông số nào cần thử, và tôi đã không tìm thấy tài liệu này ở bất cứ đâu.

Tôi đã thử http://myserver.com/~user=username&password=mypassword nhưng nó không hoạt động.

Bạn có thể xác nhận rằng trên thực tế không thể vượt qua người dùng / vượt qua các tham số HTTP (GET hoặc POST) không?

authentication http http-basic-authentication

— ripper234
nguồn

9

người dùng: pass@example.com

— Smudge

@sam - cái gì? URL hoàn chỉnh sẽ trông như thế nào?

— ripper234

4

Tất cả trong thông số ietf.org/rfc/rfc1738.txt (3.1)

— Smudge

@sam - Xin lỗi, tôi không thể phân tích bình luận của bạn vì một số lý do.

— ripper234

199

Thực sự không thể truyền tên người dùng và mật khẩu thông qua các tham số truy vấn trong auth HTTP tiêu chuẩn. Thay vào đó, bạn sử dụng định dạng URL đặc biệt, như thế này: http://username:password@example.com/- điều này sẽ gửi thông tin đăng nhập trong tiêu đề "Ủy quyền" HTTP tiêu chuẩn.

Có thể là bất cứ ai bạn đang nói đến đều nghĩ về một mô-đun hoặc mã tùy chỉnh đã xem xét các tham số truy vấn và xác minh thông tin đăng nhập. Đây không phải là HTTP auth tiêu chuẩn, tuy nhiên, đây là một thứ dành riêng cho ứng dụng.

— womble
nguồn

1

Cảm ơn, đây chỉ là những gì tôi đang tìm kiếm ... không quan trọng là nó NHẬN các tham số, chỉ là tôi có thể tạo nó thành URL.

— ripper234

42

FYI, http://username:password@example.comđịnh dạng không còn được hỗ trợ bởi IE hoặc Chrome , sẽ không ngạc nhiên nếu những người khác làm theo nếu họ chưa có.

— TJ Crowder

11

Thực tế hoạt động tốt trong Chrome. Chỉ có IE là một đứa trẻ hư hỏng.

— Damien Overeem

1

@DamienOvereem phiên bản chrome của bạn trên? Tôi đang dùng mac os x 37 và nó dường như không hoạt động với tôi

— Chris DaMour

11

Tôi đã biết rằng Chrome đã bị vô hiệu hóa trong một thời gian, nhưng đã bật lại tính năng này sau. Tôi cũng đã học được rằng Safari sẽ đưa ra các lỗi lừa đảo khi chạy vào các loại liên kết này .. Về cơ bản thời gian xác thực http dựa trên url đã kết thúc ..

— Damien Overeem

18

Truyền các tham số xác thực cơ bản trong URL không được đề xuất

Có một trường tiêu đề ủy quyền cho mục đích này kiểm tra nó ở đây: danh sách tiêu đề http

Cách sử dụng được viết tại đây: Xác thực truy cập cơ bản

Ở đó bạn cũng có thể đọc rằng mặc dù nó vẫn được một số trình duyệt hỗ trợ, giải pháp đề xuất thêm thông tin ủy quyền cơ bản trong url không được khuyến nghị.

Đọc thêm chương 4.1 trong RFC 2617 - Xác thực HTTP để biết thêm chi tiết về lý do KHÔNG sử dụng Xác thực cơ bản.

Truyền tham số xác thực trong chuỗi truy vấn

Khi sử dụng OAuth hoặc các dịch vụ xác thực khác, bạn cũng thường có thể gửi mã thông báo truy cập của mình trong chuỗi truy vấn thay vì trong tiêu đề ủy quyền, vì vậy đại loại như:

GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD

— Héo
nguồn

Và làm thế nào để đi về việc mã hóa một tiêu đề Ủy quyền thành một URL?

— womble

2

Không phải đó là hình thức bạn đã nêu bây giờ không được chấp nhận?

— womble

2

Câu hỏi bạn đã trả lời với "Có trường tiêu đề ủy quyền cho mục đích này" là hỏi cách đặt tham số xác thực vào URL . Nếu bạn không thể mã hóa các trường tiêu đề HTTP thành một URL (mà bạn không thể), câu trả lời của bạn là không theo thứ tự.

— womble

Bạn có thể trích dẫn nơi tiêu chuẩn URI nói rằng việc truyền tham số xác thực cơ bản trong URI không được chấp nhận? RFC 2396 chỉ nói rằng đó là "KHÔNG ĐƯỢC KHUYẾN NGHỊ" bởi vì chi tiết xác thực trong văn bản thuần túy, trong nhiều trường hợp, không phải là một ý tưởng tốt (trong đó tôi đồng ý), trong khi RFC 7235 không đề cập gì. Không ở đâu trong thông số kỹ thuật tôi có thể tìm kiếm nói rằng nó không dùng nữa.

— Lie Ryan

1

@Wilt: Tôi phải xin lỗi, bạn thực sự đúng. Gợi ý của bạn rằng thông số kỹ thuật đã bị "thay đổi" đã thúc đẩy tôi điều tra thêm (một RFC không bao giờ được sửa đổi một khi nó được xuất bản / đánh số). Tôi chỉ thấy rằng RFC 2396 thực sự đã được thay thế bởi RFC 3986 , mà tôi không thể tìm thấy trước đó. RFC 3986 không đề cập đến sự phản đối của tên người dùng: cú pháp mật khẩu:Use of the format "user:password" in the userinfo field is deprecated.

— Lie Ryan

17

http: // tên người dùng: password@example.com sẽ hoạt động cho FireFox, Chrome, Safari NHƯNG không dành cho IE.

Cơ sở tri thức Microsoft

— Girish Kumar
nguồn

2

Khả năng này đã bị xóa khỏi Chrome 19+. Xem code.google.com/p/chromium/issues/detail?id=123150

— Moshe Katz

4

Khi tôi đọc báo cáo lỗi đó, nó đã được thêm lại vào Chrome 20. Chắc chắn, tôi hy vọng sẽ thấy rất nhiều người tiếp tục phàn nàn về nó nếu nó không xảy ra.

— womble

Bây giờ tôi đã yêu cầu nó cho Internet Explorer: connect.microsoft.com/IE/feedback/details/873575/ mẹo . Trường hợp sử dụng hơi khác nhau, nhưng giải quyết cùng một vấn đề;)

— SimonSimCity

@Diago nếu mật khẩu chứa '@' thì nó không hoạt động. nó gây ra lỗi nghiêm trọng, bất cứ ai cũng có thể cho tôi biết làm thế nào chúng ta có thể cung cấp tên người dùng và mật khẩu cùng một lúc

— Ashish Jain

@AshishJain - Tôi sẽ thử thoát @mật khẩu dưới dạng %40. (Tuy nhiên, tôi không biết liệu nó có hoạt động hay không và nó có thể phụ thuộc vào máy chủ hoặc kết hợp trình duyệt / máy chủ.)

— David Moles

0

Rõ ràng là có thể gửi bất kỳ chuỗi nào trong các tham số GET, mặc dù không nên gửi thông tin đăng nhập và mật khẩu vì có thể làm cho nó hiển thị cao, đặc biệt nếu đó không phải trong yêu cầu AJAX.

Tuy nhiên, bạn sẽ cần mã hóa trang máy chủ để trích xuất thông tin đăng nhập và mật khẩu, sau đó xác nhận và sử dụng chúng theo bất kỳ cách nào được yêu cầu.

— Steve Smith
nguồn