Тестирование, если сайт уязвим для инъекций Sql

Ответ 1

SQL injection - это попытка выпустить команды SQL в базу данных через интерфейс веб-сайта, чтобы получить другую информацию. А именно, эта информация представляет собой хранимую информацию базы данных, такую ​​как имена пользователей и пароли.

Первое правило защиты любой script или страницы, прикрепленной к экземпляру базы данных, Не доверяет пользовательскому вводу.

В вашем примере делается попытка завершить неверную строку в инструкции SQL. Чтобы понять это, вам сначала нужно понять SQL-инструкции. В вашем примере добавления ' в paramater ваша "инъекция" надеется на следующий тип утверждения:

SELECT имя пользователя, пароль ОТ пользователей WHERE username = '$ username'

Добавив ' в этот оператор, вы можете добавить дополнительные SQL-параметры или запросы: ' OR username --

SELECT имя пользователя, пароль FROM users WHERE username = '' OR username - '$ username

Это инъекция (один тип: перепрофилирование запроса). Пользовательский ввод становится введенным оператором в предварительно написанный оператор SQL.

Как правило, существует три типа методов SQL-инъекций:

• Изменение или переадресация запроса (выше)
• На основе сообщения об ошибках (Нет такого пользователя/пароля)
• Слепые инъекции

Читайте на SQL Injection, Как проверить уязвимости, понимание и преодоление SQL-инъекции, и этот вопрос (и связанные с ним) в StackOverflow об избежании инъекций.

Edit:

Что касается ТЕСТИРОВАНИЯ вашего сайта для SQL-инъекции, понимайте, что он становится намного более сложным, чем просто "добавить символ". Если ваш сайт имеет решающее значение, и вы (или ваша компания) можете себе это позволить, нанимайте профессиональный тестер для пера. В противном случае этот отличный exaxmple/proof может показать вам некоторые общие методы, которые можно использовать для проведения теста на инъекцию. Существует также SQLMap, который может автоматизировать некоторые тесты для сценариев SQL Injection и database take over.

Ответ 2

SQL Injection может выполняться на любом входе, который может повлиять на пользователя, который не был правильно экранирован перед использованием в запросе.

В качестве примера можно привести переменную get:

http//www.example.com/user.php?userid=5

Теперь, если сопутствующий PHP-код выглядит примерно так:

$query = "SELECT username, password FROM users WHERE userid=" . $_GET['userid'];
// ...

Вы также можете легко использовать SQL-инъекцию:

http//www.example.com/user.php?userid=5 AND 1=2 UNION SELECT password,username FROM users WHERE usertype='admin'

(конечно, пробелы должны быть заменены на %20, но это более читаемо. Кроме того, это просто пример, делающий некоторые дополнительные предположения, но идея должна быть ясной.)

Ответ 3

Любой вход от клиента - это способы быть уязвимыми. Включая все формы и строку запроса. Это включает в себя все HTTP-глаголы.

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

Ответ 4

Страница входа не является единственной частью веб-сайта, управляемого базой данных, который взаимодействует с базой данных.

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

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

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

Ответ 5

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

Как правило, у вас будут запросы к базе данных за безопасным входом, но если у вас просто есть список предметов или что-то, что вам не важно, если мир увидит, что хакер может добавить некоторую инъекцию sql в конец строки запроса.

Ключ с SQL Injection - это тот, кто делает инъекцию, должен знать, что ваш запрос на базу данных так, если вы не можете запросить базу данных, а затем не добавить sql. Если ваша форма отправляется в базу данных, тогда да, они могут использовать SQL Inject. Всегда полезно использовать либо хранимые процедуры для выбора/вставки/обновления/удаления, либо убедиться, что вы подготовили или избегаете всех операторов, которые будут попадать в базу данных.

Ответ 6

Самый простой способ защитить себя - использовать хранимые процедуры вместо встроенных операторов SQL.

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