Việc sử dụng HTTP POST so với HTTP GET cho các hoạt động chỉ đọc (hoặc truy vấn) trong các API REST gần đây đã được đưa ra trong một cuộc trò chuyện. Đối với cửa hàng cụ thể này, đã có lệnh cấm từ lâu đối với việc sử dụng GET…

Bạn đang xem: get vs post rest api

HTTP POST so với GET: Is Thêm một bảo mật để sử dụng trong các API REST?

Grain / Kamil Porembiński

Việc sử dụng HTTP POST so với HTTP GET cho các hoạt động chỉ đọc (hoặc truy vấn) trong các API REST gần đây đã được đưa ra trong một cuộc trò chuyện. Đối với cửa hàng cụ thể này, đã có lệnh cấm từ lâu đối với việc sử dụng các yêu cầu GET để sử dụng trong các ứng dụng cây nhà lá vườn. Điều này đã xảy ra kể từ trước khi các API REST được sử dụng phổ biến và các ứng dụng web truyền thống (HTML được tạo từ phía máy chủ) là kiến ​​trúc tiêu chuẩn. Vấn đề duy nhất là không ai thực sự biết hoặc nhớ tại sao nó không được phép – chỉ là nó “không an toàn”. Thật không may khi một tiêu chuẩn như vậy đã phát triển vì nó ngăn cản cú pháp đầy đủ của HTTP được sử dụng trong REST APIs .

Tuy nhiên, chúng ta phải hiểu động cơ ban đầu là gì như một tiêu chuẩn cần được đưa ra ngay từ đầu. Khám phá động lực cho một tiêu chuẩn như vậy là trọng tâm của bài đăng trên blog này. Cuộc thảo luận này sẽ bao gồm nhiều chủ đề. Thật không may, không có thời gian để dành sự quan tâm cho mọi chủ đề mà thay vào đó là tóm tắt những điểm quan trọng liên quan đến tính bảo mật tương đối của các yêu cầu GET và POST.

Thiết kế API

Trước tiên, hãy tự hỏi tại sao chúng ta có thể muốn sử dụng yêu cầu GET trong API RESTful? Toàn bộ điểm của API là có thể trao đổi thông tin bằng giao thức gốc của World Wide Web như nó được sử dụng – HTTP v1.1 (hoặc v2 ) cho mục đích của chúng tôi. Phong cách kiến ​​trúc (triết lý) này được trình bày trong Luận án Tiến sĩ Roy Fielding (2000). Luận án không thảo luận cụ thể khi nào nên sử dụng phương thức HTTP này hay phương thức khác. Nó cũng không đề cập cụ thể đến hoạt động CRUD. Chi tiết về thời điểm sử dụng phương thức này với phương thức khác được để lại cho thông số kỹ thuật HTTP, “ngôn ngữ của World Wide Web.”

Vì vậy, thiết kế REST API phải lấy cảm hứng từ các nguồn khác và một chút thực dụng – và tránh tôn giáo. Điều này bao gồm, ít nhất là tập hợp con các hoạt động HTTP có sẵn triển khai các khả năng CRUD truyền thống (Tạo, Đọc, Cập nhật, Xóa); đây thường là POST, GET, PUT và DELETE. Tuy nhiên, nó không nhất thiết phải theo cách này. Có lẽ chúng ta thay thế PUT bằng PATCH. Có thể DELETE không được sử dụng và chỉ là một bản cập nhật bổ sung mà PUT / PATCH có thể giải quyết. Trong bài viết sau , Roy Fielding làm rõ một số điểm từ luận điểm ban đầu của mình, bao gồm:

  • rằng anh ấy không đề cập đến CRUD (và tại sao)
  • rằng REST yêu cầu các phương thức được sử dụng thống nhất cho tất cả các tài nguyên (đường dẫn)
  • rằng không có gì trong phong cách kiến ​​trúc REST yêu cầu phải sử dụng một phương pháp cụ thể hoặc không được sử dụng.

Trên thực tế, tiêu đề của bài viết đó là “Có thể sử dụng POST”. Tôi đã nghĩ về việc đặt tên cho bài đăng trên blog này giống nhau, nhưng tôi không muốn là nguyên bản. Anh ấy làm rõ thêm “Lý do chính khiến tôi thiếu tính cụ thể [xác định cách sử dụng các phương thức HTTP] là vì các phương thức được xác định bởi HTTP là một phần của định nghĩa kiến ​​trúc Web, không phải kiểu kiến ​​trúc REST. Các định nghĩa phương pháp cụ thể (ngoài việc truy xuất: tính đối ngẫu tài nguyên của GET) đơn giản không quan trọng đối với phong cách kiến ​​trúc REST, vì vậy rất khó để có một cuộc thảo luận về phong cách về chúng. Điều duy nhất mà REST yêu cầu đối với các phương thức là chúng được xác định thống nhất cho tất cả các tài nguyên… ”

