I. Tổng quan

Nối tiếp phần 1Ngàn lẻ một 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 1] mình nói về 2 kiểu tấn công cơ bản mà các ứng dụng về tài chính dễ bị kẻ tấn công lợi dụng để tấn công. Ở phần 2, chúng ta sẽ tiếp tục với "Numerical Processing" và "Card Number-Related Issues"

II. Numerical Processing - Xử lý số trong giao dịch

Các con số đóng vai trò vô cùng quan trọng trong các hệ thống tài chính và giao dịch điện tử. Thao tác xử lý dữ liệu số trong các ứng dụng thương mại điện tử cần được quan tâm và chú trọng để tránh gặp phải các vấn đề liên quan đến logic của ứng dụng gây ra việc mắt tiền trong một số trường hợp. Chính vì vậy, các bài test dữ liệu đầu vào với dữ liệu số không chỉ đòi hỏi người kiểm thử phải kiểm tra ứng dụng hoạt động đúng chức năng, tránh các lỗ hổng bảo mật mà còn phải hạn chế tối đa các lỗi liên quan đến "Business logic" có thể gặp phải trong ứng dụng. Bạn đọc có thể đọc thêm các lỗi về trong bài viết sau: Lỗ hổng Business logic trong bảo mật ứng dụng website .

1. Negative Numbers (số âm)

Các vấn đề xử lý dữ liệu là số âm cần được đặc biệt quan tâm, đặc biệt là các ứng dụng liên quan đến mua bán và thanh toán online. Hầu hết, các kẻ tấn công sẽ tìm cách tấn công vào logic của ứng dụng bằng việc sử dụng các công cụ chặn bắt request (BurpSuite) để chỉnh sửa request và thay đổi một số dự liệu thành số âm: số lượng, giá tiền,..

Như ở phần 1 mình đã đề cập đến môt ví dụ chuyển tiền (Ví dụ 2: Ứng dụng chuyển tiền giữa 2 ngân hàng A và B.) liên quan đến xử lý dữ liệu số âm.

Một ví dụ khác liên quan đến việc dữ liệu không xử lý tốt dữ liệu đầu vào cho phép người dùng đặt số lượng là "số âm" khiến cho số tiền người đó phải trả nhỏ hơn so với thực tế. Nếu hệ thống xử lý dữ liệu không đúng có thể khiến khi người bán hàng nhận được đơn hàng lại là số lượng sản phẩm là 31 thay vì "-31". Vì vậy, hậu quả để lại là người bán hãng sẽ bị "lỗ".

2. Decimal Numbers (số thập phân)

Vấn đề xữ liệu dữ liệu số khi làm tròn các số thập phân cũng có thể gây ra một số lỗi logic cho ứng dụng, đặc biệt khi các tham số chỉ chấp nhận số nguyên như: số lượng có thể bị lợi dụng để khai thác. Kẻ tấn công có thể lợi dụng cơ chế làm tròn số của ứng dụng để khai thác một số kịch bản sau:

Ví dụ một cupon có id: 1234 chỉ phép được sử dụng một lần. Bằng việc lợi dụng khai thác cơ chế làm tròn số thập phân, kẻ tấn công chỉ định id là :1234.000001 để tham chiếu tới cùng đối tượng có id là 1234. Vì vậy có thể sử dụng 2 lần cupon mặc dù cupon chỉ có 1 id.

3 Large or Small Numbers (Số nguyên lớn hoặc số bé)

Kiểm tra xác thực phạm vi số là một kiểm tra quan trọng, nên được thực hiện bằng cách sử dụng giá trị lớn hơn phạm vi hoặc nhỏ hơn phạm vi (cũng có thể sử dụng số thập phân ở đây).

Một ví dụ về sử dụng số nguyên: Như chúng ta đã biết phạm vi của số nguyên interger là: Phạm vi giá trị của kiểu integer (16bits) từ -32768 đến 32767 và interger ( 32 bits) là từ -2147483648 đến 2147483647. Nếu chúng ta sử dụng giá trị ngoài phạm vi trên, ứng dụng có thể xử lý lỗi. Ứng dụng kiểm tổng số tiền của một đơn hàng là một số nguyên và không được là giá trị âm, nhưng không kiểm tra giới hạn nên kẻ tấn công lợi dụng lỗ hổng đó truyền vào số lượng sản phẩm đủ lởn để giá trị tổng của đơn hàng lớn hơn: 2147483647 dẫn đến việc hệ thống xử lý bị lỗi và quay vòng về giá trị số âm

Hình thức tấn công này cũng có thể được gọi với hình thức tấn công: Overflows and Underflows

4. Zero, Null, or Subnormal Numbers

"0", "NaN" hay ký tự "null" có thể được sử dụng trong nhiều ngữ cảnh khác nhau, đặc biệt các hình thức tấn côn liên quan đến giá sản phầm. Hình thức tấn công này có thể sử dụng kết hợp với lỗ hổng về cơ chế làm tròn số trong phần 2. Hacker có thể sử dụng số thập phân rất nhỏ: 0.0000000000000000000000000000000001 hoặc 1-e50 để ứng dụng xử lý và hiểu như là một giá trị "0" nhưng thực tế số đó vẫn có giá trị >0.

5.Exponential Notation (Số mũ)

