Mở đầu

GraphQL là ngôn ngữ trung gian kết nối giữa Client và Server. Nó không phải là RESTful API và chỉ có 1 endpoint duy nhất. Có thể tùy biến được dữ liệu trả về cho client. Được phát triển bởi Facebook

Ngày nay GraphQL được sử dụng bởi nhiều công ty khác nhau như GitHub, Twitter, Shopify, Yelp…

Vấn đề của RESTful API

• Ta có một bài toán như sau: Có một danh sách post, mỗi post có một danh sách like, trong đó like gồm name và avatar, post thì gồm title, description, … Ta đã có sẵn API post, chỉ còn thiếu danh sách like trong post
• Giải quyết bài toán: Trong API của post, ta thêm like vào
• Vấn đề gặp phải: Nếu màn hình phía client chỉ cần thông tin của post như vậy dữ liệu like trả về ở đây sẽ dư thừa, gây ra ảnh hưởng lớn tới performance nếu dữ liệu nhiều

RESTful với GraphQL

GraphQL so với REST. Đó là một cuộc tranh luận gay gắt trong thế giới API trong một thời gian. Và thẳng thắn mà nói, chúng chỉ là hai phương pháp khác nhau để giải quyết cùng một vấn đề: truy cập dữ liệu từ các dịch vụ web.

Mặc dù hai công nghệ có một số điểm tương đồng, nhưng sự khác biệt nhỏ có thể khiến bạn lựa chọn công nghệ này hơn công nghệ khác.

REST và GraphQL là hai cách tiếp cận thiết kế API thực hiện cùng một chức năng: truyền dữ liệu qua các giao thức internet như HTTP. Tuy nhiên,GraphQL là một ngôn ngữ truy vấn, trong khi REST là một mẫu kiến trúc.

Một số thuộc tính của GraphQL (đối với client)

1. Fields: hiểu đơn giản là các trường ta muốn trả về

{
  hero { // đây là field
    name // đây là field
  }
}

2. Argument: là đối số truyền vào

{
  human(id: "1000") { // id: "1000" chính là đối số truyền vào
    name
    height
  }
}

3. Fragments: khi ta có quá nhiều câu truy vấn có cùng trường trả về, thì ta tạo fragment. Nó giống như một tệp đóng gói, ta sẽ đem tệp này sử dụng ở nhiều nơi

  leftComparison: hero(episode: EMPIRE) {
    ...comparisonFields
  }
  rightComparison: hero(episode: JEDI) {
    ...comparisonFields
  }
}

fragment comparisonFields on Character {
  name
  appearsIn
  friends {
    name
  }
}

4. Directives: ta có 2 loại directives là @include và @skip, như tên gọi, tùy vào trường hợp mà ta sử lý thế nào cho hợp lý

query Hero($episode: Episode, $withFriends: Boolean!) {
  hero(episode: $episode) {
    name
    friends @include(if: $withFriends) {
      name
    }
    girlFriends @skip(if: $withFriends) {
      name
    }
  }
}

5. Query và Mutation

• Query: được dùng khi chúng ta muốn hiển thị gì đấy, như show list hay show detail của post
• Mutation: được dùng khi chúng ta muốn tạo mới, chỉnh sửa hay xóa record thì mutation sẽ được sử dụng
• Có thể dùng ngược lại vì việc defined xem, tạo, xóa, sửa sẽ do phía Back-end xử lý

Kết luận

• Bài viết này mình đã giới thiệu chung về GraphQL, với mong muốn mọi người hiểu được GraphQL là gì, Tại sao nó lại ra đời. Mình cũng muốn nhấn mạnh là GraphQL là một query language cho API, nó ra đời để khắc phục những thiếu sót và nhược điểm của REST.
• Nguồn tham khảo: https://www.howtographql.com/basics/0-introduction/

The post Introduction to GraphQL appeared first on Tomoshare.

4. Unlimited Resource Consumption

API không được bảo vệ, dễ bị tổn thương trước số lượng request hoặc payload sizes quá lớn. Những kẻ tấn công có thể sử dụng điều này gây Denial of Service (DoS) cho hệ thống, hoặc brute force attacks để cố gắng authentication.

Lỗ hổng Unlimited Resource Consumption xảy ra khi API không có cơ chế hạn chế số lượng request tới server. Ví dụ chắc năng login bằng số điện thoại và mã OTP được gửi về số điện thoại, sau đó quá trình xác thực được thực hiện thông qua API POST /api/users/otp_verify. Kẻ tấn công sẽ dùng brute force attacks để tấn công API, random OTP từ 0000 -> 9999 để kiểm thử tìm ra OTP chính xác. Ngoài ra kẻ tấn công có thể upload file với kích thước quá lớn hoặc queries phức tạp khiến API gặp phải tình trạng tắc nghẽn và drop requests.

