Websecurity - Веб безпека

Нещадавно я згадував у записі Використання CSS для розкриття інформації про те, що можна визначити адреси сайтів, які відвідував користувач. І в тому числі локальні адреси - адреси сайтів в локальний мережі (в тому числі localhost). І дана інформація може бути використана для більш глибоких атак.

Також інформацію про локальні сайти можна дізнатися й іншим чином (через соціальну інженерію, віруси чи трояни, або вгадуванням чи простим перебором). І локальні сайти в свою чергу можуть бути більш вразливими і менш захищеними, бо менше перевірялися на предмет уразливостей (бо в адмінів може з’явитися помилкове уявлення, мовляв сайт локальний, за брендмауером, ніхто до нього не добереться - цю думку я й намагаюся змінити).

Зокрема процес отримання інформації про локальний сайт (для подальшої атаки) може бути спрощений за рахунок того, якщо на локалі стоїть той же сайт що і в інтернеті: тобто в мережі є сайт http://site.com, і його точна (або майже точна) копія є на http://localhost. І якщо сайт в інтернеті є уразливим (до XSS, SQL Injection тощо), то його локальна копія напевно теж - що дозволить зробити напад на локальний ПК користувача. Причому, окрім інформації з самого сайта, на локалхості можуть бути інші сайти (з іншою важливою інформацією), а також вразливими є інші дані на ПК користувача (які можуть бути викрадені, в залежносмті від прав користувача, з якими запущений браузер або від прав веб сервера).

До локальних даних можна дістатися як з уразливих скриптів конкретного сайту, так і з інших додаткових скриптів, які можуть бути на локалхості, і яких немає на сайті в інтернет (про це повинен знати атакуючий). І це цілком можливо, так як на локалхості можуть бути додаткові скрипти, встановленні для власних потреб користувача. При наявності контроля за браузером користувача, або через трояни чи руткіти, або через веб (про що я розповідав в XSS для віддаленого контролю), це може призвести до серйозних наслідків.

Зокрема в свої практиці я звертав увагу на подібні речі. І деякий час тому провів цікавий експеремент. На одному з моїх сайтів в інтеренет, котрий є на http://localhost (треба лише знати шляхи), наявна XSS уразливість (яку я планую виправити найближчим часом, не переживайте). Вона є в скрипті, який знаходиться як в інтернеті, так і локально - тому можна зробити атаку на локалхост. Цю атаку можна прости як з якогось сайту (на який можна заманити), тим же iframe, або навіть з мого власного сайту, використавши наявну XSS.

Я провів хитру атаку з виконання XSS на локальному веб сервері через сайт в інтернеті - використавши одну і ту саму уразливість на двох сайтах: у вебі і на локалхості (для цього можна використати або прихований iframe, або заманити прямо на лінку). Тобто поле для атаки тут широке. І в результаті я отримав свій локальний кукіс (можливі й інші напрямки атаки). А на локалі в мене багато різних веб додатків, тому й багато різної інформації (в тому числі паролів). А враховуючи, що пароль на локалі і в вебі може використовуватися однаковий, це може призвести до ураження, як локального сайту, так і сайту в інтернеті. Подібний витік інформації може привести до важких наслідків. Про згадану уразливість і наведену атаку ви не переживайте - у вас немає ніяких шансів (всерівно я її пофіксю). Сприймайте це лише як приклад.

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

Знайшов сьогодні цакавий відео ролик на YouTube - мануал (довідкове відео) по SQL Injection.

SQL Injection

Рекомендую подивитися всім хто цікавиться цією темою. Для отримання додаткової інформації - як зі сторони проведення SQL Injection атак, так і зі сторони протидії подібним атакам.

До речі, про YouTube я вже згадував раніше в записі уразливість на www.youtube.com.

Про Cross-Site Scripting я згадував чимало на своєму сайті - це взагалі одна із головних тем, які я піднімаю. І до цього часу мова йшла лише про класичний XSS, назвемо його так (причому класичний Cross-Site Scripting в свою чергу ділиться на декілька різновидів), щоб відрізняти від нового різновида XSS. Про який я зараз вам розповім, який по суті є лише ще одним підкласом XSS уразливостей. Мова йде про самодостатній XSS (self-contained XSS).

Самодостатній Cross-Site Scripting - це зовсім інша форма XSS уразливостей, яка має свої обмеження з одного боку, а з іншого - її набагато важче виявити і відфільтрувати (на даний час). Тому що старі методи, які фільтрують класичний XSS, вже не діють.

Як повідомив pdp, 22.09.2006, в своій статті Self-contained XSS Attacks, він виявив дану уразливість - нову форму XSS атак. На що потім в коментарях до статті, RSnake написав, що в нього даний вектор атаки XSS вже згадувався 2 роки тому (і приклад самодостатньої XSS атаки в нього на сайті приводиться, якщо уважно прочитати відповідні матеріали). Тобто це не є новим вектором атаки. Але справа не в цьому, бо все нове - це добре забуте старе. Зараз як раз з новими силами і більш доступно pdp, а тепер і я, розповідаємо про даний різновид XSS атак.

Для впровадження атаки з самодостатнім XSS використовується протокол data.

Даний ява скрипт код:

<script>alert("XSS")</script>

Має наступний вигляд:
data:text/html;base64,PHNjcmlwdD4KYWxlcnQoIlhTUyIpOwo8L3NjcmlwdD4=

Для перетворення довільного коду (для XSS) в потрібний формат для протоколу data потрібен перекодувач в Base64 формат даних (з відповідним заголовком). Для цього я пропоную для вас Онлайновий генератор самодостатніх XSS. Який і займеться генерацією потрібного XSS кода. В Генераторі XSS в формі ви можете сгенерувати html код, який можна одразу ж виконати (для перевірки).

Слід додати, що сам pdp, автор статті (а також RSnake в коментярях), заявляють, що для викрадення кукісів даний метод не придатний. Що тільки для інших векторів атаки можна застосовувати цей мотод самодостатніх XSS. На що я не можу з ними погодитися. Я провів необхідні тестування, і alert(document.cookie) працює добре. Тому при правильному підході, все буде працювати як потрібно (потрібно не просто в URL вписати, а розмістити в лінці в атибуті href). Тому даний вектор атаки є доволі небезпечним.

Лише потрібно зазначити, що його використання обмежене. Ця уразливість може бути експлуатована в Mozilla, Firefox, Opera і можливо інших браузерах. Internet Explorer 6 і 7 не дозволить зробити атаку даного типу (бо не підтримує протокол data).

P.S.

До речі, окрім статті автора, Self-contained XSS Attacks (на англійскій), також можете прочитати переклад цієї статті на секлабі Самодостаточные XSS атаки.

Давно вже планував розповісти про один цікавий веб сайт (блог) на тему веб безпеки: http://www.gnucitizen.org - GNUCITIZEN.

Рекомендую ознайомитися з даним блогом всім, кто ціватиться темою веб безпеки.

Я ще окремо розповім більш детально про безліч різних тем, пов’язаних з веб безпекою, які піднімає автор блога.

Останні п’ять цікавих тем:

• Google Search API Worms (деталі)
• Web Pages from Hell (деталі)
• Cross Context Scripting with Sage (деталі)
• Backdooring QuickTime Movies (деталі)
• Backdooring Flash Objects (the receipt) (деталі)

Я вже згадував раніше про сайт ha.ckers.org - безпека веб додатків. Автор сайту, RSnake, в своїй статті Why XSS is Here to Stay описує основні причини, чому Cross-Site Scripting уразливості мають і будуть мати місце. І в цьому питанні я з ним погоджуюсь.

Основні причини поширення XSS:

