Чому захист від ін'єкції SQL не є пріоритетним?

Під час переповнення стека я бачу багато PHP-коду у питаннях та відповідях, які мають запити MySQL, які дуже вразливі до атак ін'єкцій SQL, незважаючи на те, що основні шляхові шляхи широко доступні вже більше десяти років.

Чи є причина, чому такі типи фрагментів коду досі використовуються?

Я думаю, це здебільшого через а) необізнаність б) лінь. Початківці зазвичай мало знають про введення sql, і навіть коли вони чують про нього, вони ігнорують його, оскільки це набагато простіше і простіше кодувати таким чином.

PHP навмисно робить це дуже, дуже просто для людей, які знають дуже мало, щоб створити корисні динамічні веб-сторінки. Це означає, що PHP збирається залучити багато початківців, які створюють щось корисне, вчаться на інших корисних прикладних прикладах і обертаються, щоб навчити інших, як робити цю класну корисну річ. У результаті багато поганого коду та пропозиція програмістів, які не знають нічого кращого.

Погіршує лише те, що велика частина компетентних програмістів не хоче нічого спільного з PHP. Це зменшує базу досвідчених людей, які готові навчити інших краще. Але чому вони уникають PHP? Добре для поєднання факторів. Частково їм не подобається мати справу з мовними бородавками. Частково це тому, що вони вважають за краще працювати з хорошим кодом, і там не так багато хорошого PHP.

Це точно сузір'я проблем, що використовуються для заподіяння Perl. Як яскравий приклад розглянемо справу Метта Райт, захопленого підлітка, який мав намір надати багато корисних, добре задокументованих та простих у встановленні сценаріїв CGI ще в 90-х роках. На жаль, він нічого не розумів щодо безпеки, а також людей, які хотіли використати його речі. Результатом став архів сценаріїв Метта Райт, який був нескінченним потоком проблем безпеки для ранніх скриптів CGI. Незважаючи на такі зусилля, як http://www.scriptarchive.com/nms.html , проблема не покращилася для Perl, поки провайдери спільного хостингу не зробили PHP зручнішим, ніж будь-що інше. Це призводить до проблеми переходу з Perl на PHP.

На жаль, там є безліч підручників з PHP, а деякі старі книги PHP також смоктали, щоб сказати людям писати належний код (не використовуючи register_globals тощо).

До того ж, magic_quotes_gpcмаючи ввімкнення в минулому, люди не переймалися втечею, оскільки "це просто спрацювало".

Особисто я вважаю, що PHP простий у використанні, тому, природно, його легко використовувати.

Як людині, так і програмісту, мені здається, що легко помилятися і не помічати певних речей, особливо при натисканні на час.

Звинувачувати певну мову за те, що вона занадто доступна для власного блага, легко і, можливо, занадто спокусливо. Але це може поставити під загрозу більшу проблему помилковості людини, незалежно від мови, обраної для програмування.

Зрозуміло, ми пройшли довгий шлях від мови складання, і я думаю, що я був би набагато продуктивнішим програмуванням на більш сучасній мові, такі як PHP, Python, Ruby або Java.

PHP (та інші мови сценаріїв) фактично знизили перешкоду для входу. Це може означати, що більш новачки в програмуванні спершу спробують PHP. Але це, звичайно, також не означає, що всі програмісти PHP якимось менш кваліфікованими або менш здатними вчитися на своїх помилках, ніж програмісти інших мов.

Расмус Лердорф створив PHP у первісному вигляді ще в 1994 році, він значно розвинувся з тих пір. У своєму найсучаснішому втіленні він підтримує об'єктно-орієнтоване програмування, а також чудові рамки, такі як Symfony. PHP як мова позбавилася від своїх початкових обмежень і зросла, щоб запропонувати велику гнучкість у тому, як програмісти можуть обрати її. Ви можете використовувати його для створення 9000-лінійного сценарію коду спагетті, або ви можете використовувати його в контексті сучасних рамок MVC, таких як Symfony: це ваш вибір!

Я сильно підозрюю, що вразливості безпеки не обмежуються однією мовою. Заманливо списати всіх програмістів PHP як якось менш здатних або більш схильних до написання незахищеного коду. Але мені цікаво, наскільки це зміщення мови, і скільки це факт?

Я думаю, що частина проблеми - це люди, які просто копіюють код, не намагаючись дізнатися, що вони роблять, але, на мій погляд, порушено те, як ми навчаємо породження, і це одна з причин того, що існує стільки поганого коду. Ми навчаємо синтаксис поза контекстом, і тому початківці не знають, коли щось використовувати, а коли не робити або які проблеми синтаксис має намір вирішити і які проблеми він не збирається вирішувати. Так вони використовують молоток, коли кращим інструментом був би гайковий ключ.

Так, наприклад, замість того, щоб викладати просто синтаксис, ви організовуєте курс на кшталт (Очевидно, що кроків буде більше, це лише основний приклад побудови від базових до складніших завдань, а не просто викладання синтаксису):

1. Так ви створили основну веб-сторінку
2. Це те, як ви змушуєте веб-сторінку витягувати дані з бази даних
3. Так ви надсилаєте дані з веб-сторінки в базу даних
4. Так ви переконайтеся, що правильні дані надсилаються.
5. Так ви захищаєте свою базу даних від зловмисних даних

Я думаю, ви знайдете подібну кількість прикладів MS SQL + ASP / ASP.NET, які так само вразливі.

Я відчуваю, що проблема частково випливає з того, що, коли ви намагаєтесь навчити чомусь, скажімо, фільтруючи дані за допомогою пункту WHERE, тоді ви дійсно не хочете захаращувати свій приклад, належним чином уникаючи рядка запиту або використовуючи параметризовану команду.

Я навчаю розробників багато років і можу співпереживати людям, які пишуть жахливий код у навчальних посібниках. Іноді це найлегше зрозуміти. Однак, убік, я завжди вказую на вразливий код і перетворюю його на цікаву бічну тему.

Оригінальний автор PHP Расмус Лердорф у своєму сумнозвісному записі в блозі виступає за розвиток "поза рамки" . Хоча для запитів SQL він використовує PDO, тому немає ризику введення SQL. Все ще досить некрасиво і застаріло в порівнянні з сучасними структурами MVC з шарами ORM.

Ви можете звинувачувати цю погану практику на самому PHP. Спадкові версії PHP (до приблизно 2006 р.) Дозволять уникнути всіх вхідних змінних GET і POST, щоб вони були придатними для інтерполяції запитів бази даних BY DEFAULT. Дивіться http://php.net/manual/en/security.magicquotes.php

Не плутайте мету підручника, який просто демонструє щось із тим, що слід робити у виробничих умовах. Наприклад, більшість кодів підручників, які я написав, мають невелику перевірку помилок / виключень. Я намагаюся нагадати читачеві, що код лише демонструє, як виконати конкретне завдання, а не як охопити всі можливі результати.

Коли я навчався PHP, я переглянув деякі ці книги PHP + MySQL, і так, я відчуваю, що це сприяє цій поганій практиці. Але я співчуваю, бо вони навчають мову , а не хороші практики програмування. Інакше де б це закінчилося?