Забезпечення безпеки настільних і мобільних Web 2.0-додатків

1. Поширені Web-уразливості
2. Міжсайтовий виклик скриптів
3. Малюнок 1. Демонстраційний Web-сайт Altoro Mutual AppScan
4. Малюнок 2. У результатах пошуку завжди відображається елемент пошуку
5. Малюнок 3. Введення JavaScript-коду в якості вираження пошуку призводить до виконання цього коду
6. впровадження SQL
7. Малюнок 4. Спроба входу з довільним паролем і фрагментом SQL-коду в якості імені користувача
8. Витік інформації
9. Малюнок 6. Додаток явно вказує, що такого користувача немає
10. Малюнок 7. Додаток Altoro Mutual повідомляє про існування користувача jsmith
11. модифікація параметрів
12. підробка cookie
13. Інтеграція системи безпеки в процес розробки
14. Автоматизація тестування системи безпеки в процесі розробки
15. Висновок
16. Ресурси для скачування

Системи управління доступом, мережеві екрани, системи виявлення вторгнень і системи запобігання вторгнень є невід'ємними складовими частинами системи безпеки додатків, що забезпечують захист периметра. Однак ці механізми не повністю захищають Web-додатки від атак. Оскільки ці додатки використовують Web-технології, самі принципи взаємодії Web-користувачів з ними дозволяють безпосередньо атакувати додатки і обходити встановлені системи захисту периметра. Зловмисники знають про це, і саме тому більшість атак - це прямі атаки на Web-додатки.

Щоб вирівняти баланс, розробники додатків повинні вивчати стратегії захисту проти атак. Також вони повинні враховувати кілька факторів, що є причиною цілого ряду атак:

• У своїй більшості розробники Web-додатків не є експертами в області безпеки і можуть не знати про багатьох вразливості.
• Багато розробники не знайомі з передовими методиками захисту Web-додатків.
• Часто головним пріоритетом є функціональність, а питання безпеки вирішуються пізніше шляхом модернізації готового додатка.
• Середовище, в якому розгортаються Web-додатки, змінюється з великою швидкістю, включно із оновленнями самого коду, а також інфраструктури. Деякі з цих змін не перевіряються і не тестуються професіоналами в області безпеки додатків.

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

1. Навчайтеся.
2. Шукайте готові рішення.
3. Інтегруйте тестування в план розробки.
4. Виявляйте уразливості на ранніх етапах.

Ця стаття покликана підвищити рівень інформованості розробників. У ній розповідається про найбільш поширених вразливості Web-додатків, що використовують технологію Web 2.0. Також наводиться коротка інформація про проблеми безпеки, властивих мобільних пристроїв.

Поширені Web-уразливості

Мобільні Web-додатки багато в чому схильні до тих же уязвимостям, які притаманні настільним Web-додатків. Більш детальна інформація про уразливість і контрзаходи приведена в проекті Top 10 Project на Web-сайті Open Web Application Security Project (OWASP), посилання на який можна знайти в розділі ресурси .

У наступних підрозділах розглядається кілька основних вразливостей, про які повинні знати розробники.

Міжсайтовий виклик скриптів

При цьому поширеною атаці шкідливий код впроваджується в автентичний Web-сайт. Якщо в HTML-код, що відображається сторінки можна вставити вхідні дані HTTP-запиту, сайт відкритий для таких атак.

Наприклад, сервіс приймає параметр image для вилучення з файлової системи зображення і його обробки:

http: // somedomain / myImageProcessor? image = myimage.jpg

Зловмисник може досліджувати це додаток, вставляючи JavaScript-код в параметр image. Мета - виявити неправильну обробку помилок. Якщо вийде згенерувати повідомлення про помилку, що містить шкідливий скрипт, зловмисник може використовувати це в своїх інтересах:

http: // somedomain / myImageProcessor? image = myimage.jpg <script> ..вредоносний код .. </ script>

Якщо повідомлення про помилку повертає вміст параметра image без фільтрації, виконується код, укладений в теги <script>. Скрипт потенційно може отримати доступ до локальних cookie-файлів, що атакується Web-сторінки або навіть змінити вміст відображається сторінки. Цю вразливість можна використовувати для розсилки інфікованих посилань по електронній пошті або включення їх в зловмисні Web-сторінки.

