I. Tổng quan

Nối tiếp Phần 1 và phần 2 về chủ đề các lỗi thường gặp trong ứng dụng web về tài chính và cách phòng tránh. Ở phần tiếp theo, chúng ta sẽ tiếp tục với các vấn đề bảo mật liên quan đến việc xử lý giá sản phẩm, khuyến mại và các vấn đề thiết lập hệ thống sao cho an toàn.

II. Dynamic Prices, Prices with Tolerance, or Referral Schemes (CWE: 840)

Có những trường hợp giá và giá khuyến mãi có thể thay đổi theo tỷ giá hối đoái, số lượng hàng đã bán, các chương trình giới thiệu và độ trễ trong việc gửi giá trong các hệ thống giao dịch động. Do đó, cần xem xét đặc tả ứng dụng để kiểm tra xem liệu nó có hỗ trợ giá động hay không. Thông thường, một tham số đầu vào bổ sung sẽ giúp ứng dụng nhận ra việc sử dụng giá động.

Ví dụ, hệ thống có thể bắt đầu sử dụng giá động khi ứng dụng không sử dụng đơn vị tiền tệ mặc định hoặc khi khách hàng sử dụng thiết bị di động hoặc sinh sống tại một quốc gia có tốc độ Internet chậm hơn. Ngoài ra, hệ thống cũng có thể xem xét việc sử dụng giá đã gửi khi có thông tin giới thiệu hoặc tham số giới thiệu có sẵn. Để tìm các hệ thống như vậy, ta cần gửi một số gần giá ban đầu (giá ± 0.01) và thay đổi các tham số khác.

Chính sách ứng dụng nên được xem xét khi gặp phải giá động để đảm bảo rằng giá đã thay đổi nằm trong khoảng cho phép. Hơn nữa, cần sử dụng kết hợp một số biện pháp mật mã an toàn (chữ ksi số) khi giá được tạo ra bởi một bên đáng tin hoặc thậm chí bởi trang web chính để phát hiện bất kỳ thao tác can thiệp nào từ các bên không đáng tin.

III. Discount Codes, Vouchers, Offers, Reward Points, and Gift Cards

Người dùng có thể kiếm điểm thưởng trong nhiều ứng dụng thương mại điện tử khi điểm có thể được sử dụng để mua các mặt hàng, chúng phải được xử lý và kiểm tra chính xác như số tiền thông thường của người dùng. Do đó, các vấn đề liên quan đến xử lý số tiên như: vấn đề làm tròn, vấn đề đơn vị tiền tệ, v.v. đều phải được kiểm tra.

Enumeration and Guessing

Mã giảm giá và phiếu quà tặng có thể được sử dụng để giảm giá giá cuối cùng nên được kiểm tra để đảm bảo rằng chúng không thể được dự đoán và không thể được liệt kê một cách dễ dàng.

Tương tự, số thẻ quà tặng hoặc thẻ thành viên nên không thể đoán được và rất khó để liệt kê, nếu không kẻ tấn công có thể tạo ra một thẻ giả để sử dụng số dư của người bị hại. Khi những thẻ này mang theo số dư có thể sử dụng, chúng nên được xử lý tương tự như số thẻ ngân hàng và nên được bảo vệ bằng mã PIN hoặc mật khẩu.

Ví dụ, một mã giảm giá như sau: SALE12032023001, SALE15032023012...

Với chỉ 2 mã trên, kẻ tấn công có thể dễ dàng đoán ra và tạo ra một mã giảm giá hợp lệ bằng quy tắc sau: SALE + ngày + tháng + năm + 3 số ngẫu nhiên: Một danh sách mã hợp lệ có thể được tạo ra bằng công tụ tự động là: SALE18032023001, SALE18032023002...SALE18032023999. Sau đó, kẻ tấn công chỉ cần sử dụng một công cụ brute-force để tấn công và áp dụng mã giảm giá.

Vouchers and Offers Stacking

Các ứng dụng thương mại điện tử thường ngăn chặn việc sử dụng nhiều phiếu giảm giá hoặc ưu đãi trong một giao dịch duy nhất. Tuy nhiên, đôi khi có những lỗi logic xảy ra khi ứng dụng không giới hạn số lượng voucher được áp dụng trong một lần gây ra những lỗi logic.

