Tại sao không bảo vệ chống lại SQL tiêm ưu tiên cao?

Trên Stack Overflow, tôi thấy rất nhiều mã PHP trong các câu hỏi và câu trả lời có các truy vấn MySQL rất dễ bị tấn công SQL, mặc dù các cách giải quyết cơ bản đã có sẵn rộng rãi trong hơn một thập kỷ.

Có một lý do tại sao các loại đoạn mã này vẫn còn được sử dụng ngày nay?

Tôi nghĩ rằng điều đó chủ yếu là do a) thiếu hiểu biết b) lười biếng. Người mới bắt đầu thường không biết nhiều về tiêm sql và ngay cả khi họ nghe về nó, họ cũng bỏ qua vì đơn giản và dễ dàng hơn để viết mã theo cách đó.

PHP cố tình làm cho nó thực sự, thực sự dễ dàng cho những người biết rất ít để tạo các trang web động hữu ích. Điều này có nghĩa là PHP sẽ thu hút rất nhiều người mới bắt đầu, những người tạo ra thứ gì đó hữu ích, học hỏi từ các ví dụ tìm kiếm hữu ích khác và quay lại để dạy người khác cách làm điều tuyệt vời, hữu ích này. Kết quả là có rất nhiều mã xấu và nguồn cung cấp cho các lập trình viên không biết gì hơn.

Nó chỉ làm cho mọi thứ tồi tệ hơn khi một phần lớn các lập trình viên có năng lực không muốn làm gì với PHP. Điều này làm giảm cơ sở của những người có kinh nghiệm, những người sẵn sàng dạy người khác tốt hơn. Nhưng tại sao họ tránh PHP? Vâng cho sự kết hợp của các yếu tố. Một phần họ không thích đối phó với mụn cóc ngôn ngữ. Và một phần là vì họ thích làm việc với mã tốt và không có nhiều PHP tốt ngoài kia.

Chòm sao chính xác này của các vấn đề được sử dụng để gây ra Perl. Như một ví dụ sáng chói, hãy xem xét trường hợp của Matt Wright, một thiếu niên nhiệt tình, người đã đặt ra để cung cấp nhiều kịch bản CGI hữu ích, được ghi chép tốt và dễ cài đặt vào những năm 1990. Thật không may, anh ta không hiểu gì về an ninh, và những người muốn sử dụng công cụ của anh ta cũng không biết. Kết quả là Kho lưu trữ kịch bản Matt Wright, đây là một vấn đề bảo mật vô tận cho các kịch bản CGI ban đầu. Bất chấp những nỗ lực như http://www.scriptarchive.com/nms.html , vấn đề không được cải thiện đối với Perl cho đến khi các nhà cung cấp dịch vụ lưu trữ chia sẻ làm cho PHP thuận tiện hơn bất kỳ điều gì khác. Điều đó dẫn đến vấn đề chuyển từ Perl sang PHP.

Tiếc là có tấn nhiều hơn xấu PHP hướng dẫn lên đó, và một số sách PHP cũ cũng bị hút vào nói với mọi người để viết mã đúng (không sử dụng register_globals vv).

Ngoài ra, với magic_quotes_gpcviệc được kích hoạt trong quá khứ, mọi người không quan tâm đến việc trốn thoát vì "đơn giản là nó đã hoạt động".

Cá nhân, tôi tin rằng PHP rất dễ sử dụng, do đó, tự nhiên nó dễ sử dụng sai.

Là một con người, và là một lập trình viên, tôi thấy rất dễ mắc lỗi và bỏ qua những điều nhất định, đặc biệt là khi bị ép thời gian.

Thật dễ dàng, và có lẽ tất cả đều quá hấp dẫn, để đổ lỗi cho một ngôn ngữ nhất định, vì quá dễ tiếp cận vì lợi ích của chính nó. Nhưng điều đó sẽ che đậy vấn đề lớn hơn về khả năng cảm nhận của con người, bất kể ngôn ngữ được chọn để lập trình.

Cấp, chúng tôi đã đi một chặng đường dài kể từ ngôn ngữ lắp ráp và tôi nghĩ rằng tôi sẽ lập trình hiệu quả hơn nhiều trong một ngôn ngữ hiện đại hơn, như PHP, Python, Ruby hoặc Java.

PHP (và các ngôn ngữ kịch bản lệnh khác) trên thực tế đã hạ thấp rào cản gia nhập. Điều đó có thể có nghĩa là nhiều người mới đến lập trình thử PHP trước. Nhưng điều đó chắc chắn không có nghĩa là tất cả các lập trình viên PHP bằng cách nào đó có trình độ kém hơn hoặc không có khả năng học hỏi từ những sai lầm của họ so với các lập trình viên của các ngôn ngữ khác.

