https có mã hóa toàn bộ URL không?

Question

Tôi googled rất nhiều và nhiều câu trả lời là Có. Ví dụ: Is GET data also encrypted in HTTPS? Nhưng kỹ sư bảo mật cao cấp trong công ty của chúng tôi đã nói với tôi rằng URL sẽ không được mã hóa.

Hình ảnh, nếu URL được mã hóa, máy chủ DNS sẽ tìm máy chủ lưu trữ và kết nối như thế nào?

Tôi nghĩ đây là điểm rất mạnh mặc dù nó chống lại hầu hết các câu trả lời. Vì vậy, tôi thực sự bối rối và các câu hỏi của tôi là:

1. https có mã hóa mọi thứ trong yêu cầu không? (bao gồm URL, máy chủ, đường dẫn, thông số, tiêu đề)
2. Nếu có, cách máy chủ DNS giải mã yêu cầu và gửi nó đến máy chủ lưu trữ?

tôi đã cố gắng để truy cập https://www.amazon.com/gp/css/homepage.html/ref=ya_surl_youracct và IE của tôi gửi hai yêu cầu đến máy chủ:

Đầu tiên:

CONNECT www.amazon.com:443 HTTP/1.0 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: www.amazon.com 
Content-Length: 0 
DNT: 1 
Connection: Keep-Alive 
Pragma: no-cache 

Thứ hai:

GET /gp/css/homepage.html/ref=ya_surl_youracct HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: en-US,zh-CN;q=0.5 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: www.amazon.com 
DNT: 1 
Connection: Keep-Alive 

Dường như trình duyệt của tôi đã yêu cầu hai lần : lần đầu tiên là thiết lập kết nối với máy chủ (không mã hóa) và lần thứ hai gửi yêu cầu được mã hóa qua https? Tôi có đúng không? Nếu tôi hiểu điều này một cách chính xác, khi một khách hàng gọi API RESTFUL bằng cách sử dụng https, nó sẽ gửi các yêu cầu (kết nối và nhận/đăng) hai lần mỗi lần?

Answer 1

URL IS được mã hóa từ khi rời khỏi trình duyệt cho đến khi trình duyệt truy cập máy chủ đích.

gì xảy ra là trình duyệt chiết xuất các tên miền và các cổng từ URL và sử dụng rằng để giải quyết DNS riêng của mình. Sau đó, nó bắt đầu một kênh được mã hóa đến cổng IP của máy chủ đích: cổng. Sau đó, nó sẽ gửi một yêu cầu HTTP thông qua kênh được mã hóa đó.

Phần quan trọng là bất cứ ai nhưng bạn và máy chủ đích chỉ có thể thấy rằng bạn đang kết nối đến một địa chỉ IP cụ thể và cổng. Họ không thể nói bất cứ điều gì khác (như các URL cụ thể, các tham số GET, vv).

Những kẻ tấn công thậm chí không thể nhìn thấy miền trong hầu hết các trường hợp (dù họ có thể suy ra nó nếu có thực sự là một tra cứu DNS - nếu nó không được lưu trữ).

Điều quan trọng cần hiểu là DNS (Dịch vụ tên miền) là một dịch vụ hoàn toàn khác với giao thức khác với HTTP. Trình duyệt làm cho các yêu cầu tra cứu DNS chuyển đổi tên miền thành địa chỉ IP. Sau đó, nó sử dụng địa chỉ IP đó để đưa ra yêu cầu HTTP.

Nhưng không lúc nào không máy chủ DNS nhận được một yêu cầu HTTP, và tại không có thời gian nào nó thực sự làm bất cứ điều gì khác hơn là cung cấp một miền tên - mapping IP cho người dùng.

Answer 2

URL (còn được gọi là "Uniform Resource Locator") gồm bốn phần:

1. Protocol (ví dụ https)
2. Host name (ví dụ stackoverflow.com)
3. Port (không được tích hợp , điển hình là 80 cho http và 443 cho https)
4. Đường dẫn và tên file hoặc truy vấn

Một số ví dụ:

ftp://www.ftp.org/docs/test.txt 
mailto:user@test101.com 
news:soc.culture.Singapore 
telnet://www.test101.com/ 

URL dưới dạng toàn bộ đơn vị không thực sự được mã hóa vì nó không được chuyển toàn bộ. URL thực sự được tách ra thành từng bit và mỗi phần được sử dụng theo nhiều cách khác nhau. Ví dụ. phần giao thức sẽ thông báo cho trình duyệt của bạn cách sử dụng phần còn lại của URL, tên máy chủ sẽ cho biết cách tìm địa chỉ IP của người nhận dự kiến ​​và cổng sẽ cho biết, tốt, cổng nào sẽ sử dụng. Phần duy nhất của URL được truyền trong chính tải trọng là đường dẫn và truy vấn, và phần đó được mã hóa.

