Запуск веб-сайту з захистом від ін'єкціону

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

Як SOF стверджує, що ви повинні досліджувати, перш ніж задавати питання тут, я зробив, і, схоже, що mysql_real_escape_string (); потрібно рятувати символи, які можуть пошкодити базу даних. Тобто я також виявив, що ви підготували заяви. Проте, виконуючи пошукові запити як на SOF, так і на Google, я виявив, що це важливо, але який з двох ви використовуєте, тому що обидва способи інтуїції користувача використовуються для запиту/вставки в db.

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

Це те, що я роблю:

 For Post variables: 

 $thething = mysql_real_escape_string($_POST['field']);


 For Get variables: 

 $thething = mysql_real_escape_string($_GET['id']);


 For Request variables: 

 $thething = mysql_real_escape_string($_REQUEST['id']);

Будь ласка, дайте мені знати, що ви думаєте.

1
@Том спасибі, але що хороше, якщо я зніяковіла
додано Автор Sam Khan, джерело
@ col.shrapnel Говорячи про безпеку, немає ніякої різниці між обома способами, якщо ви правильно прив'язуєте або форматуєте змінні. Обв'язка просто простіше, тому що вона може бути використана тільки для будь-якого випадку, тоді як не вдається втекти (таким чином, ви повинні віддати деякі змінні, а не вислизати/цитувати). Також майте на увазі, що зв'язування та втеча не можуть зробити ідентифікатор безпечним. Отже, якщо у вашому запиті потрібно використовувати ім'я поля чи оператора, вам слід скористатися значенням, закодованим у вашому скрипті. //// Так я був правий? не має значення, який ви використовуєте ??
додано Автор Sam Khan, джерело
можливий дублікат Як включити змінну PHP всередині вставка MySQL
додано Автор Your Common Sense, джерело
так, не важливо, що використовувати, якщо ви знаєте, що ви робите та дотримуєтеся правил.
додано Автор Your Common Sense, джерело
додано Автор Quentin, джерело
Як мінімум, як новий розробник PHP, ви мали сенс вивчити захист від ін'єкцій Mysql! Дорога до тебе, сер. Ви не бачите цього кожен день.
додано Автор Tom, джерело
як новий розробник, ви покладетеся на вичерпання рядків, то далі ви будете використовувати бібліотеку, яка допоможе вам уникнути ін'єкцій, і ще більше полегшить ваше життя, як-от pdo_mysql. Написання цього SELECT, INSERT, UPDATE самостійно - це біль в дупі. Довіряй мені :) Може, через деякий час ви будете використовувати всю систему, яка допоможе вам ще більше.
додано Автор evildead, джерело

5 Відповіді

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

Схожі запитання:

mysqli підготував виписки та mysqli_real_escape_string

real_escape_string проти підготовлених повідомлень

1
додано

Я, як правило, використовую mysql_real_escape_string , щоб уникнути можливого зловмисного вводу користувача.

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

Якщо ви використовуєте такі схеми PHP, як CakePHP або CodeIgniter, вони зазвичай забезпечують функції для одного і того ж. Наприклад, Активні записи Active Records дбає про всі вані санітарні введення.

Додаткова інформація про безпеку:

Оскільки ви недавно стали веб-розробниками (як я), зверніться також до XSS ін'єкцій , ще одна точка вразливості.

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

Salt passwords at the time of hashing, avoid md5 hash. Go for either sha256, sha512 or bcrypt.

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

0
додано
ха-ха ... тепер ти мене засмучуєш. Приклад № 2 в посилання, яке я розмістив у коментарях вище, показує, як користувач може отримати авторизований користувацький вхід для пароля. подивіться, і, можливо, ви можете пролити світло на те, що я спотикаюсь
додано Автор xbonez, джерело
mysql_real_escape_string не потрібно дезінфікувати користувацький ввід, але буде дезинфікуватися будь-який рядок, переданий йому як аргумент. Якщо ви передаєте змінну $ _ POST , яка тримає користувацький ввід, ви дезинфікуєте введення користувача, чи не так? Наприклад, у прикладі №2 тут php.net/manual/ en/function.mysql-real-escape-string.php , чи не вони опосередковано санізують вхід користувача (який зберігається в $ _ POST ['password'] )?
додано Автор xbonez, джерело
Спасибі @xbonez подивиться на всі ваші пропозиції.
додано Автор Sam Khan, джерело
Щоб повідомити вас, mysql_real_escape_string не має нічого спільного з введенням користувача.
додано Автор Your Common Sense, джерело
Щоб повідомити вас, mysql_real_escape_string не має нічого спільного з дезінфекцією теж :)
додано Автор Your Common Sense, джерело
Впевнений Ця функція не "дезінфікує". Ця функція призначена лише для виходу обмежувачів . Таким чином, немає обмежувачів - не використовується для mysql_real_escape_string. додайте до свого прикладу `` AND area = $ _POST ['area'] '"(з ін'єкційним значенням), і подивіться.
додано Автор Your Common Sense, джерело

Я думаю, що це досить вразливий для введення sql:

$ thething = mysql_real_escape_string ($ _ GET ['id']); mysql_query ("виберіть * з користувача, де id =". $ thething);

Доказ концепції: http: //localhost/index.php? id = sleep (30 )

Ця сторінка займе 30 секунд для завантаження, оскільки вона є вразливою для ін'єкцій sql.

Більш безпечним підходом для захисту вашої особистості від ін'єкцій SQL є параметризовані бібліотеки запитів, як PDO або mysqli. Ви повинні протестувати все. Я рекомендую скористатися послугою Sitewatch або проектом з відкритим кодом, наприклад skipfish .

0
додано
пробував цю річ на моєму веб-сайті. сон (30) не працював.
додано Автор Sam Khan, джерело

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

  1. жоден символ не може пошкодити базу даних. Але деякі символи можуть порушити запит . Ви не повинні це дозволити.

  2. таким чином: mysql_real_escape_string (); щоб уникнути символів, які могли б розбити рядок.

  3. таким чином: mysql_real_escape_string (); потрібно вийти лише з рядків . І це не допоможе трохи з будь-якої іншої частини запиту.

  4. Крім того, рядки можуть надходити в запити не тільки з POST GET і REQUEST, але й з будь-якого джерела в світі. ви повинні вийти з рядка, яка переходить до запиту , не виходячи з якогось джерела. Призначення - це причина, а не джерело.

  5. будь-ласка, зверніться до питання в коментарях для подальших пояснень

0
додано
Гей, полковник. Вибачте за плутанину №1, я мав на увазі, що samesthing (порушення запиту) вибачте!
додано Автор Sam Khan, джерело

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

SELECT * FROM myTable WHERE `id` = ?

Однак його не підтримує процедурний розширення mysql, що є причиною того, чому багато існуючих сайтів залишаються за допомогою mysql_ (real_) escape_string() , але ви можете використовувати його за допомогою Mysqli або PDO. Я рекомендую використовувати підготовлені заяви, коли ви знаходитесь лише на початку розробки.

0
додано
ти дотримуєшся і рядок MySQL escape?
додано Автор Sam Khan, джерело
будь-яка причина, чому ви додали параманти до реального: mysql_ (real_) escape_string() ??
додано Автор Sam Khan, джерело
Існує також функція mysql_escape_string() .
додано Автор KingCrunch, джерело
Nope, PreparedStatements у приватному проекті (на вершині SQLite3 ) та у моїй компанії PDO_Mysql .
додано Автор KingCrunch, джерело
Ukrainian PHP comunity
Ukrainian PHP comunity
885 учасників

dev-ua/php