Как ограничить влияние и уменьшить риск SQL-инъекций для существующего сайта?

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

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

Что касается того, что вы пробовали до сих пор: скрытие сообщений об ошибках-это хорошее начало. Я'd рекомендую вам применять еще более строгие разрешения (см. ниже). Это спорно, является ли изменение имен таблиц справка, но, вероятно, он выиграл'т больно.

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

Другой вариант-использовать брандмауэр веб-приложений (WAF) в, такие как mod_security для Apache. Вы можете настроить его, чтобы блокировать запросы, которые выглядят подозрительно. Однако, нет WAF-это замечательно. И это требует времени и энергии, чтобы настроить его. Вы, вероятно, лучше использовать это время для реализации подготовленных заявлений.

Опять же, Дон'т пусть это заманить вас в ложное чувство безопасности. Нет никакой подмены, чтобы устранить проблемы.<службы></службы>

Единственно правильный способ заключается в использовании заранее подготовленных заявлений.

1. Если вы маскируете сообщения об ошибках, это немного сложнее, но выиграл'т остановить нападавших.
2. Вы можете ограничить права, но все права, предоставленные пользователю может получил злоумышленник. Также можно выполнить команды оболочки от SQL-инъекций в некоторых случаях.
3. Переименование таблиц выиграл'т помочь вам. Sqlmap инструмент `` будет перебор имен таблиц для тебя Чара на чара. Это не'т нужно много времени.

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

мы знаем, но нам не хватает разработчиков/тестеров, чтобы сделать его 100% сейф.

Это реальная проблема. Пока вы не нанять больше людей или переназначить приоритеты, вы'повторно не безопасно. Останавливаясь на 99,9% нападающих означает, что ваши данные были скомпрометированы. Лейкопластырь решения плохой и они *не *** работать. Дон'т тратить время на рефакторинг вашего шаблона доступа к SQL в то время как вы могли бы фиксируя актуальные проблемы.

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

Это's большое проще, чем пытаться использовать PHP, чтобы очистить себя аргументами, и стоит намного меньше времени. Просто грэп всю базу кода для всего, что связано с SQL и исправить ее.

Продувки все SQL из кода навсегда

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

Если у вас нет времени, чтобы учиться и реализовывать эти пакеты, или не используйте их для какой-то другой причине, trietend'ответом является следующая лучшая вещь, используя [подготовленные операторы][2]. Это позволит вам быть в безопасности от SQL-инъекций. То есть, пока вы не давить на разработчиков, чтобы достичь быстрых результатов, на это время они могут снова забыть параметризации одной переменной, оставляя вас обратно, где вы начали.

[2]: https://en.wikipedia.org/wiki/Prepared_statement на "подготовленные заявления и"

мы знаем, но нам не хватает разработчиков/тестеров, чтобы сделать его 100% безопасным.

Не совсем понятно, что вы подразумеваете под этим заявлением, как подготовленные операторы являются тривиальными во всех популярных веб-языка (PHP, питон, Ява, node.js и т. д.) и более или менее 100% эффективная мера против SQL-инъекций.

Ты имеешь в виду субподряда развития и может'т позволить себе ОК код, который они пишут для вас по контракту? Вы можете'т позволить себе не: вы по-прежнему ответственное лицо.

Вы хотите сказать, что ваши разработчики слишком заняты, реализации возможностей занять несколько часов для обновления кодовой базы? Все другие, чем подготовленные заявления займет больше времени и стоить дороже (например, ОРМ, obsfucation, детальных разрешений и т. д.).

Вы имеете в виду, что ваши разработчики не достаточно компетентны, чтобы выполнить эту простую задачу? Что'С проблема ключом побольше (или если быть более точным, SQL-инъекции не должно быть твоей заботой в этот момент).

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

Что бы это ни было, принимать решение использовать подготовленные операторы вчера, около.

После того, как первый "и подготовлено заявление" по рекомендации был реализован, я бы порекомендовал почитать о SQL-инъекции. Спрашиваю "как предотвратить SQL-инъекции" это довольно обширный вопрос! Безопасность-это вопрос, который вы (вернее, ваша вся команда) должны быть очень хорошо знакомы с, чтобы снизить риск взлома. Одна дыра подрывает все ваши усилия.

Посетите открытый проект безопасности веб-приложений (OWASP) здесь: https://www.owasp.org/index.php/SQL_Injection

В частности, дополнительный материал:

• Профилактика шпаргалка SQL-инъекции*
• Шпаргалка Параметризация Запросов
• Статья руководство о том, как избежать уязвимости SQL-инъекций

А также

• Как проверить код на уязвимости SQL-инъекций.

Временная мера будет смотреть в брандмауэр веб-приложений (WAF) в - есть несколько компаний, там, которые обеспечивают это как сервис, и несколько облачных провайдеров, которые также есть предложения. Cloudflare, кажется, предлагают один, я'вэ был один клиент использует получены путем, и я знаю, что в AWS WAF в предложении некоторых управляемых наборов правил для SQL-инъекции.

Таким образом весь трафик направляется через с WAF (либо в том числе и на сервера, и настройки DNS, чтобы указать на будущее, как для КДС), и он ищет вещи, которые выглядят как SQL-инъекции попытки по параметрам. Он выиграл'т поймать всех атак, и могут блокировать трафик, но это доступное зафиксировать лейкопластырь.

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

Ваша задача здесь-изменить свое сознание, как бы это осуществить исправление. Количественно, что's на кону - какой будет ущерб, как в деньгах, так и в плане репутации, другого нарушения? Там могут быть законы в вашей юрисдикции, которые требуют доложить компромиссы пользователя's и данные. Это было бы неловко? Может быть, сообщения средств массовой информации о вашей организации'с плохой практики?

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

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

Как всем упомянул исправить код на сайте.

Вы можете вносить любые исправления, которые вы хотите в стене, но до тех пор, пока стена построена правильно, то никаких патчей будет bandaide с проблемой кровотечения..

Любое другое предложение чистый код-это то, что Линус Торвальдс назвал бы masterbation.

• Исправить ваш код (из наиболее очевидных инъекции до последнего т. е. вам параметры) и использовать подготовленные операторы. как я могу предотвратить SQL-инъекций в PHP

• Можно попробовать п (т. е. ModSecurity) временно, пока вы'повторно в состоянии сделать вещи фиксированные.

• Попробуйте, возможно, какой-то бан по IP на 'человек-тестирования сайта' или блокируя небезопасные запросы делаются.

• Если у вас есть возможность сделать временную (безопасный) экран входа в стойке до решения этой проблемы.

• Попробуйте сторонний сервис, пока это не будет решена, то как от Cloudflare или что-нибудь еще.

Зрп была доступна начиная с версии PHP 5.1 выпущен 24 ноября 2005 года ... Разработчики должны понимать, что они'вновь последствиями своих плохих привычек кодирование и лично я считаю, что должна быть ответственность за качество работы обеспечивается.

В любой ЗРП ставка это легко реализовать . Если ваши разработчики не'т, способные обеспечить более высокое качество, то я бы предложил удалить...

Самое главное правило:

Использование библиотек, инструментов и API, которые делают безопасный вариант самый простой вариант.

Нахт говорит "просто использовать ORM" и входит в это правило.

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

И.. мы хотим безопасный вариант, чтобы быть легким и удобным, поэтому программист использует его из-за своего эгоизма и лени. Мы хотим, чтобы программисту придется выходить из их пути, и вкладывать какие-то усилия для того, чтобы использовать небезопасный вариант!...

Гораздо лучшее решение-это API-интерфейс программирования, таких как Python dbapi. Я написал PHP-эквивалента лет назад, который был бы:

db_query( "SELECT * FROM mytable WHERE id=%s", $id )

Это гораздо удобнее, чем подготовленные заявления. Только одна строка для ввода. Также он возвращает результат в виде, что цикл foreach() можно использовать, так это намного проще в использовании, чем метод fetch() и прочее. Что более важно, код, скрытый за этот API будет обрабатывать побега должным образом. Это делает SQL-инъекции неактуально. Это обрабатывает около 99% запросов, если вы не'т использовать ORM. Динамические запросы (обычно поиск), хотя и нуждаются в специальной обработке, но это's по-прежнему легко.

Если вы держите это правило в уме, то в определенный момент Вы должны задаться вопросом, почему вы должны использовать htmlspecialchars () и почему язык не'Т есть функция, которая сделает безопасной обстановке (т. е., ни XSS уязвимости в этом) самый простой в использовании? Ну почему, почему? И что's, когда вы падаете на PHP.

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

Чтобы проверить учетные данные, вам необходимо хранимую процедуру, которая принимает введенный пароль (или хэш) в качестве параметра и возвращает логическое значение. Другими словами, можно переложить работу по проверке учетных данных в базе данных и фактическое хэш никогда не покидает базу.

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