URL HTTPS có được mã hóa không?

1020

Tất cả các URL có được mã hóa khi sử dụng mã hóa TLS / SSL (HTTPS) không? Tôi muốn biết vì tôi muốn tất cả dữ liệu URL bị ẩn khi sử dụng TLS / SSL (HTTPS).

Nếu TLS / SSL cung cấp cho bạn toàn bộ mã hóa URL thì tôi không phải lo lắng về việc ẩn thông tin bí mật khỏi URL.

ssl  https  httprequest 
— Daniel Kivatinos
nguồn
76
Có lẽ đó là một ý tưởng tồi để đưa dữ liệu bí mật vào URL. Nó cũng sẽ bị hiển thị trong địa chỉ của trình duyệt. Mọi người không thích nó nếu mật khẩu của họ hiển thị cho bất cứ ai tình cờ nhìn vào màn hình. Tại sao bạn nghĩ rằng bạn cần phải đưa dữ liệu bí mật vào URL?
— jalf
43
URL cũng được lưu trữ trong lịch sử trình duyệt và nhật ký máy chủ - nếu tôi muốn lưu tên và mật khẩu của mình ở đâu đó, thì nó sẽ không ở hai nơi này.
— Piskvor rời khỏi tòa nhà vào
47
Ví dụ, giả sử tôi ghé thăm https://somewhere_i_trust/ways_to_protest_against_the_government/. Sau đó, URL chứa dữ liệu bí mật, cụ thể là đề xuất mà tôi đang xem xét phản đối chính phủ của mình.
— Steve Jessop
42
Tôi đã tự hỏi mình câu hỏi này khi thực hiện một yêu cầu HTTP từ Ứng dụng gốc (không dựa trên trình duyệt). Tôi đoán điều này có thể khiến các nhà phát triển ứng dụng di động quan tâm. Trong trường hợp này, các nhận xét ở trên (trong khi đúng) là không liên quan (không hiển thị url, không có lịch sử duyệt web), làm cho câu trả lời, theo cách hiểu của tôi đơn giản: "Có, nó được mã hóa".
— DannyA
23
Đối với những người nghĩ rằng một khi bạn là HTTPS, không ai biết bạn sẽ đi đâu, hãy đọc phần này trước: Tên máy chủ của máy chủ (ví dụ example.com) sẽ vẫn bị rò rỉ do SNI . Điều này hoàn toàn không liên quan gì đến DNS và rò rỉ sẽ xảy ra ngay cả khi bạn không sử dụng DNS hoặc sử dụng DNS được mã hóa.
— Pacerier

Câu trả lời:

913

Có, kết nối SSL nằm giữa lớp TCP và lớp HTTP. Trước tiên, máy khách và máy chủ thiết lập kết nối TCP được mã hóa an toàn (thông qua giao thức SSL / TLS) và sau đó máy khách sẽ gửi yêu cầu HTTP (GET, POST, DELETE ...) qua kết nối TCP được mã hóa đó.

— Marc Novakowski
nguồn
98
Nó vẫn đáng chú ý điều được đề cập bởi @Jalf trong bình luận về chính câu hỏi. Dữ liệu URL cũng sẽ được lưu trong lịch sử của trình duyệt, điều này có thể không an toàn lâu dài.
— Michael Ekstrand
20
Không chỉ NHẬN hoặc POST. Cũng có thể XÓA, PUT, ĐẦU hoặc TRACE.
4
Vâng, nó có thể là một vấn đề bảo mật cho lịch sử của trình duyệt. Nhưng trong trường hợp của tôi, tôi không sử dụng trình duyệt (bài viết gốc cũng không đề cập đến trình duyệt). Sử dụng cuộc gọi https tùy chỉnh phía sau hậu trường trong ứng dụng gốc. Đó là một giải pháp đơn giản để đảm bảo kết nối sever của ứng dụng của bạn được an toàn.
— zingle-dingle
28
Tuy nhiên, xin lưu ý rằng độ phân giải DNS của URL có thể không được mã hóa. Vì vậy, ai đó đánh hơi lưu lượng truy cập của bạn vẫn có thể thấy tên miền bạn đang cố truy cập.
— ChewToy
21
SNI phá vỡ phần 'máy chủ' trong mã hóa SSL của URL. Bạn có thể tự kiểm tra điều này với wireshark. Có một bộ chọn cho SNI hoặc bạn chỉ có thể xem lại các gói SSL của mình khi bạn kết nối với máy chủ từ xa.
— cmouse
654

