Открыть главное меню

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

Безопасное программное обеспечение — программное обеспечение, разработанное с использованием совокупности мер, направленных на предотвращение появления и устранение уязвимостей программы[1].

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

Содержание

ТерминологияПравить

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

Defensive programming (Оборонительное, защитное, безопасное программирование) — принцип разработки ПО, при котором разработчики пытаются учесть все возможные ошибки и сбои, максимально изолировать их и при возможности восстановить работоспособность программы в случае неполадок. Это должно делать программное обеспечение более стабильным и менее уязвимым. Например, аппаратной реализацией данного принципа является сторожевой таймер, вычисление контрольной суммы — для выявление ошибок при пакетной передаче данных[3].

Secure coding (Безопасное программирование) — методика написания программ, устойчивых к атакам со стороны вредоносных программ и злоумышленников. Безопасное программирование помогает защитить данные пользователя от кражи или порчи. Кроме того, небезопасная программа может предоставить злоумышленнику доступ к управлению сервером или компьютером пользователя; последствия могут быть различны: от отказа в обслуживании одному пользователю до компроментации секретной информации, потери обслуживания или повреждения систем тысяч пользователей[2].

ВажностьПравить

Вопросы обеспечения безопасности и работоспособности системы являются неотъемлемой частью этапа её проектирования (дизайна системы (англ.))[4]. Требования к безопасности конкретных продуктов и систем ИТ устанавливаются исходя из имеющихся и прогнозируемых угроз безопасности, проводимой политики безопасности, а также с учётом условий их применения[5]. Внедрение решений для обеспечения безопасности после того, как система уже разработана, является сложной и дорогостоящей процедурой. Поэтому следует с самого начала учитывать требования к безопасности на протяжении всего жизненного цикла системы[4].

Информационная система разделяется на физический и логический уровень. Понимание того, что именно должно быть защищено от внешних факторов, помогает с наиболее эффективным выбором и применением защитных мер. Чёткая граница между уровнями должна определяться политикой безопасности, регулирующей определённый набор информации и информационных технологий, имеющий физические границы. Дальнейшее усложнение заключается в том, что на одном компьютере или сервере может размещаться как общедоступная, так и конфиденциальная информация. В результате несколько политик безопасности могут применяться к одной машине или в пределах одной системы. Поэтому при разработке информационной системы границы безопасности должны учитываться и описываться в соответствующей документации и политиках безопасности системы[4]. Её разработчики должны уметь обеспечить безопасность системы при проектировании, разработке, управлении и конфигурировании, интеграции (англ.), правильно провести тестирование[6].

Анализ (ручной или автоматический) и обеспечение безопасности — дорогостоящая процедура, увеличивающая общую стоимость программного продукта. Ранее полное устранение рисков было общей целью обеспечения безопасности. Сегодня признаётся, что устранение всех рисков не является экономически эффективным. Для каждой предлагаемой системы контроля следует провести анализ затрат и выгод. В некоторых случаях преимущества более безопасной системы могут не оправдывать прямых и косвенных издержек. Выгоды включают не только предотвращение денежных потерь; стоит учитывать, например, и репутационные потери. Прямые расходы включают расходы на приобретение и установку данной технологии; косвенные расходы включают снижение производительности системы и дополнительное обучение сотрудников[7].

ПринципыПравить

В настоящее время существуют разнообразные технологии разработки безопасного ПО. Но есть набор принципов, учитываемых при любом подходе[8]:

  • работоспособность и полезность (юзабилити, англ. usability);
  • безопасность (англ. security) — возможность защиты от внешних угроз, атак и сохранение работоспособности после их отражения и устранения;
  • надежность (англ. reliability) — предсказуемое, корректное и безотказное поведение в случае некорректных исходных данных;
  • конфиденциальность (англ. privacy) — обеспечение безопасной и корректной работы с конфиденциальной информацией;
  • обеспечение целостности и корректности бизнеса (англ. business integrity) — чёткая организация сопровождения программы, контроль прозрачности, законности, корректности работы пользователя.

Четыре последних качества стали основой Trustworthy computing (TwC) (англ. Trustworthy computing) («Вычисления, заслуживающие доверия») — инициативы корпорации Microsoft, главная задача которой — обратить внимание разработчиков на важность обеспечения указанных требования на каждом из этапов разработки ПО[9].

Существует множество принципов обеспечения безопасности ПО, большей частью похожих друг на друга. Их обобщением можно считать приведённые выше принципы[10].

Классификация и виды уязвимостейПравить

КлассификаторыПравить

