Использование встроенных функций
Я разрабатываю приложение Windows Form на C#. Я слышал, что не следует использовать встроенные методы и функции в коде, так как хакеры глубоко разбираются в таких встроенных методах и знают, как их потерпеть неудачу. Вместо этого всегда нужно использовать свои собственные функций и методов, а если нет, то разумно вызывайте встроенные функции из этих вновь созданных функций. Насколько это верно?
Поддерживающий пример в пользу моего аргумента состоит в том, что я видел, как разработчик всегда разрабатывал собственный алгоритм шифрования, такой как AES,DES,RC4 и хэш-функции, поскольку они считают, что встроенный алгоритм шифрования во многих случаях имеет бэкдор.
2 ответа
Какие?! Нет нет нет! Кто бы ни сказал вам, это просто неправильно.
Существует распространенное заблуждение, что опубликованный исходный код более уязвим для "h4ckerz", потому что он доступен любому, кто обнаружит недостатки. Тем не менее, я рад, что вы упомянули крипто, потому что это область, в которой действительно стоит эта линия рассуждений. как заблуждение это так.
Один из самых популярных вопросов всех времен на https://security.stackexchange.com/ касается разработчика (в ОП ему был дан псевдоним "Дейв"), который разделял этот страх перед опубликованным кодом. Дейв, как и разработчик, которого вы видели, пытался создать собственный алгоритм шифрования. Вот один из самых популярных комментариев в этой теме:
У Дейва есть фундаментально ложная предпосылка, что безопасность алгоритма зависит (даже частично) от его неясности - это не так. Безопасность алгоритма хеширования зависит от того, насколько мы понимаем математику и, в меньшей степени, от аппаратной способности перебирать ее. Когда Дейв принимает эту реальность (а это действительно реальность, прочитайте статью о хешировании в Википедии), возникает вопрос, кто умнее - Дэйв сам по себе или большая группа специалистов, посвященных этой конкретной проблеме. (выделение добавлено)
Фактически, в нынешнем виде два верхних мема на Security.SE - это "Не катайся сам" и "Не будь Дейвом".
Хотя все это касалось криптографии, в целом это относится к большинству программного обеспечения с открытым исходным кодом. Вероятность того, что бэкдор будет найден и исправлен, возрастает с каждым новым взглядом на код. Это должна быть простая и неоспоримая предпосылка: чем больше людей ищут что-то, тем выше вероятность того, что это будет найдено. Да, это относится к злоумышленникам, которые ищут эксплойты. Тем не менее, это также относится к опытным пользователям, хакерам белых шапок, исследователям безопасности, криптографам, профессиональным разработчикам и другим, работающим на "добро", которое, как правило (как мы надеемся), превосходит число тех, кто работает на "зло". Это также косвенно основывается на ложной предпосылке, что хакерам нужно видеть исходный код, чтобы совершать плохие поступки. Очевидно, это должно быть ложным, исходя из огромного количества проприетарных систем, исходный код которыхникогда не публиковался (на ум приходят различные программы Microsoft и Adobe), которые годами были подвержены уязвимостям. Возможно, наличие исходного кода для чтения облегчает работу хакера, но, возможно, нет - проще ли анализировать исходный код в поисках вектора атаки или просто использовать инструменты сканирования и сценарии для скомпилированного двоичного файла?
tl; dr Не будь Дейвом. Роллинг сам по себе означает, что вы должны быть лучшими вовсем, чтобы добиться успеха, вместо того, чтобы брать выборку из лучших, которые может предложить сообщество.
Heartbleed
В своем комментарии вы опровергаете:
Тогда почему ошибка Heartbleed в openSSL не была найдена и исправлена [ранее]?
Потому что никто не смотрел на это. Это грустная правда. Вот разница - что случилось, когда кто-то нашел это? Сейчас десятки тысяч исследователей безопасности, криптоэкспертов и других смотрят на это. Предположим, что такая же уязвимость существовала в одном из проприетарных продуктов, о которых я упоминал ранее, что вполне возможно. Как только он пойман (если он пойман), спросите себя:
- Может ли команда программистов ответственной компании воспользоваться помощью всего мирового сообщества экспертов по безопасности, криптографов и других аналитиков прямо сейчас?
- Если бы в вашем программном обеспечении была обнаружена такая критическая ошибка (и это большая проблема!), Будете ли вы готовы справиться с последствиями, вызванными вашей пользовательской реализацией?
Если вы не знаете о конкретных режимах сбоев или слабостях встроенных методов, которые ваше приложение будет использовать, и не знаете, как их минимизировать или устранить, то, вероятно, лучше использовать методы, предоставляемые разработчиками языка или библиотеки, которые часто будут более эффективнее и безопаснее, чем то, что средний программист придумал бы на лету для конкретного проекта.
Ваш пример абсолютно не поддерживает вашу точку зрения: разработка собственного алгоритма шифрования без какого-либо серьезного опыта в данной области и проверка криптоаналитиками, а затем использование его в критически важном коде безопасности - это путь к катастрофе. Даже разработка собственной пользовательской реализации стандартного алгоритма шифрования может вызвать проблемы, и почти наверняка возникнет, если вы не имеете опыта в этом.