Cách phòng chống:

• Áp dụng chính sách rate-limiting cho tất cả API endpoints. Đặt biệt với những endpoints liên quan đến authentication là mục tiêu hàng đầu của những kẻ tấn công.
• Giới hạn số lượng requests có thể được thực hiện từ một địa chỉ IP hoặc người dùng trong một khoảng thời gian nhất định.
• Sử dụng keys, fingerprints, recaptcha, .. để giới hạn tốc độ requests.
• Giới hạn payload size và độ phức tạp của query.
• Giới hạn số lượng dữ liệu mà một truy vấn có thể truy xuất bằng cách áp dụng các giới hạn về pagination size, or page counts.
• Tận dụng các biện pháp bảo vệ DDoS từ cloud provider (AWS WAF, API Gateway, …).

5. Broken function level authorization

Ở Part I, chúng ta có broken object level authorization là lỗ hổng liên quan đến phân quyền truy cập đến các đối tượng, user1 có thể truy xuất dữ liệu của user2 thông qua thay đổi ID. Còn lỗ hổng broken function level authorization liên quan đến phân quyền các chức năng của hệ thống. Kẻ tấn công phán đoán các API ẩn với những đặc quyền cao hơn và thực thi chúng. Ví dụ kẻ tấn công có thể truy cập đến API /api/users/my_financial_info, bọn chúng phán đoán và thử thay đổi users -> admin truy cập vào API /api/admin/all_info, sự phân quyền yếu kém có thể dẫn đến việc lộ hết các thông tin nhạy cảm của tất cả users.

Cách phòng chống:

• Chia các API endpoints thành các function scope, phần quyền chặt chẽ theo từng scope.
• Kiểm soát truy cập các function trên server không bao giờ chỉ xử lý phân quyền ở phía client.
• Mặc định để deny all access các function. Chỉ cấp quyền với đối tượng cụ thể.

6. Unrestricted Access to Sensitive Business Flows

Khi các API thực hiện một business flow (quy trình đặt vé, mua sản phẩm, ..). Kẻ tấn công nắm được các business này, lợi dụng các API bằng các phương pháp tự động để đạt được mục đích xấu, chẳng hạn như lấy cắp dữ liệu hoặc thao túng dữ liệu thị trường hoặc giá cả.

Một business flow thường gặp và kịch bản tấn công:

• Purchasing a product flow – Kẻ tấn công sử dụng tính năng tự động để mua tất cả hàng tồn kho của một mặt hàng có nhu cầu cao cùng một lúc và bán lại với giá cao hơn.
• Creating a comment/post flow – Kẻ tấn công lợi dụng tính năng bình luận hoặc post bài viết để tự động spam hệ thống.
• Making a reservation – Kẻ tấn công có thể đặt tất cả các chỗ , ngăn chặn người dùng khác sử dụng hệ thống.

Cách phòng chống:

• Cần nắm vững các business flow, hiểu các business flow có thể dễ bị lạm dụng và thêm các lớp bảo vệ bổ sung cho các quy trình này, authentication là required.
• Áp dụng rate-limiting để hạn chế số lượng và tốc độ truy cập.
• Monitor số lượng truy cập API để phát hiện nguồn truy cập đáng ngờ.
• Identify non-human: Xác định xem đó có phải người dùng thao tác không chẳng hạn như kiểm tra giao dịch nhanh bất thường, thiết lập Captcha, human detection,..

Trong ba lỗ hổng trên, ý kiến cá nhân mình đánh giá Unrestricted Access to Sensitive Business Flows là anh em xác suất dính phải cao nhất, còn các anh em khác thấy như thế nào? Tự hỏi admin blog mình có cơ chế nào tránh việc comment spam không ta ?…….

Reference

https://apisecurity.io/owasp-api-security-top-10/

The post Top 10 API Security Vulnerabilities in 2023 (Part II) appeared first on Tomoshare.

1. Broken object level authorization

Sở dĩ Broken object level authorization nằm top 1 là vì hacker không cần sử dụng phương pháp tấn công gì cao siêu, chỉ cần thay thế ID tài nguyên của họ bằng ID tài nguyên thuộc về người dùng khác. Ví dụ như, kẻ tấn công biết được API có dạng /api/shopID/financial_info, chúng thử nghiệm thay thế từng shopID, nếu API không phân quyền user với từng shop thì hacker có thể xem được thông tin của tất cả các shop. Vấn đề có thể trầm trọng hơn khi ID là tuyến tính có thể liệt kê ra được (ID: 1,2,3,..).