Vì không ai cung cấp một dây chụp, đây là một.
Tên máy chủ (phần tên miền của URL) được trình bày trong ClientHellogói, dưới dạng văn bản thuần túy .

Sau đây cho thấy một yêu cầu trình duyệt để:
https://i.stack.imgur.com/path/?some=parameters&go=here

Khách hàng SNello Xem câu trả lời này để biết thêm về các trường phiên bản TLS (có 3 trong số chúng - không phải phiên bản, các trường mà mỗi trường chứa một số phiên bản!)

Từ https://www.ietf.org/rfc/rfc3546.txt :

3.1. Tên máy chủ

[TLS] không cung cấp cơ chế cho khách hàng nói với máy chủ tên của máy chủ mà nó đang liên hệ. Khách hàng có thể mong muốn cung cấp thông tin này để tạo điều kiện cho các kết nối an toàn đến các máy chủ lưu trữ nhiều máy chủ "ảo" tại một địa chỉ mạng cơ bản.

Để cung cấp tên máy chủ, khách hàng CÓ THỂ bao gồm một phần mở rộng của loại "server_name" trong ứng dụng khách (mở rộng) xin chào.


Nói ngắn gọn:

  • FQDN (phần tên miền của URL) CÓ THỂ được truyền rõ ràng bên trong ClientHellogói nếu sử dụng tiện ích mở rộng SNI

  • Phần còn lại của URL ( /path/?some=parameters&go=here) không có doanh nghiệp bên trong ClientHellovì URL yêu cầu là một thứ HTTP (Lớp 7 OSI), do đó, nó sẽ không bao giờ xuất hiện trong một cái bắt tay TLS (Lớp 4 hoặc 5). Điều đó sẽ đến sau này trong một GET /path/?some=parameters&go=here HTTP/1.1yêu cầu HTTP, SAU sự an toàn kênh TLS được thành lập.


TÓM TẮT THỰC HIỆN

Tên miền CÓ THỂ được truyền đi rõ ràng (nếu tiện ích mở rộng SNI được sử dụng trong bắt tay TLS) nhưng URL (đường dẫn và tham số) luôn được mã hóa.


CẬP NHẬT THÁNG 3 NĂM 2019

Cảm ơn bạn carlin.scott đã đưa cái này lên.

Tải trọng trong phần mở rộng SNI hiện có thể được mã hóa thông qua đề xuất RFC dự thảo này . Khả năng này chỉ tồn tại trong TLS 1.3 (dưới dạng tùy chọn và tùy thuộc vào cả hai đầu để thực hiện nó) và không có khả năng tương thích ngược với TLS 1.2 trở xuống.

CloudFlare đang làm điều đó và bạn có thể đọc thêm về các phần bên trong ở đây - Nếu gà phải đến trước trứng, bạn sẽ đặt gà ở đâu?

Trong thực tế, điều này có nghĩa là thay vì truyền FQDN bằng văn bản thuần túy (như chương trình chụp Wireshark), giờ đây nó đã được mã hóa.

LƯU Ý: Điều này giải quyết khía cạnh riêng tư nhiều hơn khía cạnh bảo mật vì việc tra cứu DNS ngược có thể tiết lộ máy chủ đích dự định.

— ácSnobu
nguồn
37
Câu trả lời hoàn hảo, với lời giải thích đầy đủ từ A đến Z. Tôi thích bản tóm tắt của Executive. Làm cho ngày của tôi @evilSnobu
— oscaroscar
4
Câu trả lời hoàn hảo, upvote! Vẫn xem xét phần máy khách vì lịch sử trình duyệt có thể bị rò rỉ. Tuy nhiên, liên quan đến lớp vận chuyển, các tham số URL được mã hóa.
— Jens Kreidler
2
Bạn có thể muốn cập nhật câu trả lời này với thực tế là TLS 1.3 mã hóa phần mở rộng SNI và CDN lớn nhất đang làm điều đó: blog.cloudflare.com/encrypted-sni Tất nhiên một trình thám thính gói chỉ có thể thực hiện tra cứu ngược địa chỉ IP bạn đang kết nối.
— carlin.scott
@evilSnobu, nhưng tên người dùng: mật khẩu một phần của tên người dùng: password@domain.com được mã hóa, phải không? Vì vậy, an toàn để truyền dữ liệu nhạy cảm trong url bằng https.
— Maksim Shamihulau
1
Chúng được mã hóa trên dây (trong vận chuyển) nhưng nếu một trong hai đầu (người dùng hoặc máy chủ) ghi URL vào một tệp văn bản thuần túy và không vệ sinh thông tin đăng nhập ... thì bây giờ đó là một cuộc trò chuyện khác.
— evilSnobu
159