Использование стандартизованных описаний уязвимостей упрощает работу специалистов по информационной безопасности. В настоящее время существует несколько популярных классификаторов[11]:

  • CVE (Common Vulnerabilities and Exposures) — словарь конкретных уязвимостей конкретных продуктов;
  • CWE (англ.) (Common Weakness Enumeration) — база данных типов уязвимостей. Основная задача проекта — предоставить описания распространённых видов уязвимостей, способы их предотвращения, обнаружения и исправления;
  • SecurityFocus BID (англ.);
  • OSVDB (англ.) (Open Sourced Vulnerability Database) — «открытая база данных уязвимостей», созданная тремя некоммерческими организациями. Прекратила работу 5 апреля 2016 года. Блог продолжает работать[12];
  • Secunia — лента уязвимостей известной датской компании Secunia в области компьютерной и сетевой безопасности;
  • IBM ISS X-Force.

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

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

МетрикиПравить

Каждая программа является потенциальной целью для злоумышленников. После нахождения уязвимостей в приложениях или сервисах они будут пытаться использовать их для кражи конфиденциальной информации, порчи данных, управления компьютерными системами и сетями[15]. Для описания свойств уязвимости специалистами используется система подсчёта рисков уязвимостей CVSS (англ.). Она представляет собой шкалы, на основе которых выставляются баллы. Система метрик разработана для разделения приоритетов над исправлением уязвимостей. Каждая шкала относится к определённому смысловому разделу, который называется метрикой. Таких метрик три[16][17][11]:

  • Базовая (англ. base) — характеристики уязвимости, не зависящие от времени и среды исполнения. Служит для описания сложности эксплуатации уязвимости, потенциального ущерба для конфиденциальности, целостности и доступности информации;
  • Временная (англ. temporal) — метрика, учитывающая временной фактор, например, время на исправление уязвимости;
  • Контекстная (англ. environmental) — метрика, учитывающая информацию о среде функционирования программного обеспечения.

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

Виды уязвимостейПравить

Список распространённых ошибок, ставящих под угрозу безопасность современных программ[19]:

Перечислить все известные уязвимости невозможно, учитывая, что каждый день появляются новые. В данном списке приведены часто встречающиеся уязвимости, допустить которые легко, но последствия которых могут быть катастрофическими. Например, причиной распространения червя Blaster стала ошибка всего в двух строках кода[22].

ЗащитаПравить

Правильной стратегией защиты от ошибок и уязвимостей является их предупреждение и предотвращение. Это требует от разработчика постоянной проверки входных данных. Например, лучший способ защиты от атак переполнения буфера — проверка того, что входные данные не превышают размера буфера, в котором они сохраняются. Данные, предназначенные для отправки в БД требуют проверки для защиты от атаки типа внедрения SQL-кода. Если данные отправляются на web-страницу, то следует их проверять для защиты от XSS. Однако, избыточное число проверок усложняет разработку исходного кода программы и может привести, в свою очередь, к появлению новых ошибок, поэтому следует комбинировать данную стратегию с другими[23].

Механизмы для защиты от ошибок может предоставлять компилятор или операционная система. Компилятор GCC позволяет с помощью функции _builtin_object_size() получать размер объекта по указателю на этот объект, так что её использование делает процедуру копирования безопаснее. MSVC при использовании флага /RTCs позволяет на этапе компиляции проверить переполнения локальных переменных, использование неинициализированных переменных, повреждение указателя стека, вызванное несоответствием соглашений о вызовах. Использование технологии CRED (C range error detector) и специальных вставок перед защищаемым разделом стека (StackGuard, SSP) частично позволяет обнаруживать и предотвращать атаки, связанные с выходом за границы массива и разрушением стека[24].

Операционная система также может контролировать процесс исполнения программы. Данная стратегия может быть полезной в случае, если исходный код данной программы неизвестен. Технология ASLR (рандомизация схемы адресного пространства) является функцией безопасности операционных систем, предназначенной для предотвращения запуска произвольного кода. В настоящее время ASLR поддерживается и в Linux, и в Windows. Повышение уровня безопасности достигается применением технологий неисполнимых стеков (англ.): W^X (англ.), PaX[24].

Типовыми атаками на web-сервисы являются внедрение SQL-кода, XSS, CSRF, clickjacking. Современные фреймворки помогают разработчикам в создании безопасных web-приложений. Использование готовых решений позволяет не заниматься многочисленными проверками входящих данных: от заголовков HTTP-запросов до их содержания. Также предоставляется более безопасный метод работы с БД — ORM[25][26].

УщербПравить

Информация об уязвимостях может быть использована злоумышленниками при написании вирусов. Например, один из первых известных сетевых червей (вирус Морриса) в 1988 году использовал такие уязвимости как переполнение буфера в Unix-демоне finger для распространения между машинами. Тогда количество заражённых машин составило порядка 6 тысяч [27], а экономический ущерб по данным счётной палаты США составил от 10 до 100 млн долларов[28].

В 2016 компьютерные вирусы причинили мировой экономике ущерб в 450 млрд долларов[29][30].