Cách phòng chống:

• Thực hiện kiểm tra ủy quyền chặt chẽ với từng API và nên xây dựng hệ thống phân quyền có cấp bậc với từng tài nguyên. Chỉ những user có quyền xem financial_info của shop1ID mới có quyền call API /api/shop1ID/financial_info.
• Không nên dựa vào ID phía client gửi, sử dụng ID được lưu trữ trong session. Thay vì sử dụng /api/shopID/financial_info, ta có thể sử dụng /api/financial_info lấy thông tin shop dựa vào current_user.
• Sử dụng random IDs để kẻ tấn công không thể đoán được (UUIDs – /api/cc20c3ec-1fcc-4912-a0bc-b361d1180b63/financial_info).
• Triển khai test case đầy đủ để ngăn ngừa lỗ hổng này.

2. Broken authentication

Broken object level authorization là lỗ hổng liên quan đến phân quyền, còn broken authentication là xác thực. Xác thực API được triển khai kém cho phép hacker giả định danh tính của người dùng khác hoặc truy cập tài nguyên mà không cần bất kỳ xác thực nào.

Nguyên nhân dẫn đến broken authentication:

• Những internal API không có authentication. Một số API nằm trong private network chúng ta mặc định đã an toàn mà bỏ qua việc xác thực.
• Có cơ chế xác thực nhưng cơ thể xác thực đơn giản, API key yếu, dễ đoán không rotate định kỳ.
• Mật khẩu yếu, plain text, hàm băm kém, mật khẩu dùng chung hoặc mật khẩu mặc định. Một số hệ thống tự động tạo password mặc định nhưng password dễ đoán mà không có chức năng reset password lần login đầu tiên.
• Authentication dễ bị brute force attacks. Brute force attacks là kiểu tấn công mà hacker sẽ cố gắng đoán mật khẩu hoặc các thông tin xác thực khác bằng cách thử tất cả các kết hợp ký tự có thể.
• Thông tin credentials and keys bị lộ trong URLs.
• Cơ chế xác thực yếu, JWT token chỉ decode mà không verify signature (chữ ký).
• Sử dụng token vĩnh viễn, không hết hạn.

Cách phòng chống:

• Kiểm tra tất cả các API đã xác thực chưa, nếu có thì các cách có thể xác thực.
• API cho password reset and one-time links để authenticate cần được bảo mật, có thể đính kèm với one-time verification code.
• Sử dụng những phương pháp tiêu chuẩn có sẵn để generate token (JWT), lưu trữ password và multi-factor authentication (MFA).
• Sử dụng rate-limiting cho việc authentication (quy định hạn mức request authenticate thất bại), thực hiện các chính sách lockout khi có nghi ngờ, kiểm tra password yếu của người dùng.

3. Broken Object Property Level Authorization

API endpoints có thể bị tấn công dựa vào data của chúng (request data, response data): response data tiết lộ nhiều thông tin hơn mục đích business (excessive information exposure), chấp nhận và xử lý nhiều request data hơn mức cần thiết (mass assignment).

Nhiều API trả về toàn bộ dữ liệu thuộc tính của object (user->toJson()), việc lọc dữ liệu cần thiết để hiển thị được hiện bên phía client. Kể tấn công có thể lấy các dữ liệu nhạy cảm, phân tích để biết được các fields của object của database để tấn công mass assignment.

Mass assignment ở đây là cách kẻ tấn công bổ sung thêm các fields nhạy cảm vào request payload gửi lên API. API không lọc dữ liệu đầu vào, permit data, bind toàn bộ params data sang object và lưu object đó vào database. Kẻ tấn công có thể chỉnh sửa thông tin nhạy cảm, thay đổi role người dùng,…

Cách phòng chống:

• Không trả về toàn bộ dữ liệu và dữ liệu phải được lọc ở server trước khi trả về cho client. Chỉ tiết lộ dữ liệu cần thiết để hiển thị phía client.
• Xác định các dữ liệu nhạy cảm và tránh tiết lộ các thông tin này: Personally Identifiable Information (PII – email, phone, passport, Social Security number), Payment Card Industry (PCI).
• Không tự động assign params data tới objects. Cần permit params, payload data, lọc và lấy dữ liệu cần thiết.
• Sử dụng readOnly với những thuộc tính có thể truy xuất qua API mà không bao giờ được sửa đổi.

Trên đây là top 3 lỗ hổng bảo mật hàng đầu ! Thui buồn ngủ rùi hẹn các đồng dâm ở part II nha !

Reference

https://apisecurity.io/owasp-api-security-top-10/

The post Top 10 API Security Vulnerabilities in 2023 (Part I) appeared first on Tomoshare.