Như các câu trả lời khác đã chỉ ra, https "URL" thực sự được mã hóa. Tuy nhiên, yêu cầu / phản hồi DNS của bạn khi giải quyết tên miền có thể là không, và tất nhiên, nếu bạn đang sử dụng trình duyệt, URL của bạn cũng có thể được ghi lại.

— Zach Scrivena
nguồn
21
Và việc ghi URL rất quan trọng vì có các bản hack Javascript cho phép một trang web hoàn toàn không liên quan để kiểm tra xem một URL đã cho có trong lịch sử của bạn hay không. Bạn có thể tạo một URL không thể truy cập bằng cách bao gồm một chuỗi ngẫu nhiên dài trong đó, nhưng nếu đó là một URL công khai thì kẻ tấn công có thể nói rằng nó đã được truy cập và nếu nó có một bí mật ngắn, thì kẻ tấn công có thể vũ phu rằng ở tốc độ hợp lý.
— Steve Jessop
8
@SteveJessop, vui lòng cung cấp liên kết đến "hack Javascript cho phép một trang web hoàn toàn không liên quan để kiểm tra xem một URL đã cho có trong lịch sử của bạn hay không"
— Pacerier 15/03/2016
6
@Pacerier: tất nhiên là hack ngày, nhưng điều tôi đang nói lúc đó là những thứ như stackoverflow.com/questions/2394890/ . Đó là một vấn đề lớn vào năm 2010 rằng những vấn đề này đã được điều tra và các cuộc tấn công được cải thiện, nhưng tôi không thực sự theo dõi nó vào lúc này.
— Steve Jessop
2
@Pacerier: các ví dụ khác: webdevwonders.com/... , webdevwonders.com/...
— Steve Jessop
1
Bạn có thể sử dụng OpenDNS với dịch vụ DNS được mã hóa. Tôi sử dụng nó trên máy Mac của mình, nhưng tôi thấy phiên bản Windows không hoạt động đúng. Đó là một thời gian trước đây, vì vậy nó có thể hoạt động tốt bây giờ. Đối với Linux chưa có gì. opendns.com/about/innovations/dnscrypt
— XUÂN
101

Toàn bộ yêu cầu và phản hồi được mã hóa, bao gồm URL.

Lưu ý rằng khi bạn sử dụng Proxy HTTP, nó sẽ biết địa chỉ (tên miền) của máy chủ đích, nhưng không biết đường dẫn được yêu cầu trên máy chủ này (tức là yêu cầu và phản hồi luôn được mã hóa).

— Peter ibrtibraný
nguồn
1
Toàn bộ yêu cầu. Tên máy chủ được gửi rõ ràng. Tất cả những thứ khác được mã hóa.
— Sam Sirry
98

Tôi đồng ý với các câu trả lời trước:

Để được rõ ràng:

Với TLS, phần đầu tiên của URL ( https://www.example.com/ ) vẫn hiển thị khi xây dựng kết nối. Phần thứ hai (/ herearemygetparameter / 1/2/3/4) được bảo vệ bởi TLS.

Tuy nhiên, có một số lý do tại sao bạn không nên đặt tham số trong yêu cầu GET.

Đầu tiên, như đã được đề cập bởi những người khác: - rò rỉ qua thanh địa chỉ trình duyệt - rò rỉ qua lịch sử

Ngoài ra, bạn bị rò rỉ URL thông qua người giới thiệu http: người dùng thấy trang A trên TLS, sau đó nhấp vào liên kết đến trang B. Nếu cả hai trang đều trên TLS, yêu cầu đến trang B sẽ chứa URL đầy đủ từ trang A trong tham số tham chiếu của yêu cầu. Và quản trị viên từ trang B có thể truy xuất nó từ tệp nhật ký của máy chủ B.)

