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

Продовжуючи розпочату традицію, після попереднього відео про використання MSFweb 3.0, пропоную новий відео секюріті мануал. Цього разу відео про захоплення SQL сервера через SQL ін’єкцію. Рекомендую подивитися всім хто цікавиться цією темою.

Rooting SQL Server via SQL Injection

В даному відео ролику демонструється взлом SQL сервера. Через уразливий веб сайт, що має SQL ін’єкцію, на якому SQL Server запущений з адмінськими правами, створюється новий акаунт адміністратора. Рекомендую подивитися дане відео для розуміння векторів SQL Injection атак.

Раніше я писав про можливість закриття сайтів через їх уразливості. Це можливо в зв’язку з наявністю на сайті порнографії, секретних матеріалів, або терористичних матеріалів. І як я вже казав, закриття сайта може статися через його взлом та розміщення на ньому вищезазначених метеріалів.

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

Тобто вже сам взлом може призвести до закриття сайта (це може бути дефейс і/або розміщення вірусів). Закриття може бути тимчасове - коли провайдер закрив сайт, доки його власник не почистить свій сайт, або повне - коли власник сайта закрив свій проект (бо не міг впоратися з проблемою дірявості власного сайта). В своїх дослідженнях безпеки Уанету (за 2006-2009 роки) я наводив безліч таких випадків. Як останній випадок з www.virtlibrary.dp.ua, так і минулорічні випадки з dn.kiev.ua та wmast.com.ua.

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

В своїй презентації The fundamentals of Hacking, Jen Johnson та Miria Grunick розповідають про основи хакінга в Інтернеті.

This is English version of my Cross-Site Scripting attacks via redirectors article.

In this article I’ll tell you about using of redirectors in different browsers for conducting of Cross-Site Scripting attacks. Which can be conduct for the purpose of stealing cookies, or access to web site’s pages for making of various advanced attacks (in case when there is connection between code which is executed via redirector and the site), and also for the purpose of conducting of fishing attacks and execution of JavaScript code (in case when there is no such connection).

Besides that redirectors allow to redirect to malicious and fishing sites (which is Redirector vulnerability), there are also other variants of attacks with their use. Particularly in my articles Redirectors’ hell and Hellfire for redirectors I wrote about using of redirectors for DoS attacks. Already in January 2008 I planned to write an article about various attacks with using of redirectors (was planning to make anthology of attacks via redirectors), which I’d certainly do, but now I’d tell about one of this attacks - about XSS attacks via redirectors.

There are two types of redirectors (server-side): location-header, which works via Location header, and refresh-header, which works via Refresh header.

In different browsers (via vulnerabilities in them) XSS attacks are possible in different redirectors. Attacks are doing via redirection to javascript: URI and data: URI.

Attack #1

As I wrote about Cross-Site Scripting vulnerabilities in Mozilla, Internet Explorer, Opera and Chrome, in browsers Mozilla 1.7.x (and previous versions), Mozilla Firefox 3.0.8 (and previous versions), Internet Explorer 6 (and previous versions, but not IE7 and IE8), Opera 9.52 (and previous and next versions) and Google Chrome 1.0.154.48 (and previous and next versions) is possible XSS attack via refresh-header redirectors. Attack is doing by redirecting to javascript: URI.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Refresh header:
Refresh: 0; URL=javascript:alert(document.cookie)
The code will execute in context of this site.

This vulnerability in browsers can be used for conducting of reflected XSS attacks.

Attack #2

As I wrote about Cross-Site Scripting vulnerabilities in Mozilla, Firefox and Chrome, in browsers Mozilla 1.7.x (and previous versions), Mozilla Firefox 3.0.12 (and previous and next versions) and Google Chrome 1.0.154.48 (and previous and next versions) is possible XSS attack via refresh-header redirectors. Attack is doing by redirecting to data: URI (with or without using of base64).

Method of attack:

With request to script at web site:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Which returns in answer the refresh header and the code will execute in the browser:
refresh: 0; URL=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Because in browsers Firefox 3.0.12 and Google Chrome the code is executing not in context of this site, hence there is no access to cookies, but it can be done in old Mozilla. This vulnerability in browsers (modern) can be used for conducting of fishing attacks and executing of JavaScript code.

Attack #3

As I wrote about Cross-Site Scripting vulnerabilities in Firefox and Opera, in browsers Mozilla Firefox 3.0.12 (and previous and next versions) and Opera 9.52 (and previous and next versions) is possible XSS attack via location-header redirectors. Attack is doing by redirecting to data: URI (with or without using of base64).

Method of attack:

With request to script at web site:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Which returns in answer the Location header and the code will execute in the browser:
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

Because in browsers Firefox and Opera the code is executing not in context of this site, hence there is no access to cookies. This vulnerability in browsers can be used for conducting of fishing attacks and executing of JavaScript code.

Both types of redirectors, location-header and refresh-header, very widespread in Internet, but most widespread are location-header redirectors. So existence of vulnerabilities which work via location-header redirectors pose the most threat. Particularly via this vulnerability in browsers are possible attacks via redirection services, as I wrote concerning vulnerability at tinyurl.com. It allows to spread malware via redirection services, when there will be set the code of exploit instead of address for redirection.

Attack #4

All modern browsers don’t allow execution of JavaScript code by redirecting to javascript: URI in location-header redirectors. But as showed my researches - it’s not always so. As I wrote about Cross-Site Scripting vulnerabilities in Mozilla and Firefox, in browsers Mozilla 1.7.x (and previous versions) and Mozilla Firefox 3.0.12 (and previous and next versions) is possible XSS attack via location-header redirectors, which use answer “302 Object moved”. Attack is doing by redirecting to javascript: URI (and also it’s possible to conduct attack to data: URI).

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
HTTP/1.x 302 Object moved
Location: javascript:alert%28document.cookie%29
The browser will show “Object Moved” page. At click on the link “here” the code will execute in context of this site.

This vulnerability in browsers can be used for conducting of Strictly social XSS attacks.

Attack #5

After initial publication of the article, Aung Khant informed me at 24.08.2009 about vulnerability in Maxthon 3 Alpha (3.0.0.145) with Ultramode. Which allows execution of JavaScript code by redirecting to javascript: URI in location-header redirectors. It’s variation of attack #4 (which I checked, but not found in other browsers, but he found it in Maxthon). If in that case XSS attack is possible via location-header redirectors, which use answer “302 Object moved”, then in this case attack is possible with any 301 and 302 answers of redirectors. Attack is doing by redirecting to javascript: URI.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
Location: javascript:alert%28document.cookie%29
The browser will show “Unable to connect to the site” page. At click on the link “Refresh the page” the code will execute. Besides, there is the same behaviour in Maxthon 3 Alpha in attacks #3,4,5 (code executes not in context of the site).

This vulnerability in Maxthon can be used for conducting of Strictly social XSS attacks.

Note, that in case of execution of JavaScript code by redirecting to data: URI, when code is executing not in context of this site, the danger exists. Because this vulnerabilities can be used for conducting of fishing attacks and executing of JavaScript code (for malware spreading).

Main advantages of this attack method for criminals, in comparison with ordinary redirection to their site, is first that they don’t need even to have their site (so it’ll be harder to trace them, and also it’ll be impossible to close their site). And second that none anti-fishing and anti-malware filter (in browsers and email) will can’t filter out them, because there will no such address in their base (because not http: address, but data: is using), i.e. bypass of all filters is possible. So it’s needed to fix all mentioned vulnerabilities in browsers.

Attack #6

As I wrote about Cross-Site Scripting vulnerability in Mozilla, Firefox and other browsers, in browsers Mozilla 1.7.x (and previous versions) and Mozilla Firefox 3.0.19 (and previous and next versions) and potentially in other browsers is possible XSS attack via location-header redirectors, which use answer “302 Found”. Attack is doing by redirecting to javascript: URI (and also it’s possible to conduct attack to data: URI). This attack is similar to attack #4.

Method of attack:

With request to script at web site:
http://site/script.php?param=javascript:alert(document.cookie)
Which returns in answer the Location header:
HTTP/1.x 302 Found
Location: javascript:alert(document.cookie)
The browser will show “Found” page. At click on the link “here” the code will execute in context of this site.

This vulnerability in browsers can be used for conducting of Strictly social XSS attacks.

Attacks #7,8

In article Cross-Site Scripting via redirectors 301 and 303 in different browsers I’ve described two more attacks via redirectors with status 301 and 303. These are attacks via data: and javascript: URI.

[Update: 05.08.2009]

As I checked, Mozilla Firefox 3.0.13 is also vulnerable to attacks #2,3,4.

In case of all browsers which are vulnerable to attacks #1,4, JS code executes in context of the site.

[Update: 22.08.2009]

As I found with help of Aung Khant from YEHG Team, the next browsers are also vulnerable:

Google Chrome 2.0.172.28, 2.0.172.37 and 3.0.193.2 Beta - vulnerable to attacks #1,2.

QtWeb 3.0 Build 001 and 3.0 Build 003 - vulnerable to attacks #1,2,3.

