Что такое SQL-инъекция
«Там, где есть люди, есть реки и озера, а где есть база данных, могут быть уязвимости для SQL-инъекций».
Среди всех типов уязвимостей SQL-инъекция является наиболее опасной и опасной уязвимостью. Проще говоря, SQL-инъекция — это атака, которая разрушает исходную структуру SQL путем внедрения синтаксиса SQL в параметры, контролируемые пользователем, и приводит к неожиданным результатам при написании программ. или сThinkJSНапример, предположим, что мы написали следующий интерфейс (на практике это определенно не так):
// user.js
module.exports = class extends think.Controller {
async loginAction() {
const { username, password } = this.post();
const user = await this.model().query(
`SELECT * FROM user WHERE name = "${username}" AND password= "${password}"`
);
if (think.isEmpty(user)) {
return this.fail();
}
return this.success(user);
}
}
когда пользователь отправляетusernameдаadmin"; --, окончательный выполненный оператор SQL станет
SELECT * FROM user WHERE name = "admin"; --" AND password= "111"
Наконец, злоумышленник может успешно войти в учетную запись администратора, что является простейшей инъекцией SQL. Из приведенного выше простого примера мы обнаружили, что причина уязвимости может быть связана с наложением следующих двух причин:
- Когда автор программы обрабатывает взаимодействие между прикладной программой и базой данных, оператор SQL создается путем конкатенации строк.
- Содержимое параметра встраивается в инструкцию SQL без достаточной фильтрации контролируемых пользователем параметров.
SQL-инъекции классифицируются в зависимости от того, как злоумышленник получает данные.эхо-инъекция,Инъекция ошибока такжежалюзи. Данные, полученные непосредственно из возвращаемого результата, как только что было продемонстрировано, представляют собой внедрение эха.Конечно, структура и содержимое базы данных также могут быть проанализированы из отчета об ошибках, выполняемого MySQL, что является внедрением ошибок. Слепая аннотация основана на задержке и других операциях, выполняемых базой данных, чтобы определить, близко ли оно к правильному значению.Проще говоря, это немного похоже на то, как держать стетоскоп для проверки пароля сейфа.
Различные принципы классификации будут иметь разные классификации, а также существуют классификации в зависимости от места и метода инъекции.ПОСТ-инъекция,ПОЛУЧИТЬ инъекцию,инъекция печенья,жалюзи,Задержка впрыска,поисковая инъекция,инъекция base64Ждать. Однако все поддерживают разные формы классификации, и принцип остается тем же, поэтому я не буду здесь вдаваться в подробности.
Опасности SQL-инъекций
Если на веб-сайте есть уязвимость SQL-инъекции, это равносильно тому, что злоумышленнику будет предоставлен доступ к базе данных напрямую, и можно себе представить, какой вред будет нанесен. Злоумышленники, использующие уязвимости SQL-инъекций, могут осуществить следующие атаки:
- Пропустить проверку разрешений учетной записи, чтобы получить несанкционированный доступ
- Получить информацию о ключах базы данных для извлечения из библиотеки
- В особых случаях содержимое базы данных также может быть изменено или вставлено в базу данных.Если есть проблема с распределением разрешений базы данных или сама база данных имеет недостатки, злоумышленник может напрямую получить разрешения веб-шелла или серверной системы через SQL. инъекционные уязвимости.
способ защиты
Проверка достоверности данных
Как видно из начала статьи, основная причина уязвимости в том, что вводимые пользователем данные не фильтруются.Так что для данных от пользователей (GET, POST, cookie и т.д.) лучше всего сделать следующие две проверки фильтрации:
- Убедитесь, что входные данные имеют ожидаемый формат данных. Это особенно эффективно, когда параметр является числом, и если злоумышленник решит вставить что-то в параметр, он будет преобразован в
NaNпривести к провалу атаки. В ThinkJS мы предоставляем мощныйLogicФункция может легко проверить формат данных. - Используйте функцию экранирования конфиденциальных символов для конкретной базы данных, чтобы экранировать нечисловые данные, отправленные пользователем. существуетThinkJSупаковано вescapeString()Этот метод может экранировать конфиденциальные символы, и его принцип такой же, как и в PHP.mysql_escape_string()Метод тот же.
Проверка формата входных данных также предотвращает другую неуниверсальную проблему безопасности SQL в ThinkJS. Пример кода в начале статьи обычно будет написан так в практических приложениях:
// user.js
module.exports = class extends think.Controller {
async loginAction() {
const { username, password } = this.post();
const user = await this.model('user').where({
name: username,
password
}).find();
if (think.isEmpty(user)) {
return this.fail();
}
return this.success(user);
}
}
когда мы строимname=admin&password[]=!%3D&password[]=Когда параметр запроса , окончательно выполненный оператор модели станет
this.model('user').where({name: 'admin', password: ['!=', '']});
Из-за характера автоматического слияния массивов в HTTP-запросах наш оператор SQL не является тем, что нам нужно. Хотя сама структура была разработана для этой ситуациииметь дело с, когда пользовательский входной параметр считается оператором SQL, он добавит пробелы к ключевому слову, чтобы превратить его в обычную строку, чтобы избежать этой проблемы. Однако такой способ будет иметь определенный ущерб, ведь когда эти операторы действительно нужно передавать, полученные данные отличаются от запрошенных.сбитый с толку. Поэтому лучше выполнить полную проверку данных на уровне логики, чтобы заранее определить проблему.
В дополнение к проверке данных вы также можете использовать такие функции, как хранимые процедуры базы данных и предопределенные указатели для абстрактного доступа к базе данных, чтобы пользователи не могли напрямую обращаться к таблицам данных и представлениям. Но у этого подхода есть и другие последствия.
via: SQL-инъекция
Ограничения разрешений
Строго ограничить полномочия на работу с базой данных веб-приложения и предоставить пользователю минимальные полномочия, которые могут удовлетворить только его работу, тем самым сводя к минимуму вред базе данных, причиняемый инъекционными атаками. **Пожалуйста, никогда не используйте учетную запись суперпользователя или владельца для подключения к базе данных! ** Когда база данных подвергается атаке, разумно ограничить ущерб областью действия текущей таблицы. Ограничения разрешений могут помешать злоумышленникам получить другую информацию в базе данных и даже использовать базу данных для выполнения таких операций, как команды оболочки.
обработка журнала
При сбое операций с базой данных попробуйтеНе возвращать необработанные журналы ошибок, такие как ошибки типов, несоответствия полей и т. д., для раскрытия инструкций SQL в коде, чтобы злоумышленники не могли использовать эту информацию об ошибках для внедрения SQL. Кроме того, там, где это разрешено,Сохраняйте журналы запросов, используя код или системы баз данныхТоже хороший способ. Очевидно, что ведение журнала не предотвращает любую атаку, но регулярный аудит журнала выполнения базы данных может отследить, выполняется ли оператор SQL за пределами обычной логики приложения. Журнал сам по себе бесполезен, необходимо ознакомиться с содержащейся в нем информацией. В конце концов, больше информации лучше, чем ничего.
постскриптум
Таким образом, вы можете подумать, что проверка данных SQL будет более проблематичной.На самом деле метод обработки ключевых слов был интегрирован в ThinkJS.Использование метода ORM, предоставляемого программой, для построения SQL будет сложнее, чем самостоятельное написание операторов SQL.Это более удобен, а также может улучшить повторное использование кода проекта и снизить потенциальные риски. Если по умолчанию для ThinkJSthink-modelЕсли вам это не нравится, вы также можете использовать другие сторонние ORM-фреймворки, такие какthink-sequelize.
Использованная литература: