#php #mysql #sql
#php #mysql #sql
Вопрос:
Я провел много исследований, и чем дольше я ищу и не могу найти ответ, тем счастливее я становлюсь.
Я написал свой собственный веб-фреймворк php mvc, и я беспокоюсь, что SQL-инъекция — единственная уязвимость, о которой мне нужно было беспокоиться.
Я использовал свои собственные методы абстракции базы данных и поддерживаю разные базы данных, и мои утверждения являются доказательством sql-инъекции. Итак, мой вопрос прост: есть ли что-нибудь еще, о чем мне нужно беспокоиться в отношении защиты моей базы данных.
Если есть какие-либо, пожалуйста, предоставьте подробности или статью, где я могу получить больше информации, и, если возможно, решения тоже.
Спасибо. Ибрагим
Комментарии:
2. Как вы уверены, что это защита от инъекций? Используете ли вы параметризацию?
3. Вы должны обращаться к базе данных только с пользователем, у которого не больше привилегий, чем требуется для работы приложения.
4. все параметры инструкции sql задаются из примера объекта db: $User-> setName(«имя»); и значения экранируются и сначала проверяются, правильный ли это тип данных, перед сохранением
Ответ №1:
-
Если вы разрешаете загрузку, ограничиваете ли вы размер загружаемых файлов или их количество?
-
Помимо защиты от SQL-инъекции, вы явно ограничиваете длину данных?
-
Вы ограничиваете количество раз, когда данные могут быть вставлены в вашу базу данных?
-
Помимо инъекцииSQL, защищены ли вы от инъекцииJavaScript? Если я сохраню
<script>malicious code</script>в вашей базе данных, вы уверены, что код не будет выполнен, когда кто-то просматривает мой текст через браузер?
Ответ №2:
Есть гораздо больше поводов для беспокойства, чем SQL-инъекция, просто взгляните на список здесь:
https://www.owasp.org/index.php/Category:Vulnerability
Некоторые из наиболее распространенных:
- Захват сеанса
- Возможность угадывать (и получать доступ) к другим записям по идентификатору
- Незашифрованные идентификаторы общедоступных записей
- Возможность загружать исполняемые файлы
- Возможность доступа к чужим файлам
- Уязвимости аутентификации / авторизации
- Фиксация сеанса
Список можно продолжать и дальше, но взгляните на документ по безопасности PHP user notes, там есть несколько довольно хороших комментариев:
Ответ №3:
Datawise, экранирует все входящие данные и entity / specialchars все исходящие данные. Простая философия, которая гарантирует, что вы работаете с данными только один раз при входе и один раз при выходе.
Рассмотрите возможность перехвата сеанса, взлома файлов cookie, подделки форм (не используйте прямое значение select и скрытых форм. назначьте им ключ, подобный целому числу, которое соответствует элементу в массиве, и используйте этот ключ для получения значения элемента.)
Комментарии:
1. Экранирование всех исходящих данных, в то время как в значительной степени гарантирует, что вредоносный HTML не выживет, делает это так, что никакой HTML не выводится как таковой. Если вы используете форматированный текстовый редактор для текстовых полей, вашим пользователям не понравится, что он теперь усеян видимыми HTML-тегами. Мне кажется, вам нужно быть немного более конкретным в отношении того, что нужно HTML-экранировать.
Ответ №4:
если вы используете .net, просто выполните быстрый поиск в Google. Вы можете предотвратить большинство атак, изменив свою веб-конфигурацию.
<authentication mode="Forms">
<forms protection="All" loginUrl="~/Account/Login.aspx" timeout="30" slidingExpiration="true" />
</authentication>
что касается других вещей, то да, есть несколько вещей, о которых вам, возможно, придется беспокоиться. например, люди передают <script>alert('boo');</script> свои входные данные. поэтому, когда придет время для вывода значения базы данных, вы можете подвергнуть своих клиентов угрозам безопасности. предполагая, что предупреждение (‘boo’) является чем-то более злым.
вот полный список здесьhttps://www.owasp.org/index.php/Main_Page