25 найнебезпечніших програмістських помилок
Січень 14th, 2009Я намагатимусь не публікувати тут різні новини, бо цей блоґ не для кроспостингу, однак, цього разу маю зробити вийняток, оскільки, новина цікава, важлива, до того ж, це переклад з англійської.
Так от, інститут SANS (SysAdmin, Audit, Network, Security) співпрацюючи з організацією MITRE опублікував перелік 25 найнебезпечніших помилок, які призводять до виникнення серйозних вразливостей у програмному забезпеченні. Помилки відбирались з урахуванням їх розповсюдженості, складності знаходження і простоти використання для здійснення шкідливих дій.
Небезпечна взаємодія між компонентами
Визначає проблеми, викликані небезпечною відправкою і отримання між модулями, програмами, процесами, потоками, або системами.
Переконайтеся у тім, що ваші вхідні дані правильні. Якщо ви очікуєте число, там не повинно бути букв. Так само, як і ціна нового автомобіля не може бути бути рівною одного долара. Неправильна перевірка введених даних може призвести до вразливостей, коли зловмисник здатен змінювати введені дані несподіваним способом. Багатьох найбільш загальних вразливостей можна уникнути або хоча б скоротити за допомогою суворої перевірки введених даних.
Недостатнє кодування даних, що виводяться – корінь більшості атак, заснованих на ін’єкціях. Атакуючий може змінювати команди, які ви повинні пересилати іншим компонентам, що може привезвести до повної компрометації вашої програми – я вже не кажу про виконання експлїтів на інших компонентах, які зловмисник не може запустити напряму. Якщо ваша програма генерує вивід для інших компонентів у вигляді структурованих повідомлень, таких як запити, переконайтеся у тім, що управляюча інформація та метадані відокремлені безпосередньо від самих даних.
Якщо зловмисники можуть впливати на SQL, який ви відправляєте базі даних, вони можуть змінити ваші запити щоб вкрасти, пошкодити або змінити дані в ній. Якщо ви використовуєте SQL запити для управління безпекою, наприклад, аутентифікації, зловмисники можуть змінити логіку цих запитів і обійти захист.
Міжсайтовий скриптинг (XSS) – результат об’єднання HTTP, який по своїй природі не зберігає стан, суміші даних і скриптів в HTML, великих об’ємів даних, переданих між веб-сайтами, різноманітних схем кодування і багатофункціональних веб-браузерів. Якщо ви недостатньо уважні, зловмисники можуть впровадити Javascript чи інший виконуваний у браузері код на сторінку, яку генерує ваш додаток. Потім вашу сторінку відвідують інші користувачі, чиї браузери виконують цей шахрайський скрипт так, ніби він прийшов від вас – адже, зрештою, він дійсно прийшов від вас! Неочікувано ваш веб-сайт надає код, який ви не писали. Зловмисники можуть використовувати різні прийоми, щоб впровадити такий код на ваш сервер безпосередньо або з використанням нічого не підозрюючих жертв в якості посередників.
Ваша програма працює, як міст між сторонньою людиною в мережі та нутрощами вашої операційної системи. Якщо ви запускаєте інші програми в операційній системі, яка дозволяє передати сумнівні параметри в командний рядок, ви запрошуєте зловмисників до своєї операційної системи.
Інформація, що передається по мережі, проходить безліч різних вузлів на шляху до кінцевої точки. Якщо ваша програма відсилає важливу, особисту інформацію або дані аутентифікації, стережіться: зловмисники можуть перехопити її по дорозі. Все, що їм потрібно – отримати контроль над одним з вузлів на шляху до кінцевої точки, будь-яким вузлом в тій же підмережі транзитних вузлів, або підключитися по доступному інтерфейсу. Обфускація трафіку за допомогою base64 або кодування URL не дає ніякого захисту.
Підробка міжсайтових запитів – це як взяти посилку від кого попало – з тією різницею, що зловмисник змушує користувача активувати HTTP запит, який йде на ваш сайт. Користувач може навіть не здогадуватися, що запит надіслано, однак, коли той потрапляє на сервер, він виглядає так, ніби прийшов від користувача, а не зловмисника. Зловмисник маскується під легітимного користувача, і отримує всі можливі права, які має користувач. Це особливо дієво, коли користувач має привілеї адміністратора, повністю компрометуючи функціональність вашого додатка.
Стан гонки підтримує множинні процеси, в яких зловмисник має повний контроль над одним із них; зловмисник використовує процес для створення хаосу, колізій або помилок. Вплив може бути локальним або глобальним, в залежності від того, що впливає на стан гонки (наприклад, стан змінних або логіку безпеки), а також виникає між кількома потоками, процесами або системами.
Надмірно інформативні повідомлення про помилки можуть розкрити секрети будь якому зловмиснику, який використовує вашу програму. Ці секрети можуть відноситись до широкого спектру важливих даних, включаючи персональну інформацію, дані аутентифікації та конфігурацію сервера. Ці дані можуть виглядати, як невинні секрети, зручні користувачам і адмістратором, наприклад, повний шлях встановлення вашої програми – але навіть ці маленькі таємниці можуть допомогти зловмиснику провести більш сплановану атаку.
Ризиковане управління ресурсами
Визначає проблеми, пов’язані з неправильним створенням, керуванням, використанням, передачою, або знищенням важливих системних ресурсів.
Велика кількість додатків на С за десятиліття стали надзвичайно стійкими до переповнення буферу. Способи атаки і виявлення продовжують поліпшуватися, і сьогоднішні методи переповнення буферу не очевидні на перший або навіть і на другий погляд. Ви можете вважати, що повністю захищені від переповнення буферу, оскільки пишете свій код на більш високорівневих мовами, ніж С. Але на чому написаний інтерпретатор вашої улюбленої “безпечної” мови? А, як щодо Native-коду, який ви викликаєте? На яких мовах написаний API оперціонной системи? Як щодо програм, які забезпечують інфраструктуру Інтернету?
Якщо ви зберігаєте дані користувачів про стан там, де зловмисник може їх змінити, це зпростить йому життя. Дані можуть бути збережені у конфігураційних файлах, профайлах, куках, схованих полях форм, змінних оточення, ключах реєстру, або інших місцях, де вони можуть бути змінені зловмисником. У протоколах без збереження стану, таких як HTTP, деякі форми спеціальної інформації про стан можуть бути перехоплені в кожному запиті, тобто вони відкриті зловмисникові без необхідності. Якщо ви, грунтуючись на цих даних, здійснюйте будь-які критичні з точки зору безпеки операції, можете поставити на то, що хтось змінить ці дані таким чином, щоб обдурити ваш додаток.
Якщо ви використовуєте введені дані для побудови імені файлу, шлях, що буде результатом операції, може вказувати зовсім не на призначену теку. Зловмисник може зкомбінувати декілька “..” або схожих послідовностей, щоб вибратися за межі визначеної теки. Інші атаки пов’язані з файлами, спрощуються при зовнішньому контролі імені файлу, наприклад, перехід за символьними посиланнями, що призводить до того, що ваша програма зчитує або змінює файли, до яких зловмисник не має прямого доступу. Те ж саме застосовується, коли ваш додаток запущено з надто високими привілеями, і приймає ім’я файлу в якості вхідних даних. Схожі правила вірні й для адрес URL та дозволів стороннім вказувати довільні адреси.
Ваша програма залежить від вас, або від свого оточення, в плані надання шляху пошуку (або робочого шляху) критичних ресурсів, таких як бібліотеки або конфігураційні файли. Якщо шлях пошуку знаходиться під контролем зловмисника, він може змінити його, щоб він вказував на ресурси, обрані ним.
Безсумнівно, складно заперечувати сексуальність динамічно генерировано коду, однак, зловмисники знаходять його не менш привабливим. Серйозна вразливість виникає, коли ваш код може бути безпосередньо викликаний неавторизованими користувачами, якщо зовнішні вхідні дані впливають на код, який буде виконуватися, або ж ці дані вбудовуються безпосередньо у сам код.
Якщо ви звантажуєте код і виконуєте його, ви вірите, що джерело цього коду не шахрайське. Але зловмисники можуть змінити цей код до того, як він досягне вас. Вони можуть зламати сайт, з якого ви його звантажуєте, зімітувати його за допомогою спуфінгу DNS або «отруєнням» кешу, переконати систему зробити перенаправлення на інший сайт або ж навіть змінити код на шляху по мережуі. Цей сценарій може застосовуватись навіть до випадків, коли ваш власний продукт звантажує і встановлює оновлення.
Коли ваші системні ресурси досягають «кінця свого життя», ви просто позбуваєтесь їх: пам’ять, файли, куки, структури даних, сесії, канали зв’язку і так далі. Зловмисники можуть використовувати невірні закриття для утримання контролю над цими ресурсами, коли ви уже вважаєте, що позбулися них. Зловмисники можуть просіювати їх у пошуках важливих даних. Вони також, теоретично, можуть використовувати ці ресурс повторно.
Якщо ви не ініціалізуєте ваші дані і змінні правильно, зловмисник може мати можливість ініціалізувати їх за вас або отримати важливу інформацію, що залишилася від минулих сесій. Якщо ці змінні використовуються в критичних з точки зору безпеки операцій, таких, як прийняття рішення про аутентифікацію, вони можуть бути змінені для обходу вашої захисту. Це – найбільш імовірна причина, чому ваш код раптом проскакує ініціалізацію при дивних помилки та умовах.
Коли зловмисники контролюють вхідні дані для чисельних обчислень, математичні помилки можуть мати наслідки для безпеки. Вони можуть змусити вас виділити значно більше ресурсів, ніж це необхідно – або значно менше. Вони можуть порушити бізнес-логіку (обчислення, які повертають негативну ціну) або викликати відмову в обслуговуванні (ділення на нуль, що призводить до краху програми).
Ненадійний захист
Визначає проблеми, пов’язані з неправильним використанням, ігноруванням або ж зловживанням засобами захисту.
Якщо ви не перевіряєте, що користувачі програми роблять тільки те, що їм дозволено робити, зловмисники намагатимуться використовувати невірну авторизацію і погратися з несанкціонованою функціональністю.
Самопальна криптографія – запрошення для зловмисників. Криптографія складна. Якщо геніальні математики та комп’ютерні фахівці не можуть дати їй ладу – а вони періодично визнають застарілими свої власні методи – і у вас не вийде.
Якщо пароль один і той же в усіх ваших програмах, кожен ваш клієнт стає вразливим, як тільки цей пароль стає відомим. А оскільки він жорстко прописаний в коді, виправити це – великий головний біль.
Стережіться критичних програм, сховищ даних і конфігураційних даних з читабельними дозволами за замовчуванням. Хоча ця проблема може і не розглядатися під час реалізації або розробки, вона повинна. Не вимагайте від ваших клієнтів робити ваш додаток безпечним за вас! Спробуйте забезпечити безпеку за замовчуванням, з коробки.
Ви можете залежати від випадковості, навіть коли не підозрюєте про це, наприклад, при генерації ідентифікаторів сесії або тимчасових імен файлів. Генератор псевдовипадкових чисел (ГПВЧ, PRNG) використовуються повсюдно, однак, багато речей може піти неправильно. Як тільки зловмисник зможе визначити, який алгоритм використовується, він зможе вгадувати наступне випадкове число досить часто для проведення успішної атаки після відносно невеликої кількості спроб.
Вашій програмі можуть знадобитися спеціальні привілеї для виконання певних операцій; володіння цими привілеями довше, ніж це необхідно, ризиковане. Під час роботи з екстра привілеями, ваш додаток має доступ до ресурсів, які користувачі програми не можуть використовувати напряму. Кожен раз, коли ви запускає окрему програму з підвищеними привілеями, зловмисники теоретично можуть використовувати ці привілеї.
Не довіряйте клієнту проводити перевірку безпеки від імені сервера. Зловмисники можуть проаналізувати ваш додаток і написати свій власний клієн. Наслідки залежать від того, хто захищає ваші перевірки безпеки, але основні цілі – аутентифікація, авторизація та перевірка введених даних.