Чи потрібно захищатись від введення SQL, якщо я використовував випадаючий список?

Я розумію, що НІКОЛИ не слід довіряти введенню користувачем форми, головним чином через можливість введення SQL.

Однак, чи стосується це також форми, де єдиним входом є спадне меню (див. Нижче)?

Я зберігаю $_POST['size']файл у сеансі, який потім використовується на всьому сайті для запитів до різних баз даних (із mysqliзапитом Select), і будь-яка ін’єкція SQL, безумовно, завдасть їм шкоди (можливо, знизить).

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

<form action="welcome.php" method="post">
<select name="size">
  <option value="All">Select Size</option> 
  <option value="Large">Large</option>
  <option value="Medium">Medium</option>
  <option value="Small">Small</option>
</select>
<input type="submit">
</form>

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

$possibleOptions = array('All', 'Large', 'Medium', 'Small');

if(in_array($_POST['size'], $possibleOptions)) {
    // Expected
} else {
    // Not Expected
}

Потім використовуйте mysqli_ *, якщо ви використовуєте версію php> = 5.3.0, якою ви мали б бути, для збереження результату. При правильному використанні це допоможе у введенні sql.

Так, вам потрібно захиститися від цього.

Дозвольте мені показати вам, чому, використовуючи консоль розробника Firefox:

Якщо ви не очистите ці дані, ваша база даних буде знищена. (Це може бути не повністю дійсним твердженням SQL, але я сподіваюся, що я зрозумів свою думку).

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

Якщо ви намагалися обмежити це подальше використання поведінки на своїй сторінці, мої варіанти включають відключення такої поведінки або просто написання користувацького HTTP-запиту на ваш сервер, який у будь-якому випадку імітує цю форму. Існує інструмент curl, який використовується саме для цього, і я думаю, що команда надсилати цю ін'єкцію SQL все одно виглядатиме приблизно так:

curl --data "size=%27%29%3B%20DROP%20TABLE%20*%3B%20--"  http://www.example.com/profile/save

(Це може бути не повністю дійсною командою curl, але знову ж таки, я сподіваюся, що я зрозумів свою думку).

Отже, я ще раз повторю:

НІКОЛИ не довіряйте вводу користувача. ЗАВЖДИ захищайся.

Не думайте, що будь-які введені користувачем дані є безпечними. Це потенційно небезпечно, навіть якщо воно надходить якимось способом, відмінним від форми. Жодне з них ніколи не є достатньо надійним, щоб відмовитись від захисту від ін’єкції SQL.

Оскільки це питання було позначене sql-ін'єкція, ось відповідь щодо цього конкретного виду атаки:

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

Незалежно від HTML-матеріалів!
Важливо розуміти, що запити SQL повинні бути правильно відформатовані, незалежно від будь-яких зовнішніх факторів, будь то введення HTML або щось інше.

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

Тут ви можете знайти ґрунтовне пояснення, чому підготовлені виписки є обов’язковими, і як їх правильно використовувати, а також де вони не застосовуються і що робити в такому випадку: Посібник автостопа щодо захисту від ін’єкцій SQL

Крім того, це питання було позначено тегами mysqli. Переважно випадково, я припускаю, але в будь-якому випадку, я повинен попередити вас, що сирий mysqli не є адекватною заміною старих функцій mysq_ * . Просто тому, що якщо використовувати його у старому стилі, це зовсім не додасть жодної безпеки. Незважаючи на те, що підтримка підготовлених висловлювань є болючою і клопітною, до того, що пересічний користувач PHP взагалі не може їх докласти. Таким чином, якщо жоден ORM чи якась бібліотека абстракції не є опцією, тоді PDO - це ваш єдиний вибір.

Так.

Будь-хто може підробляти будь-що для значень, які насправді надсилаються -

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

