Безопасное программирование что это

Разработка вопросов безопасности в проектах: от книги до практики

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

Безопасное программирование — это такой метод, используемый при разработке программного обеспечения, при котором исключается вероятность случайного внедрения уязвимости и обеспечивается устойчивое противостояние вредоносным программам и неразрешенному доступу. Брешь, баг, ошибка — это основные причины возникновения уязвимостей ПО. Из этого получается, что безопасная программа — это программа, при программировании которой использовались меры, направленные на предотвра щение и устран ение уязвимости программы.

Важно ли безопасное программирование

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

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

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

Условно обеспечение безопасности разделяется на 2 части:

И только общее понимание, что и от кого нужно защитить, даст возможность эффективно выбрать меры безопасности.

Эти принципы призваны обобщить все подходы по обеспечению защищенности при разработке программного обеспечения.

Виды уязвимостей и ущерб от них

Самые распространенные ошибки в программировании, которые приводят к уязвимостям в ПО:

Почему мы говорили про «простые ошибки», которые приводят к большим проблемам. Примером такого исхода может послужить ситуация, когда впервые был обнаружен червь Blaster. Его распространением послужила единственная ошибка, которая занимала всего 2 строчки кода.

К примеру, самый известный «сетевой червь» — вирус Морриса, в 1988-м году смог заразить около 6 000 компьютеров. На тот момент это было очень плачевно. Счетная палата США «насчитала» нанесенный ущерб от этого вируса в размере около 90 млн долларов. Уже в наше время «рекордным» по ущербу считается 2016-й год, когда все й экономике мира был нанесен ущерб примерно в 451 млрд долларов. Самым «успешным» в наше время считается вирус WannaCry, который в 2017-м нанес ущерб примерно в 1 млрд долларов США.

Поэтому, как видите, недооценивать безопасное программирование не стоит вообще.

Заключение

Коротко подытожим. Безопасное программирование — это важно. Любая ваша разработка должна касаться вопросов безопасности проекта. Лучше разрабатывать стратегию безопасности в самом начале, перед стартом самого кодинга, чтобы в процессе это все правильно осуществить.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Основы безопасного программирования

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

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

1. Защита конфиденциальной информации в журналах

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

2. Использование проверенных библиотек

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

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

Вот некоторые распространенные инструменты, используемые разработчиками на данный момент:

3. Инъекционные атаки

Наиболее распространенной и самой известной из инъекционных атак является SQL Injection. Базовая SQL инъекционная атака использует входные данные пользователя. Веб-приложения принимают входные данные через формы, которые передают их в базу данных для обработки. Если веб-приложение принимает эти данные без их “санитарной” обработки, злоумышленник может внедрить SQL-операторы через поля формы и удалить, скопировать или изменить содержимое базы данных (cookies и HTTP-заголовки также подходят для этих целей).

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

При добавлении or ‘a’ = ‘a’ в запрос вместе с входными данными человеку становятся доступны все транзакции.

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

Избежать таких атак можно путем использования параметризованных запросов вместо конкатенации по отношению к строковым запросам.

4. Избегайте сериализации

В Java сериализация преобразует объект в поток байтов, который можно сохранить на диске или перенести на другой компьютер. Десериализация же делает обратное, позволяя создавать объекты из потока байтов.

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

Существует несколько советов при использовании процессов сериализации/десериализации, о которых вам следует знать.

5. Изменяемость

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

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

Источник

Правила безопасного программирования на С: прошлое, настоящее и будущее

Luxoft Training предлагает вам познакомиться с переводом статьи «C Secure Coding Rules: Past, Present, and Future» Роберта С. Сикорда, профессора института программной инженерии (SEI) Карнеги-Меллон, автора книг «The CERT® C Coding Standard, Second Edition» и «Secure Coding in C and C++, Second Edition».

Инициатива CERT по безопасному программированию работает над стандартами написания кода с 2006 г. Эксперт программирования Робет С. Сикорд, автор книги «Безопасное программирование на С и С++» рассказывает о своем вкладе в этот проект, о стандарте по безопасному кодированию на языке С (ISO/IEC TS 17961) и рассуждает о будущем этих стандартов.

Разработка ПО по безопасным стандартам кодирования – хорошая практика, а в последнее время и требование. Раздел 933 акта авторизации национальной обороны США (NDAA) от 2013 г. «Совершенствование программного обеспечения, закупаемого Министерством обороны» требует свидетельств того, что организации, разрабатывающие ПО для государственного сектора придерживаются стандартов безопасного кодирования, принятых в Министерстве обороны (DoD), во время разработки, обновления и сопровождения ПО, а также во время инспектирования и оценки.

