Веб-приложение с открытым исходным кодом более склонно к взлому?
в недавнем интервью меня спросили:
Open source web app (скажем, построенный на Struts / Spring) более склонен к взлому, так как любой может получить доступ к исходному коду и изменить его. Как это предотвратить?
мой ответ:
исходный код java не доступен напрямую. Он компилируется в файлы классов, которые затем объединяются в файл war и развертываются в защищенном контейнере, таком как WebLogic app server. Сервер приложений находится за корпоративным брандмауэр и не доступен напрямую.
в то время-я ничего не упоминал о XSS и SQL-инъекции, которые могут повлиять на веб-приложение на основе COTS, подобное с открытым исходным кодом.
мои вопросы:
a) является ли мой ответ на вопрос правильным?
b) какие дополнительные пункты я могу добавить к ответу?
спасибо заранее.
EDIT:
пока я перевариваю ваши ответы-позвольте мне также указать на вопрос был также предназначен для таких фреймворков, как Liferay и Apache OFBiz.
4 ответов
вопрос является завуалированным аргументом в пользу безопасности через неясность. Я предлагаю вам прочитать обычные аргументы за и против и посмотреть, как это подходит:
мое личное мнение заключается в том, что неизвестность в лучшем случае является самым слабым слоем защиты от атак. Он может помощь отфильтровать автоматические атаки неинформированных злоумышленников, но это не очень помогает против определенного нападения.
a) является ли мой ответ на вопрос правильным?
часть о том, что источник недоступен (чтобы изменить его), потому что он скомпилирован и развернут там, где его нельзя коснуться, не является хорошим ответом. То же самое относится и к программному обеспечению с открытым исходным кодом. Точка, которая была сделана против стека с открытым исходным кодом, заключается в том, что источник доступен для чтения, что облегчило бы поиск уязвимостей ,которые могут быть использованы против установленного приложения (скомпилированного или не.)
точка о брандмауэре хороша (даже если это не касается открытого или закрытого программного обеспечения).
b) какие дополнительные пункты я могу добавить к ответу?
основной контраргумент против безопасности через неясность (который был аргументом, приводимым здесь) заключается в том, что с открытым исходным кодом многие люди будут смотреть на источник, чтобы найти и исправить эти проблемы.
так как любой может получить доступ к исходному коду и изменить его.
популярный веб-фреймворк с открытым исходным кодом / CMS / library, скорее всего, будет иметь ужасные ошибки в нем надолго, так как есть много людей, которые смотрят на код, находят ошибки и исправляют их. (Обратите внимание, что для того, чтобы это имело значение, вам нужно будет держать свои вещи в курсе.)
теперь у вашего друга есть крошечный момент - любой, кто может исправить ошибки, может также представить их, если проект управляется кучей идиотов. Если они берут патчи от любого случайного schmuck без просматривая патчи или не зная, что они делают в первую очередь, можно ввести ошибки в структуру. (Это не имеет значения, если вы не обновляете регулярно.) Поэтому важно использовать тот, который прилично поддерживается людьми, у которых есть ключ.
обратите внимание, что все проблемы с фреймворками/приложениями с открытым исходным кодом относятся и к кроваткам. Вы просто не будете знать об ошибках в последнем, пока bugtraq и другие подобные списки не опубликуют их, как любят крупные компании притворитесь, что в их программном обеспечении нет никаких ошибок, пока не придется реагировать.
a) да. Open source не означает открытые двоичные файлы :) предложение "любой может изменить исходный код" просто неверно (вы можете изменить свою копию кода, но не можете редактировать код Apache Struts)
b) возможно, тот факт, что исходный код виден, облегчает кому-то видеть возможные недостатки, которые он может иметь, и использовать их. Но тот же аргумент функционирует иначе: поскольку многие люди просматривают код, недостатки обнаруживаются быстрее, поэтому код более надежен в конец.