Соображения безопасности, касающиеся того, чтобы разработчик интрасети сделал общедоступным веб-сайт?

Question

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

Приложение написано с использованием MVC.net, JQuery и Subsonic.

Какие шаги я могу предпринять, чтобы спроектировать приложение, чтобы оно было разумно спроектировано?

Я уже кое-что сделал:

• Проверка формы на стороне сервера и клиента
• Обеспечение сложности пароля
• Проверка в контроллере. Действия, с которыми текущий пользователь может выполнить операцию.

Был довольно параноидален, когда люди смотрели на источник моих форм в формате html и видели, что форма публикует, и использовали это, чтобы вручную создать публикацию формы с различными значениями для выполнения операций, которые они не должны. Является ли эта паранойя обоснованной, нужно ли мне делать это на действиях, приписываемых HttpVerb GET и POST или просто GET?

Нужно ли беспокоиться о внедрении SQL с ORM?

Answer 1

Проверка авторизации на ВСЕХ действиях контроллера, как GET, так и POST. Авторизуйтесь не для сеанса, а для каждого запроса еще раз.

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

Не полагайтесь на идентификацию пользователя, например, имя пользователя, хранящееся в файлах cookie. Это можно заменить. Добавьте что-то еще и уникальное для этого. Файлы cookie также могут быть украдены и переданы на другой компьютер. Рассмотрим вариант проверки IP-адреса (например), чтобы получить уверенность, что вас не обманули.

Ограничение количества операций пользователя за единицу времени. Не позволяйте делать 100 представлений в минуту.

Все пользовательские данные должны быть санированы. Да, беспокоиться о SQL-инъекциях.

Не хранить пароли в виде простого текста. Хэш их. Если кто-то проникнет в вашу систему, он может неправильно использовать пароли, предполагая, что у пользователя есть тот же пароль для доступа к своей учетной записи электронной почты, банковской системе и т. Д.

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

На самом деле, проверьте эту тему. В нем содержится хорошее резюме такого рода знаний.

Что должен знать разработчик до создания общедоступного веб-сайта?

Answer 2

Паранойя при создании общедоступных сайтов - ваш друг.

Зашифрованы ли ваши куки? Это достаточно просто сделать с помощью пользовательского модуля HttpModule. Это поверх обычного SSL.

Да, вам нужно беспокоиться о внедрении SQL. Не все ORM созданы равными. Недавно мы обнаружили проблему внедрения SQL при определенных условиях с LINQ. Не доверяйте ничего, что пишет ваши запросы для вас.

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

Answer 3

• Блокировка учетной записи (30 минут) после нескольких сбоев для предотвращения перебора.
• Рассматривать SSL как вариант для страниц регистрации и входа.
• Функция IsInRole в вашем пользовательском классе - это простой способ управлять безопасностью действий пользователя.
• Используйте токен для любой функции «Запомнить меня». Убедитесь, что этот токен является криптобезопасным.
• Используйте только параметризованные запросы, чтобы предотвратить внедрение.
• Шифровать куки.
• Microsoft Anti-XSS
• Будь параноиком.

Есть много соображений. Как всегда, это будет в стадии разработки.

Answer 4

Насколько серьезно вы относитесь к безопасности?

В целях безопасности существует стандарт RFC.

http://www.faqs.org/rfcs/rfc3552.html

Беги через него (42 страницы или около того). Он содержит большинство соображений безопасности. При создании нового RFC вы будете использовать этот документ для ознакомления с соображениями.

Answer 5

• Очистить все входные данные, отправляемые клиентом вы. Данные POST / GET могут быть проще всего подделать, но это определенно не все.

• Не зависит только от JavaScript для любые меры безопасности, так как это может так же легко обойтись.

• Убедитесь, что у вас есть безопасная политика для восстановления пароля (например, нет просто "секретный вопрос")

• Имейте некоторую защиту от перебора, например CAPTCHA,

Answer 6

Для получения исчерпывающего каталога уязвимостей веб-приложений, наиболее важных решений и методов разработки, помогающих писать более безопасный код, ознакомьтесь с OWASP и CLASP.

Answer 7

• Весь пользовательский ввод должен обрабатываться так, как если бы он уничтожил ваш сервер (XSS)
• Вся информация, поступающая в / из базы данных, является дьяволом и должна быть очищена (SQL-инъекция)
• Монстр печенья получит тебя, если ты не будешь осторожен.
• Программируйте так, как будто Javascript отключен, но предоставьте функции тем пользователям, у которых он включен