— Tobias
nguồn
3
@EJP Bạn không hiểu Tobias đang nói gì. Anh ta nói rằng nếu bạn nhấp vào một liên kết trên trang A sẽ đưa bạn đến trang B, thì trang B sẽ nhận được URL giới thiệu. Ví dụ: nếu bạn đang ở trên trang webA.com?u=username&pw=123123 , thì trang webB.com (được liên kết đến trên trang của trang web.com) sẽ nhận được " siteA.com?u=username&pw=123123 " làm giới thiệu URL, được gửi đến siteB.com bên trong HTTPS bởi trình duyệt. Nếu điều này là đúng, điều đó rất tệ. Đây có phải là Tobias thật không?
— trusktr
9
@EJP, tên miền hiển thị vì SNI mà tất cả các trình duyệt web hiện đại sử dụng. Cũng xem sơ đồ này từ EFF cho thấy rằng bất kỳ ai cũng có thể thấy tên miền của trang web bạn đang truy cập. Đây không phải là về khả năng hiển thị của trình duyệt. Đó là về những gì có thể nhìn thấy đối với những kẻ nghe trộm.
— Buge
10
@trusktr: Trình duyệt không nên gửi tiêu đề Người giới thiệu từ các trang HTTPS. Đây là một phần của đặc tả HTTP .
— Martin Geisler
8
@MartinGeisler, Từ khóa là "nên". Các trình duyệt không quan tâm nhiều đến "nên" (trái ngược với "phải"). Từ liên kết của riêng bạn: "đặc biệt khuyến nghị người dùng có thể chọn có gửi trường Người giới thiệu hay không. Ví dụ: ứng dụng khách trình duyệt có thể có công tắc bật tắt để duyệt một cách mở / ẩn danh, tương ứng sẽ bật / tắt việc gửi Người giới thiệu và Từ thông tin " . Ops, đó chính xác là những gì Chrome đã làm. Ngoại trừ Chrome rò rỉ Trình giới thiệu ngay cả khi bạn đang ở chế độ ẩn danh .
— Pacerier
48

Ngoài ra câu trả lời hữu ích từ Marc Novakowski - URL được lưu trữ trong nhật ký trên máy chủ (ví dụ: trong / etc / httpd / log / ssl_access_log), vì vậy nếu bạn không muốn máy chủ duy trì thông tin lâu hơn hạn, đừng đặt nó trong URL.

— Đỗ quyên
nguồn
34

Có và không.

Phần địa chỉ máy chủ KHÔNG được mã hóa do được sử dụng để thiết lập kết nối.

Điều này có thể thay đổi trong tương lai với SNI và DNS được mã hóa nhưng đến năm 2018 cả hai công nghệ này không được sử dụng phổ biến.

Đường dẫn, chuỗi truy vấn, vv được mã hóa.

Lưu ý đối với các yêu cầu GET, người dùng vẫn có thể cắt và dán URL ra khỏi thanh vị trí và có thể bạn sẽ không muốn đưa thông tin bí mật vào đó mà bất cứ ai nhìn vào màn hình đều có thể nhìn thấy.

— Xà phòng
nguồn
8
Muốn +1 điều này, nhưng tôi thấy "sai và không" gây hiểu lầm - bạn nên thay đổi điều đó để chỉ ra rằng tên máy chủ sẽ được giải quyết bằng DNS mà không cần mã hóa.
— Lawrence Dol
7
Theo hiểu biết của tôi, OP sử dụng URL từ theo đúng nghĩa. Tôi nghĩ rằng câu trả lời này dễ gây hiểu lầm hơn, vì nó không tạo ra sự khác biệt rõ ràng giữa tên máy chủ trong URL và tên máy chủ trong độ phân giải DNS.
— Guillaume
4
URL được mã hóa. Mọi khía cạnh của giao dịch HTTP đều được mã hóa. Không chỉ là "mọi thứ khác". Giai đoạn = Stage. -1.
— Hầu tước Lorne
4
@EJP nhưng việc tra cứu DNS không sử dụng phần nào tại một điểm của URL, do đó, đối với người không có kỹ thuật, toàn bộ URL không được mã hóa. Người phi kỹ thuật chỉ đơn thuần sử dụng Google.com để tìm kiếm những thứ phi kỹ thuật không biết dữ liệu cuối cùng nằm ở đâu hoặc cách xử lý. Tên miền, một phần của URL mà người dùng đang truy cập, không được mã hóa 100% vì tôi là kẻ tấn công có thể đánh hơi được trang web nào anh ta đang truy cập. Chỉ / đường dẫn của URL vốn được mã hóa cho cư sĩ (không quan trọng bằng cách nào).
— trusktr
6
@EJP, @ trusktr, @ Lawrence, @ Guillaume. Tất cả các bạn đều nhầm. Điều này không có gì để làm với DNS. SNI " gửi tên miền ảo như một phần của đàm phán TLS ", vì vậy ngay cả khi bạn không sử dụng DNS hoặc nếu DNS của bạn được mã hóa, một sniffer vẫn có thể thấy tên máy chủ của các yêu cầu của bạn.
— Pacerier
9

