Веб-рамки с открытым исходным кодом: безопасность

Question

Насколько безопасны популярные веб-фреймворки с открытым исходным кодом?

Меня особенно интересуют популярные фреймворки, такие как Rails и DJango.

Если я создаю сайт, который собирается делать тяжелую электронную коммерцию, можно ли использовать фреймворки, такие как DJango и Satchmo?

Является ли безопасность подвергнутой риску из-за их открытой архитектуры?

Я знаю, что наличие ОС не означает, что вы просто открыты для хакеров, Linux использует превосходный механизм аутентификации, но Интернет - это другая игра.

Что можно сделать в этом отношении?

UPDATE:

Спасибо за ответы, ребята.

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

Я понимаю, что Django и Rails были разработаны аспекты безопасности, имея в виду, наиболее распространенной формой атаки, такие как XSS, Инъекции и т.д. (Django book имеет ч на Security)

Я ожидал комментарии Gurus безопасности , Если вы являетесь Гуру безопасности, вы бы порекомендовали важный сайт, который, вероятно, будет популярным, чтобы быть построен на DJango или Rails?

Answer 1

Я построил несколько сайтов, используя Django и один магазин, используя Satchmo. Нет никакой разницы в безопасности между закрытыми и открытым исходным кодом, поскольку вся информация, связанная с безопасностью, уникальна для вашей установки.

Например, «секретный код» в файле settings.py генерируется уникально при запуске проекта. Вы можете скрыть пароли пользователей и защитить свои ключи шифрования, так же, как и на любой платформе.

Что-то примечание о Django заключается в том, что все формы ввода подтверждены и «маркированы безопасно» через процесс санитарии. Вы можете получить доступ к дезинфицированным данным формы через свой cleaned_data словарь.

Кроме того, все шаблоны являются автоматически экранированными HTML, поэтому риск инъекционных атак или межсайтовых скриптов практически равен нулю.

Наконец, модели предлагают дополнительный уровень безопасности и проверку, если какие-либо данные изгоев пройдут.

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

Answer 2

Многие говорят, что security through obscurity не работает. Продукты Microsoft, Adobe Reader и т. Д. Можно назвать доказательством того, что закрытый источник не эффективнее открытого источника для предотвращения проблем безопасности.

Многие защитники с открытым исходным кодом утверждают, что больше глаз лучше подход является одним из способов борьбы с ошибками, связанными с безопасностью. Однако на самом деле, когда вы имеете дело с более мелкими приложениями или менее популярны как коммерческие, так и открытые источники, часто бывает мало глаз. Таким образом, существует реальная опасность поиска черной шляпы в коде google для фрагмента кода с дырой в безопасности.

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

Однако, если вы серьезно относитесь к созданию сайта электронной коммерции - вам необходимо несколько уровней защиты. Определенно убедитесь, что имеется надлежащий брандмауэр и система защиты/обнаружения вторжений (IPS/IDS). Возможно, вам придется заплатить за услугу хостинга, которая будет предоставлять услуги по утешению и мониторингу безопасности в дополнение к хостингу. Помните, что ваши пользователи - ваши клиенты! Любое нарушение может быть катастрофическим для бизнеса.

Answer 3

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

Скрытие источника кода не является эффективным способом защиты приложения. Он может работать для определенного программного обеспечения, но для широкого распространения люди в конечном итоге собираются выяснить, как все работает (http://en.wikipedia.org/wiki/Reverse_engineering)

Существует широкомасштабное веб-приложение для электронного бизнеса, использующее фреймворк с открытым исходным кодом. Если вы знакомы с электронной коммерцией инструменты, вы должны знать, что Shopify построен с использованием Ruby On Rails (http://weblog.rubyonrails.org/2006/6/5/shopify-is-open-for-business)

Они также выпустило ActiveMerchant:

Активный Merchant является извлечением из системы электронной коммерции Shopify. Требования к Shopify для простого и унифицированного API для доступа к десяткам различных платежных шлюзов с очень разными различными внутренними API были основным принципом при проектировании библиотеки.

Активный коммерсант в производство использования с июня 2006 года и в настоящее время используется в самых современных приложений на Ruby, который сделки с финансовыми операциями.

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

Конечно, вам нужно обеспечить безопасное приложение и не полагаться исключительно на фрейм!

Answer 4

Некоторые из ответов касаются только открытых источников и закрытых и безопасности, но поскольку вы спросили об определенных фреймах, я подумал, что прокомментирую то, что я знаю о Rails.

Есть признаки, которые косвенно комплимент безопасность и те, которые явно предназначены для обеспечения безопасности в Rails:

1. SQL Injection - ActiveRecord, как правило, приветствуются, чтобы получить доступ к базе данных в приложениях Rails. При правильном использовании вы избегаете проблем с конкатенацией строк, которые могут привести к эксплуатации с помощью SQL-инъекции. Это один из самых распространенных методов атаки на веб-приложения.
2. XSS - Простые в использовании макросы предоставляются для кодирования HTML-кода, который вводил пользователь, а также кода для очистки JavaScript, который пользователь мог ввести в поля. Используя их вместе, вы помогаете защитить себя от межсайтовых скриптов, как приходящих, так и идущих.
3. Обработка файлов cookie. Механизм хранения данных сеанса в Rails по умолчанию отправляет его конечному пользователю в виде файлов cookie. Однако пользователь не может просто изменить эти данные, а затем отправить их обратно на сервер, потому что перед отправкой он подписан длинным закрытым ключом. Любые измененные данные сеанса сразу будут очевидны для сервера.
4. CSRF - Это сложно объяснить, но Rails обеспечивает безопасность своими формами, чтобы гарантировать, что входящий запрос поступает из формы, которую вы фактически отправили пользователю.

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