Безпечне кодування (програмування) — методика розробки програмного забезпечення, що запобігає випадковому впровадженню вразливостей і забезпечує стійкість до впливу шкідливих програм і несанкціонованого доступу. Баги і логічні помилки є основною причиною появи вразливостей програмного забезпечення.
Безпечне програмне забезпечення — програмне забезпечення, розроблене з використанням сукупності заходів, спрямованих на запобігання появи і усунення вразливостей програми .
Завдання безпечного програмування — захист даних користувача від крадіжки і псування, збереження контролю над системою. Небезпечна програма — потенційна мета для зловмисника, який може використовувати наявні уразливості для перегляду, зміни або видалення наявної інформації, впливу на роботу програм і сервісів (запуск або зупинка), впровадження шкідливого коду в систему.
Термінологія В англомовній літературі існує два терміни, які можуть бути переведені, як безпечне програмування.:
Defensive programming (Оборонне, захисне, безпечне програмування) — принцип розробки ПЗ, при якому розробники намагаються врахувати всі можливі помилки і збої, максимально ізолювати їх і при можливості відновити працездатність програми в разі неполадок. Це повинно робити програмне забезпечення більш стабільним і менш уразливим. Наприклад, апаратною реалізацією даного принципу є сторожовий таймер, обчислення контрольної суми — для виявлення помилок при пакетній передачі даних.
Secure coding (Безпечне програмування/кодування) — методика написання програм, стійких до атак з боку шкідливих програм і зловмисників. Безпечне програмування допомагає захистити дані користувача від крадіжки або псування. Крім того, небезпечна програма може надати зловмисникові доступ до управління сервером або комп'ютером користувача; наслідки можуть бути різні: від відмови в обслуговуванні одному користувачеві до компрометації секретної інформації, втрати обслуговування або пошкодження систем тисяч користувачів.
Важливість Питання забезпечення безпеки і працездатності системи є невід'ємною частиною етапу її проектування (дизайну системи)Stoneburner G., Hayden C., Feringa A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security) / National Institute of Standards and Technology. — Revision A. — 2004. — 33 p.. Вимоги до безпеки конкретних продуктів і систем ІТ встановлюються виходячи з наявних і прогнозованих загроз безпеки, проведеної політики безпеки, а також з урахуванням умов їх застосування . Впровадження рішень для забезпечення безпеки після того, як система вже розроблена, є складною і дорогою процедурою. Тому слід з самого початку враховувати вимоги до безпеки протягом всього життєвого циклу системи.
Інформаційна система поділяється на фізичний і логічний рівень. Розуміння того, що саме має бути захищене від зовнішніх чинників, допомагає з найбільш ефективним вибором і застосуванням захисних заходів. Чітка межа між рівнями повинна визначатися політикою безпеки, яка регулює певний набір інформації та інформаційних технологій, що має фізичні кордони. Подальше ускладнення полягає в тому, що на одному комп'ютері або сервері може розміщуватися як загальнодоступна, так і конфіденційна інформація. В результаті кілька політик безпеки можуть застосовуватися до однієї машини або в межах однієї системи. Тому при розробці інформаційної системи кордону безпеки повинні враховуватися і описуватися у відповідній документації і політиках безпеки системи. Її розробники повинні вміти забезпечити безпеку системи при проектуванні, розробці, управлінні і конфігурації, інтеграції, правильно провести тестування.
Аналіз (ручний або автоматичний) і забезпечення безпеки — дорога процедура, яка збільшує загальну вартість програмного продукту. Раніше повне усунення ризиків було спільною метою забезпечення безпеки. Сьогодні визнається, що усунення всіх ризиків не є економічно ефективним. Для будь-якої запропонованої системи контролю слід провести аналіз витрат і вигод. У деяких випадках переваги більш безпечної системи можуть не виправдовувати прямих і непрямих витрат. Вигоди включають не тільки запобігання грошових втрат; варто враховувати, наприклад, і репутаційні втрати. Прямі витрати включають витрати на придбання та установку даної технології; непрямі витрати включають зниження продуктивності системи і додаткове навчання співробітників.
Принципи В даний час існують різноманітні технології розробки безпечного програмного забезпечення. Але є набір принципів, що враховуються при будь-якому підходіСафонов В. О. Современные технологии разработки надежных и безопасных программ // Компьютерные инструменты в образовании: Журнал. — 2008. — № 06. — P. 25—33.:
працездатність і корисність (юзабіліті, ); безпека () — можливість захисту від зовнішніх загроз, атак і збереження працездатності після їх виявлення і усунення; надійність () — передбачувана, коректна і безвідмовна роботу в разі некоректних вихідних даних; конфіденційність () — забезпечення безпечної та коректної роботи з конфіденційною інформацією; забезпечення цілісності і коректності бізнесу () — чітка організація супроводу програми, контроль прозорості, законності, правильності роботи користувача.
Чотири останніх якості стали основою Trustworthy computing (TwC) () («Обчислення, які заслуговують на довіру») — ініціативи корпорації Microsoft, головне завдання якої — звернути увагу розробників на важливість забезпечення зазначених вимог на кожному з етапів розробки ПЗ.
Існує безліч принципів забезпечення безпеки ПО, здебільшого схожих один на одного. Їх узагальненням можна вважати наведені вище принципи.
Класифікація та види вразливостей
Класифікатори Використання стандартизованих описів вразливостей спрощує роботу фахівців з інформаційної безпеки. В даний час існує декілька популярних класифікаторівКомаров А. Меряем уязвимости // Хакер: Журнал. — 2009. — № 04 (124). — P. 48—51.:
CVE (Common Vulnerabilities and Exposures) — словник конкретних вразливостей конкретних продуктів; CWE (Common Weakness Enumeration) — база даних типів вразливостей. Основне завдання проекту — надати опису поширених видів вразливостей, способи їх запобігання, виявлення та виправлення; SecurityFocus BID; OSVDB () — «відкрита база даних вразливостей», створена трьома некомерційними організаціями. Припинила роботу 5 квітня 2016 року. Блог продовжує працювати ; Secunia — стрічка вразливостей відомої данської компанії Secunia в області комп'ютерної та мережевої безпеки; IBM ISS X-Force.
Сучасні аналізатори коду і автоматизовані аудитори можуть використовувати подібні бази вразливостей. Це підвищує рівень довіри до продукту, а також може виявитися важливим при складанні звітів про уразливість, наявних в програмному продукті.
Зустрічаються й інші класифікатори. При роботі з ними слід звертати увагу на авторів, так як кожна система класифікації повинна створюватися експертами в цій галузі.
Метрики Кожна програма є потенційною метою для зловмисників. Після знаходження вразливостей в додатках або сервісах вони будуть намагатися використовувати їх для крадіжки конфіденційної інформації, псування даних, управління комп'ютерними системами і мережами. Для опису властивостей уразливості фахівцями використовується система підрахунку ризиків вразливостей CVSS. Вона являє собою шкали, на основі яких виставляються бали. Система метрик розроблена для поділу пріоритетів над виправленням вразливостей. Кожна шкала відноситься до певного змістового розділу, який називається метрикою. Таких метрик триMell P., Scarfone K., Romanosky S. Common Vulnerability Scoring System (англ.) // IEEE Security & Privacy: article. — 2006. — Vol. 4. — P. 85—89. — ISSN 1540-7993 :
Базова () — характеристики уразливості, які не залежать від часу і середовища виконання. Служить для опису складності експлуатації уразливості, потенційного збитку для конфіденційності, цілісності та доступності інформації; Тимчасова () — метрика, що враховує часовий чинник, наприклад, час на виправлення уразливості; Контекстна () — метрика, що враховує інформацію про середовище функціонування програмного забезпечення.
Останні дві метрики носять допоміжний характер і використовуються лише для коригування показників базової метрики з урахуванням різних специфік.
Види вразливостей Список поширених помилок, що ставлять під загрозу безпеку сучасних програм:
SQL ін'єкція (); уразливості, пов'язані з web-серверами (XSS, XSRF, розщеплення HTTP запиту (англ. HTTP response splitting)); уразливості web-клієнтів (DOM XSS); переповнення буфера (); дефекти форматних рядківВахрушев И. А., Каушан В. В., Падарян В. А., Федотов А. Н. Метод поиска уязвимости форматной строки // Труды ИСП РАН. — 2015. — Т. 27, № 4. — С. 23—38. — P. 25—33. (); арифметичне переповнення (); некоректна обробка винятків і помилок; впровадження команд (командна ін'єкція, ); витік інформації (); стан гонитви (); слабке юзабілітіSaltzer J.H., Schroeder M.D. The Protection of Information in Computer Systems (англ.): article / Saltzer J. H.. — 1975. (); виконання коду з завищеними привілеями (); зберігання незахищених даних (); проблеми мобільного коду (); слабкі паролі; слабкі випадкові числа; невдалий вибір криптографічних алгоритмів; використання небезпечних криптографічних рішень; незахищений мережевий трафік (); неправильне використання PKI (); довіра до механізму вирішення мережевих імен ().
Перелічити всі відомі уразливості неможливо, враховуючи, що кожен день з'являються нові. В даному списку наведені проблеми, які часто зустрічаються, допустити які легко, але наслідки яких можуть бути катастрофічними. Наприклад, причиною поширення хробака Blaster стала помилка всього в двох рядках кодуSeacord R. C. Secure Coding in C and C++ . — 2. — Addison-Wesley, 2013. — 600 p. — ISBN 9780132981972..
Захист Правильною стратегією захисту від помилок і вразливостей є їх попередження та запобігання. Це вимагає від розробника постійної перевірки вхідних даних. Наприклад, найкращий спосіб захисту від атак переповнення буфера — перевірка того, чи вхідні дані не перевищують розміру буфера, в якому вони зберігаються. Дані, призначені для відправки в БД вимагають перевірки для захисту від атаки типу впровадження SQL-коду. Якщо дані відправляються на web-сторінку, то слід їх перевіряти для захисту від XSS. Однак, надмірне число перевірок ускладнює розробку вихідного коду програми і може привести, в свою чергу, до появи нових помилок, тому слід комбінувати цю стратегію з іншими.
Механізми для захисту від помилок може надавати компілятор або операційна система. Компілятор GCC дозволяє за допомогою функції _builtin_object_size () отримувати розмір об'єкта за вказівником на цей об'єкт, так що її використання робить процедуру копіювання безпечніше. MSVC при використанні прапора / RTCs дозволяє на етапі компіляції перевірити переповнення локальних змінних, використання неініціалізованих змінних, пошкодження покажчика стека, викликане невідповідністю угод про виклики. Використання технології CRED (C range error detector) і спеціальних вставок перед розділом стека, який захищається (StackGuard, SSP) частково дозволяє виявляти і запобігати атакам, пов'язаних з виходом за межі масиву і руйнуванням стека.
Операційна система також може контролювати процес виконання програми. Дана стратегія може бути корисною у разі, якщо вихідний код цієї програми невідомий. Технологія ASLR (рандомізація схеми адресного простору) є функцією безпеки операційних систем, призначеної для запобігання змоги виконувати довільний код. В даний час ASLR підтримується і в Linux, і в Windows. Підвищення рівня безпеки досягається застосуванням технологій нездійсненних стеків: W ^ X, PaX.