Nếu tôi tuân thủ tất cả các quy tắc giả mà tôi đã nghe trong nhiều năm về những gì có thể và không thể được sử dụng như một phần của REST API, thì sẽ có rất ít thông số HTTP 1.1 còn lại thực sự có thể được sử dụng – điều này thật ngớ ngẩn. Tôi đã từng có người nói với tôi rằng một API REST thực chỉ có thể sử dụng mã trả về 201 (thay vì 200) cho các lệnh gọi POST. Tôi cho rằng, tôi đã vi phạm quy tắc đó nhiều lần – sẽ không sao cả. Hy vọng người đọc nhận ra đoạn này là châm biếm.

Nếu người đọc đã từng xem bất kỳ công việc thiết kế API REST nào của tôi, họ sẽ nhanh chóng nhận ra rằng tôi cảm thấy thoải mái với việc sử dụng GET, POST, PUT và DELETE. Điều này phù hợp với mô hình API Maturity của Leonard Richardson. Để thực hiện điều này với các API REST, nhà thiết kế API phải cảm thấy thoải mái và được phép sử dụng các phương thức HTTP có sẵn nếu thích hợp.

Phần lớn cuộc hội thoại này xoay quanh việc sử dụng GET trong một ứng dụng web chạy trong trình duyệt. Có một số trường hợp ngoại lệ. Chúng tôi sẽ xem xét cả ứng dụng dựa trên trình duyệt của người dùng cuối và giao tiếp giữa Doanh nghiệp với Doanh nghiệp (B2B) hoặc hệ thống với hệ thống thông qua API REST.

Bảo mật tương đối của HTTP POST so với GET

Tôi đã tham gia các tổ chức đã thực hiện lệnh cấm toàn cầu, nghiêm khắc, sử dụng các yêu cầu GET cho giao tiếp kiểu API hoặc thậm chí các ứng dụng web truyền thống. Các lý do được trích dẫn thường là một cái gì đó dọc theo dòng:

  • Dữ liệu sẽ được nhìn thấy trong thanh địa chỉ của trình duyệt và được ghi lại trong lịch sử trình duyệt.
  • GET bằng cách nào đó kém an toàn hơn POST khi được truyền qua dây
  • URL (bao gồm các tham số truy vấn) được ghi trên máy chủ.

Nếu HTTPS (TLS v1.2 trở lên) đang được sử dụng, cả thông số yêu cầu GET và POST đều không được đọc qua dây. Nếu cuộc gọi AJAX được thực hiện trong nền, không có gì hiển thị trong thanh địa chỉ hoặc lịch sử trình duyệt. Nhật ký truy cập HTTP không cần phải ghi lại các tham số truy vấn hoặc nếu bạn muốn thực sự lạ mắt, đừng ghi lại các giá trị nhạy cảm. Hoặc, tốt hơn hết, đừng đặt các giá trị nhạy cảm trong các tham số truy vấn HTTP.

Những điểm này có khả năng hợp lệ nhưng có thể thực hiện các giải pháp ít xâm phạm hơn để giảm thiểu các vấn đề tiềm ẩn. Việc thực hiện các chính sách nặng tay như cấm sử dụng các yêu cầu GET trong các ứng dụng mà không thực hiện đánh giá mối đe dọa chi tiết sẽ ảnh hưởng đến hệ thống bảo mật (có nghĩa là nó có thể không giúp ích nhiều cho tình hình bảo mật tổng thể).

Thường thì những câu hỏi này xoay quanh PII, HIPAA, hoặc các thông số kỹ thuật tương tự. Nói chung, nên tránh đặt loại dữ liệu này trực tiếp vào tham số truy vấn. Một số loại trừu tượng nên được đưa vào thiết kế có thể được sử dụng để gián tiếp tham chiếu dữ liệu nhạy cảm – hãy nghĩ về một thứ gì đó như mã hóa cho dữ liệu PCI.

Nói chung, nó được khuyến khích mạnh mẽ để hoạt động theo tinh thần của những gì các phương pháp này được cho là có nghĩa. Có một số khu vực màu xám và chỗ cho giáo điều / tôn giáo xâm nhập vào đó – tốt nhất nên tránh điều đó. Trên hết, hãy nhất quán. Trong trường hợp không có bất kỳ hướng dẫn nào khác, hãy nhất quán. Đảm bảo rằng bạn hiểu rõ cách các phương thức HTTP đang được sử dụng trong các API mà bạn kiểm soát.

Tiếp theo chiến lược CRUD được mô tả ở trên + Phương pháp OPTIONS ( CORS ) là chiến lược tôi đã sử dụng trong hầu hết mọi REST API mà tôi đã thiết kế. Các trường hợp ngoại lệ được thúc đẩy bởi chính trị và những thỏa hiệp ngớ ngẩn với những người đã rơi vào bẫy được mô tả trong bài đăng trên blog này.

Tác dụng phụ (so với mục đích dự kiến) của HTTP GET & amp; BÀI ĐĂNG

Các yêu cầu GET nên được sử dụng để truy xuất dữ liệu khi thiết kế các API REST; Yêu cầu POST nên được sử dụng để tạo dữ liệu khi thiết kế API REST. Tạo ra thứ gì đó là một tác dụng phụ – nếu không phải là vấn đề.