Руководство по технической реализации систем безопасности (STIG) для приложений и процесса разработки постоянно указывается в качестве требования в запросах на подачу конкурсных предложений (RFPs) Министерства обороны. Раздел 2.1.5, «Стандарты кодирования» STIG требует от Руководителя проекта «контроль того, что команда разработки следует ряду стандартов написания кода».

Однако ряд проблем затрудняет возможность соблюдения этих требований:

Стандарты безопасного кодирования CERT широко применяются в отрасли. На конференции SecCon в октябре 2011 Cisco Systems объявила о принятии стандарта CERT по безопасному кодированию на C в качестве базового стандарта разработки продуктов. Недавно Oracle интегрировала все стандарты безопасного кодирования CERT в свои стандарты безопасности. Это стало еще одним шагом в долгом сотрудничестве CERT и Oracle: обе организации уже работали над разработкой стандартов безопасного кодирования для Java.

Прошлое

Я присоединился к Комитету по стандартизации языка С (официальное название ISO/IEC JTC1/SC22/WG14) во время работы над первым изданием книги «Безопасное программирование на C и C++». В то время WG14 работала над созданием документа «C Library Security TR 24731», который должен был стандартизировать функции «_s», разрабатываемые Microsoft. Я обменялся несколькими сообщениями с Рэнди Мейерсом, который возглавлял J11 (ставшей затем PL22.11), по поводу странного поведения функции gets_s(), которая не считывала знак окончания строки. В итоге, весной 2005 г. я поехал на совещание WG14 в Лиллехаммер (Норвегия) и с тех самых пор CERT связана с Комитетом по стандартизации языка С.

ПРИМЕЧАНИЕ
Рабочая группа PL22.11 отвечает за техническую разработку стандарта для языка программирования С. Это техническая консультативная группа США при ISO/IEC JTC 1 SC22/WG14.

На совещании WG14 весной 2006 г. в Берлине, доктор Томас Плум предложил мне идею создания стандартов безопасного программирования CERT. Единственным аналогом этого на тот момент был MISRA C: Руководство по использованию языка С в критических системах (2004). Однако это руководство предназначалось для тех систем, где безопасность стоит на первом месте, требования к которым существенно отличаются от требований к большинству систем, и препятствовало использованию возможностей языка, одобренных ISO/IEC 9899:1999.

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

Стандарт безопасного кодирования CERT разрабатывался на CERT Secure Coding wiki по принципу коммьюнити-разработки. Эксперты коммьюнити, включая членов Комитета стандартизации С WG14 были приглашены в проект и наделены правами редактирования в вики. Члены коммьюнити могут зарегистрироваться в вики и оставлять комментарии по конкретным стандартам кодирования и отдельным правилам.

Рецензенты, оставлявшие высококачественные комментарии часто получали редакторские привилегии и уже напрямую участвовали в разработке стандартов программирования. На сегодняшний день в вики CERT Secure Coding насчитывается 1374 автора.

Процесс коммьюнити-разработки имеет множество преимуществ. Наиболее важным является то, что он позволяет широкой группе экспертов сформировать единое мнение по содержанию правил. Основным недостатком такого вида разработки стандартов кодирования является то, что содержание стандарта находится в процессе постоянного изменения. Это очень здорово, если вам нужна наиболее актуальная информация, и вы отдаете себе отчет в том, что последнее изменение еще не было окончательно проверено. Однако многие компании по разработке ПО требуют статический набор правил и рекомендаций, которые могут использоваться в качестве требований в их процессах разработки. С этой целью мы создали снимок состояния стандарта через два с половиной года после начала коммьюнити-разработки и выпустили его отдельным изданием, The CERT C Secure Coding Standard (Addison-Wesley, 2008). Книга покрывает версию 1.0 стандарта. С выходом рукописи в июне 2008 года, версия 1.0 (книги) и вики-версия стандарта начали расходится.

Руководство CERT C Secure Coding было впервые рассмотрено группой WG14 на встрече в Лондоне в апреле 2007 года, а затем еще раз в Коне (Гавайи) в августе 2007 года.

Вопрос, стоит ли PL22.11 представить Стандарт CERT по безопасному кодированию на С группе WG14 для публикации в качестве технического отчета 2-го или 3-го типа, обсуждался на встрече J11/U.S. TAG 15 апреля 2008 года, что отражено в протоколе совещания. Было проведено предварительное голосование по вопросу «У кого есть время поработать над этим проектом?», с распределением голосов 4 к 12. Было решено не принимать никаких действий. Позже нам сказали, что, несмотря на то, что Стандарт по безопасному кодированию на С и является серьезным набором рекомендаций, разработанных с помощью многих технических экспертов WG14, сама WG14 не занимается выдачей рекомендаций разработчикам. Однако WG14 определенно занималась разработкой нормативных требований к инструментам, таким как компиляторы.

