Возможно защищать меня от вставки sql, если я это перемещаю из-за get?

Если у меня есть url: http://ejemplo.com?usuario=1234

возможно защищения меня, равно как если я это посылаю за метод post, или есть у ataquantes больше вероятности входить в мою базу данных?

То, что он хотел узнать, если, переместив параметры из-за унифицированного указателя ресурса, это - больше слабый человек в одну атака вставка sql. Не, как объяснение этого по-другому или лучше.

4
задан 22.04.2017, 00:30
3 ответа

Безопасность твоего приложения не зависит от абсолютно того, что данные путешествуют с GET или POST. Думать, что POST безопаснее, - общая ошибка, но у которой нет никакого типа основания, так как данные путешествуют на той же форме. В самом деле, какие-то языки программирования, ориентируемые на Веб предлагают тебе параметры той же формы, независимо, из которого они прибыли из-за G

Защита против вставок SQL должен предоставлять ее ты для параметров, которые ты получаешь, независимо, от которого ты получил их методом или другим. Логически, я не имею в виду тот, что ее осуществил ты, а, что ты был исследовано, какие программные средства поставляет язык, который ты используешь, чтобы предотвращать этот тип атак.

7
ответ дан 24.11.2019, 12:22

Действительно, лучшее состоит в том, чтобы осведомляться сначала, что это действительно одна inyección SQLа именно, он состоит в том, чтобы эксплуатировать консультацию с неправильным форматом.

Источник проблемы inyección SQL это смесь кода и данных. В самом деле, наша консультация SQL это программа. Легитимная программа и заверши, равно как наши scripts PHP родственники. И так случается, что мы создаем это приложение динамической формы, добавляем какие-то данные относительно Вашего движения. Следовательно, эти данные могут вмешиваться с нашим кодом и изменять это. Такое изменение было бы самой inyección.

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

Давайте видеть канонический пример:

$nombre = 'Foo'; 
$sentencia = "SELECT * FROM usuario WHERE nombre='$nombre'";

Что составляется в злонамеренной последовательности.

SELECT * FROM usuario WHERE nombre='Foo';

Они это называют inyección? Неправильный. Это форматирование неприспособленная буквальной цепи.

Пока он форматируется правильно, он никому не нанесет вред:

SELECT * FROM usuario WHERE nombre='Foo\';

Мы возьмем другой канонический пример,

$id    = "1";
$id    = mysqli_real_escape_string($conexion, $id);
$query = "SELECT * FROM usuario where id = $id";

С менее вредным результатом:

SELECT * FROM usuario WHERE id =1;

назовите это inyección снова? Еще раз плохо. Говорится о буквальном числовом с неправильным форматом. Так как говорилось о подходящем формате, честная одна

SELECT * FROM users where id = 1;

Заявление было бы позитивно безопасным.

С другой стороны, Вся опасность приходит из заявления того же вопроса: миллионы пользователей PHP все еще думают, что очень известное намерение функции mysql_real_escape_string () - это "чтобы защищать SQL от вставок" (убегая какие-то "опасные символы" фиктивного способа). Если бы они узнали истинное намерение этой честной функции, не было бы вставок в мире! Если бы они только форматировали Ваши консультации, вместо того, чтобы "защищать их", они считали бы реальную защиту результатом.


Каковы правила формата?

Правда состоит в том, что правила формата не являются такими легкими и не могут выражать в единственном императиве. Для MySQL он был бы:

1. Цепи

  • Должны быть добавленными путь готовое родное решение или должны быть между кавычками специальные символы и должны быть убежавшими.
  • Правильное кодирование клиента должно или может кодироваться в Шестнадцатеричном.

2. Числа

  • Они должны добавляться через готовое родное заявление или будь должен выполнять формат, чтобы содержать только числа, десятичный delimitador и знак.

3. Идентификаторы

  • Они должны быть заключенными между простыми кавычками.
  • Специальные символы (откровенно - открытый акцент очень delimitadoras) должны быть убежавшими.

4. Операторы и ключевые слова

  • Нет специальных правил формата для ключевых слов и операторы, кроме которых они должны быть легитимными операторами SQL и ключевых слов. Итак, они должны быть в белом списке.

Поскольку возможно видеть, есть четыре различных набора правил, не только одной единственной инструкции.


Готовые заявления

Идея об одной sentencia preparada урожденная умная и простая: консультация и данные посланы в сервер, отделенный между собой, и следовательно нет возможности того, чтобы они вмешались. То, что он делает невозможным inyección. Но в то же время, у родного осуществления есть Ваши ограничения, так как он только выносит два типа буквальных (цепи и числа, то есть), что делает их недостаточными и небезопасными для использования реальной жизни.

И сюда мы прибываем в главную точку: общая мысль создавать консультацию SQL вне постоянной части и закладок положения, которое будет заменено реальными данными, которые будут форматироваться автоматически, это в самом деле Святой Грааль, который мы искали.

Главное и самое существенное благодеяние declaraciones preparadas это уничтожение всех опасностей ручного формата:

  • Готовое заявление делает полное форматирование. Все это без вмешательства программиста!
  • Готовое заявление, которое делает подходящий формат (всякий раз когда мы союза в наши данные используя подходящий тип).
  • Заявление, приготовленный делает форматирование invunerable.
  • У готового заявления есть формат в единственном подходящем месте - непосредственно перед выполнение консультации.

Именно поэтому ручной формат такой презирался в настоящее время и готовые заявления такие честные.

Они смогут читать статью полностью, с практическими примерами:

Также он оставляет тебя как ссылка, различие между методом POST и GET.

4
ответ дан 24.11.2019, 12:22

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

  1. Убегать специальные символы, использованные в консультациях SQL посредством mysql_real_scape_string().

  2. Разграничивать стоимость консультаций закрывая string с простыми кавычками.

  3. Проверять всегда данные, которых вводит пользователь контролируя длину, и что был действительно string.

  4. Распределять минимальные привилегии пользователю, который присоединит с базой данных.

Все же я рекомендовал бы тебе использование PDO или MySQLi, так как они являются готовившимися к тому, чтобы предотвратить вставку SQL:

Using PDO (for any supported database driver):
$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');
$stmt->execute(array('name' => $name));

foreach ($stmt as $row) {
  // do something with $row
}

2. Using MySQLi (for MySQL):

$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name=  ?');
$stmt->bind_param('s', $name);
$stmt->execute();
$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
// do something with $row
}

Используйте готовые инструкции и консультации parametrizadas. Это решения SQL, которые посланы и проанализированы сервером базы данных отдельно, любого параметра. Таким образом невозможно для взломщика делать инъекцию злонамеренному SQL.

1
ответ дан 24.11.2019, 12:22
  • 1
    Deberí схвати оставлять ответ полностью переведенным. – Francisco Romero 26.11.2016, 17:15

Теги

Похожие вопросы