Nếu bạn có một cái nhìn tại một yêu cầu HTTP trong thô, nó trông giống như sau:

GET /docs/index.html HTTP/1.1 
Host: www.test101.com 
Accept: image/gif, image/jpeg, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 
(blank line) 
--Body goes here-- 

Những gì bạn thấy trong ví dụ trên được thông qua. Lưu ý rằng URL đầy đủ sẽ xuất hiện ở đâu đó. Các tiêu đề máy chủ thực sự có thể được bỏ qua hoàn toàn (nó không được sử dụng để định tuyến).Phần duy nhất của URL xuất hiện ở đây là bên phải động từ GET và chỉ bao gồm phần ngoài cùng bên phải của URL gốc. Giao thức và số cổng xuất hiện ở đâu đó trong chính thư đó.

Câu trả lời ngắn: Tất cả mọi thứ ở bên phải của số cổng trong URL được bao gồm trong payload của yêu cầu https và thực chất là được mã hóa.

Answer 3

Trong khi các phản hồi khác là chính xác cho đến thời điểm này, thì có nhiều cân nhắc khác hơn là chỉ mã hóa giữa trình duyệt và máy chủ. Dưới đây là một số điều cần suy nghĩ về ...

• Địa chỉ IP của máy chủ được giải quyết.
• Trình duyệt tạo kết nối socket TCP tới địa chỉ IP của máy chủ bằng TLS. Đây là CONNECT bạn thấy trong ví dụ của bạn.
• Yêu cầu được gửi đến máy chủ qua phiên được mã hóa.

Nếu đây là tất cả, bạn đã hoàn tất. Không vấn đề gì.

Nhưng hãy đợi, còn nhiều hơn nữa!

Có các trường trong một GET thay vì một POST tiết lộ dữ liệu nhạy cảm khi ...

• Có người sẽ tìm trong các bản ghi máy chủ. Đây có thể là một nhân viên snoopy, nhưng nó cũng có thể là NSA hoặc cơ quan chính phủ ba chữ cái khác, hoặc các bản ghi có thể trở thành hồ sơ công khai nếu subpoenaed trong một thử nghiệm.
• Kẻ tấn công làm cho mã hóa trang web quay trở lại văn bản rõ ràng hoặc mật mã bị hỏng. Hãy xem the SSL checker từ phòng thí nghiệm của Qualsys để xem liệu trang web có dễ bị tổn thương đến điều này không.
• Bất kỳ liên kết trên trang đến một trang web bên ngoài sẽ hiển thị các URI của trang như giới thiệu. ID người dùng và mật khẩu vô ý thường được đưa ra trong thời trang này cho các mạng quảng cáo. Đôi khi tôi phát hiện ra điều này trong blog của riêng tôi.
• URL có sẵn trong lịch sử trình duyệt và do đó có thể truy cập được vào tập lệnh. Nếu máy tính được công khai (ai đó kiểm tra trang web của bạn từ máy tính khách trong phòng khách sạn hoặc sân bay), hãy yêu cầu dữ liệu rò rỉ yêu cầu GET cho bất kỳ ai khác sử dụng thiết bị đó.

Như tôi đã đề cập, đôi khi tôi tìm thấy ID, mật khẩu và thông tin nhạy cảm khác trong nhật ký liên kết giới thiệu của blog của tôi. Trong trường hợp của tôi, tôi liên hệ với chủ sở hữu của trang giới thiệu và nói với họ rằng họ đang vạch trần người dùng của họ để hack. Một người ít nghiêm túc hơn sẽ thêm nhận xét hoặc cập nhật cho trang web với các liên kết đến trang web của riêng họ, với mục đích thu thập dữ liệu nhạy cảm trong nhật ký liên kết giới thiệu của họ.

Vì vậy, kỹ sư bảo mật cao cấp của công ty bạn chính xác là URL không được mã hóa ở nhiều nơi mà điều cực kỳ quan trọng là làm như vậy. Bạn và những người trả lời khác cũng chính xác rằng nó là được mã hóa trong trường hợp sử dụng rất hẹp của trình duyệt nói chuyện với máy chủ trong ngữ cảnh của phiên TLS. Có lẽ sự nhầm lẫn bạn đề cập đến phải làm với sự khác biệt trong phạm vi của hai trường hợp sử dụng này.

Xin vui lòng xem thêm:

• Testing for Exposed Session Variables (OTG-SESS-004)
• Session Management - How to protect yourself (Lưu ý rằng "luôn luôn sử dụng POST" được lặp lại nhiều lần trên trang này.)
• Client account hijacking through abusing session fixation on the provider