Ця концепція показана на Web-сайті Altoro Mutual, який демонструє можливості програми IBM® Rational® AppScan® Standard Edition по скануванню додатків на наявність вразливостей (див. Розділ ресурси ).

Малюнок 1. Демонстраційний Web-сайт Altoro Mutual AppScan

На малюнку 2 показано, що елемент пошуку "pineapples" відображається в результатах пошуку незалежно від того, знайдений він чи ні.

Малюнок 2. У результатах пошуку завжди відображається елемент пошуку

Це говорить про те, що додаток вразливе до атак за допомогою виконання міжсайтових скриптів. На малюнку 3 показаний результат пошуку виразу <script> alert ( 'attack') </ script>. Код сценарію повертається в результатах пошуку і виконується, після чого відображається вікно з попередженням.

Малюнок 3. Введення JavaScript-коду в якості вираження пошуку призводить до виконання цього коду

контрзаходи

Для запобігання виконання міжсайтових скриптів (XSS):

• Чи не відображуйте користувачам неперевірені вхідні дані.
• Видаляйте шкідливий код з вхідних і вихідних даних шляхом, наприклад, фільтрації або використання білого списку (визначаючи допустимі дані і забороняючи всі інші).
• Кодуйте вихідні дані для запобігання виконання браузером.

У випадку з Altoro Mutual простим рішенням міг би стати заборона на повернення елемента пошуку.

Більш детальне обговорення міжсайтових скриптів і захисту від них приведено в статті developerWorks® IBM Rational AppScan: детально про міжсайтових скриптах, а також на сторінці Cross-site Scripting сайту OWASP (див. Розділ ресурси ).

впровадження SQL

Ця атака теж пов'язана з використанням вразливостей в запитах і спрямована на вставку SQL-виразів в поля Web-додатки, призначені для введення даних. Можливість вставляти запити в поля введення дозволяє зловмисникові обійти механізми аутентифікації Web-сайту і отримати доступ до бази даних. Ця атака, поряд з виконанням міжсайтових скриптів, є однією з найпоширеніших.

Наведений нижче приклад демонструє погано сконструйовану процедуру входу, в яку впроваджується SQL:
Web-додаток запитує ім'я користувача та пароль, для чого використовується наступне SQL-вираз:

String query = "SELECT * FROM users WHERE user = '" username + "' AND password = '" passwd "'";

Змінні username і password ніяк не очищається, і їм присвоюються значення, введені користувачем у додатку. Це дозволяє зловмисникові як username ввести, наприклад, наступне:

anything 'OR 1 = 1 -

Пароль може бути будь-яким. В даному випадку припустимо, що це * (зірочка).

Після підстановки цих даних в змінні username і password сформований запит буде виглядати наступним чином:

SELECT * FROM users WHERE username = 'anything' OR 1 = 1 - AND password = '*'

Цей вислів перетворює пароль в коментар і вставляє умова 1 = 1, яке завжди істинно. Зловмисник буде визначено як дозволений користувач, хоча він не надав ніяких даних, що підтверджують його повноваження.

Ця атака демонструється Web-додатком Altoro Mutual (див. Малюнок 4). Перейдіть на сторінку входу, введіть в якості імені користувача anything 'OR 1 = 1 -, і будь-який введений в якості пароля символ надасть вам адміністративний доступ до додатка (малюнок 5). Цей обліковий запис може керувати обліковими записами інших користувачів.

Малюнок 4. Спроба входу з довільним паролем і фрагментом SQL-коду в якості імені користувача

Малюнок 5. Після виконання атаки з використанням впровадження SQL зловмисник входить в систему як адміністратор

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

контрзаходи

Для запобігання цієї атаки:

• Не довіряйте даними, які вводяться користувачем.
• Виконуйте їх очищення - наприклад, за допомогою фільтрації або використання білого списку.

У разі Altoro Mutual можливим рішенням є фільтрація всіх вступників з полів Username і Password символів, відмінних від цифр і букв.

