Да я и не говорю, что защита на уровне настроек сервера не работает. Она работает. Но вы даже сами делите (поскольку это очевидно) оценку системы на серверные настройки, серверный язык и фреймворк. Вспомните теорию надежности "надежность системы определяется надежностью самого слабого звена". То есть да, защита на уровне настроек сервера работает, но если она "закрывает" дыры в программном коде, то это не повышает оценку надежности системы в целом. И это будет невеселая картинка, когда фреймворк является "слабым звеном системы". Как-то так.
А, простите, туплю под вечер. Просто пол дня убил, чтобы сначала апач, а потом nginx заставить работать как прокси именно с использованием абсолютного target, а когда уже полез в исходники nginx_http_proxy_module.c, сообразил, что такое просто не предусмотрено конструкцией :) Ну и да, при "подтягивании" контента php файлом куки-то мы не получим. Нет, мы их, конечно, получим с помощью var_dump(stream_get_meta_data($fp)); Но нам же нужно взять из браузера действительное значение для атакуемого домена, а он нам их не даст, тут вы правы. Ладно, я еще подумаю.
Ух, наминусовали :) Самое интересное, что минусуют совсем не те, кто хочет защитить свой код.
Вот вам, господа, информация к размышлению: Из доков по контексту http в php
request_fulluri boolean
Когда установлено в TRUE, весь URI будет использован при построении запроса. (Например, GET www.example.com/path/to/file.html HTTP/1.0). Хотя это нестандартный формат запроса, некоторые прокси-серверы требуют его.
По умолчанию значение FALSE.
Грубо говоря, здесь речь идет как раз об абсолютной форме HTTP target.
То есть, чтобы вам для воспроизведения уязвимости не пришлось переписывать исходники nginx, попробуйте просто сделать вот так:
А, а вот тут как раз в точку. И не только laravel. Как вы все знаете, был принят стандарт PSR-7, в котором есть объект, реализующий UriIntrface. И как заманчиво будет сделать следующее: $request = ServerRequestFactory::make();
$uri = $request->getUri();
И потом использовать это в ссылках. А то, что при этом там будет присутствовать хост, причем взятый именно из заголовков, кто будет разбираться в таких подробностях?
Вот честное слово, только-только было собрался состряпать образец, как наткнулся на старую статью еще за 2006 год. Это как раз то, о чем я говорю, была б идея, реализация найдется: http://www.securitylab.ru/analytics/271169.php Конечно, новые версии плеера не позволяют отправлять критические заголовки, но автор правильно подметил, что есть еще Action Script, чьи возможности довольно широки в этом плане http://kharchuk.ru/as3/URLRequestHeader.html. Так что, как я уже говорил, вопрос не в том, как кто-либо сделает редирект на наш скрипт, с помощью апплета, устаревшей версии плеера, с помощью Action Script или в комбинации этих методов. Важно то, как поведет себя наш PHP сценарий. Вот о чем я хотел вам сказать.
Возможно, меня не правильно поняли. Я имел в виду именно конечный результат, основанный на том, что php использует именно HTTP_HOST. А как пхп получит подобные заголовки, хоть встроенными объектами, хоть еще как-нибудь, мне, по сути, не важно.
Тут люди требуют чистого эксперимента, сразу скажу, что я не хацкер, поэтому получив подобную идею я просто перестраховался от подобной уязвимости, введя в код разрешенные хосты и НЕ ПЫТАЛСЯ эту уязвимость реализовать. Хотя, теперь вижу, что зря и постараюсь эту ошибку исправить в ближайшее время. Тем не менее, важно другое — сама идея довольно проста по меньшей мере для понимания. Это не редкость, когда один человек давал теоретическое обоснование уязвимости, а другой приводил реализацию (начал все мужик, который заявил, что Земля вертится).
Я, конечно, попытаюсь вникнуть в новую для меня область разработки аплетов, но независимо от того, получится у меня, как у новичка или нет — вы не расслабляйтесь (потому, что не факт, что не получится у кого-то другого). И, я еще раз подчеркну смысл всей этой статьи — это касается именно вариантов использования PHP кода.
Ну, если есть сомнения, что my.js с чужого хоста сработает, попробуйте сделать так: document.write('<script>window.setTimeout(function() { alert(document.cookie) }, 2000);</script>');
Вот вам, господа, информация к размышлению:
Из доков по контексту http в php
Грубо говоря, здесь речь идет как раз об абсолютной форме HTTP target.
То есть, чтобы вам для воспроизведения уязвимости не пришлось переписывать исходники nginx, попробуйте просто сделать вот так:
` <?php $opts = array( 'http'=>array( 'method'=>"GET", 'request_fulluri' => true, 'header'=>"Host:www.hacker.com\r\n" ) ); $context = stream_context_create($opts); $fp = fopen('http://www.user.com/script_to_hack.php', 'r', false, $context); if (! $fp) { exit('error'); } $contents = stream_get_contents($fp); fclose($fp); echo $contents; `$request = ServerRequestFactory::make();
$uri = $request->getUri();
И потом использовать это в ссылках. А то, что при этом там будет присутствовать хост, причем взятый именно из заголовков, кто будет разбираться в таких подробностях?
Тут люди требуют чистого эксперимента, сразу скажу, что я не хацкер, поэтому получив подобную идею я просто перестраховался от подобной уязвимости, введя в код разрешенные хосты и НЕ ПЫТАЛСЯ эту уязвимость реализовать. Хотя, теперь вижу, что зря и постараюсь эту ошибку исправить в ближайшее время. Тем не менее, важно другое — сама идея довольно проста по меньшей мере для понимания. Это не редкость, когда один человек давал теоретическое обоснование уязвимости, а другой приводил реализацию (начал все мужик, который заявил, что Земля вертится).
Я, конечно, попытаюсь вникнуть в новую для меня область разработки аплетов, но независимо от того, получится у меня, как у новичка или нет — вы не расслабляйтесь (потому, что не факт, что не получится у кого-то другого). И, я еще раз подчеркну смысл всей этой статьи — это касается именно вариантов использования PHP кода.
document.write('<script>window.setTimeout(function() { alert(document.cookie) }, 2000);</script>');