Безпечне кодування

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Не плутати з Безпечним програмуванням — принципом розробки ПЗ, при якому розробники намагаються врахувати всі можливі помилки і збої.

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

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

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

Термінологія[ред. | ред. код]

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

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

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

Важливість[ред. | ред. код]

Питання забезпечення безпеки і працездатності системи є невід'ємною частиною етапу її проектування (дизайну системи)[4]. Вимоги до безпеки конкретних продуктів і систем ІТ встановлюються виходячи з наявних і прогнозованих загроз безпеки, проведеної політики безпеки, а також з урахуванням умов їх застосування[5]. Впровадження рішень для забезпечення безпеки після того, як система вже розроблена, є складною і дорогою процедурою. Тому слід з самого початку враховувати вимоги до безпеки протягом всього життєвого циклу системи[4].

Інформаційна система поділяється на фізичний і логічний рівень. Розуміння того, що саме має бути захищене від зовнішніх чинників, допомагає з найбільш ефективним вибором і застосуванням захисних заходів. Чітка межа між рівнями повинна визначатися політикою безпеки, яка регулює певний набір інформації та інформаційних технологій, що має фізичні кордони. Подальше ускладнення полягає в тому, що на одному комп'ютері або сервері може розміщуватися як загальнодоступна, так і конфіденційна інформація. В результаті кілька політик безпеки можуть застосовуватися до однієї машини або в межах однієї системи. Тому при розробці інформаційної системи кордону безпеки повинні враховуватися і описуватися у відповідній документації і політиках безпеки системи[4]. Її розробники повинні вміти забезпечити безпеку системи при проектуванні, розробці, управлінні і конфігурації, інтеграції, правильно провести тестування[4].

Аналіз (ручний або автоматичний) і забезпечення безпеки — дорога процедура, яка збільшує загальну вартість програмного продукту. Раніше повне усунення ризиків було спільною метою забезпечення безпеки. Сьогодні визнається, що усунення всіх ризиків не є економічно ефективним. Для будь-якої запропонованої системи контролю слід провести аналіз витрат і вигод. У деяких випадках переваги більш безпечної системи можуть не виправдовувати прямих і непрямих витрат. Вигоди включають не тільки запобігання грошових втрат; варто враховувати, наприклад, і репутаційні втрати. Прямі витрати включають витрати на придбання та установку даної технології; непрямі витрати включають зниження продуктивності системи і додаткове навчання співробітників[4].

Принципи[ред. | ред. код]

В даний час існують різноманітні технології розробки безпечного програмного забезпечення. Але є набір принципів, що враховуються при будь-якому підході[6]:

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

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

Існує безліч принципів забезпечення безпеки ПО, здебільшого схожих один на одного. Їх узагальненням можна вважати наведені вище принципи[7].

Класифікація та види вразливостей[ред. | ред. код]

Класифікатори[ред. | ред. код]

Використання стандартизованих описів вразливостей спрощує роботу фахівців з інформаційної безпеки. В даний час існує декілька популярних класифікаторів[8]:

  • CVE (Common Vulnerabilities and Exposures) — словник конкретних вразливостей конкретних продуктів;
  • CWE (Common Weakness Enumeration) — база даних типів вразливостей. Основне завдання проекту — надати опису поширених видів вразливостей, способи їх запобігання, виявлення та виправлення;
  • SecurityFocus BID;
  • Secunia — стрічка вразливостей відомої данської компанії Secunia в області комп'ютерної та мережевої безпеки;
  • IBM ISS X-Force.

Сучасні аналізатори коду і автоматизовані аудитори можуть використовувати подібні бази вразливостей. Це підвищує рівень довіри до продукту, а також може виявитися важливим при складанні звітів про уразливість, наявних в програмному продукті[8].

Зустрічаються й інші класифікатори. При роботі з ними слід звертати увагу на авторів, так як кожна система класифікації повинна створюватися експертами в цій галузі[8].

Метрики[ред. | ред. код]

