<
  • Главная
Статьи

Запобігання підробки міжсайтових запитів: прихована небезпека на вкладках браузера

  1. сценарій проникнення
  2. Малюнок 1. Приклад зображення аватара з сайту AltorJ Community
  3. Таблиця 1. Приклад аватара в повідомленні на форумі сайту AltorJ Community
  4. Таблиця 2. Вказівка ​​аватара користувача
  5. Таблиця 3. Зловмисник вказує аватар
  6. Малюнок 2. Приклад повідомлення зловмисника, в якому не відобразився аватар
  7. Лістинг 1. Приклад коду шахрайської сторінки
  8. Захист проти XSRF
  9. Рішення з використанням заголовка refere
  10. Лістинг 2. Приклад шахрайського запиту, що відправляється на сервер
  11. Рішення з використанням маркера
  12. Лістинг 3. Приклад рішення з використанням маркера
  13. Лістинг 4. Приклад HTTP-заголовка з маркером XSRF Token
  14. Лістинг 5. Установка маркера заголовка
  15. Захист всієї інфраструктури
  16. Лістинг 6. Спадкування від базового класу
  17. Позитивні побічні ефекти маркера XSRF
  18. Ресурси для скачування

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

IBM Security AppScan Standard

Програма IBM® Security AppScan® Standard дозволяє знайти в додатку потенційно вразливі місця типу XSRF (підробка міжсайтових запитів). Завантажте з Web-сайту developerWorks ознайомчу версію IBM Security AppScan Standard .

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

Виявляється, інші Web-сайти, відкриті на вкладках браузера, можуть виконувати дії від вашого імені.

Припустимо, на одній вкладці ви відкрили ваш сайт в соціальній мережі, а в іншій - невідомий вам сайт під назвою many_ads.com, який виявляється шахрайським. Сайт many_ads.com може публікувати повідомлення на вашому сайті в соціальній мережі. Ця дія називається підробкою міжсайтових запитів (скорочено XSRF або CSRF).

Хоча подібна шахрайська публікація неприємна і створює незручності, вона не є проблемою. Таку публікацію завжди можна видалити.

Однак XSRF-атака може коштувати дуже дорого. Якщо ваш банківський сайт вразливий для XSRF-атаки, гроші з вашого рахунку можуть переводитися на невідомий зарубіжний рахунок, і швидше за все це вже сталося. Згідно log-файлів сервера це зробили саме ви.

сценарій проникнення

Припустимо, що вигаданий банк Altoro Mutual має сторінку для відправки грошових переказів на конкретний номер рахунку. Запит може виглядати так:

http://www.altoromutual.com/bank/transfer.aspx?creditAccount=1001160141&transferAmount=1000

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

Він може відправити це посилання по електронній пошті:

Шановний клієнт Altoro Mutual!

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

Скористайтесь будь ласка, наступного посиланням .

Однак такий лист розкриває наміри зловмисника, особливо коли користувач потрапляє на сторінку, в якій мовиться: Перерахування 1000 $ на рахунок 1001160141 успішно виконано.

Але що якщо зловмисник зробить так, що користувач перейде за цим посиланням ненавмисно?

Зловмисник може скористатися тим, що багато клієнтів Altoro Mutual часто відвідують фінансовий форум. На сайті вигаданого банку Altoro Community можна створювати аватари, які включаються в повідомлення на форумі.

Аватар для форуму - це зображення, наприклад така фігурка людини:

Малюнок 1. Приклад зображення аватара з сайту AltorJ Community
Навчіться запобігати підробку міжсайтових запитів, інакше ваші клієнти можуть здійснити хакерської проникнення, не підозрюючи про це   IBM Security AppScan Standard   Програма IBM® Security AppScan® Standard дозволяє знайти в додатку потенційно вразливі місця типу XSRF (підробка міжсайтових запитів)

Аватар в повідомленні користувача може виглядати так, як в цьому прикладі:

Таблиця 1. Приклад аватара в повідомленні на форумі сайту AltorJ Community

Сайт спільноти дозволяє користувачам вказувати URL свого аватара. Зазвичай аватар вказується шляхом заповнення поля, як в цьому прикладі:

Таблиця 2. Вказівка ​​аватара користувача

Приклад поля Приклад URL Вкажіть ваш аватар: http: //some_image_site_found_with_google/random_image.jpg

Що якщо замість посилання на аватар зловмисник використовує посилання на сторінку перекладу? наприклад:

Таблиця 3. Зловмисник вказує аватар

Приклад поля Приклад URL Вкажіть ваш аватар: http://www.altoromutual.com/bank/transfer.aspx?creditAccount=1001160141&transferAmount=1000

Тепер кожен раз, коли користувач відвідує форум спільноти і звертається до повідомлення, опублікованого зловмисником, при спробі браузера завантажити аватар виконується запит. Зображення аватара зловмисника не завантажується. Кожен користувач, який звернувся до цього повідомлення, переводить гроші на рахунок зловмисника, якщо в іншій вкладці браузера цей користувач виконав вхід на сайт онлайн-банкінгу Altoro Mutual.

Малюнок 2. Приклад повідомлення зловмисника, в якому не відобразився аватар

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

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

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

Сторінка шахрайського сайту може виглядати як сторінка в лістингу 1.

Лістинг 1. Приклад коду шахрайської сторінки

<Html> <body onLoad = "document.getElementById ( 'transferForm'). Submit ()"> <form id = "transferForm" action = "http://www.altoromutual.com/bank/transfer.aspx" method = "post"> <input type = "hidden" name = "creditAccount" value = "1001160141"> <input type = "hidden" name = "transferAmount" value = "10"> </ form> </ body>

Зверніть увагу, що ця форма відправляється автоматично при завантаженні URL-адреси. Ніяких дій від користувача не потрібно.

Захист проти XSRF

Що можуть зробити розробники сайту банку, щоб запобігти подібним атаки? Розглянемо кілька способів запобігання XSRF-атак.

Рішення з використанням заголовка refere

Найпростіший спосіб заснований на заголовку referer браузера. Більшість браузерів повідомляє Web-сервера, яка сторінка відправила запит. У лістингу 2 показаний шахрайський запит, що відправляється браузером на сервер:

Лістинг 2. Приклад шахрайського запиту, що відправляється на сервер

POST /bank/transfer.aspx HTTP / 1.1 Referer: http://evilsite.com/myevilblog User-Agent: Mozilla / 4 .... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId = x3q2v0qpjc0n1c55mf35fxid; creditAccount = 1001160141 & transferAmount = 10

Розробники можуть відхилити будь-який запит, якщо заголовок referer не збігається з ім'ям домена хоста банку. наприклад:

If (request.getHeaders ( "referer")! = Null && request.getHeaders ( "referer"). IndexOf ( "http://www.altoromutual.com")! = 0) {throw new Exception ( "Invalid referer") ; }

Крім того, можна вказати список дозволених URL-адрес, якщо запит повинен виконувати довірений сайт.

Цей спосіб можна застосувати до базового класу сервлета або сторінки, щоб всі сторінки сайту успадкували цей захист. Будьте обережні, тому що посилання на Altoro з інших сайтів працювати не будуть. Наприклад, користувачі сайту Altoro не зможуть звернутися до нього з Google.

GET / marketingannouncements HTTP / 1.1 Referer: http://www.google.com

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

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

Перевагою рішення з використанням referer є його сумісність з попередніми версіями інших HTTP-взаємодій, таких як Web-сервіси. Наприклад, якщо клієнтське мобільний додаток засноване на REST API, дане рішення прозоро для клієнта, тому що клієнт не використовує заголовок referer.

Якщо сумісність з більш ранніми версіями не важлива, є більш надійні рішення, такі як використання маркера для припинення дії чутливих запитів.

Рішення з використанням маркера

Рішення з використанням маркера засноване на додаванні в форму параметра, який припиняє її дію після перевищення часу очікування або при виході користувача з системи. Див. Лістинг 3.