Phương thức HTTP GET không được cho là có tác dụng phụ. Nó được coi là chỉ đọc để truy xuất dữ liệu. Thường được coi là một phương pháp không tốt khi thực hiện bất kỳ loại hành vi ghi nào (những thứ sẽ có tác dụng phụ) trong HTTP GET. Tuy nhiên, thực sự không có điều gì ngăn cản nhà phát triển làm điều này.

Khuyến nghị ở đây là tránh hành vi ngoài ý muốn hoặc không trực quan bằng cách tạo một số loại chức năng” viết “trong yêu cầu GET. Lưu nó cho các hoạt động HTTP POST. Đây là một tình huống mà việc sử dụng POST được khuyến nghị từ chính định nghĩa của thông số kỹ thuật hơn là GET. Điều này áp dụng cho các ứng dụng web truyền thống cũng như các API REST.

Đăng nhập HTTP trên Máy chủ (và proxy)

Nếu ứng dụng của bạn đang ghi lại các giá trị nhạy cảm, bất kể chúng được truyền như thế nào, hãy DỪNG LẠI. Dừng lại ngay! Điều này bao gồm nhật ký truy cập HTTP truyền thống mà hầu hết công nghệ máy chủ web đã bật theo mặc định. Đây là một thực tiễn không tốt và một trong những hoạt động đánh giá cơ bản và tuân thủ các phương pháp hay nhất có thể giảm thiểu.

Nói như vậy không có nghĩa là vô hiệu hóa tất cả ghi nhật ký trong sản xuất. Tôi đã đi vào một số cửa hàng đã vô hiệu hóa hoàn toàn tất cả nhật ký sản xuất của máy chủ web và máy chủ ứng dụng hoặc vô hiệu hóa nhật ký truy cập HTTP. Gần như không thể thực hiện phân tích pháp y hoặc khắc phục sự cố sau thực tế được thực hiện trên một hệ thống đã bị vô hiệu hóa tất cả ghi nhật ký ứng dụng và phần mềm trung gian. Mục tiêu phải là lọc ra hoặc loại bỏ để bắt đầu ghi nhật ký các tham số nhạy cảm hoặc có thể chứa thông tin nhạy cảm. Tùy thuộc vào sản phẩm đang được sử dụng, điều này có thể rất dễ dàng hoặc gần như không thể. Tôi sẽ coi các khả năng cần thiết ở đây là một phần của các yêu cầu kỹ thuật đối với bất kỳ sản phẩm nào đang được xem xét; mặc dù vậy, hầu hết các tổ chức không nghĩ đến điều đó một cách tổng thể khi đưa ra lựa chọn sản phẩm.

Nếu bạn có quyền kiểm soát cơ sở hạ tầng của ứng dụng và những gì được ghi lại, thì bạn có thể đảm bảo rằng không có gì nhạy cảm đang được ghi lại. Thử nghiệm thực là một cuộc kiểm tra độc lập (thường là một phần của một số loại đánh giá bảo mật hoặc kiểm tra thâm nhập) được thực hiện để đảm bảo rằng các giá trị nhạy cảm không được ghi lại.

Nếu đơn đăng ký của bạn phụ thuộc vào các API hoặc hệ thống của bên thứ ba mà tổ chức của bạn không có quyền kiểm soát, việc đảm bảo trực tiếp rằng các phương pháp hay nhất đang được tuân thủ sẽ khó hơn nhiều. Điều này có thể được giảm thiểu bằng các thỏa thuận pháp lý, nhưng chỉ trong những trường hợp chính thức nhất mới cho phép đánh giá thực hành; loại hoặc mức độ quan hệ đó có xu hướng tốn kém. Đối với một máy trung gian như máy chủ proxy có thể ghi thông tin yêu cầu (URL), những thông tin này hy vọng nằm dưới sự kiểm soát của tổ chức máy khách HTTP hoặc tổ chức máy chủ HTTP. Trong cả hai trường hợp, máy chủ proxy là một phần của cơ sở hạ tầng đáng tin cậy của một trong những tổ chức đó. Về lý thuyết, sự tin tưởng đó mở rộng sang tổ chức khác thông qua một số loại thỏa thuận pháp lý. Có một giả định trong cụm từ “cơ sở hạ tầng đáng tin cậy” rằng nó được định cấu hình đúng cách (bao gồm ghi nhật ký) để đáp ứng các yêu cầu.

Người ta cũng nên tính đến cách xử lý tập hợp và lưu trữ nhật ký (nghĩ Splunk và những thứ tương tự). Nếu các giá trị nhạy cảm cần được ghi lại, hệ thống tệp được mã hóa và kiểm soát truy cập thích hợp phải được triển khai. Ai có quyền truy cập vào nhật ký? Chính sách lưu giữ nhật ký là gì? Tất cả điều này phải được giải quyết như một phần của các tiêu chuẩn và phương pháp hay nhất về bảo mật thông tin của tổ chức, được áp dụng cho ứng dụng và cơ sở hạ tầng đáng tin cậy.

Rất nhiều điều này sẽ đi đến sự đánh đổi của việc kiểm toán thích hợp, hỗ trợ vận hành, đảm bảo rằng thông tin nhạy cảm không được ghi lại, và nếu có, thì các biện pháp bảo vệ thích hợp đã được áp dụng. Gần đây, tôi đã tham gia một cuộc trò chuyện, nơi thảo luận về việc sử dụng hợp lý ghi nhật ký theo dõi. Thông thường, không có dữ liệu nhạy cảm nào được ghi lại (thông tin, lỗi, ghi nhật ký cấp gỡ lỗi), nhưng trong một tình huống khắc phục sự cố trong đó các chi tiết cấp thấp như tương tác với nền tảng lưu trữ thông tin xác thực an toàn (nghĩ rằng CyberArk hoặc Hashicorp Vault) cần được khám phá, có thể cần thiết phải ghi nhật ký theo dõi để lưu trữ nhiều nhật ký hơn so với mong muốn của chúng tôi. Sau những tình huống như vậy, đã đến lúc xoay mật khẩu, khóa, chứng chỉ, thông tin xác thực ứng dụng khách OAuth2, v.v.

Một số sản phẩm tôi đã làm việc cung cấp khả năng trực tiếp để đánh dấu trường nào nên được ghi lại (không được ghi lại) hoặc được lọc trong các điều kiện cụ thể Hệ thống CNTT điển hình có nhiều lớp và nhiều bản ghi. Giám sát hiệu quả cũng phức tạp như ứng dụng cơ bản đang được giám sát. Bạn có thể cân nhắc việc ghi nhật ký thích hợp, tổng hợp nhật ký và bảo mật nhật ký / vệ sinh một phần của thiết bị giám sát đó.

Cuộc thảo luận này áp dụng cho cả ứng dụng web truyền thống và API REST.

Phần này nên là bài đăng trên blog của chính nó. Tôi hơi xa chủ đề chính một chút, nhưng điều này quan trọng.

Proxy Caching các yêu cầu HTTP GET

Các nhận xét được đưa ra trong phần cuối về tổ chức nào sở hữu proxy đều có liên quan ở đây. Nếu không thể phân loại proxy là đáng tin cậy, cần thực hiện các bước để tránh nó.

Gần đây, tôi không gặp nhiều trường hợp trong đó proxy đã bật bộ nhớ đệm phản hồi chung cho các API. Nơi tôi đã thấy bộ nhớ đệm phản hồi nằm trên một cái gì đó giống như CDN phía trước API Gateway hoặc được tích hợp vào API Gateway. Việc kích hoạt tính năng này thường được thực hiện với mục đích cụ thể có ý nghĩa đối với các phản hồi API đang được lưu vào bộ nhớ đệm. Khi được sử dụng, nó tuân thủ các chỉ thị HTTP về thời gian lưu nội dung nào đó vào bộ nhớ cache và liệu nó có nên được lưu vào bộ nhớ cache hay không.

Ngoài ra còn có các biến thể của bộ nhớ đệm dựa trên Tiêu đề HTTP, tham số truy vấn, đường dẫn đầy đủ, v.v. Điều này có thể rất khác nhau. < / p>

Tôi có ‘ không thấy tình huống mong muốn lưu các phản hồi vào bộ nhớ cache trên các proxy HTTP trung gian cho các API REST có thông tin nhạy cảm. Tôi cho rằng điều đó có thể xảy ra, nhưng nó sẽ là một phần của cuộc thảo luận về cơ sở hạ tầng đáng tin cậy ở phần cuối.

Về lý thuyết, bạn có thể lưu vào bộ nhớ cache phản hồi của bất kỳ phương thức HTTP nào, nhưng điều này hiếm khi có ý nghĩa đối với các hoạt động ghi. Nếu cần thiết phải lưu vào bộ nhớ cache thứ gì đó, việc cố gắng triển khai bộ nhớ đệm của các yêu cầu API chỉ đọc được bao bọc trong các POST sẽ là một thách thức (có thể thực hiện được với các sản phẩm chắc chắn có đầy đủ tính năng, nhưng sẽ dẫn đến các tình huống vô lý). Đây sẽ là lý do để sử dụng GET cho các lệnh gọi API chỉ đọc thay vì ĐĂNG.

Phần này áp dụng cho các ứng dụng web truyền thống và API REST. Đối với các API REST, bộ nhớ đệm phản hồi không xuất hiện thường xuyên nhưng đôi khi nó cũng xuất hiện.

Hiển thị thông tin trong trình duyệt (Thanh địa chỉ, Lịch sử, Làm mới, Bộ nhớ cache, v.v.)

Đúng vậy, bạn có thể thấy yêu cầu GET với các tham số truy vấn trong thanh địa chỉ và Lịch sử trình duyệt . Bạn cũng có thể xem toàn bộ nội dung của POST, PUT và các phương thức HTTP khác trong Công cụ dành cho nhà phát triển của trình duyệt. Người ta luôn có thể xóa lịch sử; tuy nhiên, điều này thường yêu cầu sự hợp tác (hoặc ít nhất là sự cho phép) của người dùng cuối.

