Bạn có thể dùng HMAC như @library nói. Khoá riêng tư thì bạn đặt trong source code rồi obfuscate source code để khó dịch ngược, khó tìm ra hơn. Để obfuscate code JS thì có trang https://obfuscator.io/
Hướng dẫn bảo mật API chống lộ Endpoint?
3 Likes
Các bạn giải thích giúp xem (mình chưa đọc mấy cái API) tại sao người ta lo ngại việc bảo mật API như vậy và cứ sợ lộ này nọ kia. Nếu vậy thì mấy cái web API là đang được thiết kế kém, quá dễ bị thủng hay sao?
Mình nghĩ một cách tổng quát, thì các API dùng trên web thì chẳng qua là việc kết nối client - server mà thôi. Hay là lại có cách kết nối gì khác kiểu như dùng thần giao cách cảm!?
Vậy thì để tránh client kết nối vô tội vạ, người ta cần thiết lập một giao thức, nếu trình đủ cao thì tự viết giao thức mới (như ông gì đó làm nên BitTorrent), còn trình thấp thì áp dụng các giao thức đã có sẵn, chọn cái phù hợp trong khả năng.
Và rồi cách làm thông dụng đó là thực hiện một thao tác kiểu dáng giống đăng nhập, ai có “mật khẩu” (hoặc token hay cookie hay gì đó như cái chìa khoá) thì đăng nhập, ai không có thì nằm đó chơi. Lâu lâu (định kỳ N ngày/ tháng) bên cung cấp API lại đá văng ra tất cả, buộc những ông đang có mật khẩu phải đổi/ tạo mới mật khẩu mới rồi cho đăng nhập lại để tránh có kẻ nào đó trộm được mật khẩu truy cập trái phép. Hầu hết các ứng dụng theo kiểu client - server như SSH, FTP, email đều theo cách đó.
Còn nếu cảm thấy sợ mất tiền quá thì chơi như bên nhà nước, thấy một số cái cần có USB gắn vào máy tính, cái này hacker bình thường dễ gì đánh thủng được.
Không lẽ làm ra API thì có thể tự do vi phạm các nguyên tắc đó hay sao? Ai đó giải thích giúp xem?
9 Likes
Ừ, cậu hiểu general concept rồi đó @superthin 
Như cậu nói, API default chỉ là kết nối giữa client và server. Cậu có thể thấy, việc bảo mật không có trong scope nhiệm vụ của API, tức là cậu phải add thêm tính năng “bảo mật” để bảo vệ API.
Mặt khác, không phải API nào cũng cần bảo mật. Có những API chỉ dùng trong internal network, và chẳng có lý do gì để hi sinh một chút performance cost để bảo vệ chúng. Những API cần được bảo mật thường là:
- API ở tầng gateway: là những API có thể được access từ ngoài mạng nội bộ internal network.
- API có trả về những thông tin nhạy cảm như tài khoản ngân hàng, thông tin cá nhân, hoặc các thông tin phải được bảo mật theo mấy luật GDPR/CCPA, etc.
Vậy nên, lý do người ta hay bàn về bảo mật API chủ yếu vì đó là tính năng phổ thông cho bất cứ API nào expose ra ngoài internet hoặc chứa thông tin nhạy cảm, và cũng vì topic này tương đối khó (do có rất nhiều phương án cài đặt, và cần có tương đối nhiều kinh nghiệm để lựa chọn phương án cài đặt phù hợp với requirement)
Hope it helps!
9 Likes
Đã muốn public rồi thì thôi, còn muốn bảo vệ. Cái không đúng ở em là mindset, đã xác định thông tin nào public thì kệ, người ta làm gì thì kệ người ta. Cái cần nghĩ là trong trường hợp nhiều request quá thì làm gì để hạn chế truy cập đỡ tốn băng thông server hay làm cách nào server chịu tải tốt hơn.
8 Likes
Mình cần tạo 1 API xử lý dữ liệu cho người dùng sử dụng thôi bạn, nhưng người khác muốn hack qua post man, chứ mình có muốn publish ra đâu 
Sử dụng một signature trong body lúc request về API, API sẽ do khớp signature này và phản hồi. Signature có thể tạo bằng cách dùng hmac sha256 của một đoạn mã theo quy tắc bạn muốn. Dĩ nhiên accessKey và secretKey phải bảo mật trong env rồi.
[Bổ sung] Cách bảo vệ này hợp với các dữ liệu quan trọng như: thông tin giao dịch, cần kiểm tra và so khớp các lệnh giao dịch trực tuyến như ngân hàng, giao dịch mua bán,…
1 Like
Có câu ngạn ngữ nổi tiếng của Tây Ban Nha: “Mặc tiếng chó sủa, đoàn lữ hành vẫn tiếp tục bước”.
Nếu bạn đang tìm cách để đấu trí với các crawler thì bạn nên bình tỉnh và suy xét lại các vấn đề sau:
- Hiện tại sản phẩm của bạn đã đầy đủ tất cả tính năng mà người dùng cần hay chưa?
- Nội dung của bạn có thực sự tốt hay chưa?
- Sản phẩm của bạn có còn tồn đọng những lỗi khiến người dùng khó chịu hay không?
Nếu mọi thứ trên đã thỏa thì bạn hẳn nghĩ đến việc đấu trí với crawler, “đạo cao 1 thước thì ma cao 1 trượng”, những gì bạn đưa lên giao diện web thì nó đã mất rồi, vấn đề là bạn chỉ muốn đấu trí với crawler khiến nó khó khăn khi lấy cắp nội dung tự động thôi, và cuộc chiến này là trường kỳ, chỉ cho đến khi 1 trong 2 bỏ cuộc thì mới có kết quả.
Hiện tại nếu sản phẩm đang trong quá trình phát triển thì khoan quan tâm đến vấn đề trộm cắp, mà hãy tập trung phát triển sản phẩm cho thật tốt, kẻ cắp luôn đi sau chúng ta một bước trong vấn đề nội dung.
Đừng để quá trình phát triễn bị trì trệ để rồi bỏ lở cơ hội tốt nhất để đến tay người dùng. Khi người dùng biết đến bạn, họ sẽ không để ý đến những nơi cắp nội dung nữa.
2 Likes
Cách tốt nhất để dấu API là làm FE SSR (Server side rendering)
3 Likes
ý bạn là dùng tụi ssr như nextjs?
hay viết hết logic + view vào 1 file rồi cho cgi print ra content?
nếu là ý 1 thì ssr này vẫn sẽ có API, và hoàn toàn ko có chuyện giấu dc, ko khác gì ko implement ssr
nếu là ý 2 thì bạn đã làm 1 website thuần ssr, làm gì có API để giấu?
2 Likes
Sau nhiều năm nghiên cứu mình đã tìm ra cách. Đó chính là cho API đi qua proxy của cloudflare kèm theo một số config, lúc này chỉ có frontend của chính mình mới có thể request tới public API của mình. Dùng postman hay bất kỳ cách giải lập http request nào khác sẽ bị cloudflare reject 403
Tớ tò mò xíu, cậu config gì ở cloudfare để chỉ allow traffic của front end vậy?
2 Likes
Câu này cực kỳ tối nghĩa đó là khi người truy cập vào trang web của bạn thì lúc này của “chính mình” là của ai?
Theo như mình biết (có thể sai be bét) một API cho phép trình duyệt gọi tới trực tiếp mà không cần có cơ chế xác thực thì không giấu được.
Bạn đang dùng proxy mà nếu chỉ cho chính trình duyệt của bạn gọi đến (hoặc front-end của chính mình chạy bằng gì khi không có trình duyệt?) & cấm mọi trình duyệt khác => người truy cập trang web của bạn sẽ thấy trang trống trơn? (vì làm cách nào để trình duyệt của họ gọi đến được proxy của bạn và được proxy cho qua mà bạn không rõ họ là ai vì không áp dụng cơ chế xác thực nào? Đừng nói họ truy cập vào web bạn, bạn load cái trang web trên máy của bạn vào iframe và hiện lên cho họ xem?
Nói chung, mình đoán rằng có vẻ bạn đang xác thực qua cơ chế client -> proxy (hoặc reverse proxy) -> server. Vậy là có sự tham gia của back-end rồi, chỉ là bạn không ý thức được nó mà thôi (vì luồng kết nối này không nằm ở ngay trình duyệt người dùng đến trực tiếp web của bạn nên front-end là gì ở đây). Lúc này ý kiến của bạn @victor128 và @Dark.Hades , @Cat_Lord, @library và vân vân… bên trên đều đáng suy ngẫm.
Nếu chỉ trình duyệt kết nối tới một public API , mình chưa thấy cách (không liên quan đến cái gọi là xác thực như dùng cookie, token) để người ta không fake được một trình duyệt và kết nối thành công, trừ khi trang web bạn cấm hết trình duyệt thông thường, buộc người truy cập phải dùng trình duyệt của riêng bạn truy cập (mục đích để bạn ở trên server nhận ra rằng client không phù hợp và ngắt kết nối hoặc không gửi dữ liệu về).
Túm lại, bạn đang dùng Cloudflare mục đích là cũng giống như bạn ở trên có đoạn:
Hoặc trong thực tế là CloudFlare đang làm giúp việc mà JWT làm.
Mấy bạn có ý kiến gì góp vui vào xem.
1 Like
Về vụ này thì cũng không cần bàn nhiều nữa vì nó nằm ngoài phạm vi của bài viết rồi. Về cơ bản cách của chủ thread là đẩy trách nhiệm cho người có kinh nghiệm hơn ở đây là cloudflare. Cụ thể cách họ xử lí như thế nào thì đó là cuộc chiến không hồi kết giữa bên crawl và bên phòng thủ mà càng bàn càng rộng. Còn với chủ thread thì API của anh ta đã được bảo vệ rồi nên cũng vui vẻ. Hết phim
4 Likes
hoặc có thể là anh ta tưởng thế
1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?