Xác thực dữ liệu đầu vào luôn là một cuộc đấu tranh nội bộ đối với tôi.
Trước khi thêm một khung bảo mật và mã bảo mật thực sự vào dự án viết lại ứng dụng cũ của chúng tôi (điều này cho đến nay vẫn giữ được mã bảo mật di sản mạnh mẽ của thẻ lâu đài và xác thực dữ liệu), tôi lại tự hỏi về việc tôi nên xác thực bao nhiêu, ở đâu, v.v.
Trong hơn 5 năm làm nhà phát triển Java chuyên nghiệp, tôi đã tạo và tinh chỉnh các quy tắc cá nhân của mình để xác thực dữ liệu và các biện pháp bảo mật. Khi tôi muốn cải thiện phương pháp của mình, tôi muốn nghe một số ý tưởng từ các bạn. Các quy tắc và quy trình chung đều ổn và các quy tắc cụ thể của Java cũng vậy.
Tóm tắt, đây là những hướng dẫn của tôi (được trình bày theo kiểu ứng dụng web 3 tầng), với lời giải thích ngắn gọn:
Phía máy khách cấp 1 (trình duyệt): xác thực tối thiểu, chỉ các quy tắc bất biến (trường email bắt buộc, phải chọn một mục và tương tự); việc sử dụng xác nhận bổ sung như "từ 6 đến 20 ký tự" ít thường xuyên hơn, vì điều này làm tăng công việc bảo trì đối với các thay đổi (có thể được thêm vào sau khi mã doanh nghiệp ổn định);
Phía máy chủ cấp 1 (xử lý giao tiếp web, "bộ điều khiển"): Tôi không có quy tắc cho điều này, nhưng tôi tin rằng chỉ nên xử lý lỗi thao tác và lắp ráp / phân tích dữ liệu ở đây (trường sinh nhật không phải là ngày hợp lệ); thêm xác nhận ở đây dễ dàng làm cho nó trở thành một quá trình thực sự nhàm chán;
Tầng thứ 2 (lớp nghiệp vụ): xác thực rắn, không kém; định dạng dữ liệu đầu vào, phạm vi, giá trị, kiểm tra trạng thái nội bộ nếu phương thức không thể được gọi bất cứ lúc nào, vai trò / quyền của người dùng, v.v. sử dụng càng ít dữ liệu đầu vào của người dùng càng tốt, lấy lại từ cơ sở dữ liệu nếu cần; nếu chúng tôi cũng xem xét việc lấy dữ liệu cơ sở dữ liệu làm đầu vào, tôi sẽ chỉ xác thực nó nếu một số dữ liệu cụ thể được biết là không đáng tin cậy hoặc bị hỏng đủ trên DB - gõ mạnh thực hiện hầu hết công việc ở đây, IMHO;
Tầng thứ 3 (lớp dữ liệu / DAL / DAO): không bao giờ tin rằng cần phải xác thực nhiều ở đây, vì chỉ có lớp doanh nghiệp được truy cập dữ liệu (có thể xác thực trong một số trường hợp như "param2 không được null nếu param1 là đúng"); tuy nhiên, lưu ý rằng khi tôi có nghĩa là "ở đây" tôi có nghĩa là "mã truy cập cơ sở dữ liệu" hoặc "phương thức thực thi SQL", thì chính cơ sở dữ liệu hoàn toàn ngược lại;
cơ sở dữ liệu (mô hình dữ liệu): cần phải được suy nghĩ cẩn thận, mạnh mẽ và tự thực thi để tránh dữ liệu không chính xác và bị hỏng trên DB càng nhiều càng tốt, với các khóa chính tốt, khóa ngoại, ràng buộc, loại / độ dài / kích thước dữ liệu / độ chính xác và vân vân - Tôi sẽ để lại các yếu tố kích hoạt, vì họ có cuộc thảo luận riêng.
Tôi biết xác thực dữ liệu sớm là tốt và hiệu suất, nhưng xác thực dữ liệu lặp đi lặp lại là một quá trình nhàm chán và tôi thừa nhận rằng chính xác thực dữ liệu là khá khó chịu. Đó là lý do tại sao rất nhiều lập trình viên bỏ qua nó hoặc làm điều đó nửa chừng. Ngoài ra, mọi xác thực trùng lặp là một lỗi có thể xảy ra nếu chúng không được đồng bộ hóa mọi lúc. Đó là những lý do chính mà ngày nay tôi thích để hầu hết các xác nhận hợp lệ cho tầng doanh nghiệp, với chi phí thời gian, băng thông và CPU, các trường hợp ngoại lệ được xử lý theo từng trường hợp cụ thể.
Vậy, bạn nghĩ gì về điều này? Phản đối ý kiến? Bạn có thủ tục khác? Một tài liệu tham khảo cho chủ đề như vậy? Bất kỳ đóng góp là hợp lệ.
Lưu ý: nếu bạn đang nghĩ cách làm Java, ứng dụng của chúng tôi là Spring dựa trên Spring MVC và MyBatis (hiệu suất và mô hình cơ sở dữ liệu xấu loại trừ các giải pháp ORM); Tôi dự định thêm Spring Security làm nhà cung cấp bảo mật của chúng tôi cộng với JSR 303 (Trình xác thực Hibernate?)
Cảm ơn!
Chỉnh sửa: một số làm rõ thêm trên lớp thứ 3.