2009-05-21 26 views
41

Giả sử tôi thiết lập một máy chủ web php đơn giản với một trang có thể được truy cập bằng HTTPS. URL có các thông số đơn giản, như https://www.example.com/test?abc=123.Nếu bạn sử dụng HTTPS, thông số URL của bạn sẽ an toàn khi đánh hơi?

Có đúng là tham số ở đây trong trường hợp này sẽ an toàn với những người ngửi gói dữ liệu không? Và điều này có đúng không nếu máy chủ không sử dụng bất kỳ chứng chỉ SSL nào?

Trả lời

5

phụ thuộc vào những gì bạn có nghĩa là bởi an toàn

SSL mã hóa toàn bộ yêu cầu HTTP/Đáp lại, vì vậy các URL trong phần GET sẽ được mã hóa. Điều này không ngăn chặn các cuộc tấn công MITM và tham nhũng của tính toàn vẹn của phiên SSL. Nếu một chứng chỉ không có thẩm quyền được sử dụng, điều này làm cho các vector tấn công tiềm năng đơn giản hơn.

Are REST request headers encrypted by SSL?

Là một câu hỏi tương tự.

46

http://answers.google.com/answers/threadview/id/758002.html

HTTPS Thiết lập một cơ SSL conenction trước khi bất kỳ dữ liệu HTTP là chuyển. Điều này đảm bảo rằng tất cả URL dữ liệu (ngoại trừ tên máy chủ, được sử dụng để thiết lập kết nối ) chỉ được thực hiện trong phạm vi kết nối được mã hóa này và được bảo vệ khỏi các cuộc tấn công theo cách tương tự bất kỳ dữ liệu HTTPS nào.

Mọi giao dịch HTTP cấp trong phạm vi kết nối HTTPS được tiến hành trong vòng phiên SSL được thiết lập, và không có dữ liệu truy vấn được chuyển giao trước khi kết nối an toàn được thành lập.

Từ bên ngoài, dữ liệu duy nhất là hiển thị với thế giới tên máy chủ và cổng bạn đang kết nối. Mọi thứ khác chỉ đơn giản là luồng dữ liệu nhị phân được mã hóa bằng cách sử dụng khóa riêng chỉ được chia sẻ giữa bạn và máy chủ.