Ví dụ như một ưu đãi mua 1 tặng 1 được kết hợp với mua 3 sản phẩm trả tiền 2 hoặc mua 3 sản phẩm trả tiền 1, dẫn đến kết quả chúng ta có thể mua 3 sản phẩm với giá 1 sản phẩm hoặc 05 giá của sản phẩm.

Đôi khi có những mã khuyến mại áp dụng cho khách hàng có ngày sinh nhật trong năm nhưng ứng dụng cho phép người dùng cập nhật thông tin cá nhân (bao gồm ngày sinh) mà không có cơ chế kiểm tra (có thể sử dụng giấy tờ tùy thân) và không giới hạn số lần sử dụng mã này trong 1 năm. Một kịch bản tấn công là người dùng sẽ cập nhật ngày sinh liên tục để có thể lấy mã ngày sinh nhật nhiều lần trong năm.

Earning More Points or Cash Return than the Price when Buying an Item

Việc tích điểm khi sử dụng điểm để mua hàng không nên được phép, vì nó có thể dẫn đến các lỗi logic. Một ví dụ có thể là một ưu đãi quảng cáo, khi mua hàng bằng điểm sẽ dẫn đến việc tích lũy cùng lượng điểm đó và kết quả là mua sản phẩm mà không mất. Điều này cũng có thể xảy ra trong các hệ thống có thể nhận tiền mặt khi tiền mặt hoặc điểm tích lũy từ ưu đãi có thể được sử dụng để mua cùng một sản phẩm.

Một ví dụ thú vị khác là việc mua thẻ voucher có thể sử dụng như tiền mặt thật (giảm giá trực tiếp khi thanh toán). Những thẻ này có thể được mua với giá thấp hơn giá trị thực tế của chúng khi có ưu đãi trên tất cả các thẻ quà tặng. Ví dụ, một thẻ giảm 100usd có thể được bán với giá 50 usd trong chương trình khuyến mại. Điều này có thể trở nên nguy hiểm hơn khi thẻ quà tặng có thể được sử dụng để mua thêm các voucher trên, vì việc này sẽ tạo ra lợi nhuận liên tục cho khách hàng.

Using Expired, Invalid, or Other Users’ Codes

Ứng dụng cần có cơ chế kiểm tra các mã giảm giá để đảm bảo kiểm tra các vấn đề sau:

• Mã giảm giá đã được sử dụng quá số lần quy định trước đó chưa (đối với mã giảm giá sử dụng giới hạn số lần)
• Mã giảm giá đã quá hạn sử dụng chưa (đối với mã giới hạn thời gian sử dụng)
• Mã giảm giá có được áp dụng đúng chủng loại sản phẩm không (với mã áp dụng riêng biệt cho từng mã)
• Với mã sử dụng một lần cho mỗi user cần có cơ chế kiểm tra việc replay attack để chống việc sử dụng lại mã đó nhiều lần.

Một ví dụ khác về việc sử dụng mã khuyến mại khi mã khuyến mại của nhà cung cấp A có thể được sử dụng trên trang web của nhà cung cấp B, ngay cả khi người dùng không có một tài khoản với nhà cung cấp A.

State and Basket Manipulation

Ứng dụng cần có cơ chế kiểm tra để đảm bảo mã khuyến mại được áp dụng ở trạng thái cuối cùng của đơn hàng và cần tính toán lại điều kiện áp dụng voucher sau mỗi lần người dùng cập nhật giỏ hàng (thay đổi mặt hàng, số lượng sản phẩm, chủng loại...).

• Một kịch bản tấn công có thể xảy ra khi người dùng áp dụng mã khuyến mại thành công sau đó giảm hoặc tăng số lượng sản phẩm mà ứng dụng không kiểm tra lại đơn hàng. Ví dụ, một mã giảm giá 100 usd cho đơn hàng từ 3000 usd. Sau khi áp dụng mã thành công, người dùng remove bớt số lượng sản phẩm và đơn hàng chỉ còn 1000 usd, nhưng khi đó mã khuyến mại vẫn được áp dụng thành công và từ đó người dùng có thể mua được sản phẩm và áp dụng mã thành công.