if(in_array($_POST['ddMenu'], $dropDownValues){

    $valueYouUseLaterInPDO = $dropDownValues[array_search("two", $arr)];

} else {

    die("effin h4x0rs! Keep off my LAMP!!"); 

}

Одним із способів захисту від користувачів, які змінюють спадні меню за допомогою консолі, є використання в них лише цілочисельних значень. Тоді ви можете підтвердити, що значення POST містить ціле число, і використати масив, щоб перетворити це в текст, коли це потрібно. Наприклад:

<?php
// No, you don't need to specify the numbers in the array but as we're using them I always find having them visually there helpful.
$sizes = array(0 => 'All', 1 => 'Large', 2 => 'Medium', 3 => 'Small');
$size = filter_input(INPUT_POST, "size", FILTER_VALIDATE_INT);

echo '<select name="size">';
foreach($sizes as $i => $s) {
    echo '<option value="' . $i . '"' . ($i == $size ? ' selected' : '') . '>' . $s . '</option>';
}
echo '</select>';

Тоді ви можете використовувати $sizeу своєму запиті, знаючи, що він коли-небудь міститиме FALSEабо ціле число.

Інші відповіді вже охоплюють те, що вам потрібно знати. Але, можливо, це допоможе пояснити ще:

Є ДВА РЕЧІ, які вам потрібно зробити:

1. Перевірити дані форми.

Як відповідь Джонатана Хоббса показує дуже чітко, вибір елемента html для введення форми не робить для вас жодної надійної фільтрації.

Зазвичай перевірка виконується таким чином, що не змінює дані, але знову показує форму, поля з позначкою "Будь ласка, виправте це".

У більшості фреймворків та CMS є конструктори форм, які допоможуть вам у виконанні цього завдання. І не лише це, вони також допомагають проти CSRF (або "XSRF"), що є іншою формою атаки.

2. Дезінфекція / втеча змінних у операторах SQL ..

.. або дозвольте підготовленим заявам зробити роботу за вас.

Якщо ви створюєте оператор (My) SQL із будь-якими змінними, наданими користувачем чи ні, вам потрібно вникнути та вказати ці змінні.

Як правило, будь-яка така змінна, яку ви вставляєте в оператор MySQL, повинна бути або рядком, або чимось, що PHP можна надійно перетворити на рядок, який MySQL може засвоїти. Такі як цифри.

Для рядків тоді потрібно вибрати один із декількох методів, щоб уникнути рядка, тобто замінити будь-які символи, які мали б побічні ефекти в MySQL.

• У старій школі MySQL + PHP mysql_real_escape_string () виконує свою роботу. Проблема в тому, що це занадто легко забути, тому вам слід абсолютно використовувати підготовлені виписки або конструктори запитів.
• У MySQLi ви можете використовувати підготовлені оператори.
• Більшість фреймворків та CMS надають конструктори запитів, які допоможуть вам у виконанні цього завдання.

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

Важливо зазначити, що ви уникаєте змінних для оператора SQL, а НЕ для самої бази даних . База даних буде зберігати вихідний рядок, але для оператора потрібна екранована версія.

Що станеться, якщо пропустити одне з них?

Якщо ви не використовуєте перевірку форми , але дезінфікуєте свої дані SQL, ви можете бачити всілякі погані речі, але ви не побачите введення SQL! (*)

По-перше, він може перевести вашу заявку в стан, який ви не планували. Наприклад, якщо ви хочете розрахувати середній вік усіх користувачів, але один користувач вказав "aljkdfaqer" для віку, ваш розрахунок не вдасться.

По-друге, можуть бути всілякі інші ін'єкційні атаки, які вам слід враховувати: Наприклад, користувацькі дані можуть містити javascript чи інше.

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

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

(*) або це було б щось справді екзотичне.

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

По-перше, ви ризикуєте, що коли ви зберігаєте дані в базі даних і завантажуєте їх знову, це вже не будуть ті самі дані, "загублені в перекладі".

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

По-третє, це все одно може спричинити ін’єкцію SQL.

Якщо ваші дані користувача з форм уже відфільтровані / перевірені, навмисне введення SQl може стати менш вірогідним, ЯКЩО ваше введення буде зведено до жорстко закодованого списку варіантів або якщо воно обмежене цифрами. Але будь-який вільний введення тексту може бути використаний для введення SQL, якщо ви неправильно уникнете змінних у операторах SQL.

І навіть якщо у вас взагалі немає введення форми, ви все одно можете мати рядки з усіх видів джерел: читати з файлової системи, витирати з Інтернету тощо. Ніхто не може гарантувати, що ці рядки безпечні.

Ваш веб-браузер не "знає", що він отримує сторінку з php, він бачить лише html. А рівень http знає навіть менше цього. Ви повинні мати можливість обробляти майже будь-який тип введення, який може перетинати рівень http (на щастя, для більшості введених php вже видає помилку). Якщо ви намагаєтеся не допустити, щоб шкідливі запити зіпсували вашу базу даних, вам потрібно припустити, що хлопець з іншого боку знає, що робить, і що він не обмежується тим, що ви можете бачити у своєму браузері за звичайних обставин ( не кажучи вже про те, що ви можете возитися з інструментами розробника браузера). Так що так, вам потрібно врахувати будь-які вхідні дані зі спадного меню, але для більшості введених даних ви можете дати помилку.

Той факт, що ви обмежили користувача лише використанням значень з певного випадаючого списку, не має значення. Технічний користувач може захопити http-запит, надісланий на ваш сервер, перш ніж він покине їх мережу, змінити його, використовуючи такий інструмент, як локальний проксі-сервер, а потім продовжити його на своєму шляху. Використовуючи змінений запит, вони можуть надсилати значення параметрів, що не є тими, які ви вказали у випадаючому списку. Розробники повинні пам’ятати, що обмеження клієнта часто безглузді, оскільки будь-що на клієнті може бути змінено. Перевірка сервера потрібна в кожній точці введення даних клієнта. Зловмисники покладаються на наївність розробників у цьому єдиному аспекті.

Найкраще використовувати параметризований запит для того, щоб захиститись від введення SQL. У такому випадку вигляд запиту буде таким:

SELECT * FROM table WHERE size = ?

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

SELECT * FROM table WHERE size = 'DROP table;'

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

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

Приклад того, що може і станеться, коли ви довіряєте клієнту.

Хакер може повністю обійти браузер, включаючи перевірку форми Javascript, надіславши запит за допомогою Telnet. Звичайно, він перегляне код вашої html-сторінки, щоб отримати імена полів, якими він повинен скористатися, але відтепер у нього все "йде". Отже, ви повинні перевірити всі значення, подані на сервері, ніби вони не походять з вашої сторінки html.