Safari 4.0.3 - vulnerable to attacks #1,2.

Opera 10.00 Beta 3 Build 1699 - vulnerable to attacks #1,3.

SeaMonkey 1.1.17 - vulnerable to attacks #1,2,4 and in #1,2,4 JS code executes in context of the site.

[Update: 25.08.2009]

New information from Aung Khant from YEHG Team:

Firefox 3.6 a1 pre - vulnerable to attacks #1,2,3,4 and in #1,2,4 JS code executes in context of the site.

Firefox 3.7 a1 pre - vulnerable to attacks #2,3,4.

Orca Browser 1.2 build 5 - vulnerable to attacks #2,3,4.

Maxthon 3 Alpha (3.0.0.145 and 3.0.2.2) with Ultramode (Apple’s WebKit emulation) - vulnerable to attacks #1,2. And also vulnerable to attacks #3,4,5 as Strictly social XSS.

[Update: 05.08.2010]

Added information about attack #6.

[Update: 07.08.2010]

New information:

Mozilla Firefox 3.0.19 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 3.5.11 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 3.6.8 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 4.0b2 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Opera 10.53 - vulnerable to attacks #1,4,5,6.

[Update: 16.09.2012]

New information:

Firefox 3.5.19, Firefox 3.6.28 - vulnerable to attacks #2,3,4,6 and in #4,6 JS code executes in context of the site.

Firefox 10.0.7, Firefox 15.0.1 - vulnerable to attacks #2,3. In versions Firefox 10.0.7 and 15.0.1 the attacks #4,6 are no more possible - these vulnerabilities were hiddenly fixed by Mozilla in Firefox 9.0.

Opera 10.62 - vulnerable to attacks #1,4,5,6.

[Update: 25.09.2012]

Added information about attacks #7 and #8.

This is English version of my URL Hiding - new method of URL Spoofing attacks article.

In continue of my researches of vulnerabilities in search engines, I tell you about new interesting method of URL Spoofing attacks, which I called URL Hiding. It can be used for conducting of fishing attacks and for spreading of malware (particularly it can be used with previously described methods). This URL Hiding attack I found in Google, but other search engines also can be vulnerable.

This month, 19.05.2009, during searching in Google, I found interesting site, which not shows its URL in serp. I saw such sites earlier during using of Google (from 2000), but it’s first site which address I wrote down. This site is http://_-lilit-_.photosight.ru.

site:_-lilit-_.photosight.ru

In case when URL Hiding is using together with URL Spoofing methods, which I wrote about earlier (when long URL is made, e.g. with using of “_” char), then it improves the effectiveness of fishing and others attacks. Because long and suspicious URL will not be shown in serp of search engine, and when user will go by the link, then he can to not notice the URL (via using of URL Spoofing methods).