Кожна програма є потенційною метою для зловмисників. Після знаходження вразливостей в додатках або сервісах вони будуть намагатися використовувати їх для крадіжки конфіденційної інформації, псування даних, управління комп'ютерними системами і мережами[2]. Для опису властивостей уразливості фахівцями використовується система підрахунку ризиків вразливостей CVSS. Вона являє собою шкали, на основі яких виставляються бали. Система метрик розроблена для поділу пріоритетів над виправленням вразливостей. Кожна шкала відноситься до певного змістового розділу, який називається метрикою. Таких метрик три[8][10][11]:

  • Базова (англ. Base) — характеристики уразливості, які не залежать від часу і середовища виконання. Служить для опису складності експлуатації уразливості, потенційного збитку для конфіденційності, цілісності та доступності інформації;
  • Тимчасова (англ. Temporal) — метрика, що враховує часовий чинник, наприклад, час на виправлення уразливості;
  • Контекстна (англ. Environmental) — метрика, що враховує інформацію про середовище функціонування програмного забезпечення.

Останні дві метрики носять допоміжний характер і використовуються лише для коригування показників базової метрики з урахуванням різних специфік[11].

Види вразливостей[ред. | ред. код]

Список поширених помилок, що ставлять під загрозу безпеку сучасних програм[12]:

  • уразливості, пов'язані з web-серверами (XSS, XSRF, розщеплення HTTP запиту (англ. HTTP response splitting));
  • уразливості web-клієнтів (DOM XSS);
  • дефекти форматних рядків[13] (англ. Uncontrolled format string);
  • впровадження команд (командна ін'єкція, англ. Command injection);
  • витік інформації (англ. Information Exposure);
  • стан гонитви (англ. Race condition);
  • слабке юзабіліті[14] (англ. Insufficient Psychological Acceptability);
  • виконання коду з завищеними привілеями (англ. Execution with Unnecessary Privileges);
  • зберігання незахищених даних (англ. Protection Mechanism Failure);
  • проблеми мобільного коду (англ. Mobile Code Issues);
  • слабкі паролі;
  • слабкі випадкові числа;
  • невдалий вибір криптографічних алгоритмів;
  • використання небезпечних криптографічних рішень;
  • незахищений мережевий трафік (англ. Cleartext Transmission of Sensitive Information);
  • неправильне використання PKI (англ. Improper Certificate Validation);

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

Захист[ред. | ред. код]

Правильною стратегією захисту від помилок і вразливостей є їх попередження та запобігання. Це вимагає від розробника постійної перевірки вхідних даних. Наприклад, найкращий спосіб захисту від атак переповнення буфера — перевірка того, чи вхідні дані не перевищують розміру буфера, в якому вони зберігаються. Дані, призначені для відправки в БД вимагають перевірки для захисту від атаки типу впровадження SQL-коду. Якщо дані відправляються на web-сторінку, то слід їх перевіряти для захисту від XSS. Однак, надмірне число перевірок ускладнює розробку вихідного коду програми і може привести, в свою чергу, до появи нових помилок, тому слід комбінувати цю стратегію з іншими[15].

Механізми для захисту від помилок може надавати компілятор або операційна система. Компілятор GCC дозволяє за допомогою функції _builtin_object_size () отримувати розмір об'єкта за вказівником на цей об'єкт, так що її використання робить процедуру копіювання безпечніше. MSVC при використанні прапора / RTCs дозволяє на етапі компіляції перевірити переповнення локальних змінних, використання неініціалізованих змінних, пошкодження покажчика стека, викликане невідповідністю угод про виклики. Використання технології CRED (C range error detector) і спеціальних вставок перед розділом стека, який захищається (StackGuard, SSP) частково дозволяє виявляти і запобігати атакам, пов'язаних з виходом за межі масиву і руйнуванням стека.

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

Типовими атаками на web-сервіси є впровадження SQL-коду, XSS, CSRF, clickjacking. Сучасні фреймворки допомагають розробникам у створенні безпечних web-додатків. Використання готових рішень дозволяє не займатися численними перевірками вхідних даних: від заголовків HTTP-запитів до їх змісту. Також надається більш безпечний метод роботи з БД — ORM[16][17].

Збитки[ред. | ред. код]

Монітор комп'ютера, зараженого вірусом Petya

Інформація про уразливість може бути використана зловмисниками при написанні вірусів. Наприклад, один з найперших відомих мережевих черв'яків (вірус Моріса) в 1988 році використовував такі уразливості як переповнення буфера в Unix-демоні finger для поширення між машинами. Тоді кількість заражених машин склало близько 6 тисяч[18], а економічний збиток за даними рахункової палати США склав від 10 до 100 млн доларів.[19]

З 2016 комп'ютерні віруси завдали світовій економіці збитків в 450 млрд доларів[20][21].

У 2017 збиток від вірусу WannaCry оцінили в 1 млрд доларів. Випадки зараження були зафіксовані щонайменше в 150 країнах[22][23]. Вірус застосовував експлойт EternalBlue, що використовує уразливість в протоколі SMB, пов'язану з переповненням буфера[24][25][26][27].

У 2017 році відбулась масштабна хакерська атака з боку Росії проти України та ще 59 країн[28]. Причиною стала компрометація системи оновлення програми M.E.Doc з встановленням бекдору та вірусу NotPetya. Збитки підприємств по всьому світу склали 8 млрд доларів[29].

Примітки[ред. | ред. код]

  1. ↑ Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модел. webportalsrv.gost.ru. Архів оригіналу за 22 жовтня 2017. Процитовано 9 квітня 2018.
  2. ↑ а б в Introduction to Secure Coding Guide. developer.apple.com (англ.). Архів оригіналу за 21 березня 2018. Процитовано 9 квітня 2018.
  3. ↑ Defensive Programming. Dr. Dobb's. Архів оригіналу за 13 листопада 2017. Процитовано 9 квітня 2018.
  4. ↑ а б в г д Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security) [Архівовано 19 лютого 2018 у Wayback Machine.] / National Institute of Standards and Technology. — Revision A. — 2004. — 33 p.
  5. ↑ Руководящий документ. Приказ председателя Гостехкомиссии России от 19 июня 2002 г. N 187 - ФСТЭК России. fstec.ru (ru-ru) . Архів оригіналу за 10 квітня 2018. Процитовано 9 квітня 2018.
  6. ↑ а б Сафонов В. О. Современные технологии разработки надежных и безопасных программ // Компьютерные инструменты в образовании: Журнал. — 2008. — № 06. — P. 25—33.
  7. ↑ Secure Programming HOWTO - Information on Creating Secure Software. www.dwheeler.com. Архів оригіналу за 16 травня 2018. Процитовано 9 квітня 2018.
  8. ↑ а б в г Комаров А. Меряем уязвимости [Архівовано 6 січня 2018 у Wayback Machine.] // Хакер: Журнал. — 2009. — № 04 (124). — P. 48—51.
  9. ↑ OSVDB: FIN. OSVDB (амер.). 6 квітня 2016. Архів оригіналу за 28 травня 2016. Процитовано 9 квітня 2018.
  10. ↑ Mell P., Scarfone K., Romanosky S. Common Vulnerability Scoring System (англ.) // IEEE Security & Privacy: article. — 2006. — Vol. 4. — P. 85—89. — ISSN 1540-7993 [Архівовано 9 березня 2021 у Wayback Machine.]
  11. ↑ а б CVSS v3.0 Specification Document. FIRST — Forum of Incident Response and Security Teams. Архів оригіналу за 8 березня 2022. Процитовано 9 квітня 2018.
  12. ↑ Howard, Michael; LeBlanc, David; Viega, John (22 вересня 2009). 24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them (англ.). McGraw Hill Professional. ISBN 9780071626767. Архів оригіналу за 10 квітня 2018. Процитовано 9 квітня 2018.
  13. ↑ Вахрушев И. А., Каушан В. В., Падарян В. А., Федотов А. Н. Метод поиска уязвимости форматной строки [Архівовано 19 червня 2018 у Wayback Machine.] // Труды ИСП РАН. — 2015. — Т. 27, № 4. — С. 23—38. — P. 25—33.
  14. ↑ Saltzer J.H., Schroeder M.D. The Protection of Information in Computer Systems [Архівовано 20 квітня 2018 у Wayback Machine.] (англ.): article / Saltzer J. H.. — 1975.
  15. ↑ а б в Seacord R. C. Secure Coding in C and C++ [Архівовано 10 квітня 2018 у Wayback Machine.]. — 2. — Addison-Wesley, 2013. — 600 p. — ISBN 9780132981972.
  16. ↑ Security in Django | Django documentation | Django. docs.djangoproject.com (англ.). Архів оригіналу за 3 травня 2018. Процитовано 9 квітня 2018.
  17. ↑ Ruby on Rails Security Guide — Ruby on Rails Guides. guides.rubyonrails.org (англ.). Архів оригіналу за 10 квітня 2018. Процитовано 9 квітня 2018.
  18. ↑ Kric., Kasperski, (2006). Zapiski issledovateli︠a︡ kompʹi︠u︡ternykh virusov. Moskva [Russia]: Piter. ISBN 5469003310. OCLC 70916777.
  19. ↑ Malware History [Архівовано 3 березня 2016 у Wayback Machine.] / BitDefender. — 2010. — P. 23—24. — 71 p.
  20. ↑ Graham, Luke (7 лютого 2017). Cybercrime costs the global economy $450 billion: CEO. CNBC. Архів оригіналу за 3 травня 2018. Процитовано 9 квітня 2018.
  21. ↑ Sun, David. Cybercrime cost world economy $620 billion last year [Архівовано 24 січня 2022 у Wayback Machine.] (англ.), Singapore: The New Paper (5 July 2017).
  22. ↑ Збиток від вірусу WannaCry оцінили в мільярд доларів. osvita.mediasapiens.ua. Архів оригіналу за 17 березня 2018. Процитовано 9 квітня 2018.
  23. ↑ The damage from the virus WannaCry exceeded $ 1 billion [Архівовано 15 жовтня 2017 у Wayback Machine.] (англ.), US: 6abc (25 May 2017)
  24. ↑ William Gamazo Sanchez (Vulnerability Research). MS17-010: EternalBlue's Large Non-Paged Pool Overflow in SRV Driver [Архівовано 8 січня 2018 у Wayback Machine.] (англ.). http://blog.trendmicro.com/ [Архівовано 4 травня 2018 у Wayback Machine.]. Trend Micro (2 June 2017)
  25. ↑ WannaCry ransomware used in widespread attacks all over the world [Архівовано 12 квітня 2018 у Wayback Machine.] (англ.). https://securelist.com/ [Архівовано 7 квітня 2015 у Wayback Machine.]. ЗАО «Лаборатория Касперского» (12 May 2017)
  26. ↑ Боровко, Роман. Экономический ущерб от вирусов [Архівовано 5 квітня 2018 у Wayback Machine.], Москва: CNews Analytics (2003).
  27. ↑ Net Losses: Estimating the Global Cost of Cybercrime [Архівовано 24 жовтня 2017 у Wayback Machine.] (англ.). https://www.mcafee.com/'Архівована копія. Архів оригіналу за 17 лютого 2022. Процитовано 9 квітня 2018.{{cite web}}: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання)'. McAfee (2014).
  28. ↑ Rbc.ua. Хакерська атака на Україну: подробиці. РБК-Украина (укр.). Архів оригіналу за 13 січня 2018. Процитовано 9 квітня 2018.
  29. ↑ Збитки від атаки вірусу Petya.A у світі сягають 8 мільярдів доларів - експерт (укр.). Архів оригіналу за 10 квітня 2018. Процитовано 9 квітня 2018.
Засоби захисту від несанкціонованого доступу
Інформація
Захист
Вразливості
Отримано з https://uk.wikipedia.org/w/index.php?title=Безпечне_кодування&oldid=40930975