Kỹ thuật sử dụng số mũ là một biện pháp hữu ích được kẻ tấn công sử dụng để bỏ qua các kiểm tra về giới hạn độ dài dữ liệu số nhập vào. Giả sử một input giới hạn số nhập vào là số có 4 chữ số với giá trị max là "9999". Kẻ tấn công có thể nhập vào là 9e99, khi đó giá trị server sẽ xử lý thành: một số lớn hơn 9999 rất nhiều lần mà vẫn thỏa mãn điều kiện về độ dài số nhập vào:

9e99 = 9 * 10^99 -> số có 100 chữ số

Một ví dụ khác, dữ liệu nhập vào giới hạn không cho phép nhập vào số thập phân (số có chứa kí tự: "."). Khi đó kẻ tấn công sẽ nhập vào input là 1e-1 khi đó server sẽ nhận giá trị là 0.1

6. Numbers in Different Formats (Số định dạng khác nhau)

Các số trong các công nghệ khác nhau có thể được viết ở các định dạng khác nhau có thể được kẻ tấn công lợi dụng để vượt qua cơ chế kiểm tra. Ví dụ: Nếu input là “0” sẽ bị chặn tuy nhiên khi nhập giá trị là: “0,00”, “-0,00” hoặc thậm chí “$0” hoặc “£0” lại không bị chặn.

Bảng sau đây cho thấy sự khác nhau trong việc xử lý các định dạng số trong các ngôn ngữ ASP Classic (VBScript), C# .NET, Java và PHP:

III. Card Number-Related Issues (Các vấn đề liên quan đến số thẻ tín dụng)

Số thẻ thanh toán là một số dữ liệu hấp dẫn nhất đối với những kẻ tấn công. Ngoài việc được sử dụng nhằm mục đích mua sắm trực tuyến, chúng có thể được bán ở chợ đen ngay cả khi không có số CVV (ba chữ số hoặc bốn chữ số được in ở mặt trước hoặc mặt sau của thẻ thanh toán). Ngày nay, nhiều trang web thương mại điện tử tuân thủ Bảo mật dữ liệu thẻ thanh toán tiêu chuẩn (PCI DSS), làm cho chúng an toàn hơn và để thu hút nhiều nhà cung cấp và khách hàng cũng như giảm nguy cơ vi phạm dữ liệu thẻ.

Theo tiêu chuẩn PCI-DSS, nhà cung cấp dịch vụ thanh toán không được lưu trữ vĩnh viễn số thẻ, số cvv. Ngoài ra, trong trường hợp lưu trữ số thẻ thì họ phải mã hóa các số thẻ trong cơ sở dữ liệu.

(Nguồn: https://www.zeolearn.com/magazine/logic-of-credit-card-number)

1. Showing a Saved Card Number during the Payment Process

Một số trang web thương mại điện tử có thể hiển thị số thẻ ngân hàng đã lưu của người dùng trong quá trình thanh toán. Điều này vô cũng nguy hiểm có thể dẫn đến nguy cơ lộ lọt thông tin thẻ. Tuy nhiên, đôi khi, số thẻ phải được giải mã trên các cổng trang thanh toán của bên thứ 3, ví dụ: trang web xác thực 3D-Secure. Điều này có thể gây ra sự cố vì kẻ tấn công có thể lợi dụng lỗ hổng XSS hoặc sử dụng mã độc trên website để thực hiện chiếm quyền điều khiển phiên hoặc thông tin đăng nhập của người dùng hoặc có thể lấy được số thẻ của người dùng.

Rủi ro có thể được giảm thiểu nếu số thẻ chỉ được hiển thị một phần (ví dụ: 6 chữ số đàu tiên và 4 chữ số cuối cùng của thẻ) . Thậm chí để an toàn hơn, các trang web thanh toán có chứa số thẻ phải được bảo vệ bằng mật khẩu và 3D-Secure mỗi khi thực hiện các thanh toán.

2. Card Number Enumeration via Registering Duplicate Cards

Đây là hình thức tấn công nhằm thu nhập thông tin dữ liệu thẻ thông qua các thông báo lỗi khi nhập thông tin thẻ trùng trên các website cho phép nhập à lưu trữ thông tin thẻ.

Một số trang web không cho phép khách hàng của họ lưu cùng một số thẻ trong nhiều tài khoản. Một trong số các lý do là để phát hiện các tài khoản trùng lặp hoặc ngừng lạm dụng ưu đãi của người mua lần đầu. Chức năng này khi được triển khai không tốt, có thể bị hacker lợi dụng để lấy số thẻ người dùng khác đã được đăng ký trên trang web.

IV. Tổng kết

Ở phần 2 này mình đã trình bày 2 kiểu lỗi cũng như hình thức tấn công mà kẻ tấn công thường sử dụng để tấn công vào các website mua hàng và thanh toán trực tiếp liên quan đến các vấn đề xử lý dữ liệu số và quản lý dữ liệu thẻ. Với kiến thức trên, mong rằng các lập trình viên sẽ ít gặp phải những vấn đề trên để giảm thiểu tối đa nguy cơ tấn công đến từ kẻ xấu.

Bài viết được tham khảo theo nội dung: https://soroush.secproject.com/downloadable/common-security-issues-in-financially-orientated-web-applications-_v1.1.pdf

Cảm ơn các bạn đã theo dõi bài viết. Và hãy đón chờ những phần tiếp theo trong chuỗi bài viết này nhé.