Bên thứ ba đang theo dõi lưu lượng truy cập cũng có thể xác định trang được truy cập bằng cách kiểm tra lưu lượng truy cập của bạn so sánh lưu lượng truy cập mà người dùng khác có khi truy cập trang web. Ví dụ: nếu chỉ có 2 trang trên một trang web, một trang lớn hơn nhiều so với trang kia, thì so sánh kích thước truyền dữ liệu sẽ cho biết trang nào bạn đã truy cập. Có nhiều cách điều này có thể bị ẩn khỏi bên thứ ba nhưng chúng không phải là hành vi bình thường của máy chủ hoặc trình duyệt. Xem ví dụ bài viết này từ SciRate, https://scirate.com/arxiv/1403.0297 .

Nói chung, các câu trả lời khác đều đúng, thực tế mặc dù bài báo này cho thấy các trang được truy cập (tức là URL) có thể được xác định khá hiệu quả.

— pbhj
nguồn
Điều đó thực sự sẽ chỉ khả thi trên các trang web rất nhỏ và trong những trường hợp đó, chủ đề / tông màu / tính chất của trang web có thể vẫn giống nhau trên mỗi trang.
— Cameron
5
Từ trích dẫn tôi đã đưa ra: "Chúng tôi trình bày một cuộc tấn công phân tích lưu lượng truy cập vào hơn 6000 trang web trải rộng trên 10 triển khai HTTPS của 10 trang web dẫn đầu ngành được sử dụng rộng rãi trong các lĩnh vực như chăm sóc sức khỏe, tài chính, dịch vụ pháp lý và phát trực tuyến video. cùng một trang web với độ chính xác 89% [...] ". Có vẻ như kết luận của bạn về tính khả thi là sai.
— pbhj
2
Đối với bất kỳ ai thú vị khi đọc thêm về loại lỗ hổng này, các loại tấn công này thường được gọi là các cuộc tấn công kênh bên .
— Dan Bechard
7

Bạn cũng không thể luôn tin tưởng vào quyền riêng tư của URL đầy đủ. Chẳng hạn, đôi khi như trên các mạng doanh nghiệp, các thiết bị được cung cấp như PC của công ty bạn được định cấu hình với chứng chỉ gốc "đáng tin cậy" để trình duyệt của bạn có thể tin tưởng một cách kiểm tra lưu lượng truy cập https (trung gian) . Điều này có nghĩa là URL đầy đủ được hiển thị để kiểm tra. Điều này thường được lưu vào một bản ghi.

Hơn nữa, mật khẩu của bạn cũng bị lộ và có thể được ghi lại và đây là một lý do khác để sử dụng mật khẩu một lần hoặc để thay đổi mật khẩu thường xuyên.

Cuối cùng, nội dung yêu cầu và phản hồi cũng được phơi bày nếu không được mã hóa.

Một ví dụ về thiết lập kiểm tra được mô tả bởi Checkpoint tại đây . Một "quán cà phê internet" kiểu cũ sử dụng PC được cung cấp cũng có thể được thiết lập theo cách này.

— Don Gillis
nguồn
6

Liên kết với câu trả lời của tôi trên một câu hỏi trùng lặp . URL không chỉ có sẵn trong lịch sử trình duyệt, phía máy chủ ghi nhật ký mà còn được gửi dưới dạng tiêu đề HTTP Referenceer mà nếu bạn sử dụng nội dung của bên thứ ba, sẽ hiển thị URL cho các nguồn ngoài tầm kiểm soát của bạn.

