Chỉ thoát những gì cần thiết, là có thể?

Question

Tôi đang làm việc với một nhóm các nhà phát triển trên một trang web. Trang web sẽ sử dụng các lớp học. Tôi phụ trách việc tạo lớp truy cập dữ liệu cho các lớp. Có một sự hiểu biết rằng tất cả đầu vào của người dùng sẽ được thoát khi truy xuất (từ bài đăng hoặc nhận). Có ít quyền kiểm soát mức đầu vào (trừ khi cá nhân tôi xem xét mã của mọi người), tôi nghĩ rằng nó sẽ rất tuyệt khi ném vào phần cuối của tôi (ngay trước khi nó truy cập cơ sở dữ liệu). Vấn đề là tôi không biết cách sử dụng mysql_real_escape_string mà không cần thêm nhiều dấu gạch chéo nữa.

Vì nhập của người dùng có thể chứa dấu gạch chéo nên tôi không thể kiểm tra để đảm bảo có dấu gạch chéo trong đó. Tôi có thể kiểm tra tất cả những thứ cần trốn thoát và đảm bảo họ có dấu gạch chéo trước mặt họ, nhưng điều đó dường như không phải là cách tốt nhất để làm điều đó.

Mọi đề xuất?

Answer 1

Bạn đã xem xét không thoát dữ liệu cho đến khi nó truy cập lớp truy cập dữ liệu? Tôi hỏi, bởi vì họ là một số gotchas với cách tiếp cận nhóm của bạn đang tiến hành:

• Nếu bạn cần để hiển thị dữ liệu mẫu cho người sử dụng (ví dụ, để hiển thị lại hình thức với một thông báo lỗi bởi vì một số xác nhận thất bại), bạn cần phải loại bỏ dữ liệu (vì ' không phải là đặc biệt đối với HTML) và sau đó thoát khỏi dữ liệu (vì < là đặc biệt). Nếu bạn cần hiển thị dữ liệu biểu mẫu cho người dùng được lấy từ cơ sở dữ liệu, bạn không được thực hiện bước thoát đó (vì nó được thực hiện bởi cơ sở dữ liệu, khi dữ liệu được lưu), nhưng vẫn phải thực hiện thoát HTML bậc thang. Nếu bạn làm sai và làm thủ tục sai, bạn bị hỏng dữ liệu hoặc tệ hơn sẽ đưa ra các vấn đề về bảo mật.
• Bạn có thể xử lý các định dạng khác nhau từ các vấn đề nguồn khác nhau bằng cách quyết định tất cả dữ liệu được truyền xung quanh ứng dụng của bạn sẽ bị thoát. Vì vậy, lớp truy cập dữ liệu của bạn sẽ thoát khỏi dữ liệu khi nhận dữ liệu từ cơ sở dữ liệu. Tuy nhiên, như các phần khác nhau của ứng dụng cần một chút (hoặc hoàn toàn) thoát khác nhau, điều này nhanh chóng dẫn đến rất nhiều de-thoát/tái thoát vô nghĩa. Lấy dữ liệu từ cơ sở dữ liệu, thoát khỏi nó, thoát khỏi nó, thoát khỏi nó cho HTML, xuất nó.
• Mã xử lý biểu mẫu đầu cuối của bạn phải có kiến ​​thức thân mật về cơ sở dữ liệu của bạn. Ví dụ: \' có nghĩa là gì đối với cơ sở dữ liệu của bạn? Làm thế nào để một số ' hoặc \ thoát - nếu có? Nếu bạn thay đổi công cụ cơ sở dữ liệu của bạn, hoặc thậm chí thay đổi các thiết lập của nó, chúng có thể thay đổi. Và sau đó bạn có một loạt các mã thoát/de-thoát để tìm. Thiếu một lối thoát duy nhất/de-escape có thể dẫn đến việc tiêm SQL. Ngoài ra, bạn có thể lấy kiến ​​thức đó về cơ sở dữ liệu từ mã front-end bằng cách làm cho lớp cơ sở dữ liệu thực hiện một chu trình thoát/thoát để chuyển đổi từ chuỗi thoát ứng dụng sang cơ sở dữ liệu của bạn. Nhưng điều này có vẻ khá ngớ ngẩn!

Có một cách khác: Cho phép bất kỳ lớp nào cần dữ liệu được thoát khỏi chính nó. Dữ liệu luôn được chuyển giữa các lớp ở dạng thô, không thoát. Vì vậy, lớp truy cập dữ liệu của bạn làm tất cả cơ sở dữ liệu thoát. Mã đầu ra HTML của bạn làm tất cả HTML thoát. Khi bạn quyết định muốn tạo tệp PDF, mã PDF của bạn sẽ thực hiện tất cả việc thoát PDF.

• Bây giờ, khi bạn thực hiện biểu mẫu, rõ ràng phải làm gì: luôn HTML thoát dữ liệu. Dù nó đến từ đâu. Không bao giờ chạy trốn thoát.
• Hiện tại không có de-escape/escape vô nghĩa, vì mọi thứ được truyền xung quanh thô. Nó chỉ được thoát khi cần thiết.
• Mã front-end của bạn không quan tâm đến việc triển khai lớp truy cập dữ liệu. Lớp truy cập dữ liệu lưu trữ và trả về bất kỳ chuỗi tùy ý nào.
• Bạn chỉ có một địa điểm để xem trong ứng dụng của mình để đảm bảo bạn không gặp phải sự cố về tiêm SQL.
• Bạn có thể dễ dàng sử dụng các tính năng của trình điều khiển cơ sở dữ liệu như trình giữ chỗ. Sau đó, ngay cả lớp truy cập dữ liệu của bạn cũng cần phải biết về các yêu cầu thoát của mỗi cơ sở dữ liệu; trình điều khiển cơ sở dữ liệu xử lý nó.

Answer 2

Không có cách nào bạn có thể thêm một quyết định tự động để thoát hay không nếu bạn không biết liệu đầu vào có được thoát hay không. Bạn có thể cố gắng phân tích nó nhưng nó sẽ không bao giờ tốt và bạn sẽ gặp phải các cặp dấu chéo ngược đôi và như vậy.

Đưa ra quyết định khi dữ liệu được gửi đến lớp truy cập của bạn phải sạch sẽ và xử lý việc thoát ở một nơi. Nếu bạn làm như vậy, các nhà phát triển khác sẽ không phải lo lắng về nó (có thể họ cũng không muốn) và sẽ dễ dàng hơn để chuyển sang cơ sở dữ liệu khác trong tương lai. Nó cũng sẽ cung cấp cho bạn sự tự do để chuyển sang các tuyên bố chuẩn bị bất cứ lúc nào.

Edit: Quên này:

Có ít kiểm soát mức độ đầu vào (trừ trường hợp cá nhân tôi xem xét mã của mọi người)

Tôi nghĩ rằng đó là giá trị cơn đau có họ khám phá nó nếu bạn chỉ làm cho nó rất rõ ràng rằng thoát là cái gì đó thuộc về lớp cơ sở dữ liệu và không nên được thực hiện ở nơi khác.

Answer 3

Nếu tôi ở vị trí của bạn, tôi sẽ không đủ lười để không xem lại mã của mọi người. Ngay cả khi bạn không xem xét việc thoát khỏi đầu vào của người dùng, bạn vẫn có thể muốn xem liệu mã của họ có được thực hiện hiệu quả hay không. Hoặc có lẽ, nó không phải là bạn để làm việc xem xét, nhưng ai đó đã làm điều đó.

Tôi đã trải nghiệm một thiết lập gần như tương tự cách đây không lâu, nơi chúng tôi chia các tác vụ theo lớp. Một người làm việc trên mô hình, tôi làm việc trên bộ điều khiển, và người kia làm việc trên quan điểm. Bởi vì chúng tôi tin tưởng mọi người rất nhiều nên mã của mọi người sẽ hoạt động theo cách chúng tôi mong đợi nó hoạt động, chúng tôi không bận tâm xem xét mã của người khác cho đến khi chúng tôi cần hợp nhất chúng. Điều gì đã xảy ra là chúng tôi đã phát hiện ra mã không hiệu quả trong mô hình muộn trong quá trình phát triển. Và nó không chỉ không hiệu quả, nó không hoạt động! Vì lý do đó, chúng tôi phải sửa chữa lớn các đoạn mã khiến chúng tôi tốn nhiều thời gian hơn.

Tôi khuyên bạn nên tạo tài liệu thông số kỹ thuật yêu cầu kỹ thuật trong đó tài liệu được chỉ định trong đó các đầu vào được chấp nhận từ người dùng. Tài liệu này nên được theo sau bởi những người sẽ mã phần sẽ chấp nhận đầu vào của người dùng. Tốt hơn, hãy tạo các bài kiểm tra đơn vị để xem các yêu cầu đó có được tuân theo nghiêm ngặt không, do đó bạn không phải lo lắng liệu dữ liệu mà chúng sẽ chuyển cho bạn có hợp lệ hay không.

Một điều nữa ... vì bạn đang sử dụng PHP, tại sao không sử dụng khung tốt? Hầu hết các khung công tác có sẵn đều có DAL riêng của chúng, nơi bạn không còn phải lo lắng nhiều về việc thoát khỏi cơ sở dữ liệu đầu vào (tốt, không nhiều). Các khuôn khổ nên làm điều đó cho bạn.

Ngoài ra, bạn có thể muốn xem 'báo cáo đã chuẩn bị'.