• Một kịch bản khác về việc áp dụng mã giảm giá cho những sản phẩm không nằm trong danh mục. Ví dụ một mã giảm giá 20% được áp dụng cho toàn bộ đơn hàng nếu người dùng mua sản phẩm A, tuy nhiên khi áp dụng thành công xong mã giảm giá người dùng thêm một số sản phẩm B vào đơn hàng nhưng ứng dụng không thực hiện kiểm tra lại mà vẫn áp dụng mã giảm giá cho toàn bộ đơn hàng. Kết quả là, người dùng được áp dụng mã khuyến mại cho cả sản phẩm A và sản phẩm B.

Vì vậy, chúng ta cần luôn kiểm tra lại điều kiện áp dụng mã giảm giá sau mỗi lần cập nhật đơn hàng hoặc ở bước thanh toán cuối cùng cần kiểm tra danh sách toàn bộ đơn hàng để kiểm tra việc thỏa mãn điều kiện của mã khuyến mại.

Buy-X-Get-Y-Free

Các mã giảm giá mua 1 tặng 1 thường chỉ được áp dụng cho những sản phẩm có giá cao hoặc trong một số chương trình khuyến mại đặc biệt và đôi khi chỉ giới hạn cho 1 lần mua hoặc 1 sản phẩm nhất định. Một số kịch bản tấn công có thể được sử dụng để kẻ tấn công có thể mua được nhiều hàng hóa với giá rẻ hơn thông thường bằng cách kết hợp các mã giảm giá với nhau:

• Ví dụ như một ưu đãi mua 1 tặng 1 được kết hợp với mua 3 sản phẩm trả tiền 2 hoặc mua 3 sản phẩm trả tiền 1, dẫn đến kết quả chúng ta có thể mua 3 sản phẩm với giá 1 sản phẩm hoặc 05 giá của sản phẩm.
• Một ví dụ khác khi người dùng sử dụng mã mua 3 tính tiền 2 nhưng giá sản phẩm khác nhau (2 sản phẩm giá rẻ và 1 sản phẩm giá đắt) nhưng khi thanh toán thì người dùng chỉ cần trả tiền giá của 2 sản phẩm rẻ còn sản phẩm đắt sẽ là free.

Point Transfer

Nếu người dùng có thể nhận được điểm từ việc giới thiệu người khác hoặc họ tự tăng ký bằng các email khác nhau, họ có thể lợi dụng cơ chế chuyển điểm để có thể đạt được nhiều điểm hơn. Các ứng dụng chỉ nên cho phép thực hiện cơ chế đổi điểm khi đóng tài khoản hoặc thẻ thành viên của họ bị mất. Các chức năng chuyển điểm không nên cho phép thực hiện từ phía user. Nếu ứng dụng cần phát triển tính năng này, các kịch bản test trước đó cũng cần được kiểm tra.

IV. Downloadable and Virtual Goods

Một số hệ thống thương mại điện tử cho phép chúng ta thực hiện một số chức năng liên quan đến việc download file: MP3, PDF, EXCEL... Nếu các ứng dụng không có các biện pháp bảo mật được triển khai về mặt phân quyền có thể dẫn đến các lỗ hổng IDOR. Một ví dụ, người dùng có thể downoad đơn hàng của mình bằng file PDF, nếu file PDF chỉ sử dụng ID của đơn hàng là một số có 6 chữ số và không có cơ chế phân quyền có thể dễ dàng bị tấn công bằng môt cuộc tấn công IDOR kết hợp công cụ brute-force để download toàn bộ các đơn hàng của người dùng trong hệ thống.

V. Hidden and Insecure Backend APIs

