Interested Article - Безопасное программирование

amity
  • 2021-02-01
  • 1

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

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

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

Терминология

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

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

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

Важность

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

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

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

Принципы

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

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

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

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

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

Классификаторы

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

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

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

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

Метрики

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

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

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

Виды уязвимостей

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

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

Защита

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

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

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

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

Ущерб

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

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

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

Примечания

  1. , Термины и определения, pp. 2.
  2. ↑ .
  3. .
  4. ↑ , Security Foundations.Principle 2, pp. 7.
  5. , Общие положения, pp. III—IV.
  6. , Security Foundations, pp. 6—8.
  7. , Security Foundations. Principle 5, pp. 8.
  8. , pp. 25—26.
  9. , pp. 26.
  10. , Security Principles, pp. 7—8.
  11. ↑ , pp. 48—51.
  12. .
  13. , Использование классификаторов в сканерах, pp. 51: «Современные автоматизированные аудиторы принято затачивать под какую-либо конкретную базу знаний. Во-первых, это престижно, во-вторых — полезно. К примеру, при подготовке к аттестации по одному из современных стандартов (NERC-CIP, PCI , FISMA, GLBA или HIPAA) администратору предоставляется возможность получить шаблонный отчет, соответствующий документу, издаваемому аудитором.».
  14. , Отдельные классификации, pp. 51: «Подчас в Сети можно заметить абсолютно самопальные классификации... Естественно, большого веса такая система не имеет, потому что составляться она должна реальными экспертами, которые понимают суть проблемы».
  15. , At a Glance.
  16. , p.86.
  17. .
  18. , 1.2. Scoring: «Базовая метрика может быть уточнена путем подсчета временной и контекстной метрик, чтобы точнее отражать риск, вызванный уязвимостью, для пользователя».
  19. , Inroduction.
  20. , Введение: «Еще в работах 90-х годов было показано, что неправильная работа с форматной строкой может привести к серьезным уязвимостям в безопасности ПО, таким как выполнение произвольного кода, повышение привилегий, а также утечка чувствительных данных.».
  21. , h) Psychological acceptability: «Очень важно, чтобы пользовательский интерфейс был удобным в использовании, чтобы пользователи интуитивно и просто применяли механизмы защиты правильным образом. Если мысленные представления пользователя о целях защиты соответствуют тем механизмам, которые он использует на практике, количество ошибок будет сведено к минимуму. Если же пользователь должен переводить свои представления о защите на совершенно иной язык спецификаций, он неизбежно будет совершать ошибки.».
  22. , Figure 1.2. Flawed logic exploited by the W32.Blaster.Worm: «Недостатки логики, использованные червём W32.Blaster.Worm, показаны на рис. 1.2. Ошибка заключается в том, что цикл while в строках 21 и 22 (используемый для выделения имени узла из длинной строки) недостаточно ограничен.».
  23. , 2.6 Runtime Protection Strategies:Input Validation.
  24. ↑ , 2.6 Runtime Protection Strategies.
  25. .
  26. .
  27. , Таблица 3.1, p. 90.
  28. , The NSA versus Morris: $100 Million in Damage, p. 23.
  29. .
  30. .
  31. .
  32. .
  33. .
  34. .
  35. .
  36. .
  37. .

