Вы активно думаете о безопасности при кодировании?

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

Вроде. Отказ от ответственности: я парень безопасности;)

Таким образом, я работаю так, что у меня есть модель угрозы, которая описывает, какого рода атаки возможны. Это помогает выработать требования безопасности. Когда я на самом деле кодирую, я выполняю обычные практики «безопасного кодирования», например, следя за тем, чтобы переменные курсора всегда были в пределах границ, испорченный ввод очищался, условия ошибок обрабатывались. Затем я возвращаюсь к своей модели угроз, чтобы увидеть, какие модули наиболее вероятно будут выбраны злоумышленниками; те получают дополнительный обзор.

Я использую стандартные отраслевые практики, такие как использование параметров SQL. Я использую «безопасные» платформы, такие как .NET Framework, и пользуюсь такими функциями безопасности, как токены защиты от подделки в ASP.NET MVC. Я не пишу свои собственные алгоритмы шифрования, но я понимаю, что эти шифры обеспечивают с точки зрения безопасности, и когда мне нужно использовать их для получения этих преимуществ безопасности.

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

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

Я проверяю пользовательский ввод как на клиенте, так и на сервере.

Абсолютно.

Безопасность это все. И с числовым программным обеспечением это идет дважды.
Буквально на днях пользователю удалось найти и использовать ошибку в одной из моих старых программ. Ущерб был непоправимым. См. ниже:

Раньше было круглым.

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

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

Я не эксперт по безопасности, но когда я пишу веб-приложения, я всегда предполагаю, что пользовательский ввод может содержать все виды странностей и всегда должен быть полностью экранирован и тому подобное. Кроме того, я стараюсь, чтобы Ajax перезванивал на сервер, чтобы убедиться, что пользователь вошел в систему (если они должны быть для этого конкретного события) и что у него есть разрешения на выполнение того, что он пытается сделать.

Кодовая база имеет набор фильтров для входов. Я никогда не проверяю PHP $_GETили $_POSTмассивы напрямую. Вместо этого я запрашиваю их с помощью функции Request::get('parameter', 'filter')с фильтрами , такими как int, textи некоторыми другими. (И Request::post()для входов POST, конечно.)

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

Да. Безопасность важна и не должна быть второстепенной; добавить безопасность после факта, как правило, сложнее, чем сначала встроить ее в приложение, и если вы добавите ее позже, вы, вероятно, пропустите некоторые вещи (или просто не будете добавлять ее вообще).

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

Затем прочитайте несколько хороших книг по стратегии проектирования и тестирования, и вы узнаете, как встроить тестируемость в вашу архитектуру.

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

Это влияет на дизайн. Файлы конфигурации могут иметь зашифрованные разделы ключей или отдельные поля могут быть в виде открытого текста со связанным полем подписи. С услугами, связанными с Интернетом, все становится сложнее, так как следует ожидать большей враждебности.

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

Да.

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

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

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

Как разработчик, вы можете получить определенное преимущество, если у вас есть опыт в этой области - я специально думаю о банках и финансовых услугах, но другие отрасли также применимы. В настоящее время они могут выделить 70-100 тыс. Человек на подготовку нового выпускника, который будет обучен быстрому изучению процессов, безопасности и других особенностей этой организации. Если вы можете сэкономить им 30 тыс., Это хороший плюс для резюме!

В Великобритании, Институт специалистов по информационной безопасности и в Шотландии Центр передового опыта в области безопасности и киберпреступности тесно сотрудничает с университетами, чтобы помочь в рассмотрении материалов курса, проведении гостевых лекций о реальных последствиях плохого кодирования и организации летних размещений (например, Разработчики программного обеспечения помещены в отделы по борьбе с мошенничеством в правоохранительных органах.) Большинство организаций поддержки делают это бесплатно, поскольку это может сэкономить им большую сумму денег - звучит для меня как ценность.

(отказ от ответственности - я был парнем по безопасности для различных глобальных организаций)