Rasmus Lerdorf đã tạo ra PHP ở dạng ban đầu vào năm 1994, nó đã phát triển đáng kể kể từ đó. Trong phiên bản hiện đại nhất của nó, nó hỗ trợ lập trình hướng đối tượng, cũng như các khung công tác tuyệt vời, như Symfony. PHP là một ngôn ngữ đã thoát ra khỏi các ràng buộc ban đầu của nó và đã phát triển để mang đến sự linh hoạt tuyệt vời trong cách các lập trình viên có thể chọn sử dụng nó. Bạn có thể sử dụng nó để tạo tập lệnh 9.000 dòng mã spaghetti hoặc bạn có thể sử dụng nó trong bối cảnh của khung công tác MVC hiện đại, như Symfony: đó là lựa chọn của bạn!

Tôi nghi ngờ rằng các lỗ hổng bảo mật không bị hạn chế trong một ngôn ngữ. Thật là hấp dẫn khi viết ra tất cả các lập trình viên PHP vì bằng cách nào đó ít có khả năng hơn hoặc dễ viết mã không an toàn hơn. Nhưng tôi tự hỏi bao nhiêu trong số đó là thiên vị ngôn ngữ, và bao nhiêu trong số đó là sự thật?

Tôi nghĩ một phần của vấn đề là những người chỉ cần sao chép mã mà không bận tâm tìm hiểu những gì họ đang làm, nhưng thực sự theo cách của tôi, cách chúng tôi dạy porgamnming bị hỏng và đó là một trong những lý do tại sao có quá nhiều mã xấu. Chúng tôi dạy cú pháp ngoài ngữ cảnh và vì vậy những người mới bắt đầu không biết khi nào nên sử dụng một cái gì đó và khi nào không hoặc vấn đề nào cú pháp nhằm giải quyết và vấn đề nào không nhằm giải quyết. Vì họ sử dụng búa khi cờ lê sẽ là công cụ tốt hơn.

Vì vậy, ví dụ thay vì chỉ dạy cú pháp, bạn tổ chức khóa học như (Rõ ràng sẽ có nhiều bước hơn, đây chỉ là một ví dụ cơ bản về xây dựng từ các vấn đề cơ bản đến phức tạp hơn thay vì chỉ dạy cú pháp):

1. Đây là cách bạn thiết lập một trang web cơ bản
2. Đây là cách bạn tạo trang web lấy dữ liệu từ cơ sở dữ liệu
3. Đây là cách bạn gửi dữ liệu từ một trang web đến cơ sở dữ liệu
4. Đây là cách bạn đảm bảo dữ liệu đúng được gửi.
5. Đây là cách bạn bảo vệ cơ sở dữ liệu của mình khỏi việc nhập dữ liệu độc hại

Tôi nghĩ rằng bạn sẽ tìm thấy một số lượng tương tự các ví dụ MS SQL + ASP / ASP.NET cũng dễ bị tổn thương.

Tôi cảm thấy vấn đề một phần xuất phát từ thực tế là khi bạn đang cố dạy một điều gì đó, hãy nói rằng lọc dữ liệu bằng mệnh đề WHERE, sau đó bạn thực sự không muốn làm lộn xộn ví dụ của mình bằng cách thoát đúng chuỗi truy vấn của bạn hoặc sử dụng lệnh tham số.

Tôi đã đào tạo các nhà phát triển trong nhiều năm và tôi có thể đồng cảm với những người viết mã khủng khiếp trong hướng dẫn. Đôi khi đó là điều dễ hiểu nhất. Tuy nhiên, ở một bên, tôi luôn chỉ ra mã dễ bị tổn thương và biến nó thành một chủ đề phụ thú vị.

Tác giả ban đầu của PHP, Rasmus Lerdorf , trong mục blog khét tiếng của mình ủng hộ sự phát triển "không khuôn khổ" . Mặc dù đối với các truy vấn SQL, anh ta sử dụng PDO, do đó không có rủi ro về việc tiêm SQL. Vẫn còn khá xấu xí và lỗi thời so với các khung MVC hiện đại với các lớp ORM.

Bạn có thể đổ lỗi cho thực tiễn kém này trên chính PHP. Các phiên bản kế thừa của PHP (cho đến khoảng năm 2006) sẽ thoát khỏi tất cả các biến đầu vào GET và POST để chúng phù hợp với phép nội suy truy vấn cơ sở dữ liệu BY DEFAULT. Xem http://php.net/manual/en/security.magicquotes.php

Đừng nhầm lẫn mục đích của một hướng dẫn, đó là thể hiện một cái gì đó đơn giản, với những gì nên được thực hiện trong môi trường sản xuất. Ví dụ, hầu hết mã hướng dẫn tôi đã viết có ít hoặc không có lỗi / kiểm tra ngoại lệ. Tôi cố gắng nhắc nhở người đọc rằng mã chỉ trình bày cách thực hiện một nhiệm vụ cụ thể, chứ không phải làm thế nào để bao quát tất cả các kết quả có thể.

Khi tôi học PHP tôi đã xem một số sách PHP + MySQL này và vâng tôi cảm thấy rằng nó góp phần vào thực tiễn tồi tệ đó. Nhưng tôi có cảm tình, vì họ đang dạy ngôn ngữ chứ không phải thực hành lập trình tốt. Nếu không thì nó sẽ kết thúc ở đâu?