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

До раніше наведених пам’яток з SQL Injection в різних Базах Даних, пропоную ознайомитися з пам’яткою розробленою RSnake. Котра може стати вам у нагоді при проведенні аудиту безпеки веб сайта (чи атаки на сайт).

SQL Injection Cheat sheet: Esp: for filter evasion

Дана пам’ятка не така об’ємна, як попередня пам’ятка SQL Injection, яле вона також може стати в нагоді. В даній пам’ятці наводяться стандартні SQL запити при проведенні перевірок на наявність SQL ін’єкцій та наводяться приклади атак.

Розповім вам про обхід багатопрохідних фільтрів (multi-pass filters bypass). У випадку коли на веб сайті використовується комплексна (багатопрохідна) система фільтрації, зокрема для фільтрації XSS, можливий обхід багатопрохідних фільтрів. Подібні багатопрохідні системи фільтрації можуть використовуватися на великих порталах та соціальних мережах.

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

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

Розглянемо наступні приклади.

1. Код для обходу багатопрохідних фільтрів:

<p/style="xss:e xpression(alert(document.cookie))">

На першій стадії фільтр перевіряє на наявність XSS кода: перевіряється наявність ключевих слів, в тому числі й “expression”. Враховуючи, що в даному випадку використовується “e xpression”, то ключевих слів не знаходиться і даний рядок проходить фільтр.

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

<p/style="xss:expression(alert(document.cookie))">

Зазначу, що враховуючи другу стадію, я використовав “<p/style”, а не “<p style”, щоб зробити код робочим після проходження фільтрів (бо пробіли витираються на другій стадії фільтрації).

2. Код для обходу багатопрохідних фільтрів:

<img/width="100"src="http://site/image.jpg"o nLoad="alert(document.cookie)">

На першій стадії фільтр перевіряє на наявність XSS кода: враховуючи, що в даному випадку використовується “o nLoad”, то ключевих слів не знаходиться і даний рядок проходить фільтр.

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

<img/width="100"src="http://site/image.jpg"onLoad="alert(document.cookie)">

Як я вже зазначав, враховуючи другу стадію, в якості роздільника між ім’ям тега та його властивістю я використав “/”, тобто використав запис “<img/width”. Для того щоб зробити код робочим після проходження фільтрів.

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

В своїй статті Advanced Cross-Site-Scripting with Real-time Remote Attacker Control, Anton Rager розповідає про просунуті Cross-Site Scripting атаки. Про використання XSS уразливостей для проведення просунутих атак, що будуть у реальному часі віддалено контролюватися нападником. З метою віддаленого контролю над браузером користувача.

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

Як повідомив pdp в своєму записі Co-authoring Google Hacking for Penetration Testers, Volume 2, в минулому році він активно працював над другим виданням книги “Google Hacking for Penetration Testers”. Це його друга книга (написана разом з Johnny Long), після співавторства в написанні книги про Cross-Site Scripting. Дана книга вже вийшла.

Тема Гугл хакінга доволі цікава - я чимало писав про неї. Зокрема про використання Гугл хакінга для пошуку XSS, Full path disclosure та Information disclosure уразливостей.

В своїй презентації Unusual Web Bugs, Alex aka kuza55 розповідає про незвичайні веб баги. Він наводить різні цікаві ідеї та підходи до використання уразливостей в веб додатках.

Раніше я приводив пам’ятки з SQL Injection в різних Базах Даних, а зараз пропоную вам ознайомитися з детальною пам’яткою по SQL Injection, в котрій розглядаються одразу декілька різних СУДБ (MySQL, Microsoft SQL Server, Oracle та PostgreSQL). Котра може стати вам у нагоді при проведенні аудиту безпеки веб сайта (чи атаки на сайт).

SQL Injection Cheat Sheet

В даній пам’ятці наводяться стандартні SQL запити при проведенні перевірок на наявність SQL ін’єкцій, наводяться приклади атак та розглядаються особливості різних СУБД.

Продовжуючи розпочату традицію, після попереднього відео про SQL Injection в JSP, пропоную новий відео секюріті мануал. Цього разу відео про Cross-Site Scripting атаки через Flash. Рекомендую подивитися всім хто цікавиться цією темою.

Multiple Websites Embedded SWF File Vulnerability Demonstration

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

Про persistent XSS атаки через флеш я вже розповідав, коли писав про XSS уразливість в IPB.

This is English version of my Recursive File Include article.

From various vulnerabilities of web applications there is a class Denial of Service. And at the sites in Internet we can see DoS vulnerabilities quite often (I wrote about such ones many times at my site). As opposed to DDoS attacks (when resource is overloaded by large amount of requests), DoS attacks represent attacks to vulnerable web applications, which with corresponding conditions can lead to server overload, up to its full denial of service. I.e. web applications with DoS vulnerabilities are attacking.

I’ll tell you about new form of Denial of Service vulnerabilities, which I found 03.10.2007 (I saw such holes earlier, but just at October 2007 I begun to research them in detail). It is Recursive File Include, which I referred to the subclass of the class Denial of Service in vulnerability classification.