Вооруженные этим знанием, мы предложили WG14 создать рабочую группу для изучения проблемы создания руководства по безопасному кодированию на языке С. Первая встреча рабочей группы состоялась 27 октября 2009 года. Томас Плум выступил в роли председателя, а я был избран на роль редактора проекта. CERT внесла набор реализуемых правил по безопасному кодированию на С в ISO/IEC для использовании в процессе стандартизации.

Дэвид Китон, действующий председатель PL22.11, впоследствии заменил Тома на его посту. Среди участников группы были поставщики анализаторов, такие как Coverity, Fortify, GammaTech, Gimpel, Klocwork и LDRA; эксперты по безопасности; эксперты по языку и пользователи. Наконец вопрос о разработке и публикации стандарта безопасного кодирования на языке С ISO/IEC TS 17961 был поставлен в план действий на совещании WG14 в марте 2012, и рабочая группа прекратила свою работу. Позже к редакторской коллегии присоединился Роберто Багнара, работавший в Лаборатории прикладных формальных методов Пармского университета и компании BUGSENG.

Настоящее

Цель ISO/IEC TS 17961 – закрепить базовый набор требований для анализаторов, включая средства статического анализа, и поставщиков компиляторов языка С, которые хотели бы проводить диагностику небезопасного кода за пределами стандартов языка С. Все правила реализуются через статический анализ. Критерием для выбора правил является то, что анализаторы, реализующие эти правила, должны эффективно распознавать ошибки в безопасности кода без генерации избыточного числа ложных результатов.

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

Стандарт ISO/IEC TS 17961 предписывает правила безопасного кодирования на языке С и приводит примеры кода. Стандарт не описывает механизм применения этих правил или конкретного стиля кодирования. Каждое правило сопровождается примерами кода. Примеры плохого кода демонстрируют языковые конструкции, обладающие потенциальными изъянами безопасности; такие примеры кода должны вылавливаться стандартизированными анализаторами. Примеры образцового кода не должны вылавливаться анализаторами.

В следующей таблице показана связь ISO/IEC TS 17961 с другими стандартами. Из всех перечисленных публикаций, только ISO/IEC TS 17961 предназначен для анализаторов, а не разработчиков.

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

ISO/IEC TS 17961 не требует от анализатора выдавать диагностику для ошибок в синтаксисе или для ограничений Стандарта на язык С. Речь идет только об исходном коде, который может быть прочитан анализатором. На бинарные библиотеки и обращения к ним данные правила не распространяются.

Интересный аспект технической спецификации – переносимость допущений, известная также под именем «Правило Сан-Франциско», поскольку эти допущения были сформулированы на встрече, организованной компанией Coverity в их главном офисе. «Правило Сан-Франциско» гласит, что отвечающий стандарту анализатор должен распознавать случаи нарушения предписаний по крайней мере для одной реализации С, но не обязан распознавать нарушения правила, если результат документируется для конечной реализации и не создаёт изъянов в безопасности. Различия в качестве реализации позволяют анализатору выдавать диагностику для проблем переносимости. Например, для следующего фрагмента программы:

ISO/IEC TS 17961:2013(E) «Информационные технологии. Языки программирования, их окружение и системы программных интерфейсов. Правила безопасного кодирования C» был официально опубликован в ноябре 2013 и доступен для покупки в магазине стандартов ISO.

Помимо прочего, книга The CERT®C Coding Standard, Second Edition была исправлена для соответствия с ISO/IEC TS 17961. Хотя эти документы предназначены для разных аудиторий, согласованность между документами должна помочь разработчикам использовать анализаторы, отвечающие ISO/IEC TS 17961, вылавливать нарушения правил данного стандарта кодирования.

CERT также разработала Secure Coding Validation Suite, набор тестов для валидации правил, установленных ISO/IEC TS 17961. Эти тесты основаны на примерах данной технической спецификации и распространяются по лицензии BSD.

Будущее

Разработчики статических анализаторов работают над созданием анализаторов, отвечающих требованиям ISO/IEC TS 17961. Пока ведутся эти работы, мы будет продолжать оценивать эффективность технической спецификации и попытаемся понять: нужно ли подготовить вторую редакцию, которая либо устранит недостатки опубликованной версии, либо пополнится новыми правилами, например, касательно нестандартного поведения, связанного с использованием функций многопоточности, представленных в версии C11.