Các ứng dụng thương mại điện tử thường có nhiều ứng dụng chạy song song: web, mobile, desktop app... Các ứng dụng này có thể được sử dụng để gọi tới hệ thống api. Một số api thường được gọi đến "ẩn" với người dùng vì chúng ta chỉ thao tác trên giao diện hoặc các chức năng không dành cho người dùng (chức năng của admin). Vì các api này chạy và được gọi từ ứng dụng nên đôi khi các nhà phát triển không có cơ chế xác thực hay phân quyền có thể dẫn đến các cuộc tấn công vượt qua xác thực và phân quyền. Một ví dụ về một end-point quản lý users chỉ dành cho admin, /api/v1/users có thể được gọi trực tiếp từ một người dùng thông thường trên hệ thống do không có cơ chế phân quyền. Lý do của lỗ hổng này là vì người phát triển ứng dụng nghĩ rằng user thông thường không có chức năng này nên không thể biết được. Nhưng thực tế, chúng ta có thể sử dụng một số công cụ để tìm kiếm và phát hiện ra các endpoint này một cách tự động, từ đó tìm cách khai thác và tấn công lỗ hổng này.

VI. Using Test Data in Production Environment

Thông thường các ứng dụng thương mại điện tử thường có các môi trường khác nhau: testing, staging, development, production. Các môi trường phát triển và test cần được tách biệt với môi trường production. Một số lỗi có thể xảy ra khi dữ liệu dùng chung giữa các môi trường hoặc do thiếu cơ chế kiểm tra xử lý các request đến từ các môi trường khác nhau. Một số kịch bản tấn công phổ biến:

• Một ứng dụng sử dụng tham số: payment_type là môt số nguyên gửi đến server, tham số này được sử dụng để xác định payment method được sử dụng trên server. Bằng cách thay đổi tham số này sang một giá trị số nguyên khác, ứng dụng sẽ gọi đến payment gateway của hệ thống test sử dụng tài khoản test để giả lập mội trường thật. Và kết quả là, kẻ tấn công có thể mua hàng thật nhưng không mất tiền do sử dụng tiền trên môi trường test.

• Tất cả các input và page của người dùng gửi lên sẽ được kiểm tra để đảm bảo không thể tiến hành gửi request với dữ liệu test tới hệ thống đang chạy production . Tuy nhiên, bằng cách thay đổi tham số HOST trong header, kẻ tấn công có thể thay đổi tham số này để điều hướng ứng dụng gọi tới hệ thống test từ đó khai thác lỗ hổng này.

Khi các ứng dụng chạy trên môi trường production, chúng ta cũng cần sử dụng các dữ liệu test để kiểm tra và từ đó đảm bảo rằng các dữ liệu này không thể sử dụng trên môi trường production.

VII. Currency Arbitrage in Deposit/Buy and Withdrawal/Refund

Nếu một ứng dụng thương mại điện tử hỗ trợ nhiều phương thức thanh toán khác nhau với nhiều loại tiền tệ khác nhau, một người dùng có thể tiến hành rút tiền từ một đơn vị tiền tệ này sang đơn vị tiền tệ khác. Các ứng dụng cần kiểm tra và tính toán để tránh việc bị lợi dụng tấn công. Một ví dụ minh họa cho kiểu tấn công này như sau:

Một bên thứ ba hỗ trợ hai payment types khác nhau: Đổi từ usd -> euro và euro ->usd ở 2 ngân hàng khác nhau là A và B Ngân hàng A: Đổi 2 euro tương ứng 3 usd và ngược lại Ngân hàng B: Đổi 3 euro tương ứng 4 usd và ngược lại Vậy với cùng 12 usd nếu đổi ở ngân hàng A, người dùng sẽ có 8 euro nhưng nếu đổi ở ngân hàng B thì người dùng sẽ nhận về 9 euro. Vì vậy người dùng sẽ lợi hơn khi sử dụng việc chuyển đổi ở ngân hàng A.

Tổng kết

Nội dung ở phần số 3 tập trung vào các vấn đề liên quan đến việc tính toán giá trị đơn hàng cũng như các kịch bản tấn công và phòng tránh khi sử dụng mã khuyến mại, sử dụng điểm, đổi rút tiền thưởng... và lưu ý về dữ liệu được phép sử dụng trong môi trường production. Hi vọng với chuỗi 3 bài viết trong series này sẽ giúp các bạn phần nào hình dung được các lỗ hổng bảo mật cũng như phòng tránh các lỗ hổng trên khi phát triển ứng dụng.