Recursive File Include - it’s Local file include vulnerability, which is using for making DoS attack. I.e. it is local inclusion of the files (scripts), which leads to DoS attack due to recursion, when files are infinitely including.

For PHP applications the attack with using of this vulnerability will have the next look:

http://site/page.php?include=page.php

As you can see from example, web application is including itself (if manually set the call of the file with name of main web application). To make recursive inclusion possible it is needed that parameter with name of included file (in this case it’s parameter “include”) automatically pass to all following included web applications. Due to infinitely recursive including this request will lead to server overload.

Examples of DoS vulnerabilities via Recursive File Include (which I found 03.10.2007).

DoS:

1. http://www.paulscomputerservice.net/index.php?body=index.php

This vulnerability doesn’t work already (it worked in October, but two days ago, when I wrote about it and other vulnerabilities at www.paulscomputerservice.net, it was fixed already). But nevertheless it is nice example of such type of vulnerabilities.

2. http://reloader.net.ru/index.php?path=index.php

3. http://www.vc-link.net/index.php?inc=index

Hole at www.vc-link.net I found as far back at 2006, but not attended too much at it. Until in October 2007 I remembered about it, when I was conducting this research.

Recursive File Include can be in PHP (Recursive PHP Include), and in other languages (for example in ASP). But, as showed my researches, recursion automatically works only in PHP applications (full recursive file inclusion). But nevertheless with special way it’s possible to conduct Recursive File Include attacks and in other languages, particularly in ASP. Recursive PHP Include, Recursive ASP Include and other recursive inclusions are variety of Recursive File Include vulnerability.

This vulnerability represent a danger to web sites, so developers of web applications need to not allow such vulnerabilities and more attend to security of their applications.

Серед різноманітних уразливостей веб додатків є клас Denial of Service. І на сайтах в Інтернеті нерідко можна зустріти DoS уразливості (про подібні я багато разів згадував в себе на сайті). На відміну від DDoS атак (коли ресурс перенавантажується великою кількістю запитів), DoS атаки представляють собою атаки на уразливі веб додатки, що при відповідних умовах можуть призвести до перенавантаження сервера, аж до його повної відмови в обслуговуванні. Тобто атакуються веб додатки, що мають DoS уразливості.

Розповім вам про новий вид Denial of Service уразливостей, що я виявив 03.10.2007 (подібні дірки я зустрічав і раніше, але саме в жовтні 2007 року я взявся за детальне їх дослідження). Це Recursive File Include, що я відніс як підклас класу Denial of Service в класифікації уразливостей.

Recursive File Include - це Local file include уразливість, що використовується для проведення DoS атаки. Тобто це локальне включення файлів (скриптів), що призводить до DoS атаки за рахунок рекурсії, коли файли інклюдяться нескінченно.

Для PHP додатків атака з використанням даної уразливості буде мати наступний вигляд:

http://site/page.php?include=page.php

Як видно з прикладу, веб додаток підключає сам себе (якщо власноруч задати виклик файла з іменем основного веб додатку). Щоб відбулося рекурсивне включення потрібно, щоб параметр з іменем підключаємого файла (в даному випадку це параметр “include”) автоматично передавався усім наступним підключеним веб додаткам. За рахунок нескінченного рекурсивного включення даний запит призведе до перенавантаження сервера.

Приклади DoS уразливостей через Recursive File Include (знайдені мною 03.10.2007).

DoS:

1. http://www.paulscomputerservice.net/index.php?body=index.php

Дана уразливість вже не працює (вона працювала в жовтні, але два дні тому, коли я писав про цю та інші уразливості на www.paulscomputerservice.net, вона вже була виправлена). Але тим не менш вона є гарним прикладом даного типу уразливостей.

2. http://reloader.net.ru/index.php?path=index.php

3. http://www.vc-link.net/index.php?inc=index

Дірку на www.vc-link.net я знайшов ще в 2006 році, але не став приділяти до неї багато уваги. Доки в жовтні 2007 я не згадав про неї, коли проводив дане дослідження.

Recursive File Include може бути як в PHP (Recursive PHP Include), так і в інших мовах (наприклад в ASP). Але, як показали мої дослідження, автоматично рекурсія спрацьовує лише в PHP додатках (повне рекурсивне включення файлів). Тим не менш спеціальним чином можна проводити Recursive File Include атаки й в інших мовах, зокрема в ASP. Recursive PHP Include, Recursive ASP Include та інші рекурсивні включення є різновидами Recursive File Include уразливості.

Дана уразливість становить значну загрозу для веб сайтів, тому розробникам веб додатків варто не допускати подібних уразливостей та більше слідкувати за безпекою власних додатків.

При проведенні аудиту безпеки веб сайта ви можете зіткнутися з наявністю на сайті баз даних. У випадку коли використовується СУБД IBM DB2, то для проведення дослідження на предмет SQL Injection вам може стати у нагоді пам’ятка з SQL Injection в DB2. Існує одна подібна і детальна пам’ятка.

DB2 SQL Injection Cheat Sheet

В даній пам’ятці наводяться стандартні запити при проведенні перевірок на наявність SQL ін’єкцій в DB2.