— JoshBerke
nguồn
Cung cấp các cuộc gọi bên thứ ba của bạn là HTTPS mặc dù điều này không phải là vấn đề phải không?
— Liam
3
Nó sẽ được mã hóa với chứng chỉ của bên thứ ba để họ có thể thấy URL
— JoshBerke
5

Bây giờ là năm 2019 và TLS v1.3 đã được phát hành. Theo Cloudflare, SNI có thể được mã hóa nhờ TLS v1.3. Vì vậy, tôi đã nói với bản thân mình tuyệt vời! hãy xem giao diện của các gói TCP của cloudflare.com như thế nào Tôi vẫn có thể đọc tên máy chủ bằng văn bản đơn giản trong gói Hello của khách hàng.

nhập mô tả hình ảnh ở đây

Vì vậy, hãy cẩn thận với những gì bạn có thể đọc bởi vì đây vẫn không phải là một kết nối ẩn danh. Một phần mềm trung gian giữa máy khách và máy chủ có thể ghi nhật ký mọi miền được khách hàng yêu cầu.

Vì vậy, có vẻ như mã hóa của SNI yêu cầu triển khai bổ sung để hoạt động cùng với TLSv1.3

Bài viết sau đây mô tả mã hóa SNI do Cloudflare cung cấp như một phần của TLSv1.3. Tuy nhiên, tất cả các URL HTTP từ cloudflare.com đều ở dạng văn bản thuần trong gói TCP trong TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/[[3]

— Nicolas Guérinet
nguồn
"SNI có thể được mã hóa" - đó là điểm chính. Kiểm tra cloudflare.com/ssl/encrypted-sni bằng Google Chrome hiện tại cho biết "Trình duyệt của bạn không mã hóa SNI khi truy cập trang này." Phải mất hai đến tango ...
— Piskvor rời khỏi tòa nhà
Rõ ràng Firefox hiện tại có thể thực hiện ESNI, nhưng nó bị tắt theo mặc định: bạn cần bật network.security.esni.enabled, đặt network.trr.modethành 2 (hiện đang đặt trình phân giải DoH của bạn thành CloudFlare) và khởi động lại trình duyệt (sic!); sau đó, nó sẽ sử dụng ESNI - nơi được hỗ trợ bởi cơ sở hạ tầng của tên miền. Xem blog.mozilla.org/security/2018/10/18/ Khăn để biết chi tiết.
— Piskvor rời khỏi tòa nhà
2

Mặc dù đã có một số câu trả lời hay ở đây, nhưng hầu hết chúng đều tập trung vào điều hướng trình duyệt. Tôi đang viết bài này vào năm 2018 và có lẽ ai đó muốn biết về tính bảo mật của ứng dụng di động.

Đối với ứng dụng dành cho thiết bị di động , nếu bạn kiểm soát cả hai đầu của ứng dụng (máy chủ và ứng dụng), miễn là bạn sử dụng HTTPS thì bạn an toàn . iOS hoặc Android sẽ xác minh chứng chỉ và giảm thiểu các cuộc tấn công MiM có thể xảy ra (đó sẽ là điểm yếu duy nhất trong tất cả những điều này). Bạn có thể gửi dữ liệu nhạy cảm thông qua các kết nối HTTPS rằng nó sẽ được mã hóa trong quá trình vận chuyển . Chỉ cần ứng dụng của bạn và máy chủ sẽ biết bất kỳ tham số nào được gửi qua https.

"Có thể" duy nhất ở đây sẽ là nếu máy khách hoặc máy chủ bị nhiễm phần mềm độc hại có thể xem dữ liệu trước khi được bọc trong https. Nhưng nếu ai đó bị nhiễm loại phần mềm này, họ sẽ có quyền truy cập vào dữ liệu, bất kể bạn sử dụng gì để vận chuyển nó.

— Ricardo BRGWeb
nguồn
1

Ngoài ra, nếu bạn đang xây dựng API ReSTful, các sự cố rò rỉ trình duyệt và giới thiệu http chủ yếu được giảm thiểu vì máy khách có thể không phải là trình duyệt và bạn có thể không có người nhấp vào liên kết.

Nếu đây là trường hợp tôi khuyên bạn nên đăng nhập oAuth2 để lấy mã thông báo mang. Trong trường hợp đó, dữ liệu nhạy cảm duy nhất sẽ là thông tin xác thực ban đầu ... có lẽ nên có trong một yêu cầu bài viết

— Chris Rutledge
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.