Детальна інформація про впровадження SQL і можливі способи протидії приведена на сторінці SQL Injection сайту OWASP (див. Розділ ресурси ).

Витік інформації

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

• Вручну досліджувати додаток для пошуку прихованих каталогів.
• Систематично викликати виняткові ситуації і переглядати детальну інформацію про них.
• Сканувати HTML в пошуках коментарів, які розкривають деталі інфраструктури і поведінки програми.
• Систематично вводити різні імена користувачів для пошуку існуючих облікових записів.

Додаток Altoro Mutual допускає витік існуючих в системі імен користувачів. Наприклад (див. Рисунок 6), введення неправильного імені та пароля користувача призводить до появи наступного повідомлення про помилку "Login Failed: We're sorry, but this user name was not found in our system. Please try again" (Під вході відмовлено: на жаль даний користувач не знайдений в системі. Спробуйте ще раз).

Малюнок 6. Додаток явно вказує, що такого користувача немає

Далі зловмисник вводить ім'я jsmith, і Web-додаток Altoro Mutual видає наступне повідомлення: "Login Failed: Your password appears to be invalid. Please re-enter your password carefully" (Під вході відмовлено: ваш пароль невірний. Введіть пароль повторно). З цієї інформації зловмисник дізнається про існування облікового запису jsmith. Отже, він може сконцентруватися на зломі пароля і спробувати вгадати його, виконуючи так звану атаку методом "грубої сили" (brute force attack).

Малюнок 7. Додаток Altoro Mutual повідомляє про існування користувача jsmith