Лістинг 3. Приклад рішення з використанням маркера

<Form id = "transferForm" action = "https://www.altoromutual.com/bank/transfer.aspx" method = "post"> Enter the credit account: <input type = "text" name = "creditAccount" value = ""> Enter the transfer amount: <input type = "text" name = "transferAmount" value = ""> <input type = "hidden" name = "xsrftoken" value = "JKBS38633jjhg0987PPll"> <input type = "submit "value =" Submit "> </ form>

Не використовуйте маркер як параметр запиту, оскільки це зробить інформацію сеансу видимої в історії браузера або в Web-статистикою і аналітиці. Наступний запит, наприклад, складений невдало:

https://www.altoromutual.com/bank/getuserinfo.aspx?creditAccount=1001160141&transferAmount=1000& xsrftoken = JKBS38633jjhg0987PPll

Щоб гарантувати всеосяжний захист всіх видів запитів, які не вказуючи значення маркера в URL, використовуйте HTTP-заголовок. Приклад приведений в лістингу 4.

Лістинг 4. Приклад HTTP-заголовка з маркером XSRF Token

POST /bank/transfer.aspx HTTP / 1.1 Referer: https://www.altoromutual.com/bank xsrftoken: JKBS38633jjhg0987PPll User-Agent: Mozilla / 4 .... Host: www.altoromutual.com Content-Length: 42 Cookie : SessionId = x3q2v0qpjc0n1c55mf35fxid; creditAccount = 1001160141 & transferAmount = 10

HTTP-заголовок є основним рішенням в більшості сучасних додатків, все частіше використовують REST API і Ajax. Маркер заголовка встановлюється за допомогою коду, наведеного в лістингу 5.

Лістинг 5. Установка маркера заголовка

<Form id = "transferForm" action = "https://www.altoromutual.com/bank/transfer.aspx" method = "post"> Enter the credit account: <input type = "text" name = "creditAccount" value = ""> Enter the transfer amount: <input type = "text" name = "transferAmount" value = ""> <button onClick = "addXsrfHeaderAndSubmitForm (dojo.byId (transferForm))" value = "Submit"> </ form >

Захист всієї інфраструктури

Як і в рішенні з використанням referer, маркер найкраще перевіряти там, де виконується аутентифікація.

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

Лістинг 6. Спадкування від базового класу

class AuthenticatedServletBase extends ServletBase {protected bool service (...) {..... if (sessionUtil.getXsrfToken (). equals (requestUtil.getXsrfToken ()) == false) {showXSRFTokenError (); return true; // handled..stop any further processing here} ....}}

Позитивні побічні ефекти маркера XSRF

Крім захисту від XSRF-атак, заголовок з маркером забезпечує додаткові переваги в запобіганні на стороні клієнта інших видів атак на захищені сторінки:

  • Атака типу JSON Hijacking.
  • Відбитий міжсайтовий скриптинг.
  • Фішинг з використанням перенаправлення URL.

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

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

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

Схожі теми

Підпишіть мене на повідомлення до коментарів

Aspx?
Але що якщо зловмисник зробить так, що користувач перейде за цим посиланням ненавмисно?
Aspx?
Aspx?


Новости
  • Виртуальный хостинг

    Виртуальный хостинг. Возможности сервера распределяются в равной мере между всеми... 
    Читать полностью

  • Редизайн сайта

    Редизайн сайта – это полное либо частичное обновление дизайна существующего сайта.... 
    Читать полностью

  • Консалтинг, услуги контент-менеджера

    Сопровождение любых интернет ресурсов;- Знание HTML и CSS- Поиск и обновление контента;-... 
    Читать полностью

  • Трафик из соцсетей

    Сравнительно дешевый способ по сравнению с поисковым и контекстным видами раскрутки... 
    Читать полностью

  • Поисковая оптимизация

    Поисковая оптимизация (англ. search engine optimization, SEO) — поднятие позиций сайта в результатах... 
    Читать полностью