Поскольку язык С и наши знания о его безопасном использовании постоянно развиваются, SEI продолжит коммьюнити-разработку SEI CERT C Coding Standard в вики по безопасному кодированию. Эти изменения позднее могут быть включены в будущий официальный релиз этого стандарта. Новая версия будет отправлена в Addison-Wiley для публикации.

Благодарность

Выражаю признательность рецензентам, которые сыграли большую роль в этой истории: Дэвиду Китону, Томасу Плуму, и Джону Бенито.

Published with permission from Pearson Education.

26 и 27 ноября Luxoft Training приглашает вас на мастер-класс Роберта С. Сикорда, посвященный безопасному программированию на языках С и С++.

Источник

Искусство оборонительного программирования

Почему разработчики не могут написать безопасный код? Мы не говорим здесь очередной раз про «чистый код». Мы говорим о большем с чисто практической точки зрения — о надёжности и безопасности программного обеспечения. Да, потому что небезопасное программное обеспечение в значительной степени бесполезно. Посмотрим, что значит «небезопасное» программное обеспечение:

Первое знакомство с защитным программированием (проектирование самотестирующих и самокорректирующих программ)

Защищайтесь от невозможного, потому что произойдёт именно оно.

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

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

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

Никогда не доверяйте входным данным от пользователя

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

Лучшая защита — это нападение

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

Лучшая защита — это нападение. Будьте строгими.

Используйте абстрактное представление баз данных

Первой из топ-10 уязвимостей ПО согласно OWASP являются инъекции. Это означает, что кто-то (или много людей) ещё не использует безопасные инструменты для обращения к своим базам данных. Используйте пакеты и библиотеки абстрактного представления баз данных. В языке PHP можно использовать PDO (переносимый распределённый объект), чтобы обеспечить базовую защиту от инъекций.

Не изобретайте велосипед

Вы не используете фреймворк (или микрофреймворк)? Ну, значит, вам нравится делать дополнительную работу без какой-либо нужды, поздравляем! Это относится не только к фреймворкам, но и ко многим другим новым возможностям, где можно легко использовать то, что уже сделано, хорошо протестировано, чему доверяют тысячи разработчиков и что стабильно работает; не стоит здесь заниматься демонстрацией своего мастерства только из любви к оному. Единственной причиной сделать что-либо самому является необходимость получить нечто, чего не существует или что существует, но не отвечает вашим требованиям (плохие рабочие параметры, отсутствующие характеристики и т.п.).

Именно это называют разумным многократным использованием кода. Пользуйтесь этой возможностью.

Не доверяйте разработчикам

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

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

Пишите НАДЁЖНЫЙ код

Это трудное дело для (защитного) программиста — написать надлежащий код. Об этом многие знают и говорят, но в действительности мало кто заботится или уделяет достаточные внимание и усилия для того, чтобы получить НАДЁЖНЫЙ код.

Рассмотрим несколько примеров ненадлежащего подхода.

Не делайте так: неинициализированные свойства

В этом случае необходимо помнить, что для проведения платежа следует вызвать сначала setCurrency. Это, действительно, плохой подход — операцию изменения состояния, такую как указанная (проведение платежа), не следует осуществлять в два этапа с использованием двух (или более) публичных методов. Можно иметь много методов проведения платежа, но мы обязаны иметь только один простой публичный метод для изменения статуса (категорически недопустимо нахождение объектов в неопределённом состоянии).

В этом случае мы сделали ещё лучше, инкапсулируя неинициализированное свойство в объект Money:

Защитите программу от неправильного обращения. Не используйте неинициализированные свойства объекта.

Не делайте так: дающее утечку состояние за пределами области действия класса

В этом случае Message (Сообщение) передаётся по ссылке, и результат будет в обоих случаях «joe message» («сообщение Джо»). Решением могло бы быть клонирование объекта сообщения в конструкторе Mailer. Но что мы всегда должны стараться сделать, так это использовать (неизменяемый) объект-значение вместо простого изменяемого объекта Message. Используйте неизменяемые объекты, когда вы можете.

Пишите тесты

Неужели об этом ещё надо говорить? Написание модульных тестов поможет вам выдерживать общие принципы, такие как сильная связность, персональная ответственность, слабое связывание и правильная композиция объектов. Это поможет тестировать не только работающий отдельный небольшой модуль, но и способ структурирования ваших объектов. Действительно, вы будете ясно видеть, тестируя ваши небольшие функции, сколько модулей надо протестировать и сколько объектов надо сымитировать, чтобы получить 100% покрытие тестами кода.

Выводы

Надеюсь, вам понравилась статья. Помните, что здесь — только предложения. Вам решать, когда и где их применять и применять ли вообще.

Источник