Какие шаги необходимо выполнить, прежде чем разрешить доступ к новому сайту, чтобы убедиться, что он безопасен и "готов к работе"?
Пока у меня есть следующее:
<customErrors mode="RemoteOnly" />Мой текущий технический стек — IIS7 и ASP.Net MVC3.
Я уверен, что забыл или не знаю о многих других вещах. Любой совет?
Защита от SQL-инъекций. Используйте хранимые процедуры ИЛИ параметризованные операторы sql. Вы можете использовать динамический sql, но будьте очень осторожны, и если вы это сделаете, убедитесь, что вы используете параметризованные запросы и не формируете «встроенные» операторы sql, добавляя переменные.
Защитите себя от подделки межсайтовых запросов (CSRF), убедившись, что вы используете Html.AntiForgeryToken.
Убедитесь, что трассировка отключена
Убедитесь, что пользовательские ошибки включены, чтобы желтые экраны смерти (т. е. сведения об ошибках) не отображались для клиента.
Защитите себя от межсайтового скриптинга, убедившись, что любые выходные данные, отображаемые в вашей системе из вашей модели, базы данных и т. д., закодированы с использованием синтаксиса ‹%: на ваших страницах aspx и просто @XXXX на ваших страницах mvc 3, так как mvc3 кодирует все BY DEFAULT, что является большим улучшением по сравнению с прошлыми методами.
Убедитесь, что в вашей базе данных нет тестовых учетных записей.
Убедитесь, что никакие действия не могут быть выполнены только с помощью строки запроса — например, передача /MyApp/DeleteUser/10. Требовать сообщения для выполнения действия, и эти сообщения должны использовать Html.AntiForgeryToken и [ValidateAntiForgeryToken] на вашем контроллере.
Убедитесь, что любые пользователи, редактирующие информацию на вашей странице, не могут редактировать (используя такой инструмент, как fiddler) первичный ключ, скрытый на странице, тем самым изменяя редактируемую запись при отправке изменений. Например, вы можете хэшировать CustomerId на странице в скрытое поле и сравнивать его при публикации, чтобы убедиться, что он соответствует тому, что есть в модели.
Приходи ко мне в tech ed в Атланте в следующем месяце, чтобы поговорить о безопасности :)
Если вы используете ELMAH, убедитесь, что доступ к обработчику elmah.axd защищен и закрыт. В противном случае вы даете потенциальным хакерам ценную информацию.
Убедитесь, что ваш веб-сервер полностью обновлен с исправлениями и автоматически загружает / устанавливает их, когда они доступны из MS. Слишком много сайтов не применяют их и получают pwn.
Убедитесь, что на вашем сайте нет динамического sql; или, по крайней мере, все обрабатывается с помощью параметризованных запросов. В соответствии с этим убедитесь, что учетные данные пользователя базы данных заблокированы, чтобы у него были только те возможности, которые вам действительно нужны (подсказка: уровень dbo НЕ подходит).
Убедитесь, что каждый бит ввода данных, сделанный пользователем, правильно экранирован, чтобы его отображение не приводило к проблемам межсайтового скриптинга. В общем, проведите полный аудит безопасности. Если это достаточно важно, наймите для этого стороннюю фирму.
Первое, что приходит на ум, это поисковая оптимизация (SEO). Для начала используйте набор инструментов SEO от MS.
В дополнение к вышесказанному я всегда запускаю бесплатный инструмент Xenu ( http://home.snafu.de/tilman/xenulink.html#Description ), чтобы проверить наличие неработающих ссылок. Даже если вы используете другой инструмент, это обеспечивает превосходную двойную проверку.
Рассмотрите возможность размещения файла web.config в каждой подпапке с соответствующими разрешениями. Например, если все изображения хранятся в папке \images, тогда эта папка не может обслуживать файл ASCX, а только файлы с правильным расширением изображения.
Делаете ли вы что-то удобное для пользователя, когда страница не найдена, например, перенаправляете пользователя на страницу поиска? Пользовательские страницы ошибок могут сделать сайт более удобным для использования.
Вы можете захотеть иметь файл robots.txt и собственный значок, которые часто упускают из виду.