Nhấn nút làm mới trình duyệt sẽ phát lại cùng một yêu cầu HTTP GET cho các yêu cầu trong thanh địa chỉ.

Đối với lệnh gọi API REST được thực hiện như Các cuộc gọi AJAX trong nền (hãy gọi đây là yêu cầu HTTP mà trình duyệt thực hiện không được phản ánh trong thanh địa chỉ), cuộc gọi không được ghi lại trong lịch sử trình duyệt hoặc hiển thị trên thanh địa chỉ (ít nhất là với các trình duyệt chính). Vì lý do đó, tôi thường không lo lắng về việc sử dụng lệnh gọi GET với REST API vì không có mối quan tâm nào trong số này áp dụng.

Nếu trình duyệt thực hiện cuộc gọi GET, phản hồi sẽ được trình duyệt lưu vào bộ đệm nếu bộ điều khiển bộ đệm thích hợp tiêu đề được cung cấp. Điều này hoạt động cho dù trình duyệt kích hoạt cuộc gọi hay Javascript thực hiện cuộc gọi AJAX. Hầu hết các API tôi đã làm việc đều không đặt tiêu đề phản hồi kiểm soát bộ nhớ cache thành true, nhưng điều đó có thể xảy ra.

Nếu một máy / thiết bị hoặc trình duyệt nào đó bị xâm phạm, kẻ tấn công vẫn có thể xem thông tin.

Tôi không nghĩ rằng bất cứ điều gì thực sự bị mất ở đây bằng cách sử dụng HTTP GET với các API REST, có hoặc không có các giá trị nhạy cảm miễn là có các biện pháp phòng ngừa. Lịch sử trình duyệt luôn có thể bị xóa.

Phần này áp dụng cho API REST nếu Người dùng API đang sử dụng trình duyệt.

Người giới thiệu HTTP:

Các yêu cầu HTTP do trình duyệt tạo ra thường sẽ bao gồm một tiêu đề yêu cầu được gọi là Người giới thiệu ( spec viết sai chính tả từ trong ngày). Điều này sẽ chứa URL của trang đã tạo ra nó. Nếu thông tin nhạy cảm được chứa trong URL yêu cầu GET, thì có thể URL đó sẽ xuất hiện trong tiêu đề Người giới thiệu yêu cầu trong tương lai. Một yêu cầu ĐĂNG sẽ không có vấn đề này. Vì vậy, một điểm khác có lợi cho các yêu cầu ĐĂNG.

Tuy nhiên, đối với API AJAX REST gọi từ một trình duyệt, tiêu đề Người giới thiệu sẽ có URL của tệp javascript đã khởi tạo yêu cầu AJAX. Điều này sẽ không đặc biệt thú vị. Đối với lệnh gọi API từ hệ thống đến hệ thống, rất có thể sẽ không có tiêu đề Người giới thiệu. Vì vậy, trong hầu hết các trường hợp liên quan đến API, đây sẽ không phải là vấn đề.

Lộ thông tin qua đường dây

Nếu dữ liệu chưa được mã hóa được chuyển qua kết nối mạng, dữ liệu đó sẽ được các tác nhân có quyền truy cập trên mạng đó xem được. Trên internet công cộng, điều này có nghĩa là tất cả mọi người. Điều này đúng như nhau cho dù đó là HTTP hay một giao thức văn bản rõ ràng khác hay một yêu cầu HTTP POST hoặc một yêu cầu HTTP GET.

Nếu tất cả các yêu cầu được chuyển qua HTTPS (TLS v1.2 trở lên), thông tin sẽ không bị lộ qua dây . Bây giờ, nếu proxy HTTP (S) công ty của bạn mà trình duyệt được định cấu hình để tương tác với (tin cậy) đang kiểm tra lưu lượng HTTPS, thì bạn thực sự có một người trung gian đang đọc lưu lượng được mã hóa của bạn, nhưng đây là nói chung là một phần của sự tuân thủ lớn hơn và thiết lập cơ sở hạ tầng đáng tin cậy. Vì vậy, có lẽ không sao với những đảm bảo mà chúng tôi đang tìm kiếm.

Trong nhiều năm qua, mọi người đã nêu mối lo ngại rằng một URL HTTP GET bị lộ qua dây khi HTTPS đang được sử dụng. Dường như có ấn tượng sai trong một số vòng kết nối trong ngành rằng TLS / HTTPS chỉ mã hóa nội dung thư của một yêu cầu HTTP. Đây KHÔNG phải là cách TLS / SSL hoạt động. Tất cả dữ liệu tạo nên yêu cầu HTTPS (bao gồm phương thức, đường dẫn, tham số truy vấn, tiêu đề, v.v.) được mã hóa trên máy khách và được giải mã trên máy chủ bằng mã hóa AES256 (hoặc tốt hơn). Điều đó đúng bất kể phương pháp nào được sử dụng.