As I thought first, when using of underscore (like in case of http://_-lilit-_.photosight.ru), Google will not show address in serp at all. But there is no such effect in case of http://ane4ka-_.shalala.ru. Potentially it works only in case, if first char of domain is underscore.

I made a lot of researches when I was looking for sites with underscores, which hasn’t URL in serp, but didn’t find any such sites (but found one interesting bug in Google). So method of attack on Google for hiding of address of sites in serp can use this (with underscore at the beginning of domain), or other approach. But in any case URL Hiding attack is dangerous, because it allows to use search engines (Google in particular) for conducting of fishing and other attacks.

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

Окрім того, що редиректори дозволяють редиректити на зловмисні та фішинг сайти (що є Redirector уразливістю), є також інші варіанти атак з їх використанням. Зокрема в своїх статтях Пекло редиректорів та Пекельний вогонь для редиректорів я писав про використання редиректорів для DoS атак. Ще в січні 2008 року я запланував написати статтю про різноманітні атаки з використанням редерикторів (планую зробити антологію атак через редиректори), що я обов’язково зроблю, але зараз розповів про одну з цих атак - про XSS атаки через редиректори.

Існують два типа редиректорів (серверних): location-header, що працюють через заголовок Location, та refresh-header, що працюють через заголовок Refresh.

В різних браузерах (через уразливості в них) можливі XSS атаки в різних редиректорах. Атаки відбуваються через редирекцію на javascript: URI та data: URI.

Атака №1

Як я писав про Cross-Site Scripting уразливості в Mozilla, Internet Explorer, Opera та Chrome, в браузерах Mozilla 1.7.x (та попередні версії), Mozilla Firefox 3.0.8 (та попередні версії), Internet Explorer 6 (та попередні версії, але не IE7 та IE8), Opera 9.52 (та попередні й наступні версії) та Google Chrome 1.0.154.48 (та попередні й наступні версії) можлива XSS атака через refresh-header редиректори. Атака відбувається при редирекції на javascript: URI.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Refresh:
Refresh: 0; URL=javascript:alert(document.cookie)
Код спрацює в контексті даного сайту.

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

Атака №2

Як я писав про Cross-Site Scripting уразливості в Mozilla, Firefox та Chrome, в браузерах Mozilla 1.7.x (та попередні версії), Mozilla Firefox 3.0.12 (та попередні й наступні версії) та Google Chrome 1.0.154.48 (та попередні й наступні версії) можлива XSS атака через refresh-header редиректори. Атака відбувається при редирекції на data: URI (з або без використання base64).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Що поверне у відповіді заголовок refresh і код виконається у браузері:
refresh: 0; URL=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b

Так як в браузерах Firefox 3.0.12 і Google Chrome код спрацює не в контексті даного сайту, то таким чином до кукісів не дістатися, зате це можна зробити в старій Mozilla. Дана уразливість в браузерах (сучасних) може використовуватися для проведення фішинг атак та виконання JavaScript коду.

Атака №3

Як я писав про Cross-Site Scripting уразливості в Firefox та Opera, в браузерах Mozilla Firefox 3.0.12 (та попередні й наступні версії) та Opera 9.52 (та попередні й наступні версії) можлива XSS атака через location-header редиректори. Атака відбувається при редирекції на data: URI (з або без використання base64).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ%2b
Що поверне у відповіді заголовок Location і код виконається у браузері:
Location: data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+

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

Обидва типи редиректорів, location-header та refresh-header, дуже поширені в Інтернеті, але найбільш поширеними є location-header редиректори. Тому наявність уразливостей, що працюють через location-header редиректори представляє найбільшу загрозу. Зокрема через дану уразливість в браузерах можливі атаки через сервіси редирекції, як я писав стосовно уразливості на tinyurl.com. Це дозволяє розповсюджувати malware через сервіси редирекції, коли замість адреси для редирекції буде вказаний код експлоіта.

Атака №4

Всі сучасні браузери не дозволяють виконання JavaScript коду при редирекції на javascript: URI в location-header редиректорах. Але як показали мої дослідження - це не завжди так. Як я писав про Cross-Site Scripting уразливості в Mozilla та Firefox, в браузерах Mozilla 1.7.x (та попередні версії) та Mozilla Firefox 3.0.12 (та попередні й наступні версії) можлива XSS атака через location-header редиректори, що використовують відповідь “302 Object moved”. Атака відбувається при редирекції на javascript: URI (а також можна провести атаку і на data: URI).

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
HTTP/1.x 302 Object moved
Location: javascript:alert%28document.cookie%29
Браузер виводить сторінку “Object Moved”. При кліку по лінці “here” код спрацює в контексті даного сайту.

Дана уразливість в браузерах може використовуватися для проведення Strictly social XSS атак.

Атака №5

Після початкової публікацї статті, Aung Khant повідомив мені 24.08.2009 про уразливість в Maxthon 3 Alpha (3.0.0.145) з Ultramode. Яка дозволяє виконання JavaScript коду при редирекції на javascript: URI в location-header редиректорах. Це варіація атаки №4 (яку я перевіряв, але не знаходив в інших браузерах, але він знайшов її в Maxthon). Якщо в тому випадку XSS атака можлива через location-header редиректори, що використовують відповідь “302 Object moved”, то в даному випадку атака можлива при будь-яких 301 і 302 відповідях редиректорів. Атака відбувається при редирекції на javascript: URI.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
Location: javascript:alert%28document.cookie%29
Браузер виводить сторінку “Unable to connect to the site”. При кліку по лінці “Refresh the page” код спрацює. До речі, Maxthon 3 Alpha веде себе однаково у випадку атак №3,4,5 (код виконається не в контексті сайта).

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

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

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

Атака №6

Як я писав про Cross-Site Scripting уразливість в Mozilla, Firefox та інших браузерах, в браузерах Mozilla 1.7.x (та попередні версії) та Mozilla Firefox 3.0.19 (та попередні й наступні версії) та потенційно в інших браузерах можлива XSS атака через location-header редиректори з відповіддю “302 Found”. Атака відбувається при редирекції на javascript: URI (а також можна провести атаку і на data: URI). Дана атака схожа на атаку №4.

Методика атаки:

При запиті до скрипта на сайті:
http://site/script.php?param=javascript:alert(document.cookie)
Що поверне у відповіді заголовок Location:
HTTP/1.x 302 Found
Location: javascript:alert(document.cookie)
Браузер виводить сторінку “Found”. При кліку по лінці “here” код спрацює в контексті даного сайту.

Дана уразливість в браузерах може використовуватися для проведення Strictly social XSS атак.

Атаки №7,8

В статті Cross-Site Scripting через редиректори 301 і 303 в різних браузерах я описав ще дві атаки через редиректори зі статусом 301 і 303. Це атаки через data: та javascript: URI.

[Оновлення: 05.08.2009]

Як я перевірив, Mozilla Firefox 3.0.13 також уразливий до атак №2,3,4.

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

[Оновлення: 22.08.2009]

Як я виявив з домопогою Aung Khant з YEHG Team, наступні браузери також уразливі:

Google Chrome 2.0.172.28, 2.0.172.37 та 3.0.193.2 Beta - уразливі до атак №1,2.

QtWeb 3.0 Build 001 та 3.0 Build 003 - уразливий до атак №1,2,3.

Safari 4.0.3 - уразливий до атак №1,2.

Opera 10.00 Beta 3 Build 1699 - уразливий до атак №1,3.

SeaMonkey 1.1.17 - уразливий до атак №1,2,4 і в №1,2,4 JS код виконується в контексті сайта.

[Оновлення: 25.08.2009]

Нова інформація від Aung Khant з YEHG Team:

Firefox 3.6 a1 pre - уразливий до атак №1,2,3,4 і в №1,2,4 JS код виконується в контексті сайта.

Firefox 3.7 a1 pre - уразливий до атак №2,3,4.

Orca Browser 1.2 build 5 - уразливий до атак №2,3,4.

Maxthon 3 Alpha (3.0.0.145 та 3.0.2.2) з Ultramode (емуляція Apple WebKit) - уразливий до атак №1,2. А також уразливий до атак №3,4,5 як Strictly social XSS.

[Оновлення: 05.08.2010]

Додав інформацію про атаку №6.

[Оновлення: 07.08.2010]

Нова інформація:

Mozilla Firefox 3.0.19 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 3.5.11 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 3.6.8 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 4.0b2 - уразливий до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Opera 10.53 - уразливий до атак №1,4,5,6.

[Оновлення: 16.09.2012]

Нова інформація:

Firefox 3.5.19, Firefox 3.6.28 - уразливі до атак №2,3,4,6 і в №4,6 JS код виконується в контексті сайта.

Firefox 10.0.7, Firefox 15.0.1 - уразливі до атак №2,3. В версіях Firefox 10.0.7 і 15.0.1 атаки №4,6 більше неможливі - дані уразливості були приховано виправлені Mozilla в Firefox 9.0.

Opera 10.62 - уразливий до атак №1,4,5,6.

[Оновлення: 25.09.2012]

Додав інформацію про атаки №7 і №8.

Продовжуючи розпочату традицію, після попереднього відео про хакінг SQL за допомогою SecureState Swiss Army Knife, пропоную новий відео секюріті мануал. Цього разу відео про використання MSFweb 3.0. Рекомендую подивитися всім хто цікавиться цією темою.

LSO: MSFweb 3.0 part 2

В даному відео ролику демонструється використання Metasploit Framework Web Console 3.0. Демонструються можливості MSF 3.0 та її Web Console по створенню експлотів, зокрема для IE. Рекомендую подивитися дане відео для розуміння середовища MSF.

Продовжуючи розпочату традицію, після попереднього відео про XSS атаки через файли зображень, пропоную новий відео секюріті мануал. Цього разу відео про хакінг SQL за допомогою SecureState Swiss Army Knife. Рекомендую подивитися всім хто цікавиться цією темою.

Hacking SQL in Linux using the SecureState Swiss Army Knife

В даному відео ролику демонструється пошук SQL сервера та атака на нього за допомогою SecureState Swiss Army Knife. За допомогою даного додатку відбувається автоматизований пошук вразливого SQL сервера і створення на комп’ютері з ним нового акаунта адміністратора. Рекомендую подивитися дане відео для розуміння можливостей SecureState Swiss Army Knife.

Наскількі часто потрібно проводити перевірки веб додатків та веб сайтів? На це запитання спробував відповісти Binu Thomas в своїй статті How frequently should an Application be tested.

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

На думку Томаса, є наступні критерії вибору частоти проведення повторних перевірок веб додатків:

• Важливість даних
• Критичність додатку
• Частота змін у додатку

В своїй презентації Hacking Web 2.0 - Defending Ajax and Web Services, Shreeraj Shah розповідає про хакінг Веб 2.0. Про захист AJAX додатків та Веб Сервісів.