Chào mọi người, trong thời gian vừa rồi em có đọc được 1 bài viết trên testing.vn liên quan đến việc test chức năng upload file.
Em thấy chủ đề này khá thú vị vì trước giờ khi test File Upload, chúng ta thường tập trung vào những case quen thuộc như:
- File có đúng định dạng được cho phép không?
- Dung lượng có vượt quá giới hạn không?
- Tên file quá dài thì sao?
- Upload file dung lượng lớn có bị timeout không?
- Mất mạng trong lúc upload thì hệ thống xử lý thế nào?
Đây đều là những trường hợp quan trọng và chắc chắn cần kiểm thử.
Nhưng có một câu hỏi khác mà đôi khi chúng ta dễ bỏ qua:
Nếu người dùng tình cờ upload một file chứa virus hoặc malware thì hệ thống sẽ làm gì?
Đây cũng là một scenario rất đáng để đặt ra ngay từ giai đoạn phân tích yêu cầu. Dưới đây là một số góc nhìn khi xử lý bài toán này:
Hệ thống có cơ chế quét virus cho file upload không?
- File có được virus scan sau khi upload không?
- Scan ngay lập tức (real-time) hay scan định kỳ (cron-job)?
- Nếu phát hiện file đáng ngờ thì file sẽ được xử lý thế nào?
- Người upload có được thông báo không?
- Admin có nhận được cảnh báo không?
- Có log lại sự kiện này không?
Những câu hỏi này khá quan trọng vì nó có thể ảnh hưởng trực tiếp đến scope của feature.
Ví dụ, requirement chỉ ghi đơn giản:
“User can upload documents.”
Nhưng nếu hệ thống thực tế yêu cầu virus scanning, quarantine và notification thì đây không còn chỉ là một chức năng upload file đơn thuần nữa.
Nếu những yêu cầu này không được phát hiện từ sớm, team có thể thiếu task, estimate sai effort hoặc chỉ phát hiện vấn đề khi feature gần release.
Vậy làm sao để test file chứa virus?
Có nên tìm một malware thật để upload lên môi trường test không?
Câu trả lời là không nên. Ngay cả trên môi trường development hoặc staging, việc sử dụng malware thật vẫn có thể tạo ra rủi ro không cần thiết.
Giải pháp chuẩn xác nhất chính là dùng tập tin nhiễm virus giả do EICAR cung cấp.
Đây là một tập tin tiêu chuẩn được cộng đồng an ninh mạng dùng để kiểm tra các phần mềm diệt virus. Điểm thú vị là file này không phải malware thật, nhưng được các chương trình antivirus nhận diện như một mối đe dọa để phục vụ mục đích testing.
Có thể hình dung nó giống như nút TEST trên một hệ thống báo cháy.
Không cần đốt một tòa nhà để kiểm tra hệ thống báo cháy có hoạt động hay không. Tương tự, cũng không cần dùng malware thật để kiểm tra virus scanning.
Cách thực hiện:
- Bước 1: Tạo một file hợp lệ với định dạng hệ thống cho phép (ví dụ:
test-malware.txthoặctest-malware.pdf).
- Bước 2: Truy cập vào trang https://www.eicar.org/download-anti-malware-testfile/ và làm theo hướng dẫn để lấy được nội dung test file do EICAR cung cấp.
- Bước 5: Kiểm tra xem thử hệ thống xử lý file như thế nào:
- File có bị xóa ngay lập tức hoặc bị di chuyển vào một thư mục cách ly [khu vực an toàn] không?
- Hệ thống có gửi cảnh báo cho Admin hay Dev hay không?
- Hãy thử nén file EICAR này thành
.zip, thậm chí nén nhiều tầng (zip lồng zip), hoặc đổi đuôi file nén sang định dạng khác để kiểm tra xem trình quét virus của hệ thống có đủ khả năng "đọc sâu" vào cấu trúc file hay không.
Vậy còn file hình ảnh thì sao?
"File ảnh (.png, .jpg) không thể tự thực thi mã độc như .exe hay .bat nên rất an toàn".
Đúng là việc một file.png chứa dữ liệu bất thường không đồng nghĩa với việc nó sẽ tự động thực thi như một executable. Nhưng vấn đề nằm ở những gì backend làm với file đó sau khi upload.
Ví dụ ta có 1 luồng xử lý như thế này:
Upload image → Resize → Generate Thumbnail → OCR → Convert Format → Store
Một file ảnh bị "xào nấu" (chứa mã độc ẩn bên trong cấu trúc metadata) hoàn toàn có thể gây lỗi (crash) hoặc khai thác lỗ hổng của các thư viện xử lý ảnh phía Backend
Vì vậy, khi test image upload, cần phải làm rõ luồng xử lý ảnh:
- Backend có resize ảnh không?
- Có generate thumbnail không?
- Có convert sang format khác không?
- Có OCR không?
- Có extract metadata không?
- File có được scan trước khi xử lý không?
- Nếu image parser gặp một file bất thường thì hệ thống xử lý thế nào?
Bởi vì đôi khi bug không nằm ở bước upload.
Upload có thể thành công hoàn toàn.
Nhưng lỗi lại xảy ra ở bất kỳ bước nào trong một chuỗi xử lý:
Đó cũng là lý do khi kiểm thử file upload, phạm vi không nên dừng lại ở câu hỏi:
“File này có upload được không?”
Mà nên mở rộng thành:
“Sau khi upload, hệ thống sẽ làm gì với file này?”