Cơ chế bảo vệ request khi bị lắng nghe từ tab Network trên trình duyệt

Chào mọi người.
Em mới bắt đầu làm sang web nên có câu hỏi như này. Ae ai biết chỉ e với ạ.
Em thấy khi mình gửi request thì đều lắng nghe đc từ tab network trên trình duyệt. Và nếu mình request bằng ajax thì gần như tất cả các tham số và url đều bị lộ. Thì có cách nào để người ta(người muốn lấy api của web mình) có lấy được cũng sẽ k gửi đc request đó lên server không ạ.
Em cảm ơn mọi người. E newbie có hỏi ngu gì ae đừng ném đá tội e :((((((((((((

Người ta ở đây là ai?
Khi bạn truy cập 1 trang web, sẽ có tối thiểu 4 bên biết bạn đang làm gì
1: trình duyệt (đôi khi sẽ kèm cả nhà cung cấp trình duyệt)
2: bản thân bạn
3: người giữ router (modem) của bạn
4: người nằm trong cùng LAN với bạn
5: Chủ trang web
6: …

Trình duyệt bạn không thể cấm được. 1,2 pass
Người giữ router và người nằm trong mạng LAN sẽ chỉ nhìn thấy URL trang web và thông tin bạn gửi đi nếu trang đó không có mã hoá SSL (https). Mặc dù nhìn thấy được nhưng cũng phải giải mã các thông tin đó mới có thể chuyển thành thông tin mà con người có thể đọc được.

Kết luận
Không có kết luận

3 Likes

Ý e là nhưng người muốn lấy api của web mình đó a.

Bạn cung cấp key cho request, khi post/get phải ràng buộc điều kiện mới trả về dữ liệu
Tìm hiểu OAuth và cách nó hoạt động nếu có thời gian

3 Likes

E cũng có biết qua về cơ chế này. K biết e hiểu có đúng k. Đó là giống cơ chế khi gọi api facebook đều cần 1 access_token giống key mà a bảo. Nhưng như thế thì nếu e request bằng ajax trong file javascript thì cũng phải có 1 param là key=ADJSK_HFJFI… gì đó thì nếu đọc trên network vẫn đọc đc mà a.
Với thêm 1 cái nữa là nếu e k muốn user có bất kì tài khoản nào thì có phải sẽ k dùng đc Oauth đúng k ạ? Lúc đấy thì mình sẽ bảo vệ API của mình bằng cách nào ạ?

mua 1 cái host, rồi request tới host đó, host đó sẽ send request kèm api key tới host thực sự

ví dụ muốn lấy json thông tin thời tiết tại tọa độ (1,2) do weather.xyz cung cấp thì request thật sự là GET https://weather.xyz?key=ABC..123&x=1&y=2 thì bây giờ tạo cái host myhost.xyz gửi GET https://myhost.xyz?x=1&y=2. myhost.xyz sẽ gửi request thực sự (có api key) tới weather.xyz lấy json về rồi gửi response này về lại. API key store trên host thì ko bị lộ.

1 Like

Mình cũng mù mờ cái này, lấy api của web là lấy cái gì, bạn có thể cho ví dụ được không?

API là viết tắt của Application Programming Interface (giao diện lập trình ứng dụng). Nó là 1 giao tiếp phần mềm được dùng bởi các ứng dụng khác nhau. Cũng giống như bàn phím là một thiết bị giao tiếp giữa ngườI dùng và máy tính, API là 1 giao tiếp phần mếm chẳng hạn như giữa chương trình và hệ điều hành (HĐH).

Bộ API của từng HĐH là khác nhau, làm cho các HĐH khác nhau và thường không tương thích với nhau. Ví dụ những phần mềm trên HĐH linux không thể chạy được trên máy Windows bởi vì Linux và Windows có các API hòan tòan khác nhau.

Một trong các mục đích chính của một API là cung cấp khả năng truy xuất đến một tập các hàm hay dùng — ví dụ, hàm để vẽ các cửa sổ hay các icon trên màn hình. Các API, cũng như hầu hết các interfaces, là trừu tượng (abstract). Phần mềm mà muốn cung cấp truy xuất đến chính nó thông qua các API cho sẵn, phải hiện thực API đó. Trong nhiều tình huống, một API thường là một phần của bộ SDK, hay software development kit. Một bộ SDK có thể bao gồm một API cũng như các công cụ/phần cứng, vì thế hai thuật ngữ này không thay thế cho nhau được.

ref: http://khachhang.sps.vn/knowledgebase.php?action=displayarticle&id=49

Lộ thì cứ cho lộ, chỉ là người ta gửi request nhưng ta không thèm trả về mới là điều quan trọng, vì request đó được xem là… tà đạo, chứ cấm gửi request không chặn được ở cấp web server vì bản chất là phải gửi request mới có sự tương tác. Hay là bạn định cách ly server ra khỏi Internet? :smiley:

Không thể chặn được “lắng nghe request” (theo cách viết và hiểu của chủ topic nhé) bởi vì đó là cách hoạt động của trình duyệt, và trình duyệt ngày nay có tích hợp chức năng đó để người ta debug này nọ.

Chỉ có cách là người ta kèm theo một giá trị đặt trong input type hidden để kiểm tra xem cái get hay post vừa thực hiện có “chính chủ” hay không. Tuy vậy, cũng phải loay hoay nhiều, có thể phải kết hợp JavaScript để chắc rằng giá trị nhập vào là gõ bằng tay mà không đến từ script hoặc copy & paste :smiley:

Xem ra nan giải rồi, chỉ có cách là mã hoá tất cả mấy cái đoạn JS thực hiện công việc để những kiddie sớm bỏ cuộc vì xem ra rối rắm quá. Hoặc cách điên hơn là tự sáng tác ra một ngôn ngữ scripting, khi gửi giá trị lên server thì ta gửi ở dạng mã hoá, trên đó giải mã cái đó thành ngôn ngữ scripting vừa sáng tác, rồi thực hiện các câu lệnh trong đó.

1 Like

cách này họ request lên https://myhost.xyz?x=1&y=2 thì coi như cái key kia k có tác dụng r ạ

Vâng. Em cảm ơn anh.

Ko có cách nàu để ẩn hết thông tin req trên trình duyệt, có thể mã hóa thông tin trước khi gửi bằng javascript, tuy nhiên nếu người ta đã cố muốn biết thì chả có cách nào dấu,

Thông thường các dịch vụ cung cấp api thường giới hạn số lần được request ví dụ như với $1-1api key thì anh được cấp 50k request/tháng chẳng hạn chứ có secretkey, public key hết mà ko cho nó request thì @@@~

1 Like

giả sử cái web mình có cái api:


Khi dùng ajax post {a:1,b:1} đến cái api trên sẽ trả về 2 (1+1)

Vậy mình hỏi ở một trang web khác http://xyz-khac.com
người ta cũng ajax post {a:5,b:5} đến http://xyz.com/cong
thì nó có trả về giá trị tổng không??

Mình thấy web đã tự động chặn bằng cross domain mà các bạn!!!

Đọc bài này để biết thêm chi tiết https://viblo.asia/p/cross-domain-ajax-requests-l5y8Rr52vob3

1 Like

Có 2 bước cần phải làm để ngăn người khác gọi API của mình.

  1. Không cho Coss Origin Request Sharing, cái này mặc định là tắt. Chỉ cho phép XHR từ domain của mình thôi. Tuy nhiên không chặn được việc người ta không dùng browser để query API. Ít ra chặn được fishing.

  2. User phải login rồi thì mới được gọi API. Khi login xong rồi thì sẽ gửi session key cho client lưu lại ở dạng cookie. Khi nào XHR thì gửi sesson key lên.

Phía server dùng private key decrypt ra, nếu đúng thì trả về response, còn sai thì reject request này.


Làm tới bước 1 là đã chặn được request bậy(fishing) rồi, bước hai để tăng bảo mật, chỉ có user của mình đăng nhập bằng site của mình mới xài được API. Mà có query được thì mình cũng biết user đó là ai, ban luôn id đó nếu thấy nghi ngờ làm gì xấu.

4 Likes

Vâng. Em cảm ơn a. e k biết cơ chế kia. để e tìm hiểu thử và áp dụng

Về cái CORS (Coss Origin Request Sharing) em có thể đọc thêm trên mạng nhiều. Em cũng thể query thử API của trang khác em sẽ thấy là nếu em query bằng XHR, thì có khả năng cao là em sẽ không query được nếu site đó không cho.

Nhưng nếu em dùng tool như Postman để query thì không có vấn đề gì. Tính năng này do browser làm để chặn fishing. Ví dụ có một trang giả mạo DNH, giao diện giống hệt, chỉ khác domain. Trang này yêu cầu người dùng đăng nhập để ăn cắp password. Nhưng nếu trang này muốn đăng nhập được thì nó cần phải gọi được API của DNH. Nhưng vì domain nó khác, nên nó sẽ không gọi được API của DNH kể cả nó biết API đó là gì.


Nhưng nếu em làm hệ thống bảo mật hơn, thì em phải yêu cầu login trước khi gọi api. Như vậy là chắc nhất. Khi gọi API thì client phải gửi kèm theo sesion key, token (giống như FB API), để xác thực đó là người dùng cụ thể. Nếu người dùng đó có vấn đề thì ban thẳng tay, thế là xong :slight_smile:

3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?