Sau 3 bài viết, chúng ta đã hiểu thế nào là client và server, cách chúng sử dụng HTTP để nói chuyện với nhau và việc xác định định dạng dữ liệu để hiểu nhau. Có lẽ trong đầu chúng ta sẽ có câu hỏi: Làm thế nào để server biết client mà mình đang nói chuyện là anh nào, chị nào, xinh hay xấu. )))
Nội dung bài viết
I. Xác thực danh tính trong thế giới ảo
Giả sử bạn đã đăng ký 1 account ở 1 website, 2 thông tin không thể thiếu là username và password. Những thông tin này còn được gọi là “Giấy thông hành” – Credentials. Và những lần sau, để vào website bạn cần đưa ra cái “Giấy thông hành” đó.
Việc đăng nhập với username và password là 1 ví dụ của quá trình xác định danh tính – Authentication. Khi bạn chứng minh Danh tính với 1 server, bạn cung cấp thông tin mà chỉ có bạn và server biết. (không tính tới trường hợp ngy share account fb của nhau nhé :v). Một khi server biết bạn là ai, nó sẽ tin tưởng và cho phép bạn tiếp cận những thông tin bên trong.
Trong API, có rất nhiều kỹ thuật để xử lý phần Authentication này. Chúng được gọi là Authentication schemes.
II. Basic Authentication
Cái ví dụ vừa nói ở trên là cái form cơ bản nhất của Authentication, tên gọi chuẩn là Basic Authentication, hay được viết tắt là “Basic Auth”. Basic Auth thì chỉ yêu cầu username và password thôi. Client nhập 2 thông tin trên rồi gửi chúng qua HTTP header cho server, đây gọi là quá trình xin phép – Authorization.
Khi server nhận được 1 request, nó sẽ soi vào Authorization header và so sánh thông tin đó với thông tin Credential mà chúng cất giữ ở DB. Nếu đúng, server sẽ chấp thuận request của client và trả thêm các thông mà client yêu cầu ở phần Body. Nếu không đúng, server sẽ trả lại mã code 401, báo hiệu rằng quá trình xác thực fail và yêu cầu bị từ chối.
Mặc dù Basic Auth là 1 kỹ thuật thường xuyên được sử dụng nhưng trên thực tế việc nó dùng cùng 1 username và password để truy cập đến API và quản lý tài khoản là không lý tưởng. Nó giống như việc 1 khách sạn đưa cho khách cả chùm chìa khóa của cả khách sạn chứ không phải là chìa khóa của 1 phòng.
III. API Key Authentication
API Key Authentication là 1 kỹ thuật giúp xử lý điểm yếu của mô hình Basic Auth ở phía trên. Thay vì đưa cả chùm chìa khóa cho khách hàng, chủ khách sạn chỉ đưa cho khách hàng đúng 1 (Key) chìa khóa phòng của họ. Key thông thường là 1 dãy dài số và chữ, là duy nhất và khác biệt với password.
Khi Client xác thực với API Key, server sẽ biết để đồng ý cho client truy cập tới data. Vậy thì API Key sẽ nằm ở vị trí nào trên request. Có thể chúng ta sẽ nghĩ là Key này chắc cũng nằm ở header giống như Basic Auth phía trên. Ơ không, nó nằm ở vị trí mà người lập trình mong muốn vì không có chuẩn nào cả. :v Có thể đặt nó trên header, trên URL (http://example.com?api_key=my_secret_key), hoặc là ở Body. Và cho dù có đặt chúng ở đâu đi chăng nữa, chúng cũng sẽ có cùng 1 tác dụng.
(Còn tiếp, hẹn các bạn phần OAuth, OAuth2 vào 1 bài khác)
Nguồn: chương 4 của cuốn sách: “An Introduction to APIs” by Brian Cooksey
[…] API Testing với Postman (Phần 4) – Các chuẩn bảo mật Authentication […]
Mặc dù Basic Auth là 1 kỹ thuật thường xuyên được sử dụng nhưng trên thực tế việc nó dùng cùng 1 username và password để truy cập đến API và quản lý tài khoản là không lý tưởng. Nó giống như việc 1 khách sạn đưa cho khách cả chùm chìa khóa của cả khách sạn chứ không phải là chìa khóa của 1 phòng.
Đoạn này khó hiểu nhỉ 😐
Mình đoán là nếu người dùng gửi thông tin username và pass để được quyền dùng toàn bộ API, một khi thông tin username và pass bị đánh cắp, kẻ đánh cắp có thể dùng toàn bộ API. Nhưng nếu người dùng gửi API Key để được quyền dùng 1 API, thì kẻ đánh cắp dù lấy được API Key thì cũng chỉ có thể dùng được 1 API, những API khác không bị ảnh hưởng.
Vì với Basic Auth, tất cả các request đều có chứa password và nó tăng nguy cơ bị đánh cắp. Và vì nó là cái chìa khoá duy nhất cho tất cả các request nên một khi bị mất –> tất cả các phần khác đều toi.
Những thằng khác nó dùng cơ chế dạng như token, session nên nếu có bị đánh cắp thì nguy cơ chỉ đến với API đó thôi
Cảm ơn các bài chia sẻ rất hay của anh
Anh cho em hỏi thêm về việc test bảo mật API thì ngoài test Authentication như anh đã nêu trên thì cần phải test những phần nào nữa ạ. Em đang gặp vấn đề ở việc là được phân công test bảo mật API chứ k phải test toàn bộ. Nên muốn rõ hơn phạm vi cần test để tránh lan man mất thời gian ạ
Bạn có thể làm checklist theo link này https://github.com/shieldfy/API-Security-Checklist
Nếu bạn đã học và biết các vấn đề về bảo mật thì có thể nhìn vào checklist rồi làm, còn nếu chưa biết gì nhiều thì bạn nên tập trung vào các lỗi cơ bản theo owasp https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
Dạ em cảm ơn những chia sẻ rất hữu ích của anh Giang, em hiểu như này có đúng ko anh ạ. VÍ DỤ VỀ BASIC VÀ API KEY
Em cảm ơn anh Giang ạ
Không đúng em ạ.
– Để login thì có nhập username và password thật nhưng nó ko phải là basic authentication vì username và password ở phần login sẽ không nằm ở trên URL.
– API Key AuthN khác với OTP (ONE time token) em ạ, OTP chỉ sử dụng 1 lần như 1 step xác nhận nữa. Ứng dụng thường thấy của API key là 1 platform/system nào đó có rất nhiều users và nó cung cấp API để các users này có thể tương tác với system thông qua tools. Ví dụ sàn giao dịch tiền ảo Binance, người dùng có thể tương tác với sàn thông qua các ứng dụng ở mobile (UI interaction). Tuy nhiên có nhiều users muốn tự động trading (mua bán tiền ảo) theo những thuật toán, điều kiện nào đó. Những users này phải tương tác thông qua API và để xác nhận đc user đó là user nào thì sàn Binance cấp cho mỗi user như vậy 1 API key. Tương tự như vậy với github, google hay fb…
Anh đã note lại, để sau viết lại 1 bài về vấn đề này cho rõ ràng, chứ bài viết này cũ là bài dịch từ sách.
Em cam on a Giang nhieu a
Thank you!