Điểm mấu chốt là các yêu cầu GET và POST đều được bảo mật như nhau khi sử dụng HTTPS. Vì vậy, điều này không tạo ra động lực để sử dụng cái này hơn cái kia. Điều này áp dụng cho các ứng dụng web truyền thống và API REST.

Search Engine Spiders

Tất cả các công cụ tìm kiếm đều có một thành phần (trình thu thập dữ liệu) sẽ quét định kỳ mọi trang web có thể truy cập được trên internet (tuân thủ một số quy tắc cơ bản). Trình thu thập thông tin tìm kiếm ( Google , Bing , ít hơn, không rõ ràng, những thứ bạn không thực sự muốn thu thập dữ liệu trang web của mình) sẽ đi theo mọi liên kết trên trang web của bạn (tất cả các đường dẫn có thể truy cập sử dụng GET), nhưng sẽ không gửi các biểu mẫu ngẫu nhiên mà họ tìm thấy . Nếu một yêu cầu GET có một số loại tác dụng phụ, điều này có thể tạo ra các tình huống không mong muốn. Đối với các công cụ tìm kiếm hoạt động tốt, tệp robot.txt sẽ giới hạn những gì có thể quét được. Tương tự như vậy, các công cụ tìm kiếm hoạt động tốt sẽ không tuân theo các hoạt động ĐĂNG biểu mẫu. Nhưng, điều đó không có nghĩa là ai đó hoặc thứ gì khác sẽ không.

Tóm lại, có những vấn đề tiềm ẩn ở đây với yêu cầu GET mà nếu không thì sẽ không tồn tại với yêu cầu POST. Miễn là các phương pháp hay nhất (không có tác dụng phụ trong lệnh gọi GET, bảo vệ các điểm cuối nhạy cảm bằng xác thực + ủy quyền thích hợp, v.v.) được áp dụng, thì điều này không nhất thiết là vấn đề.

Đây có lẽ không phải là vấn đề đối với REST API đâu Sẽ không có một liên kết dẫn đến “nhấp chuột” nội tuyến trong một trang mà bạn có thể dễ dàng khám phá, nhưng tùy thuộc vào kiến ​​trúc ứng dụng web của bạn, điều này có thể không đúng.

Web Accelerator

Trình tăng tốc web là phần mềm hoặc phần cứng nhằm mục đích tăng tốc trải nghiệm web cho người dùng. Một ví dụ sẽ là chức năng của trình tăng tốc web trong NGINX . Thành phần này có thể chạy trên thiết bị của người dùng hoặc là một phần của proxy trên mạng. Mặc dù ý tưởng cơ bản có thể có ý nghĩa tốt, nhưng công nghệ này có thể “nhấp” vào tất cả các liên kết (tức là GET) trên một trang / trang web trong ngữ cảnh của người dùng đã được xác thực. Vì vậy, nếu một ứng dụng đang sử dụng yêu cầu GET để sửa đổi (hoặc xóa), nó sẽ xóa mọi thứ mà trình tăng tốc web yêu cầu.

Đây là một ví dụ về” cuộc tấn công phó bối rối “.

Hầu hết các tổ chức tôi đã làm việc đều không sử dụng loại công nghệ này. Tuy nhiên, đó là một cuộc bỏ phiếu ủng hộ việc sử dụng yêu cầu POST cho bất kỳ việc gửi biểu mẫu nào dẫn đến các thay đổi đối với hệ thống, điều mà bạn nên thực hiện dựa trên thảo luận về “tác dụng phụ” trước đó.

Cuộc tấn công hỗn loạn

Per Wikipedia , Thứ trưởng bối rối“ là chương trình máy tính hợp pháp, có nhiều đặc quyền hơn span> bị lừa bởi một chương trình khác sử dụng sai quyền hạn của nó trên hệ thống. Đây là một loại cụ thể của leo thang đặc quyền . ” Nếu trình duyệt là cấp phó trong câu chuyện này, cả yêu cầu GET và ĐĂNG đều có thể tham gia vào một cuộc tấn công cấp phó nhầm lẫn. Nếu kẻ tấn công kiểm soát một trang web (bằng cách sở hữu nó ban đầu hoặc giành quyền kiểm soát thông qua một số kiểu tấn công), các yêu cầu GET và POST đều dễ dàng gửi như nhau mà không cần sự đồng ý hoặc hành động của người dùng. Đây là Truy vấn yêu cầu chéo trang web (CSRF), là một kiểu tấn công Phó chủ tịch khó hiểu.

< p class = "pw-post-body-paragraph ju jv ii jw b jx jy jz ka kb kc kd ke kf kg kh ki kj kk kl km kn ko kp kq kr ib gj" id = "3acf"> Đây là một mối quan tâm cho các ứng dụng web truyền thống và API REST, nhưng rất có thể sẽ yêu cầu sử dụng trình duyệt web cho Người tiêu dùng API.

Yêu cầu chéo trang web