Литература

  • Касперски К. . — Питер, 2005. — P. 93, 103—104, 117—122. — 316 p. — ISBN 5469003310 .
  • / Федеральное агентство по техническому регулированию и метрологии. — Стандартинформ, 2016. — 24 p.
  • / Федеральное агентство по техническому регулирванию и метрологии. — Стандартинформ, 2015. — 36 p.
  • Гостехкомиссия России . . — 2002. — P. III—IV. — 48 p.
  • : Исследование / Лаборатория Касперского. — 2014. — P. 14.
  • Комаров А. // Хакер : Журнал. — 2009. — № 04 (124) . — P. 48—51.
  • Сафонов В. О. // Компьютерные инструменты в образовании : Журнал. — 2008. — № 06 . — P. 25—33.
  • Вахрушев И.А., Каушан В.В., Падарян В.А., Федотов А.Н. // Труды ИСП РАН. — 2015. — Т. 27 , № 4 . — С. 23—38 . — P. 25—33.
  • Howard M., LeBlanc D., Viega J. (англ.) . — McGraw Hill Professional, 2009. — 464 p. — ISBN 9780071626767 .
  • Seacord R. C. (англ.) . — 2. — Addison-Wesley, 2013. — 600 p. — ISBN 9780132981972 .
  • Stoneburner G., Hayden C., Feringa A. (англ.) / National Institute of Standards and Technology . — Revision A. — 2004. — 33 p.
  • Wheeler D. A.. (англ.) . — 2015. — 186 p.
  • (англ.) / BitDefender . — 2010. — P. 23—24. — 71 p.
  • Howard M., LeBlanc D. (англ.) . — 2. — Microsoft Press, 2002. — P. 43. — 512 p. — ISBN 9780735615885 .
  • Saltzer J.H., Schroeder M.D.. (англ.) : article / Saltzer J. H.. — 1975.
  • Mell P., Scarfone K., Romanosky S. (англ.) // IEEE Security & Privacy : article. — 2006. — Vol. 4. — P. 85—89. — ISSN .
  • (англ.) . . McAfee (2014). Дата обращения: 23 октября 2017. Архивировано из 24 октября 2017 года.

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

  • Seacord R. C. (англ.) . — 2008. — P. Pearson Education. — 720 p. — ISBN 9780132702461 .
  • Long F. (англ.) / Carnegie-Mellon University. CERT Coordination Center. — Addison-Wesley Professional, 2012. — 699 p. — ISBN 9780321803955 .

Ссылки

  • Бондаренко, Мария (2017-05-25). . Москва: РБК . Дата обращения: 23 октября 2017 . {{ cite news }} : Указан более чем один параметр |author= and |last= ( справка )
  • Матюхин, Григорий (2017-05-25). . Москва: Hi-Tech Mail.ru . Дата обращения: 23 октября 2017 . {{ cite news }} : Указан более чем один параметр |author= and |last= ( справка )
  • Боровко, Роман (2003). . Москва: CNews Analytics . Дата обращения: 23 октября 2017 . {{ cite news }} : Указан более чем один параметр |author= and |last= ( справка )
  • (англ.) . . Apple Inc. . Дата обращения: 23 октября 2017.
  • Django Software Foundation . (англ.) . . Дата обращения: 5 декабря 2017.
  • (англ.) . . Дата обращения: 5 декабря 2017.
  • Graham, Luke (2017-02-07). (англ.) . US: CNBC International . Дата обращения: 23 октября 2017 . {{ cite news }} : Указан более чем один параметр |author= and |last= ( справка )
  • Sun, David (2017-07-05). (PDF) (англ.) . Singapore: The New Paper . Дата обращения: 23 октября 2017 . {{ cite news }} : Указан более чем один параметр |author= and |last= ( справка )
  • (англ.) . US: 6abc. 2017-05-25. из оригинала 15 октября 2017 . Дата обращения: 23 октября 2017 .
  • William Gamazo Sanchez (Vulnerability Research). (англ.) . . Trend Micro (2 июня 2017). Дата обращения: 23 октября 2017.
  • (англ.) . . ЗАО «Лаборатория Касперского» (12 мая 2017). Дата обращения: 23 октября 2017.
  • M. Tim Jones. (англ.) (1 февраля 2005). Дата обращения: 12 ноября 2017. Архивировано из 13 ноября 2017 года.
  • (англ.) . (5 апреля 2016). Дата обращения: 3 декабря 2017. Архивировано из 28 мая 2016 года.
  • (англ.) . . FIRST. Дата обращения: 12 ноября 2017.


Источник —

amity
  • 2021-02-01
  • 1
  • Tags:

Same as Безопасное программирование

The title for the last searches