В 2017 ущерб от вируса WannaCry оценили в 1 млрд долларов. Случаи заражения были зафиксированы по меньшей мере в 150 странах[31][32][33]. Вирус применял эксплойт EternalBlue, использующий уязвимость в протоколе SMB, связанную с переполнением буфера[34][35][36][37].

ПримечанияПравить

  1. ГОСТ Р 56939-2016, 2016, Термины и определения, pp. 2.
  2. 1 2 Introduction to Secure Coding Guide.
  3. Defensive Programming.
  4. 1 2 3 Engineering Principles for Information Technology Security, 2004, Security Foundations.Principle 2, pp. 7.
  5. Критерии оценки безопасности информационных технологий, 2002, Общие положения, pp. III—IV.
  6. Engineering Principles for Information Technology Security, 2004, Security Foundations, pp. 6—8.
  7. Engineering Principles for Information Technology Security, 2004, Security Foundations. Principle 5, pp. 8.
  8. Современные технологии разработки надежных и безопасных программ, 2008, pp. 25—26.
  9. Современные технологии разработки надежных и безопасных программ, 2008, pp. 26.
  10. Secure Programming HOWTO - Creating Secure Software, 2015, Security Principles, pp. 7—8.
  11. 1 2 Журнал Хакер: Меряем уязвимости, 2009, pp. 48—51.
  12. OSVDB: FIN, 2016.
  13. Журнал Хакер: Меряем уязвимости, 2009, Использование классификаторов в сканерах, pp. 51: «Современные автоматизированные аудиторы принято затачивать под какую-либо конкретную базу знаний. Во-первых, это престижно, во-вторых — полезно. К примеру, при подготовке к аттестации по одному из современных стандартов (NERC-CIP, PCI, FISMA, GLBA или HIPAA) администратору предоставляется возможность получить шаблонный отчет, соответствующий документу, издаваемому аудитором.».
  14. Журнал Хакер: Меряем уязвимости, 2009, Отдельные классификации, pp. 51: «Подчас в Сети можно заметить абсолютно самопальные классификации... Естественно, большого веса такая система не имеет, потому что составляться она должна реальными экспертами, которые понимают суть проблемы».
  15. Introduction to Secure Coding Guide, At a Glance.
  16. Common Vulnerability Scoring System, 2006, p.86.
  17. CVSS:Specification.
  18. CVSS:Specification, 1.2. Scoring: «Базовая метрика может быть уточнена путем подсчета временной и контекстной метрик, чтобы точнее отражать риск, вызванный уязвимостью, для пользователя».
  19. 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them, 2009, Inroduction.
  20. Метод поиска уязвимости форматной строки, 2015, Введение: «Еще в работах 90-х годов было показано, что неправильная работа с форматной строкой может привести к серьезным уязвимостям в безопасности ПО, таким как выполнение произвольного кода, повышение привилегий, а также утечка чувствительных данных.».
  21. The Protection of Information in Computer Systems, 1975, h) Psychological acceptability: «Очень важно, чтобы пользовательский интерфейс был удобным в использовани, чтобы пользователи интуитивно и просто применяли механизмы защиты правильным образом. Если мысленые представления пользователя о целях защиты соответствуют тем механизмам, которые он использует на практике, количество ошибок будет сведено к минимуму. Если же пользователь должен переводить свои представления о защите на совершенно иной язык специфи каций, он неизбежно будет совершать ошибки.».
  22. Secure Coding in C and C++, 2013, Figure 1.2. Flawed logic exploited by the W32.Blaster.Worm: «Недостатки логики, использованные червем W32.Blaster.Worm, показаны на рис. 1.2. Ошибка заключается в том, что цикл while в строках 21 и 22 (используемый для выделения имени узла из длинной строки) недостаточно ограничен.».
  23. Secure Coding in C and C++, 2013, 2.6 Runtime Protection Strategies:Input Validation.
  24. 1 2 Secure Coding in C and C++, 2013, 2.6 Runtime Protection Strategies.
  25. Django Security.
  26. Ruby on Rails Security.
  27. Записки исследователя компьютерных вирусов, 2005, Таблица 3.1, p. 90.
  28. Malware History, 2010, The NSA versus Morris: $100 Million in Damage, p. 23.
  29. CNBC International: Cybercrime costs the global economy $450 billion.
  30. The New Paper: Cybercrime cost world economy $620 billion last year.
  31. РБК: Ущерб от вируса WannaCry оценили в $1 млрд.
  32. 6abs: The damage from the virus WannaCry exceeded $ 1 billion.
  33. Hi-Tech Mail.ru: Эксперты назвали рекордную сумму ущерба от вируса WannaCry.
  34. MS17-010: EternalBlue’s Large Non-Paged Pool Overflow in SRV Driver.
  35. WannaCry ransomware used in widespread attacks all over the world.
  36. CNews: Экономический ущерб от вирусов.
  37. Net Losses: Estimating the Global Cost of Cybercrime.

ЛитератураПравить

Дополнительная литератураПравить

СсылкиПравить