Từ OWASP , một cuộc tấn công Cross-Site Request Forgery “là một cuộc tấn công buộc người dùng cuối thực hiện các hành động không mong muốn trên một ứng dụng web mà họ hiện đang được xác thực. Với một chút trợ giúp của kỹ thuật xã hội (chẳng hạn như gửi liên kết qua email hoặc trò chuyện), kẻ tấn công có thể lừa người dùng ứng dụng web thực hiện các hành động mà kẻ tấn công chọn. Nếu nạn nhân là người dùng bình thường, một cuộc tấn công CSRF thành công có thể buộc người dùng thực hiện các yêu cầu thay đổi trạng thái như chuyển tiền, thay đổi địa chỉ email của họ, v.v. Nếu nạn nhân là tài khoản quản trị, CSRF có thể xâm phạm toàn bộ ứng dụng web. ”

Giả sử một trang web cho phép nhúng hình ảnh như một phần của người dùng nhập vào diễn đàn thảo luận và không nằm trong tầm kiểm soát của kẻ tấn công. Nếu nó cho phép hình ảnh được tham chiếu qua URL trên các trang web của bên thứ ba, thì các yêu cầu GET sẽ được sử dụng. Về lý thuyết, điều này cung cấp một cách để tạo một cuộc tấn công CSRF bằng cách đưa vào một yêu cầu GET tùy ý. Có một tình huống cụ thể không thể xảy ra với một yêu cầu ĐĂNG. Tuy nhiên, có những cách tiếp cận khác có thể dẫn đến cuộc tấn công CSRF với yêu cầu ĐĂNG.

Các cuộc tấn công CSRF có thể ảnh hưởng Yêu cầu POST và GET. Đúng là việc làm cho lỗ hổng này xảy ra với HTTP GET (ví dụ: như đã lưu ý ở trên) sẽ dễ dàng hơn so với HTTP POST, nhưng chỉ dễ hơn một chút. Có chiến lược giảm thiểu có thể giảm thiểu thành công loại tấn công này cho cả GET & amp; ĐĂNG yêu cầu. Điều này được thảo luận ngắn gọn tại đây tại đây .

Đây là mối quan tâm đối với các ứng dụng web truyền thống và API REST, nhưng rất có thể sẽ yêu cầu sử dụng trình duyệt web cho Người tiêu dùng API.

Cross-Site Scripting Attack

Trang web chéo Các cuộc tấn công bằng Scripting ( XSS ) đánh lừa người dùng (hay chính xác hơn là trình duyệt của người dùng) thực thi một tập lệnh tùy ý (thường là Javascript). Điều này thường xảy ra khi thông tin đầu vào của người dùng chưa được lọc được phép sử dụng trong các câu trả lời được gửi lại cho người dùng khác, chẳng hạn như trong một diễn đàn thảo luận. Đầu vào chưa được lọc có thể chứa javascript thực thi thực hiện một hành động không mong muốn. Điều này được thảo luận ngắn gọn tại đây tại đây .

Loại lỗ hổng này có thể tác động đến cả GET và POST. Có chiến lược giảm thiểu có thể hoạt động trên cả GET & amp; Yêu cầu ĐĂNG.

Đây là mối lo ngại đối với các ứng dụng web truyền thống và API REST, nhưng rất có thể sẽ yêu cầu sử dụng trình duyệt web cho Người tiêu dùng API.

Giá trị nhạy cảm trong yêu cầu GET

Nói chung, phương pháp hay nhất sẽ là tránh đặt các giá trị nhạy cảm trong URL (bao gồm cả các tham số truy vấn). Điều này đã được thảo luận trước đó trong phần “Bảo mật tương đối của HTTP POST so với GET”.

Với bộ chức năng phong phú có sẵn trong API REST dựa trên HTTP và sự dễ dàng làm việc với HTTP GET để truy xuất dữ liệu trong API REST, một lệnh cấm bán buôn có vẻ phản tác dụng và không cần thiết. Thay vào đó, thông qua các tiêu chuẩn phân loại dữ liệu, đánh giá mã và các kỹ thuật khác được mô tả trong bài đăng này, hãy tránh đặt các giá trị nhạy cảm trong đường dẫn URL và tham số truy vấn. Hãy xem xét cách các nhiệm vụ như vậy loại bỏ việc sử dụng HATEOAS (điều này làm cho điều đó trở nên bất khả thi).

Tóm tắt

Bài đăng trên blog này bao gồm rất nhiều lãnh thổ. Đúng là có một số tình huống trong đó việc sử dụng yêu cầu POST có lợi thế bảo mật hơn yêu cầu GET mà không cần thực hiện các biện pháp phòng ngừa bổ sung, nhưng cũng có những tình huống trong đó cả hai đều dễ bị tổn thương bởi các vectơ tấn công chung. Điều quan trọng là các phương pháp hay nhất và chiến lược giảm thiểu các lỗ hổng phổ biến / đã biết phải được tích hợp vào tất cả các ứng dụng web. Những ưu điểm nhỏ đó mà yêu cầu ĐĂNG không thể biện minh cho việc xóa yêu cầu GET khỏi vành đai công cụ thiết kế API của chúng tôi.

Nếu chúng tôi không thể sử dụng GET, thì chúng tôi không tận dụng thiết kế CRUD của các API và mục đích của thông số HTTP. Bối cảnh của các ứng dụng dựa trên trình duyệt so với các ứng dụng hệ thống ảnh hưởng đến các mối quan tâm về bảo mật. Trên thực tế, hầu hết các cảnh báo được khám phá trong bài đăng này chỉ liên quan đến các ứng dụng dựa trên trình duyệt. Vì vậy, khi xây dựng Ứng dụng trang đơn (SPA) hoặc ứng dụng Javascript chạy trong trình duyệt, điều quan trọng là phải tuân theo các phương pháp hay nhất và chỉ sử dụng GET cho các yêu cầu chỉ đọc không sửa đổi hệ thống. Ngay cả đối với giao tiếp giữa hệ thống với hệ thống, có những tình huống cần phải thận trọng với các yêu cầu GET.

Miễn là các yêu cầu GET được sử dụng phù hợp với tất cả các phương pháp hay nhất được áp dụng, nó có thể được sử dụng an toàn với các API REST và ứng dụng web. < / p>

Hình ảnh: Grain / Kamil Porembiński


Xem thêm những thông tin liên quan đến chủ đề nhận vs post phần còn lại api

2.3 HTTP Post Request with fetch() – Working with Data and APIs in JavaScript

  • Tác giả: The Coding Train
  • Ngày đăng: 2019-06-03
  • Đánh giá: 4 ⭐ ( 3323 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: 💻https://github.com/CodingTrain/Intro-to-Data-APIs-JS

    We are now in Module 2! In the previous module, we focused on client-side JavaScript. We now will learn the basics of server-side programming with Node.

    2.3 Let’s take data from the client and send it to the server. This video covers routing, JSON parsing, and HTTP POST requests with fetch().

    🎥 NEXT LESSON: https://youtu.be/xVYa20DCUv0
    🎥 PREVIOUS LESSON: https://youtu.be/3ls013DBcww
    🎥 FULL COURSE: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6YxDKpFzf_2D84p0cyk4T7X

    🚂 Website: http://thecodingtrain.com/
    💖 Patreon: https://patreon.com/codingtrain
    🛒 Store: https://www.designbyhumans.com/shop/codingtrain/
    📚 Books: https://www.amazon.com/shop/thecodingtrain

    🎥 Coding Challenges: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6ZiZxtDDRCi6uhfTH4FilpH
    🎥 Intro to Programming: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6Zy51Q-x9tMWIv9cueOFTFA

    🔗 p5.js: https://p5js.org
    🔗 Processing: https://processing.org

    📄 Code of Conduct: https://github.com/CodingTrain/Code-of-Conduct

Lấy các bài viết theo trang trong api phần còn lại của wp

  • Tác giả: vi.fantasypewter.com
  • Đánh giá: 4 ⭐ ( 5128 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Tôi muốn phát triển một ứng dụng cho trang web WordPress.org của mình. Tôi đang sử dụng api phần còn lại của wp để nhận bài đăng trong json. Câu hỏi của tôi là làm cách nào để truy xuất các bài đăng từng trang. Ví dụ: nếu có 50 bài đăng tôi muốn

One moment, please…

  • Tác giả: tungnt.net
  • Đánh giá: 3 ⭐ ( 7504 lượt đánh giá )
  • Khớp với kết quả tìm kiếm:

Hướng dẫn sử dụng Postman cho chạy thử các API

  • Tác giả: timoday.edu.vn
  • Đánh giá: 4 ⭐ ( 6603 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Postman là công cụ sử dụng trong thử nghiệm API phổ biến nhất hiện nay với nhiều ưu điểm Khả năng truy cập, Sử dụng Bộ sưu tập, Cộng tác, Tích hợp liên tục…

RESTful API là gì? Cách thiết kế RESTful API

  • Tác giả: topdev.vn
  • Đánh giá: 5 ⭐ ( 5890 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: RESTful API là một tiêu chuẩn dùng trong việc thiết kế API cho các ứng dụng web (thiết kế Web services) để tiện cho việc quản lý các resource. Nó chú trọng vào tài nguyên hệ thống (tệp văn bản, ảnh, âm thanh, video, hoặc dữ liệu động…), bao gồm các trạng thái tài nguyên được định dạng và được truyền tải qua HTTP.

Tất tần tật về RESTful APIs và công cụ Postman

  • Tác giả: movan.vn
  • Đánh giá: 4 ⭐ ( 7654 lượt đánh giá )
  • Khớp với kết quả tìm kiếm:

Vtiger CRM Blog »Nền tảng

  • Tác giả: www.vtiger.com
  • Đánh giá: 4 ⭐ ( 6799 lượt đánh giá )
  • Khớp với kết quả tìm kiếm: Nội dung được gửi trong danh mục Nền tảng.

Xem thêm các bài viết khác thuộc chuyên mục: Kiến thức lập trình

Xem Thêm  Sử dụng tiện ích Google Dịch - ví dụ về tiện ích google dịch

By ads_php