Защита сайта ASP.Net MVC - PullRequest
       34

Защита сайта ASP.Net MVC

7 голосов
/ 17 марта 2009

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

Сайт будет общедоступным с «умеренно конфиденциальными данными» (то есть мы не сможем получить иск, но, вероятно, не получим много друзей, если данные будут получены!), И будут предприняты следующие меры безопасности: a: Проверка подлинности форм / членства и авторизация b: параметризованные запросы для предотвращения внедрения SQL. c: автоматический тайм-аут с x минутой бездействия c: SSL для шифрования клиента на сервер

Что еще вы рекомендуете?

* Защита IIS и сети не входит в мой домен, поэтому меня больше интересует, что мне нужно сделать с программным обеспечением.

Ответы [ 7 ]

4 голосов
/ 17 марта 2009
  • Если вы используете файлы cookie для распознавания пользователей, обязательно используйте произвольный токен (например, GUID ) для хранения на клиенте для идентификации. Я видел слишком много веб-сайтов, которые хранят мой адрес электронной почты или имя пользователя в моем cookie-файле ... просто нужно изменить его на другой!

  • Напишите ваше программное обеспечение, чтобы оно могло работать с Среднее доверие .

3 голосов
/ 17 марта 2009

Если вы новичок в веб-разработке, вы должны знать о межсайтовом скриптинге (XSS) . Для защиты от этого в ASP.NET MVC можно использовать вспомогательный метод Http.Encode.

2 голосов
/ 17 марта 2009

Удостоверьтесь, что вы препятствуете запросам вне очереди. Убедитесь, что клиент прошел проверку подлинности, прежде чем разрешить просмотр конфиденциальных данных, или, в некоторых случаях, убедитесь, что клиент прошел через правильный канал, прежде чем разрешать манипулирование данными. Например, разрешите добавлять товар в корзину, только если запрос поступил со страницы сведений о продукте. Если вы не проверяете, любой может возиться с действием. URL будет выглядеть как http://server/cart/add/XYZ123, и любой может просто настроить параметр 'id'.

1 голос
/ 17 марта 2009
  1. Возможно, вам следует выбрать методы, которые можно вызывать извне или нет. Например, будьте осторожны, создайте метод, такой как удаление любых таблиц, таких как http://yourhost.com/edit/deletealltable. Убедитесь, что вы хорошо спроектировали свой класс и методы. И дать атрибуты [NonAction] для предотвращения вызова публичного метода.

  2. Убедитесь, что вы отображаете данные (особенно конфиденциальные) так, как вам нужно, с минимальным замысловатым дизайном и используете клиентский сценарий столько времени, сколько необходимо.

  3. Удалите все неиспользуемые мусорные файлы, например неиспользуемые файлы, в папке вашего решения.

  4. Проверьте и дважды проверьте и подтвердите любой элемент управления вводом, как текстовое поле. Я просто могу дать что-то в текстовом поле, чтобы взломать вашу систему.
  5. Если вы используете смесь между MVC и обычным ASP.NET, удалите все зависимости между ними.
1 голос
/ 17 марта 2009

Взгляните на этот пост Фила Хаака - одного из разработчиков MS, участвовавших в разработке.

Дополнительно взгляните на Microsoft Anti-Cross Site Scripting Library , чтобы отфильтровать все входящие параметры

1 голос
/ 17 марта 2009

Вот еще одна важная персона, на которую стоит обратить внимание: CSRF

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

0 голосов
/ 17 марта 2009

Убедитесь, что вы подробно осветили основы, независимо от ASP.NET. Убедитесь, что в вашей СУБД есть отдельный пользователь с минимально необходимыми привилегиями (например, CRUD и выполнение sprocs из указанных баз данных), настроенный для доступа к базе данных из веб-приложения. Параметризация запросов - отличная идея, но ВСЕГДА ОБРАЩАЙТЕСЬ С ВАШИМ ВХОДОМ: В любом случае, это не полная защита от внедрения SQL.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...