Дану ситуацію можна виправити, виводячи стандартне повідомлення, що не вказує конкретно, що сталося, наприклад: "Login failed: User name or password invalid. Please re-enter your credentials carefully" (Під вході відмовлено: ім'я користувача або пароль введені невірно. Спробуйте ще раз).

контрзаходи

Витік інформації необхідно розглядати в контексті програми, і кращим захистом є компетентність розробника. Існують різні заходи щодо пом'якшення наслідків витоку інформації, які слід розглянути розробникам.

• Видаляйте з HTML-коду всі коментарі, повідомляють щось про програму.
• Чи не відображуйте в браузері конкретні виняткові ситуації. Якщо ведеться журнал виняткових ситуацій, зберігайте їх на сервері і відображуйте узагальнену помилку.
• Чи не розкривайте інформацію про те, на якому етапі аутентифікація завершилася невдало.
• Крім того, налаштуйте Web-сервер і сервер додатків на запобігання довільній навігації по Web-сайту і з додатком.

Цей список жодним чином не претендує на повноту. Необхідно враховувати специфіку програми та робочого середовища.

Додаткова інформація про витік інформації наведена на сторінці Information Leakage сайту OWASP.

модифікація параметрів

Ця атака націлена на управління параметрами, переданими в додаток. Розглянемо погано написане додаток, що дозволяє клієнту встановлювати вартість товару, що купується. Таке додаток може відправляти наступний запит:

http: // somedomain / myStore? item = одна тисяча двісті тридцять чотири & price = $ 200

Якщо бізнес-логіка не виконує подвійну перевірку на стороні сервера, зловмисник може змінити вартість, щоб отримати товар за меншою ціною. В даному випадку дозвіл установки ціни з боку клієнта є явною помилкою.

контрзаходи

• Для виправлення цієї конкретної ситуації можна змінити код, щоб отримувати ціну з бази даних на стороні сервера, запобігаючи маніпуляцію ціною.
• Захист від такої атаки включає в себе перевірку параметрів і ретельний аналіз логіки додатка.

Додаткова інформація про модифікацію параметрів і можливі контрзаходи приведена на сторінці Web Parameter Tampering сайту OWASP (див. Розділ ресурси ).

підробка cookie

Cookie являє собою інформацію, що зберігається у вигляді пар ключ / значення в текстовому файлі або в пам'яті і відправляється сервером в браузер. Вміст cookie використовується створив його Web-додатком. Підробка cookie - це зміна його вмісту після виконання Web-додатки. Ця атака аналогічна модифікації параметрів.

контрзаходи

• Контрзаходи проти підробки cookie включають в себе перевірку параметрів і ретельний аналіз логіки і коду програми.

• Також можуть застосовуватися просунуті механізми захисту.
  • Загальноприйнятим підходом є використання цифрових підписів, які гарантують відсутність змін сховища текстових файлів.
  • Ще однією контрзаходом є захист cookie шляхом шифрування при передачі для зниження ризику зміни і перехоплення.

Підробка cookie обговорюється на сторінці OWASP, присвяченій уязвимостям через введення неперевірених даних (див. Розділ ресурси ).

Інтеграція системи безпеки в процес розробки

Система безпеки стає важливою складовою розробки Web-додатків, в тому числі мобільних. Багато організацій основну увагу приділяють реалізації функціональності. Однак врахуйте, що усунення вразливостей в системі безпеки коштує недешево. Тому розумно включити аналіз і тестування системи безпеки до складу процесу розробки.

Захист найбільш ефективна, коли вона повністю інтегрована в процес розробки - від проектування до розгортання.

При проектуванні необхідно ідентифікувати захищається інформацію, можливі ризики і доступні контрзаходи. По можливості запрошуйте експертів з систем безпеки для обговорення і прийняття рішень на самих ранніх етапах. Це знизить ймовірність виявлення вразливостей на більш пізніх етапах циклу розробки. Пізніше виявлення призводить до неоптимальним і недешевим рішенням по модернізації. Створюйте практичні сценарії для тестування на етапі проектування. Це допоможе організувати інтегрований процес тестування по всьому циклу розробки. Покрокове тестування системи безпеки (наприклад, тестування можливості несанкціонованого доступу) на етапі розгортання допомагає організації накопичити навички, що забезпечують розробку хороших додатків.
Етап розробки Проінформуйте розробників про найбільш поширених вразливості і навчіть їх передовими методиками написання захищеного коду. При перевірці коду особливу увагу приділіть проблемам безпеки, залучаючи професіоналів у цій галузі. Виконайте тести системи безпеки, проаналізуйте їх і включіть в набори автоматизованих тестів. Заплануйте час на усунення проблем в системі безпеки, виявлених при перевірці та тестуванні коду.
Етап розгортання Ретельно протестуйте готове додаток на етапі дослідної експлуатації. Даний етап тестування може включати в себе аналіз можливості несанкціонованого доступу до додатка, що виконується групою сторонніх розробників або автоматизованими засобами сканування системи безпеки. Критерії для остаточного затвердження зазвичай диктує практика ІТ-керівництва.
Етап управління Після розгортання періодично спостерігайте за додатком і його оточенням з метою виявлення атак і вразливостей, використовуючи засоби сканування, тестування можливості несанкціонованого доступу і аудит файлів журналів. Створіть чіткий процес безпечного зміни середовища і застосування пакетів виправлення помилок для додатка.

Автоматизація тестування системи безпеки в процесі розробки

На практиці автоматизація є ключовим аспектом створення повторюваного і цілісного процесу тестування системи безпеки протягом циклу розробки. Продукти IBM Rational AppScan надають кошти, які можуть сканувати код, допомагаючи розробникам розібратися в уразливості. Автоматизовані засоби сканування можна повторно використовувати після розробки для моніторингу розгорнутих додатків. Це дозволить продовжити моніторинг розгорнутих Web-додатків і виявити уразливості системи безпеки, що з'явилися в результаті змін додатки або інфраструктури.

Сімейство продуктів Rational AppScan забезпечує автоматизацію цієї діяльності на етапах розробки і розгортання.

етап розробки

• Rational AppScan Source Edition. Дана програма надає аналіз коду методом "білого ящика", допомагаючи розробникам додатків ідентифікувати проблеми на самих ранніх стадіях розробки. Також вона надає розробникам інформацію про можливі вразливості і поради щодо їх усунення.
• Rational AppScan Tester Edition. Для відділів забезпечення якості дана програма є інструментом автоматизації та інтеграції тестування системи безпеки в процес забезпечення якості. Тестировщики можуть додати її в свої середовища тестування, щоб інтегрувати тестування системи безпеки в процес тестування функціональності і продуктивності.
• Rational AppScan Build Edition. Ця версія підтримує інтеграцію сканування системи безпеки в процесі компонування. Вона інтегрується з системами управління компонуваннями (наприклад, Rational® Build Forge®), а також направляє розробникам звіти за допомогою ПО з управління дефектами (наприклад, Rational® Clear Quest®).

етап розгортання

• Rational AppScan Standard Edition. Ця програма допомагає тестувальник системи безпеки, віконуючі тестування Розгорнутим Додатки методом "чорної скриньки". Тестувальник вказує URL наявної програми (бажано дослідного екземпляр), а програма досліджує додаток и сканує на відомі уразлівості. В результаті створюється список розставлених відповідно до пріоритетів вразливостей разом з докладною інформацією по кожній з них і можливими заходами щодо усунення. Підтримується створення спеціалізованих звітів, які направляються групам розробки та управління.
• Rational AppScan Enterprise Edition. Це на багато користувачів Web-додаток, призначений для централізованого сканування додатків по всьому підприємству. Аналогічно Rational AppScan Standard Edition, воно сканує існуючі програми і генерує звіти зі списками вразливостей і завданнями щодо їх усунення. Додаток дозволяє призначати відповідальних за усунення проблем.

Посилання на додаткову інформацію по продуктах сімейства Rational AppScan наведені в розділі ресурси ; там же розміщено посилання на керівництво IBM® Red guide®, в якому описується автоматизація та інтеграція забезпечення безпеки в процес розробки за допомогою продуктів сімейства Rational AppScan.

Багато ризики для додатків і пристроїв є продовженням вразливостей настільних додатків. Розгляд сучасної практики ідентифікації та управління доступом виходить за рамки даної статті, але зазвичай керівництво Web-додатками охоплює наступні області:

• Сканування додатків на відомі уразливості.
• Управління доступом.
• Ідентифікація та аутентифікація користувачів.
• Ідентифікація кінцевих точок і управління ними.
• Шкідливе ПЗ.

У документі IBM® Redbooks® (див. Розділ ресурси ) Приведена додаткова інформація про те, як сімейство продуктів IBM сприяє інтеграції системи безпеки. Додаткову інформацію про сімействі продуктів IBM® Tivoli® можна знайти на Web-сторінці IBM Web Application Security Solutions.

Мобільні пристрої являють собою додаткове джерело проблем, оскільки за своєю природою є персоналізованими і переносяться. Мобільні пристрої легко втратити. Смартфон, вислизнув з кишені в таксі або літаку - вельми поширений сценарій. Крім того, через свого маленького розміру смартфони є об'єктами крадіжок. Тому до Web-програм, наявних з мобільних пристроїв, повинні застосовуватися додаткові заходи безпеки.

Такими додатковими заходами корпоративного керівництва при розгортанні мобільних пристроїв можуть бути:

• Багатофакторна аутентифікація. Скомбінуйте два методи аутентифікації, наприклад, пароль і пристрій для читання відбитків пальців (якщо він є в пристрої).
• Детальне управління доступом. Користувачі повинен мати доступ тільки до тих ресурсів, які потрібні їм для роботи, але не більше. Будь-який механізм управління доступом повинен бути якомога більш деталізованим.
• Обмеження доступу. Надавайте доступ до інтранет-ресурсів з Інтернету з використання віртуальних приватних мереж (VPN).
• Шифрування даних. Узгодьте можливості пристрою до вимог до конфіденційних даних.
• Управління. Якщо дозволений доступ до конфіденційної інформації, для вкрадених і (або) втрачених телефонів бажано передбачити безпечне стирання такої інформації.

Висновок

У Web 2.0-додатків, призначених для настільних і мобільних пристроїв, є багато спільних проблем безпеки і, отже, багато однакових способів їх вирішення. Розробники повинні знати про найбільш поширених вразливості і боротися з ними протягом усього циклу розробки. Для забезпечення безпеки додатки також необхідно постійне автоматичне сканування на наявність вразливостей в процесі розробки і розгортання. Мобільні пристрої мають свій власний унікальний набір проблем, оскільки за своєю природою є персоналізованими і переносяться. Заздалегідь, ще до розгортання мобільних рішень, продумайте захист даних при крадіжці або втраті пристрою.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів