Безопасность для веб-приложений - PullRequest
7 голосов
/ 25 февраля 2011

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

  • Запуск приложения на Heroku (Ruby on Rails)
  • Сайт зашифрован с использованием 256 SSL (при включенном принудительном SSL))
  • Файлы cookie зашифрованы, и мы сдаем тест Firesheep
  • Их пароль и все данные в базе данных зашифрованы односторонним образом, поэтому даже если кто-то получит доступ к базе данных, он будет бесполезен.1010 *
  • Мы не храним какие-либо ключи или пароли открыто в исходном коде, а используем Config Vars

Кроме того, что еще мы должны / могли бы делать.Мы рассматриваем возможность сканирования сайта McAfee, но они дают нам по 2500 долларов в год.Я не уверен, что оно того стоит.

У кого-нибудь есть какие-либо предложения?

Ответы [ 4 ]

3 голосов
/ 25 февраля 2011

Обязательно прочитайте OWASP Top 10 .Также $ 2500 - это плагиат, Sitewatch бесплатно.Вам также следует подумать о запуске брандмауэра веб-приложений, например mod_security , но имейте в виду, что это вызовет проблемы для таких инструментов тестирования, как McAfee или Sitewatch.Вы должны настроить mod_security для разрешения определенных IP-адресов.Или протестируйте свое приложение перед включением WAF.

2 голосов
/ 25 февраля 2011

Я бы рекомендовал проверить OWASP Top 10: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

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

Чтобы проверить конфигурацию SSL, вы можете попробовать https://www.ssllabs.com/ssldb/index.html.

Если вам интересно узнать о разнообразных атаках, ознакомьтесь с постом Джеремии Гроссмана под названием Десять лучших методов веб-взлома 2010 и прокрутите вниз, пока не увидите «Полный список».

Если вы хотите запустить несколько инструментов сканирования уязвимостей веб-приложений, чтобы поймать низко висящий фрукт, вы можете попробовать:

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

Что касается разработки, вам могут понравиться идеи, представленные в упрощенном SDL от Microsoft:

«Жизненный цикл разработки безопасности (SDL) - это процесс обеспечения безопасности, ориентированный на разработку программного обеспечения».

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

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

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

Человеческий интеллект является ключом к выявлению логических проблем.

Безопасность - это также и обслуживание. Важно назначить кого-либо или команду ответственным за постоянную защиту.

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

2 голосов
/ 25 февраля 2011

После исключения обычных подозреваемых (XSS, SQL-инъекция, массовое назначение и т. Д.) На стороне клиента возникает большинство проблем, и это часто упускается из виду. Я не знаю, о чем ваш сайт, но такие вещи, как уведомление ваших пользователей о том, что им не следует переходить по ссылкам в электронных письмах, которые они явно не запрашивали, обычно обеспечивают максимальную отдачу от обязательств.

С уважением,

- И. Фернандес

0 голосов
/ 16 апреля 2017

Информацию о распространенных уязвимостях в приложениях Ruby on Rails и их мерах противодействия можно найти в Контрольном списке безопасности Zen Rails , включая большинство из 10 основных элементов OWASP.

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