• Аналітичні сервіси - щоб вирішити кардинально проблему XSS, потрібно відмивитися від включення віддалених скриптів (на JavaScript), але на це не підуть компанії, які надають, наприклад, аналітичні сервісі - ті ж рахівники різного гатунку (а з минулого року цим почала займатися Google). Я вже не кажу про повну відмову від JavaScript - ніхто на це не піде (хоча це вирішить багато проблем з безпекою), бо всі до нього звикли і дуже багато сервісів на ньому базується.
• Контекстна та банерна реклама - системи контекстної та здебільшого й банерної реклами базуються саме на JavaScript коді, розміщеному на сторінках веб сайтів (прочитайте мою замітку Хакінг сайту через уразливості в коді зовнішніх систем). Дуже багато людей зайняті в цій сфері, як самих компаній, так і власників сайтів - тому ніхто від цього не захоче відмовитися. Зокрема тому, що в цій сфері обертаються гроші (які заробляють як власники рекламних систем, так і власники сайтів).
• AJAX - він базується на віддалених запитах JavaScript, тому нічого вдіяти тут не вийде, якщо ми хочемо AJAX, який є основою Web 2.0, ми повині миритися з його недоліками (і в тому числі з можливістю XSS). Інакше, ми залишимося веб самого AJAX-а, і повернемося до Веб 1.0 (та й багато компаній задіяні зараз в ajax напрямку, які не захочуть від своїх планів відмовитися).
• Akamai - це система кешування відвідуємих веб сайтів, яка вимагає наявність JavaScript в браузері користувача (з відповідними наслідками).
• Завантаження сторінок і SEO - з точки зору швидкості завантаження сторінок, яка зменшується від наявності JS-коду на сторінках сайтів, а також з точки зору релевантності сторінки для пошукових систем (SEO), та й з точки зору трафіка, то з цих причин власники сайтів намагаються розміщати віддалени скрипти (різноманітних систем), і тому даний функціонал вкрай потрібен для власників сайтів.

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

Тому єдиним засобом на сьогодні для боротьби з XSS є пошук і виправлення уразливостей З приводу пошуку уразливостей (і рекомендацій щодо їх виправлення) можна звертатися до мене.

Добірка цікавого чтива на тему web security (статті з Вікіпедії):

• Cross-site scripting
• Cross-zone scripting
• HTTP response splitting
• Cross-site tracing
• SQL Injection

Поповнюйте свої знання з веб безпеки.

Чимала частина власників сайтів, яким я повідомляю про уразливості на їх веб сайтах, та взагалі велика частина усіх власників сайтів, в наш час мало обізнані стосовно такої проблеми як Cross Site Scripting. І навіть якщо чули про наявність даної загрози і зокрема про наявність XSS на власному сайті (по інформації від мене), дані власники сайтів не переймаються цією проблемою - або не виправляють уразливості зовсім, або виправляють неякісно, або відповідають, що мовляв це не серйозна проблема і вони не бачать ніяких ризиків пов’язаних з даними уразливостями (і що адмінів навряд чи похакають, а стосовно юзерів їх сайтів їм байдуже).

Причому подібне відношення до уразливостей (і зокрема до XSS) існує давно - нагадаю, що Cross Site Scripting уразливості як окремий напрямок веб безпеки існує вже багато років (з 2000 року). І кількість похаканих сайтів щоденно зростає, але їх власники так і не почали замислюватися над проблемами безпеки своїх веб сайтів. В результаті своєї дослідницької діяльності стосовно уразливостей, я регулярно стикаюся з подібним відношенням власників до своїх сайтів, до їх безпеки і до XSS уразливостей.

Стосовно останніх, то зазначу, що окрім безпосереднього ризику для адмінів і користувачів даних веб сайтів (на яких знайдені XSS уразливості), уразливі сайти також небезпечні для будь-яких інших інтернет користувачів, навіть тих, хто про ці сайти і не чув взагалі. Це явище я називаю сайти зомбі.

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

Я вже писав про фішинг за допомогою Yahoo та Google і таких прикладів можна привести чимало. І з кожним днем ситуація погіршується і небезпека зростає, що або власний сайт користувача, або відомий сайт, може бути використаний проти самого ж інтернет користувача.

P.S.

Вже в 2010 році я створив програму DDoS attacks via other sites execution tool (DAVOSET) для використання сайтів зомбі. DAVOSET - це інструмент для використання Abuse of Functionality та XML External Entities уразливостей на одних сайтах, для проведення DoS і DDoS атак на інші сайти.

Нещодавно знайшов цікавий веб сайт (блог) на тему веб безпеки: http://ha.ckers.org/blog/ - ha.ckers.org web application security lab.

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

Останні п’ять цікавих тем:

• Brute Force Password Guessing (деталі)
• Masking XSS Attacks (деталі)
• Redirection in Yahoo Forwards Phishing (деталі)
• Email Risks (деталі)
• Why XSS is Here to Stay (деталі)

Цікавая стаття про XSS (на секлабі): Просунутий міжсайтовий скриптінг із віддаленим контролем у реальному часі.

• Продвинутый межсайтовый скриптинг с удаленным контролем в реальном времени (деталі)