2013-07-04 31 views
10

Tôi đã thực hiện xác thực đầu vào trên tất cả dữ liệu đầu vào của mình bằng cách sử dụng php (cũng như js trên giao diện người dùng). Tôi đang nhập vào vị trí mà tôi có thể, xác thực các nội dung như email chống lại regex, đảm bảo các giá trị thả xuống chỉ là những cái tôi mong đợi và trong nhiều trường hợp tôi chỉ mong đợi một chuỗi. chữ cái, số và dấu cách. Bất kỳ điều gì không đáp ứng các quy tắc này dẫn đến biểu mẫu không xác thực và không có truy vấn sql nào được chạy.vệ sinh đầu vào VS xác nhận

Với điều đó nói rằng nếu biểu mẫu của tôi vượt qua xác thực tôi đang giả định rằng nó an toàn cho đầu vào vào db của tôi (mà tôi đang thực hiện thông qua pdo) và sau đó thoát trên đầu ra.

Vì vậy, với lý do đó, tại sao tôi cần vệ sinh đầu vào?

+1

Tôi muốn nói rằng bạn đang theo một phương pháp được chấp nhận. Vệ sinh và xác nhận (cùng) không phải lúc nào cũng cần thiết. Mặc dù, tôi là một fan hâm mộ của quốc phòng trong chiều sâu, vì vậy tôi có lẽ sẽ làm cả hai. Nhưng "từ chối biết xấu" và "chấp nhận tốt được biết đến" cũng được coi là chấp nhận được. https://www.owasp.org/index.php/Data_Validation – cmt

Trả lời

7

Nếu bạn có máy chủ xác thực rất nghiêm ngặt, bạn không cần phải khử trùng. Ví dụ. xác nhận một chuỗi chống lại/^ [a-z0-9] {5,25} $/sẽ không cần bất kỳ sự khử trùng nào (việc loại bỏ các ký tự không phải chữ và số sẽ không có ý nghĩa gì vì chúng không thể chuyển qua được).

Chỉ cần đảm bảo bạn có thể xác thực tất cả dữ liệu và nếu điều đó là không thể (ví dụ: html có xu hướng hơi khó), bạn có thể sử dụng chiến lược thoát hoặc những thứ như trình lọc html.

Để có cái nhìn tốt về chiến lược thoát ra để phòng ngừa XSS: thấy https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

Đối với một ý tưởng về các mối đe dọa bảo mật khác nhau: https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

+0

Có trong nội dung trên owasp. Cảm ơn –

3

Bạn cần cả hai. Việc xác thực dữ liệu đầu vào có thể dễ dàng bị đánh bại ở phía máy khách, nhưng nó hữu ích cho những người dùng hợp pháp không cố gắng hack bạn. Vệ sinh dữ liệu (tất cả dữ liệu, cho dù đó là dữ liệu đầu vào hoặc thứ gì đó trực tiếp từ DB của bạn mà bạn nghĩ bạn có thể tin tưởng) trước khi đưa nó vào cơ sở dữ liệu của bạn.

Thậm chí nếu bạn tin cậy 100% xác thực của mình và thực hiện nó ở phía máy chủ (trong lý thuyết, mọi người không nên gây rối với dữ liệu), nó vẫn có giá trị sử dụng một số loại vệ sinh. thói quen để đi vào.

+0

Thậm chí nếu bạn cực kỳ tự tin về việc xác thực của mình, tại sao lại mạo hiểm? –

+0

Đúng, tôi muốn được an toàn nhất có thể để câu hỏi này được yêu cầu để làm sáng tỏ sự nhầm lẫn của tôi. Sự khác biệt duy nhất tôi thấy giữa xác thực và vệ sinh là xác nhận trả về đúng hoặc sai khi kiểm tra đầu vào trong khi vệ sinh thực sự thay thế các ký tự không mong muốn. Tôi sẽ kết thúc xác nhận chống lại một regex và sau đó sanitize chúng với cùng một regex nhưng thay vì sử dụng preg_replace.Just có vẻ hơi lạc hậu. –

+2

Một bối cảnh mà việc vệ sinh có thể là của riêng mình là nơi tôi không thể xác thực tích cực, ví dụ: trường văn bản miễn phí, nơi người dùng có thể nhập ký tự không phải chữ số ... sau đó tôi có thể thấy việc sử dụng trong vệ sinh –

Các vấn đề liên quan