Cách tốt nhất để bảo mật Rest API được xây dựng dựa trên PHP và được sử dụng trong ứng dụng Android và iOS chỉ dành cho thành viên là gì?
trả lời 1
Bạn cần xác định hoặc rút ra các mục tiêu bảo mật từ các yêu cầu. Điều này bao gồm việc xác định loại dữ liệu và mức độ bảo vệ cần thiết. Sau đó, bạn có thể tìm kiếm một giải pháp thích hợp. Điều này có thể bao gồm từ OAuth2 đến mã hóa khóa công khai/riêng tư được lưu trữ trong kho lưu trữ khóa điện thoại. Nó có thể yêu cầu thêm 2MFA trên thiết bị thứ hai
Để có ý tưởng hay, hãy kiểm tra Tài liệu API được sử dụng nhiều, như mailgun để biết cách tiếp cận vững chắc. Cũng xem xét liệu bạn sẽ sử dụng
- API đồng bộ nơi một cuộc gọi được thực hiện thì tải trọng được trả lại hoặc;
- API không đồng bộ trong đó lệnh gọi được thực hiện thì lệnh gọi lại Webhook sẽ kích hoạt vào một thời điểm nào đó trong tương lai
Cả hai đều có ưu và nhược điểm của họ. Cho dù bạn chọn mẫu nào đồng bộ hay không đồng bộ, cũng sẽ ảnh hưởng đến phương pháp bảo mật của bạn
Có nhiều hơn để bảo mật API của bạn mặc dù. Hãy nghĩ về máy chủ web của bạn. Khi bạn thiết lập kết nối cơ sở dữ liệu, có thể bạn có tệp cấu hình thiết lập $db bao gồm cơ sở dữ liệu, tên người dùng và mật khẩu của bạn. Có thể bạn đã thiết lập một API nội bộ để quản lý tất cả các cuộc gọi và giữ cho chế độ xem của bạn tách biệt với logic của bạn. Bạn không cần lo lắng về $db_name hoặc $db_password vì thông thường không ai có thể truy cập được trừ khi họ tấn công máy chủ của bạn, điều này sẽ không xảy ra khi bạn có các phương pháp hay và bạn không phải là mục tiêu lớn
Nếu bạn có hai máy chủ, một cho trang web của bạn và một cho cơ sở dữ liệu của bạn, bạn vẫn có thể thực hiện lệnh gọi API ở phía máy chủ và mọi thứ được bảo vệ
Nhưng bạn có đưa máy chủ của mình cho người khác bằng mật khẩu cơ sở dữ liệu hoặc khóa API không? . Nhưng đó là những gì bạn đang làm với một ứng dụng di động gốc. Có, bạn có thể tạo mã thông báo API thay đổi và gửi mã thông báo đó tới API nơi đặt máy chủ dữ liệu của bạn
Có tài nguyên thực sự tốt về điều này trên tài liệu dành cho Nhà phát triển Android của Google – Các phương pháp hay nhất về bảo mật ứng dụng và tài liệu này có đủ chi tiết
Bạn có thể đọc tài liệu và tìm hiểu cách thức cơ chế thiết lập điểm cuối của mình và cách mailgun sử dụng xác thực cơ bản, điều đó không giải thích được rằng bạn đang hỏi về bảo mật đối với API DB của mình
trả lời 2
Ý tưởng chung cho hầu hết các API là người dùng API của bạn có thông tin xác thực của riêng họ. Giả sử bạn có một người dùng với tên người dùng là john. thợ rèn và mật khẩu 12345
John. Người dùng smith đưa ra một yêu cầu ban đầu tới API, cung cấp tên người dùng/mật khẩu của anh ấy và máy chủ sẽ kiểm tra xem thông tin đăng nhập có đúng không. Nếu có, thì máy chủ sẽ tạo một loại mã thông báo nào đó. Có nhiều mã thông báo khác nhau, chẳng hạn như JWT, nhưng để đơn giản, giả sử đó là một chuỗi duy nhất như GUID hoặc thứ gì đó, chẳng hạn như “f3ef72e4-6adf-4f6d-a2aa-c948dc15955e”
Bất kể mã thông báo đó là gì, nó được tạo trên máy chủ và được liên kết với người dùng đó theo một cách nào đó [e. g. một bản ghi trong bảng cơ sở dữ liệu hoặc một cái gì đó nói rằng “john. smith” = “f3ef72e4-6adf-4f6d-a2aa-c948dc15955e”] và sau đó được trả lại cho người dùng
Từ đó, tất cả các yêu cầu API khác sẽ không gửi tên người dùng/mật khẩu mà thay vào đó sẽ chuyển mã thông báo như một phần của yêu cầu API của chúng
Vì vậy, bây giờ khi máy chủ nhận được yêu cầu API, nó có thể kiểm tra xem mã thông báo đó có hợp lệ hay không, nó thuộc về ai, họ nên có những quyền gì, v.v… và sau đó, nó có thể xử lý yêu cầu API nếu mọi thứ đều hợp lệ
Thông thường, các mã thông báo này được chuyển trong cookie hoặc tiêu đề HTTP, do đó, mã thông báo không hiển thị trong bất kỳ nhật ký nào và không làm cho nội dung của yêu cầu API trở nên lộn xộn, nhưng tùy thuộc vào cách bạn muốn thực hiện phần đó
Sau một khoảng thời gian nhất định, mã thông báo sẽ không hoạt động nữa [khi bạn tạo mã thông báo, bạn có thể lưu trữ ngày/giờ để cho biết mã thông báo có thể hoạt động trong bao lâu] và người dùng sẽ phải tạo một mã mới với
Một lần nữa, có nhiều loại mã thông báo – JWT là một định dạng rất phổ biến, do đó, bạn phải chọn loại phù hợp cho API của mình
trả lời 3
Thông thường, khi mọi người nói về việc băm mật khẩu và so sánh trong SQL, họ đang nghĩ đến một tình huống trong đó mật khẩu đã được băm trong cơ sở dữ liệu, chẳng hạn như mật khẩu “abc” được băm thành phiên bản SHA-1. “a9993e364706816aba3e25717850c26c9cd0d89d”
Tuy nhiên, một phần mục đích của việc băm là để chỉ một bên [phía máy chủ] biết chính xác cách thức hoạt động của việc băm đó. Thông thường, bạn sẽ thấy quá trình băm được thực hiện dưới dạng băm “salted”, có nghĩa là thay vì băm “abc” và lưu trữ giá trị đó trong DB, trước tiên, máy chủ sẽ thêm tiền tố vào giá trị bằng giá trị bí mật của chính nó, chẳng hạn như “[email được bảo vệ]#”
Mục đích của việc này là giúp bảo vệ mật khẩu nếu danh sách tên người dùng/mật khẩu băm bị rò rỉ hoặc bị tấn công. Nếu điều đó xảy ra, thì người dùng ác ý có thể dịch ngược mã phía ứng dụng/máy khách và xem kỹ thuật băm, sau đó thử chạy danh sách dựa trên từ điển băm ngược
Nhưng với việc tạo muối phía máy chủ, giờ đây có một thành phần của hàm băm đó mà khách hàng không biết. Vì vậy, cơ sở dữ liệu sẽ phải bị rò rỉ VÀ thành phần muối bổ sung đó sẽ phải được biết để ai đó thực hiện một cuộc tấn công đúng cách
Tất cả những gì đã nói, việc sử dụng hàm băm muối tiêu chuẩn thường không còn phổ biến nữa. Chúng không -khủng khiếp-, nhưng thường có những cách tốt hơn. Bạn có PHP làm vùng chủ đề, vì vậy, bạn muốn sử dụng các hàm password_hash[] và password_verify[], tương tự về khái niệm nhưng sử dụng các phương thức rất an toàn cũng tự động tận dụng các phương thức mạnh hơn theo thời gian trong khi vẫn tương thích ngược
Bây giờ, khi băm mọi thứ ở phía máy khách, tôi sẽ lưu ý rằng vẫn còn -some- giá trị trong đó, nhưng không liên quan theo bất kỳ cách nào đến cách băm được lưu trữ trong cơ sở dữ liệu
Giả sử bạn đang sử dụng HTTPS cho các yêu cầu API này [bạn nên như vậy], miễn là bạn không gửi thông tin đăng nhập bên trong chuỗi truy vấn [không bao giờ gửi bất kỳ thông tin nhạy cảm nào trong chuỗi truy vấn – chuỗi truy vấn thường là một phần của quyền truy cập web . Thông tin đăng nhập được gửi trong tiêu đề hoặc trong nội dung sẽ được mã hóa [và nếu bạn nghĩ về nó, đó là cách chúng tôi đăng nhập vào hầu hết các ứng dụng web hiện nay thông qua trình duyệt của chúng tôi]. Điều đó nói rằng, nếu có bất kỳ mối quan tâm nào với điều này [e. g. MITM, chẳng hạn như tường lửa của công ty chặn lưu lượng truy cập để kiểm tra và có thể giải mã vì chúng đóng vai trò là điểm cuối], bạn luôn có thể băm mật khẩu để mật khẩu thực của người dùng không bị gửi qua
Máy chủ sẽ không thực sự quan tâm - nó chỉ đơn giản nghĩ rằng ai đó tình cờ nhập 8b476a33a779b52582d13e4f7d85a1e6cd99f72a [hoặc bất kỳ hàm băm nào] làm mật khẩu của họ. Ưu điểm chính sẽ nằm trong các kịch bản proxy đó. Nếu người dùng tình cờ sử dụng lại cùng một mật khẩu cho tất cả các ứng dụng của họ và nếu CÓ một proxy chặn SSL đang hoạt động, thì quản trị viên hệ thống độc hại không thể thấy mật khẩu ban đầu và sau đó thử lại thông tin đăng nhập của người dùng đó ở một nơi khác. Và nếu bạn sử dụng một loại muối thực sự dài, khó hiểu khi băm ở phía ứng dụng, ngay cả khi họ dịch ngược ứng dụng và lấy được muối, thì sẽ rất khó để tìm thấy kết quả khớp trong bất kỳ từ điển tra cứu hàm băm nào