Пользуюсь китайским пластиковым чехлом, защищающим поликарбонатный корпус (и частичной экран) от царапин. А так же китайской триногой, крепление от которой отлично подходит к любому другому штативу нормальных размеров. В длительные поездки непременно беру внешний аккум на 11Ач (раз 5 позволяет зарядить телефон).
На подходе 8х и 12х телеобъективы. Китайская солнечная зарядка показала неспособность работать с устройствами, потребляющими больше 500мА (пару минут работает, потом срабатывает защита, и 20 минут зарядка прикидывается дохлой).
Получается, что если комментарии не отключены, включены динамические снипперы и стоит один из выше упомянутых плагинов, то выполнять произвольный код может любой пользователь, следующим комментарием:
Хорошо, когда за nginx находятся свои приложения, которым можно доверять. Но бывает, что ставятся чужие решения, и не всегда они достаточно качественные, чтобы просто их поставить и забыть.
Пример с авторизацией через поддомен — это частный случай. Но можно взять более распространённый пример — сбор статистики средствами самого движка. Очень часто приходится сталкиваться с тем, что переменной HTTP_HOST доверяют, считая, что раз веб сервер отправил на их сайт запрос, значит в HOST будет точно их хост.
Опять же, одно дело дорогие регулярки и модули, а другое дело, практически бесплатный костыль :)
В моём случае, в server_name написано "~^((.*)\.)*(.+\..+)$", а валидный хост передаётся отдельным заголовком.
Перенастроил fastcgi на обычные сокеты, посмотрел трафик — действительно, передаётся оба заголовка HTTP_HOST. Но опять таки, то, что nginx и php в разном порядке рассматривают заголовки — это не правильно, как мне кажется.
Согласен, что доверять данным, полученным от пользователя нельзя. Но от этого не становится меньше уязвимых приложений. И если есть возможность на уровне веб сервера хоть немного прикрыть дыры приложений, которые за ним прячутся, то я не упускаю такой возможности.
Конечно браузер не будет посылать два заголовка Host, но ведь не только браузеры заходят на сайты. Внимание на данную проблему я обратил после того, как на одном сайте обнаружил «хитрый» механизм входа в админку, основанный на домене. Авторизация для входа на поддомен админки была настроена в nginx, а проверка домена в самом приложении.
Возможно оно так и есть, но ведь решить проблему можно только на уровне nginx. И в конфиге по умолчанию, который так же предлагается во многих мануалах по настройке nginx+php-fpm, этот момент упущен.
А tcpdump умеет слушать файловые сокеты? Если нет, то чем можно? Сходу не смог найти подходящей утилиты.
Скрипт index.php выводит некоторые переменные из массива $_SERVER, включая HTTP_HOST.
Делаем запрос:
# nc darkbyte.ru 80
GET / HTTP/1.1
Host: xenv.darkbyte.ru
Host: evil.com
Connection: close
В ответе видим: HTTP_HOST=evil.com
Т.е. nginx в переменной server_name видел xenv.darkbyte.ru, а PHP увидел уже evil.com.
Если добавить строку: fastcgi_param HTTP_HOST $host, то проблема решается, PHP видит тоже самое, что и nginx.
Это можно проверить, сделав такой же запрос, но в первом Host указать env.darkbyte.ru.
Если поменять заголовки местами, то будет 404, ибо evil.com у меня на сервере не объявлен.
Это интересно. Ещё есть забавный момент с передачей двух заголовков Host. В случае неправильной (той, которая по умолчанию, и в мануалах в интернетах) конфигурации nginx, он увидел первый заголовок, а на бэк-энд отправит второй.
Быстрый гуглинг дал следующие результаты:
данные трубки со спутником общаются на частотах: 1618.85 — 1626.5 Мгц
спутники данной системы связи между собой общаются на: 23.18 — 23.38 Ггц.
На второй картинке уже побольше частоты: 3.4 — 4.2 GHz и 5.700 — 6.725 GHz на приём и передачу. Вместе с увеличением частоты, увеличился размер антенны. Потребляемая мощность 180Вт.
И сигналы принимаются антеннами в десятки метров, а отправляются передатчиками, запитываемыми не от солнечных батарей? Спутники разные бывают, и на частотах разных общаются. Взять тот же GPS. Чем сильнее облачность — тем хуже качество сигнала, принимаемого со спутников.
Насколько я знаю, чем выше частота, тем лучше сигнал проходит через ионосферу, но в данном случае, точка доступа будет летать ниже ионосферы, в стратосфере. А вот для прохождения тропосферы, в которой облачность образуется, наоборот, чем ниже частота, тем лучше проходимость. Вода из облаков умеет как поглощать, так и отражать сигнал, всё это негативно будет сказываться на уровне сигнала.
Про погоду понятнее не стало. Если шар летает выше облаков, а пользователи находятся ниже, то какой мощности должен быть сигнал на частоте 2.4Ггц (уж не говоря про 5Ггц), чтобы пробиться сквозь облака? Или интернет будет работать только в ясную погоду?
На подходе 8х и 12х телеобъективы. Китайская солнечная зарядка показала неспособность работать с устройствами, потребляющими больше 500мА (пару минут работает, потом срабатывает защита, и 20 минут зарядка прикидывается дохлой).
А архив действительно интересен, чувствую много времени понадобится, чтобы его целиком изучить.
Опять:
?
Пример с авторизацией через поддомен — это частный случай. Но можно взять более распространённый пример — сбор статистики средствами самого движка. Очень часто приходится сталкиваться с тем, что переменной HTTP_HOST доверяют, считая, что раз веб сервер отправил на их сайт запрос, значит в HOST будет точно их хост.
Опять же, одно дело дорогие регулярки и модули, а другое дело, практически бесплатный костыль :)
В моём случае, в server_name написано "~^((.*)\.)*(.+\..+)$", а валидный хост передаётся отдельным заголовком.
Согласен, что доверять данным, полученным от пользователя нельзя. Но от этого не становится меньше уязвимых приложений. И если есть возможность на уровне веб сервера хоть немного прикрыть дыры приложений, которые за ним прячутся, то я не упускаю такой возможности.
Конечно браузер не будет посылать два заголовка Host, но ведь не только браузеры заходят на сайты. Внимание на данную проблему я обратил после того, как на одном сайте обнаружил «хитрый» механизм входа в админку, основанный на домене. Авторизация для входа на поддомен админки была настроена в nginx, а проверка домена в самом приложении.
А tcpdump умеет слушать файловые сокеты? Если нет, то чем можно? Сходу не смог найти подходящей утилиты.
Берём fastcgi_params из wiki.nginx.org/PHPFcgiExample (соответствует конфигу по умолчанию)
В конфиге хоста пишем примерно следующее:
Скрипт index.php выводит некоторые переменные из массива $_SERVER, включая HTTP_HOST.
Делаем запрос:
В ответе видим: HTTP_HOST=evil.com
Т.е. nginx в переменной server_name видел xenv.darkbyte.ru, а PHP увидел уже evil.com.
Если добавить строку: fastcgi_param HTTP_HOST $host, то проблема решается, PHP видит тоже самое, что и nginx.
Это можно проверить, сделав такой же запрос, но в первом Host указать env.darkbyte.ru.
Если поменять заголовки местами, то будет 404, ибо evil.com у меня на сервере не объявлен.
При использовании fastcgi, в файле fastcgi_params отсутствует установка заголовка Host. Должно быть:
fastcgi_param HTTP_HOST $host;
При использовании proxy_pass нужно обязательно указывать:
proxy_set_header Host $host;
данные трубки со спутником общаются на частотах: 1618.85 — 1626.5 Мгц
спутники данной системы связи между собой общаются на: 23.18 — 23.38 Ггц.
На второй картинке уже побольше частоты: 3.4 — 4.2 GHz и 5.700 — 6.725 GHz на приём и передачу. Вместе с увеличением частоты, увеличился размер антенны. Потребляемая мощность 180Вт.
Насколько я знаю, чем выше частота, тем лучше сигнал проходит через ионосферу, но в данном случае, точка доступа будет летать ниже ионосферы, в стратосфере. А вот для прохождения тропосферы, в которой облачность образуется, наоборот, чем ниже частота, тем лучше проходимость. Вода из облаков умеет как поглощать, так и отражать сигнал, всё это негативно будет сказываться на уровне сигнала.