Безпечне програмування — одна з форм , мета якої забезпечити тривале функціонування певної частини коду програми під впливом непередбачуваних обставин. Його ідея полягає у зменшенні або навіть ліквідації можливості появи прояву закону Мерфі. Техніка безпечного програмування використовується особливо часто коли потрібно звести до мінімуму використання коду не за призначенням.
Мета безпечного програмування покращити програмний код в таких його аспектах:
- якість коду в цілому (зменшення кількості програмних багів та інших проблем)
- покращення зрозумілості програмного коду(код має бути читабельний і зрозумілий)
- програма повинна працювати належним чином навіть при некоректному введенні даних або інших невизначених діях користувача
Однак надмірне застосування принципів безпечного програмування може призвести до надлишковості перевірок. Тобто код запобігатиме помилкам, які не можуть трапитись, але повинні опрацьовуватися програмістом. Таким чином збільшується час виконання програми або витрати на технічне обслуговування. В цьому випадку також збільшується кількість опрацьованих виняткових ситуацій. Таким чином помилка буде опрацьована і пройде непомітно, але результат все ще буде хибний.
Захищене програмування
Проектування захищених програм інколи використовує принципи безпечного програмування. Деякі науковці вважають, що такий підхід мінімізує помилки, які потенційно можуть бути використані зловмисниками для DDOS-атак або включення коду.
Відмінність між захисним програмуванням і звичайною практикою програмування полягає у тому, що програміст не обдумує всіх можливих помилок, до яких призводить та чи інша функція. Іншими словами, програміст не припускає, що виклик певної функції або використання певної бібліотеки буде працювати не так, як зазначено в документації. Наприклад:
int risky_programming(char *input){ char str[1000+1]; // one more for the null character // ... strcpy(str, input); // copy input // ... }
Якщо користувач введе більше ніж 1000 символів, функція перестане працювати належним чином. Недосвідчений програміст не побачить в цьому жодної проблеми, припускаючи, що користувач ніколи не введе стільки символів.
Проблему можна вирішити так:
int secure_programming(char *input){ char str[1000]; // ... strncpy(str, input, sizeof(str)); // copy input without exceeding the length of the destination str[sizeof(str) - 1] = '\0'; // if strlen(input) == sizeof(str) then strncpy won't NUL terminate // ... }
Техніки безпечного програмування
Ось декілька технік безпечного програмування:
Розумне повторне використання коду
Якщо є код, який добре відтестований і працює коректно, то його повторне використання зменшить ймовірність появи помилок.
Щоправда, повторне використання коду не завжди є доречним, особливо коли це стосується бізнес-логіки. В цьому випадку це може викликати серйозні помилки в бізнес-процесі.
Унаслідувані проблеми
Перед повторним використанням старого коду, бібліотек, API та інших компонент програм потрібно переконатися, що цей код можна використовувати повторно. Цілком можливо, що він може викликати проблеми наслідування.
Проблеми наслідування виникають коли старі конструкції мають працювати з новими вимогами. Особливо коли ці конструкції не розроблялися чи тестувалися для нових вимог.
Багато програмних продуктів мають проблеми з старим унаслідуваним кодом, наприклад:
- Унаслідуваний код може не відповідати принципам безпечного програмування, і тому може бути значно нижчої якості ніж нещодавно створений код.
- Успадкований код був написаний і ввідтестований для умов, які більше не є актуальними. Старі тести можуть бути не дійсними.
- Приклад 1: успадкований код розроблявся для ASCII вводу, але зараз ввід UTF-8.
- Приклад 2: успадкований код компілювався і тестувався на 32-бітний архітектурі, але під час компіляції на 64-бітній архітектурі можути виникнути проблеми з арифметикою(наприклад помилки при визначенні знаку числа, недійсне приведення типів).
- Приклад 3: успадкований код розроблявся для комп'ютерів без доступу до мережі. Тому цей код стає вразливим на комп'ютері з мережею.
- Успадкований код розроблявся без урахування теперішніх загроз. Наприклад, написаний в 90-х роках минулого століття швидше за все буде схильний до включення коду, оскільки в той час ця проблема не була до кінця усвідомленою.
Відомі приклади проблем з успадкованим кодом:
- BIND 9, представлений Полом Віксі та Девідом Конрадом «Безпека була ключовим фактором в дизайні» * [ 31 січня 2015 у Wayback Machine.], безпека назв, надійність, маштабованість і нові протоколи були ключовими проблемами при переписувані старого коду.
- Microsoft Windows страждав від Windows Metafile вразливості та іншими проблемами використання WMF формату. Центр Безпеки Майкрософт пояснює особливості WMF так «В 1990 було додано підтримку WMF… Тоді безпека виглядала по-іншому… ми довіряли їй»
- Oracle також бореться з проблемами успадкованого коду. Наприклад, старий код написаний без адресації, не обробляв SQL-включення. В результаті виникали вразливості безпеки, на виправлення яких йшов час а також виникали неповні виправлення. Це призвело до різкої критики з боку експертів безпеки. Окрім того дефолтні інсталятори не відповідали власним вимогам безпеки. Наприклад, Oracle Database Security Checklist [ 6 серпня 2009 у Wayback Machine.], оскільки багато програм вимагають менш безпечних налаштувань безпеки, щоб функціонувати правильно.
Безпечна обробка вводу і виводу
Канонізація
Зловмисники можуть придумувати нові види представлення некоректних даних.
Для прикладу, якщо ви перевіряєте чи запит на файл не має вигляд «/etc/passwd», зловмисник може придумати інший варіант назви цього файлу, наприклад «/etc/./passwd».
Щоб уникнути помилок через неканонічні вхідні дані, використовуйте канонізаційні бібліотеки.
Нетолерантність до потенційних помилок
Припустимо, код побудований таким чином, що схильний до помилок. Основне правило полягає в тому, щоб спочатку опрацювати виняткові ситуації, про які відомо, і вже потім в міру виявлення нових проблем додавати їхнє опрацювання.
Інші техніки
- Однією з найпоширеніших є проблема неперевіреного використання структур фіксованого розміру та функцій для роботи з даними різної довжини(проблема переповнення буфера). Це особливо поширено для стрічок в мові С. Не можна використовувати такі функції бібліотеки С як gets, оскільки функція не знає розміру об'єкта, з яким вона працює. Такі функції як scanf можуть використовуватися, але програміст має вибрати вірний формат стрічки.
- Шифрування й аутентифікація всіх важливих даних, що передаються мережею. Не потрібно придумувати власну систему шифрування, просто використовуйте перевірену.
- Всі дані важливі, поки не буде доведено протилежне
- Всі дані зіпсовані, поки не доведено протилежне
- Весь код небезпечний, поки не доведено протилежне
- Безпечність коду не можна довести з боку користувача, або іншими словами: «ніколи не довіряй користувачу»
- Якщо дані будуть перевірятися на коректність, то потрібно перевіряти їх коректність, а не зіпсованість.
- Контрактне програмування
- Контрактне програмування використовує передумови, післяумови і інваріанти, щоб переконатися, що дані і стан програми в цілому є коректним. Це може включати перевірку аргументів функції або методу перед виконанням тіла функції. Після тіла функції перевіряється стан об'єкта або інших даних, після цього повертається результат роботи і функція завершується.
- Припущення
- В тілі функції деколи потрібно перевірити чи об'єкт є валідним(не вказує на null), чи довжина масиву правильна, і т. д. і т. ін. Краще не довіряти бібліотекам, які ви не створювали. Тому кожного разу коли ви їх викликаєте потрібно перевіряти що вони повертають. Часто допомагає створення невеличкої бібліотеки припущень і перевірок для зручнішого відслідковування помилок.
- Надавайте перевагу винятковим ситуаціям(виняткам) над поверненням коду помилки
- Взагалі кажучи, після виникнення виняткової ситуації потрібно вивести зрозуміле повідомлення про помилку, а не повертати код помилки, яка не дасть користувачу жодної інформації. Тому використовуючи винятки зводиться до мінімуму кількість скарг і підвищується надійність і безпека програмного забезпечення.
Зовнішні посилання
- by Dinu P. Madau 1999
- «Rules for Defensive C Programming(Mirror2)»[недоступне посилання з лютого 2019] by Dinu P. Madau 1999
- «Secure Programming for Linux and Unix HOWTO» [ 28 квітня 2007 у Wayback Machine.] by David A. Wheeler
- «Proactive Debugging» article by Jack Ganssle 2001-02-26
- «Defensive programming» [ 15 серпня 2010 у Wayback Machine.] article by Rob Manderson 2004-08-06
- «The art of defensive programming: Or how to write code that will be easy to maintain» [ 13 червня 2015 у Wayback Machine.] article by Jonathan West
- by Mark Dowd, John McDonald, and Justin Schuh
- Solid Software [ 9 травня 2015 у Wayback Machine.] by Shari Lawrence Pfleeger, Les Hatton and Charles C. Howell, has a section on Defensive Programming.
- «Defensive Programming» [ 2 липня 2015 у Wayback Machine.] by Andrew Phillips
- William R. Cheswick and Steven M. Bellovin, Firewalls and Internet Security: Repelling the Wily Hacker http://www.wilyhacker.com/ [ 11 липня 2015 у Wayback Machine.]
Ця стаття потребує додаткових для поліпшення її . (січень 2016) |
Це незавершена стаття про програмування. Ви можете проєкту, виправивши або дописавши її. |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Ne plutati z Bezpechnim koduvannyam metodikoyu napisannya program stijkih do atak z boku shkidlivih program i zlovmisnikiv Bezpechne programuvannya odna z form meta yakoyi zabezpechiti trivale funkcionuvannya pevnoyi chastini kodu programi pid vplivom neperedbachuvanih obstavin Jogo ideya polyagaye u zmenshenni abo navit likvidaciyi mozhlivosti poyavi proyavu zakonu Merfi Tehnika bezpechnogo programuvannya vikoristovuyetsya osoblivo chasto koli potribno zvesti do minimumu vikoristannya kodu ne za priznachennyam Meta bezpechnogo programuvannya pokrashiti programnij kod v takih jogo aspektah yakist kodu v cilomu zmenshennya kilkosti programnih bagiv ta inshih problem pokrashennya zrozumilosti programnogo kodu kod maye buti chitabelnij i zrozumilij programa povinna pracyuvati nalezhnim chinom navit pri nekorektnomu vvedenni danih abo inshih neviznachenih diyah koristuvacha Odnak nadmirne zastosuvannya principiv bezpechnogo programuvannya mozhe prizvesti do nadlishkovosti perevirok Tobto kod zapobigatime pomilkam yaki ne mozhut trapitis ale povinni opracovuvatisya programistom Takim chinom zbilshuyetsya chas vikonannya programi abo vitrati na tehnichne obslugovuvannya V comu vipadku takozh zbilshuyetsya kilkist opracovanih vinyatkovih situacij Takim chinom pomilka bude opracovana i projde nepomitno ale rezultat vse she bude hibnij Zahishene programuvannyaProektuvannya zahishenih program inkoli vikoristovuye principi bezpechnogo programuvannya Deyaki naukovci vvazhayut sho takij pidhid minimizuye pomilki yaki potencijno mozhut buti vikoristani zlovmisnikami dlya DDOS atak abo vklyuchennya kodu Vidminnist mizh zahisnim programuvannyam i zvichajnoyu praktikoyu programuvannya polyagaye u tomu sho programist ne obdumuye vsih mozhlivih pomilok do yakih prizvodit ta chi insha funkciya Inshimi slovami programist ne pripuskaye sho viklik pevnoyi funkciyi abo vikoristannya pevnoyi biblioteki bude pracyuvati ne tak yak zaznacheno v dokumentaciyi Napriklad int risky programming char input char str 1000 1 one more for the null character strcpy str input copy input Yaksho koristuvach vvede bilshe nizh 1000 simvoliv funkciya perestane pracyuvati nalezhnim chinom Nedosvidchenij programist ne pobachit v comu zhodnoyi problemi pripuskayuchi sho koristuvach nikoli ne vvede stilki simvoliv Natomist programist znajomij z bezpechnim programuvannyam ne dopustit cogo Oskilki zgidno zakonu Merfi yaksho v kodi ye pomilka to vona vse odno viyavit sebe Pomilka v danomu prikladi demonstruye vrazlivist sho dopuskaye perepovnennya bufera Problemu mozhna virishiti tak int secure programming char input char str 1000 strncpy str input sizeof str copy input without exceeding the length of the destination str sizeof str 1 0 if strlen input sizeof str then strncpy won t NUL terminate Tehniki bezpechnogo programuvannyaOs dekilka tehnik bezpechnogo programuvannya Rozumne povtorne vikoristannya kodu Yaksho ye kod yakij dobre vidtestovanij i pracyuye korektno to jogo povtorne vikoristannya zmenshit jmovirnist poyavi pomilok Shopravda povtorne vikoristannya kodu ne zavzhdi ye dorechnim osoblivo koli ce stosuyetsya biznes logiki V comu vipadku ce mozhe viklikati serjozni pomilki v biznes procesi Unasliduvani problemi Pered povtornim vikoristannyam starogo kodu bibliotek API ta inshih komponent program potribno perekonatisya sho cej kod mozhna vikoristovuvati povtorno Cilkom mozhlivo sho vin mozhe viklikati problemi nasliduvannya Problemi nasliduvannya vinikayut koli stari konstrukciyi mayut pracyuvati z novimi vimogami Osoblivo koli ci konstrukciyi ne rozroblyalisya chi testuvalisya dlya novih vimog Bagato programnih produktiv mayut problemi z starim unasliduvanim kodom napriklad Unasliduvanij kod mozhe ne vidpovidati principam bezpechnogo programuvannya i tomu mozhe buti znachno nizhchoyi yakosti nizh neshodavno stvorenij kod Uspadkovanij kod buv napisanij i vvidtestovanij dlya umov yaki bilshe ne ye aktualnimi Stari testi mozhut buti ne dijsnimi Priklad 1 uspadkovanij kod rozroblyavsya dlya ASCII vvodu ale zaraz vvid UTF 8 Priklad 2 uspadkovanij kod kompilyuvavsya i testuvavsya na 32 bitnij arhitekturi ale pid chas kompilyaciyi na 64 bitnij arhitekturi mozhuti viniknuti problemi z arifmetikoyu napriklad pomilki pri viznachenni znaku chisla nedijsne privedennya tipiv Priklad 3 uspadkovanij kod rozroblyavsya dlya komp yuteriv bez dostupu do merezhi Tomu cej kod staye vrazlivim na komp yuteri z merezheyu Uspadkovanij kod rozroblyavsya bez urahuvannya teperishnih zagroz Napriklad napisanij v 90 h rokah minulogo stolittya shvidshe za vse bude shilnij do vklyuchennya kodu oskilki v toj chas cya problema ne bula do kincya usvidomlenoyu Vidomi prikladi problem z uspadkovanim kodom BIND 9 predstavlenij Polom Viksi ta Devidom Konradom Bezpeka bula klyuchovim faktorom v dizajni 31 sichnya 2015 u Wayback Machine bezpeka nazv nadijnist mashtabovanist i novi protokoli buli klyuchovimi problemami pri perepisuvani starogo kodu Microsoft Windows strazhdav vid Windows Metafile vrazlivosti ta inshimi problemami vikoristannya WMF formatu Centr Bezpeki Majkrosoft poyasnyuye osoblivosti WMF tak V 1990 bulo dodano pidtrimku WMF Todi bezpeka viglyadala po inshomu mi doviryali yij Oracle takozh boretsya z problemami uspadkovanogo kodu Napriklad starij kod napisanij bez adresaciyi ne obroblyav SQL vklyuchennya V rezultati vinikali vrazlivosti bezpeki na vipravlennya yakih jshov chas a takozh vinikali nepovni vipravlennya Ce prizvelo do rizkoyi kritiki z boku ekspertiv bezpeki Okrim togo defoltni instalyatori ne vidpovidali vlasnim vimogam bezpeki Napriklad Oracle Database Security Checklist 6 serpnya 2009 u Wayback Machine oskilki bagato program vimagayut mensh bezpechnih nalashtuvan bezpeki shob funkcionuvati pravilno Bezpechna obrobka vvodu i vivodu Kanonizaciya Zlovmisniki mozhut pridumuvati novi vidi predstavlennya nekorektnih danih Dlya prikladu yaksho vi pereviryayete chi zapit na fajl ne maye viglyad etc passwd zlovmisnik mozhe pridumati inshij variant nazvi cogo fajlu napriklad etc passwd Shob uniknuti pomilok cherez nekanonichni vhidni dani vikoristovujte kanonizacijni biblioteki Netolerantnist do potencijnih pomilok Pripustimo kod pobudovanij takim chinom sho shilnij do pomilok Osnovne pravilo polyagaye v tomu shob spochatku opracyuvati vinyatkovi situaciyi pro yaki vidomo i vzhe potim v miru viyavlennya novih problem dodavati yihnye opracyuvannya Inshi tehniki Odniyeyu z najposhirenishih ye problema neperevirenogo vikoristannya struktur fiksovanogo rozmiru ta funkcij dlya roboti z danimi riznoyi dovzhini problema perepovnennya bufera Ce osoblivo poshireno dlya strichok v movi S Ne mozhna vikoristovuvati taki funkciyi biblioteki S yak gets oskilki funkciya ne znaye rozmiru ob yekta z yakim vona pracyuye Taki funkciyi yak scanf mozhut vikoristovuvatisya ale programist maye vibrati virnij format strichki Shifruvannya j autentifikaciya vsih vazhlivih danih sho peredayutsya merezheyu Ne potribno pridumuvati vlasnu sistemu shifruvannya prosto vikoristovujte perevirenu Vsi dani vazhlivi poki ne bude dovedeno protilezhne Vsi dani zipsovani poki ne dovedeno protilezhne Ves kod nebezpechnij poki ne dovedeno protilezhne Bezpechnist kodu ne mozhna dovesti z boku koristuvacha abo inshimi slovami nikoli ne doviryaj koristuvachu Yaksho dani budut pereviryatisya na korektnist to potribno pereviryati yih korektnist a ne zipsovanist Kontraktne programuvannya Kontraktne programuvannya vikoristovuye peredumovi pislyaumovi i invarianti shob perekonatisya sho dani i stan programi v cilomu ye korektnim Ce mozhe vklyuchati perevirku argumentiv funkciyi abo metodu pered vikonannyam tila funkciyi Pislya tila funkciyi pereviryayetsya stan ob yekta abo inshih danih pislya cogo povertayetsya rezultat roboti i funkciya zavershuyetsya Pripushennya V tili funkciyi dekoli potribno pereviriti chi ob yekt ye validnim ne vkazuye na null chi dovzhina masivu pravilna i t d i t in Krashe ne doviryati bibliotekam yaki vi ne stvoryuvali Tomu kozhnogo razu koli vi yih viklikayete potribno pereviryati sho voni povertayut Chasto dopomagaye stvorennya nevelichkoyi biblioteki pripushen i perevirok dlya zruchnishogo vidslidkovuvannya pomilok Nadavajte perevagu vinyatkovim situaciyam vinyatkam nad povernennyam kodu pomilki Vzagali kazhuchi pislya viniknennya vinyatkovoyi situaciyi potribno vivesti zrozumile povidomlennya pro pomilku a ne povertati kod pomilki yaka ne dast koristuvachu zhodnoyi informaciyi Tomu vikoristovuyuchi vinyatki zvoditsya do minimumu kilkist skarg i pidvishuyetsya nadijnist i bezpeka programnogo zabezpechennya Zovnishni posilannyaby Dinu P Madau 1999 Rules for Defensive C Programming Mirror2 nedostupne posilannya z lyutogo 2019 by Dinu P Madau 1999 Secure Programming for Linux and Unix HOWTO 28 kvitnya 2007 u Wayback Machine by David A Wheeler Proactive Debugging article by Jack Ganssle 2001 02 26 Defensive programming 15 serpnya 2010 u Wayback Machine article by Rob Manderson 2004 08 06 The art of defensive programming Or how to write code that will be easy to maintain 13 chervnya 2015 u Wayback Machine article by Jonathan West by Mark Dowd John McDonald and Justin Schuh Solid Software 9 travnya 2015 u Wayback Machine by Shari Lawrence Pfleeger Les Hatton and Charles C Howell has a section on Defensive Programming Defensive Programming 2 lipnya 2015 u Wayback Machine by Andrew Phillips William R Cheswick and Steven M Bellovin Firewalls and Internet Security Repelling the Wily Hacker ISBN 0 201 63357 4 http www wilyhacker com 11 lipnya 2015 u Wayback Machine Cya stattya potrebuye dodatkovih posilan na dzherela dlya polipshennya yiyi perevirnosti Bud laska dopomozhit udoskonaliti cyu stattyu dodavshi posilannya na nadijni avtoritetni dzherela Zvernitsya na storinku obgovorennya za poyasnennyami ta dopomozhit vipraviti nedoliki Material bez dzherel mozhe buti piddano sumnivu ta vilucheno sichen 2016 Ce nezavershena stattya pro programuvannya Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi