Với SaaS phục vụ nhiều khách hàng trên cùng một database, câu query nào đụng tới bảng của khách cũng phải có WHERE tenant_id = ?. Quên một lần là khách A thấy đơn hàng của khách B. Review code hiếm khi bắt được, vì thiếu một điều kiện là một thứ vắng mặt, rất khó nhìn ra. Test thì vẫn xanh, vì dữ liệu test thường chỉ có một tenant.
QueryFence kiểm tra các câu SQL mà integration test thật sự gửi xuống database, và cho build fail ở đúng câu quên lọc tenant. Trước khi phát hành 0.1.0, bọn mình muốn biết nó xử lý thế nào với code không được viết để chiều nó, nên đã chạy thử trên Northwind Shop: một ứng dụng mẫu riêng trong repo QueryFence, viết theo kiểu một codebase Spring Boot thật đã lớn lên vài năm, có Spring Data JPA, JPQL, native query và mapper MyBatis.
Cách chạy thử
Bọn mình làm đúng theo hướng dẫn áp dụng, như một người dùng mới:
- Thêm dependency
queryfence-spring-test. - Lấy danh sách bảng có tenant từ
information_schema, viết policy vớimode: REPORTđể chưa làm fail gì cả. - Chạy các test mà ứng dụng đã có sẵn. Không thêm hay sửa test nào.
- Đọc báo cáo và xét từng kết quả xem có phải lỗi thật không.
Con số
queryfence.yml [REPORT]: 20 findings, 75 statements, 62 tests Kết luận lỗi lộ dữ liệu thật 15 báo nhầm 4 ngoại lệ có chủ đích 1
Mỗi kết quả đến từ một chỗ khác nhau trong code, nên mỗi cái là một lần sửa riêng. Quan trọng không kém: mọi câu query viết đúng đều qua. Derived query có tenant, phân trang kèm câu count(*), join được lọc qua bảng bên kia, subquery exists, CTE có điều kiện bên trong, và SQL động của MyBatis giữ được tenant đều không bị báo.
Những lỗi đáng xem kỹ
Phần lớn trong 15 lỗi là những thủ phạm quen mặt: một findByStatus còn sót từ bản prototype đầu tiên, một findAll() trên bảng có tenant, một lệnh update hàng loạt chạy qua mọi tenant, một findByNumber dựa vào chuyện số hoá đơn là duy nhất, mà duy nhất không có nghĩa là đã tách tenant, và một findById từ màn hình hỗ trợ khách hàng. Có hai lỗi thuộc loại người review gần như không bao giờ thấy:
Điều kiện MyBatis biến mất lúc chạy
Mapper dựng mệnh đề WHERE bằng <if>. Khi tham số tenant là null, điều kiện lặng lẽ biến mất và câu query trả về đơn hàng của mọi tenant. Cùng một câu trong mapper, lần gọi này an toàn, lần gọi sau thì không, nên đọc file XML sẽ không thấy. Chỉ kiểm câu thật sự đã chạy mới bắt được.
Nửa sau của UNION ALL
Một báo cáo đối soát có hai nhánh. Nhánh đầu có p.tenant_id = ?, nên nhìn qua tưởng đã lọc. Nhánh thứ hai cộng hoá đơn chưa thanh toán của tất cả tenant. QueryFence kiểm từng nhánh riêng, nên đã bắt được nhánh thứ hai.
Những chỗ QueryFence sai
Có 4 lần báo nhầm, tức 20% số kết quả, hay khoảng 5% số câu lệnh:
- Hai lần nạp quan hệ của ORM. Một fetch join và một lần lazy load các dòng con, mà các dòng này chỉ tới được qua một dòng cha đã được lọc. Engine xét từng câu một, nên đòi cả bảng con cũng phải có điều kiện tenant. Khai báo tenant trên entity con (
@TenantId) là hết cả hai. - Một bảng dẫn xuất. Câu bên trong trả ra
tenant_idvà câu bên ngoài lọc theo nó. Như vậy là an toàn, nhưng bản 0.1 chưa đẩy điều kiện vào trong subquery. - Một lỗi parser. Cột tên
numberkhông ghi kèm bảng thì JSqlParser không đọc được, nên câu đó bị báo là không phân tích được. Ghi rõi.numberlà chạy.
QueryFence cố ý chọn cách "không chắc thì báo": khi không chứng minh được một câu là an toàn, nó nói ra thay vì im lặng. Bọn mình thà để bạn thấy 4 lần báo nhầm còn hơn bỏ lọt một lỗi lộ dữ liệu.
Những gì đã sửa trước bản 0.1.0
Lần chạy thử này cũng tìm ra lỗi của chính QueryFence, và những lỗi chính đã được sửa trước khi phát hành: tuỳ chọn onUnparseable giờ đã có tác dụng, bản tóm tắt trên console đã hiện cho người dùng Maven, và câu không phân tích được giờ nêu tên các bảng cần bảo vệ mà nó nhắc tới, thay vì giấu đi.
Dùng thử
QueryFence 0.1.0 đã có trên Maven Central. Với dự án Spring Boot, chỉ cần thêm một dependency test và một file policy. Không phải thêm annotation, không phải sửa code test.
<dependency> <groupId>com.steelreed</groupId> <artifactId>queryfence-spring-test</artifactId> <version>0.1.0</version> <scope>test</scope> </dependency>
Với dự án đang chạy, hãy bắt đầu ở chế độ REPORT, đọc những gì nó tìm thấy, rồi mới chuyển sang FAIL. Hướng dẫn bắt đầu mất khoảng năm phút, báo cáo đầy đủ liệt kê từng kết quả, còn mã nguồn ở trên GitHub. Nếu bạn tìm được kiểu câu query nào lọt qua được, hãy báo bọn mình: đó là lỗi bọn mình muốn nghe nhất.