Trong ví dụ bạn cung cấp trình duyệt của bạn sẽ làm điều này:

  1. Rút ra hostname (và cổng nếu có) từ từ URL.
  2. Kết nối với máy chủ lưu trữ.
  3. Giấy chứng nhận kiểm tra (nó phải được 'ký' ' bởi cơ quan đã biết, áp dụng cụ thể để sửa địa chỉ IP và cổng và là hiện tại).
  4. Trình duyệt và máy chủ trao đổi dữ liệu mật mã và trình duyệt nhận khóa riêng tư.
  5. Yêu cầu HTTP được thực hiện, được mã hóa bằng mật mã được thiết lập.
  6. Đã nhận được phản hồi HTTP. Cũng được mã hóa.

HTTP là giao thức 'Lớp ứng dụng' , giao thức này được mang lên trên lớp bảo mật . Theo thông số kỹ thuật SSL , soạn thảo bởi Netscape, mệnh lệnh mà không có lớp ứng dụng dữ liệu có thể được truyền cho đến khi một kết nối an toàn được thành lập - như nêu trong đoạn sau đây:

"Tại thời điểm này, một sự thay đổi mật mã đặc tả nhắn được gửi bởi các khách hàng, và bản client đang chờ Cipher Spec vào Cipher Spec hiện hành. các khách hàng sau đó ngay lập tức gửi nhắn xong dưới mới thuật toán, chìa khóa, và bí mật. Trong đáp lại, máy chủ sẽ gửicủa chính nóthay đổi thông số kỹ thuật mã hóa, chuyển đang chờ xử lý tới Mã hóa hiện tại Spec và gửi thông báo hoàn thành theo Thông số kỹ thuật mã hóa mới. Tại thời điểm này, những cái bắt tay hoàn tất và client và server có thể bắt đầu dữ liệu lớp ứng dụng giá hối đoái." http://wp.netscape.com/eng/ssl3/draft302.txt

Vì vậy, có. Các dữ liệu chứa trong các truy vấn URL trên một kết nối HTTPS là mã hóa. Tuy nhiên nó là rất nghèo thực hành bao gồm như nhạy cảm dữ liệu như một mật khẩu trong một 'GET' yêu cầu. trong khi nó có thể không được chặn, các dữ liệu sẽ được ghi lại trong máy chủ văn bản thô trên nhận máy chủ HTTPS và hoàn toàn cũng có thể trong lịch sử trình duyệt. Nó có lẽ là cũng có sẵn cho trình duyệt plugins và thậm chí có thể cả các ứng dụng khác trên máy khách. Tại hầu hết URL HTTPS có thể là được cho phép hợp lý để bao gồm ID phiên hoặc biến số không thể sử dụng lại tương tự . KHÔNG BAO GIỜ chứa mã thông báo xác thực tĩnh.

Khái niệm kết nối HTTP là nhất giải thích rõ ràng ở đây: (?/Test abc = 123) http://www.ourshop.com/resources/ssl_step1.html

+1

+1 cho thông số nhạy cảm không được gửi trong yêu cầu GET – jah

+8

-1 vì không đề cập đến nguồn của bạn: http://answers.google.com/answers/threadview/id/758002.html – Bruno

+0

+1 cho mọi thứ được mã hóa ngoại trừ tên máy chủ – Yadu

7

Các yêu cầu URI được gửi đến máy chủ web như một phần của yêu cầu HTTP header và do đó được mã hóa .

Tuy nhiên, URL có thể bị rò rỉ theo các cách khác, thường là thanh công cụ trình duyệt web, dấu trang và gửi liên kết tới bạn bè. Dữ liệu đăng có thể phù hợp hơn tùy thuộc vào ngữ cảnh/độ nhạy của dữ liệu bạn đang gửi.

Tôi tin rằng kết nối HTTPS yêu cầu chứng chỉ SSL, thậm chí là một chứng chỉ tự tạo nếu bạn không muốn mua.

Hy vọng rằng sẽ giúp ích một chút!

2

Url: s sẽ được lưu trữ cả trong nhật ký máy chủ và trong lịch sử trình duyệt, do đó ngay cả khi chúng không bị phát hiện thì chúng không an toàn.

+1

+1 cho các thông số nhạy cảm sẽ không được gửi trong yêu cầu GET – jah

63

Có URL của bạn sẽ an toàn khi đánh hơi; tuy nhiên, một lỗ dễ bị bỏ qua là nếu trang của bạn tham chiếu bất kỳ tài nguyên của bên thứ ba nào như Google Analytics, Thêm Nội dung bất kỳ, toàn bộ URL của bạn sẽ được gửi tới bên thứ ba trong phần giới thiệu. Nếu nó thực sự nhạy cảm thì nó không thuộc về chuỗi truy vấn.

Đối với phần thứ hai của câu hỏi, bạn không thể sử dụng SSL nếu bạn không có chứng chỉ trên máy chủ.

+0

Tại sao một lưu ý lại? URL của bạn được gửi đến với tư cách người giới thiệu để truy xuất tất cả nội dung được liên kết của bạn. – JoshBerke

+4

+1 cho các thông số nhạy cảm không được gửi trong yêu cầu GET – jah

1

Trên dây, có. Tại các điểm cuối (trình duyệt và máy chủ) không nhất thiết. SSL/TLS là transport layer security. Nó sẽ mã hóa lưu lượng truy cập của bạn giữa trình duyệt và máy chủ. Có thể ở phía trình duyệt để xem nhanh dữ liệu (ví dụ: BHO). Một khi nó đạt đến phía máy chủ, nó có sẵn cho người nhận tất nhiên và chỉ là an toàn như ông đối xử với nó. Nếu dữ liệu cần di chuyển an toàn vượt ra ngoài trao đổi ban đầu và được bảo vệ khỏi con mắt tò mò trên máy khách, bạn cũng nên xem message layer security.

1

SSL/TSL là bảo mật lớp truyền tải, có dữ liệu có thể được chọn với BHO (như @JP đã viết) hoặc bất kỳ bổ sung nào nhưng cũng có trình gỡ lỗi HTTP "ngoài trình duyệt". Họ đọc tin nhắn giữa winsock32 và ứng dụng. Việc mã hóa diễn ra trong winsock32 không có trong trình duyệt.

Hãy xem (phần này được taked từ trang của IEinspector): IEInspector HTTP Analyzer là một công cụ hữu ích như vậy cho phép bạn giám sát, theo dõi, gỡ lỗi và phân tích HTTP/HTTPS giao thông trong thời gian thực.

Các vấn đề liên quan