Комментарии 31
russian-domains.ru — неработающий сервис
Это первое, что нашлось по запросу «77.221.130.41» в яндексе. И там есть мой сайт, который я не так давно создал. Так что не соглашусь с Вами.
Можно проверить nslookup — реальные адреса хотя бы первых десяти доменов по Вашей ссылке — часть мертвы, часть на других адресах. Данные сервиса только очень частично соответствуют действительности.
В php.ini по умолчанию файлы сессий создаются с правами 600 — только владелец файла может читать и писать этот файл. Если php запущен в режиме FastCGI или CGI, с использованием suexec для каждого виртуального хоста (домена) — то с соседнего домена/площадки чужие файл-сессии прочитать не удастся.
А вот если режим mod_php — то все площадки читаются от одного и того же имени пользователя (от которого запущен Apache). Соответственно, с чужой площадки легко прочитать не только файл-сессии, но и сделать листинг чужого каталога.
Посмотрите в phpinfo информацию по режиму работы и настройке сессий.
PS: в этой статье на хабре описан пример взлома при mod_php/mod_perl.
А вот если режим mod_php — то все площадки читаются от одного и того же имени пользователя (от которого запущен Apache). Соответственно, с чужой площадки легко прочитать не только файл-сессии, но и сделать листинг чужого каталога.
Посмотрите в phpinfo информацию по режиму работы и настройке сессий.
PS: в этой статье на хабре описан пример взлома при mod_php/mod_perl.
Прочитать вы их и не сможете. Не об этом речь. В имени файла соддержится идентефикатор сессии, имя файла получить может любой владелец
Имя файла — да. Идентификатор сессии соответственно тоже. Но безопасность не ограничивается идентификатором сессии — а содержимое файла прочитать не удастся. Как правильно сказал сотрудник хостера — «многое зависит от реализации авторизации на сайте». И рекомендации даны правильные.
Для Apache есть MPM_ITK, который позволяет запускать PHP под нужным юзером даже в режиме mod_php.
А passthru и прочее в этом духе разрешены на вирт хостинге Инфобокса?
Переносите в информационную безопасность, кармы хватает.
Да да, давайте обхаим инфобокс :)
По теме — баян еще тот, который работает практически на всех хостингах. /tmp в 90% случаев для всех.
По теме — баян еще тот, который работает практически на всех хостингах. /tmp в 90% случаев для всех.
выставление ~/tmp в php.ini в данном случае ничего не даст.
правильно вам ответили — «Для абсолютной безопасности Вы можете заказать выделенное решение, где сможете изменять все необходимые настройки самостоятельно». для того, у кого сайт состоит из трех страниц(а на вирт. хостинге ничего серьезнее не должно быть) гипотетическая кража сессии не такая уж большая проблема.
правильно вам ответили — «Для абсолютной безопасности Вы можете заказать выделенное решение, где сможете изменять все необходимые настройки самостоятельно». для того, у кого сайт состоит из трех страниц(а на вирт. хостинге ничего серьезнее не должно быть) гипотетическая кража сессии не такая уж большая проблема.
К сожалению, между «не должно» и реальностью очень большая разница. Я работаю со многими людьми, содержащие сайты на вирт. хостинге, но при этом их технических знаний вряд ли хватит, чтобы обнаружить такую проблему самостоятельно. И примерно половина из них сумели неплохо раскрутить свой сайт, прежде чем им понадобилась помощь технического специалиста.
А что касается самой уязвимости, то для целенаправленного взлома она мало пригодна, так как сложно получить аккаунт именно на целевом сервере, особенно у крупных хостеров. Но вот для массовых взломов она вполне подходит, хоть и не очень проста в эксплуатации.
А что касается самой уязвимости, то для целенаправленного взлома она мало пригодна, так как сложно получить аккаунт именно на целевом сервере, особенно у крупных хостеров. Но вот для массовых взломов она вполне подходит, хоть и не очень проста в эксплуатации.
Вам абсолютно правильно ответили и дали правильные рекомендации, такая структура наблюдается на 90% хостингов и в этом нет ничего криминального, хотите настаривайте на ~/tmp хотите берите выделенный сервер/впс все зависит от степени запущенности паранойи клиента.
Я единственный уже по горло сыт подобным нытьем по пустякам?
Автор, тебе не жалко времени?
Автор, тебе не жалко времени?
Кхм, а вы зря не верите товарищу. Зимой поломали целую пачку госсайтов у одного хостера в Казахстане, как сообщили пострадавшие товарищи — именно так.
Как уже было отмечено выше про работающий на нашем хостинге PHP в режиме FastCGI
В php.ini по умолчанию файлы сессий создаются с правами 600 — только владелец файла может читать и писать этот файл. Если php запущен в режиме FastCGI или CGI, с использованием suexec для каждого виртуального хоста (домена) — то с соседнего домена/площадки чужие файл-сессии прочитать не удастся.
уязвимости, о которой Вы говорите в своем посте, не существует. Возможность листинга файлов сессий не означает возможность получения доступа к ним. Плюс, как Вам верно ответила техническая поддержка, Вы можете использовать директорию в своем хостинговом пространстве для хранения файлов сессий.
По поводу сайтов на IP хостингового сервера попробуйте сделать такой поисковой запрос в Bing:
IP:77.221.130.41
и увидите все сайты на 41-м сервере виртуального хостинга. Это ни для кого не секрет что поисковые машины знают IP-адреса сайтов, которые индексируют и не скрывают их.
Подводя итог всему вышесказанному, делаем вывод, что описанная Вами «уязвимость» не может быть использована на нашем хостинге, а имеет место быть некоторое непонимание работы виртуального хостинга.
В php.ini по умолчанию файлы сессий создаются с правами 600 — только владелец файла может читать и писать этот файл. Если php запущен в режиме FastCGI или CGI, с использованием suexec для каждого виртуального хоста (домена) — то с соседнего домена/площадки чужие файл-сессии прочитать не удастся.
уязвимости, о которой Вы говорите в своем посте, не существует. Возможность листинга файлов сессий не означает возможность получения доступа к ним. Плюс, как Вам верно ответила техническая поддержка, Вы можете использовать директорию в своем хостинговом пространстве для хранения файлов сессий.
По поводу сайтов на IP хостингового сервера попробуйте сделать такой поисковой запрос в Bing:
IP:77.221.130.41
и увидите все сайты на 41-м сервере виртуального хостинга. Это ни для кого не секрет что поисковые машины знают IP-адреса сайтов, которые индексируют и не скрывают их.
Подводя итог всему вышесказанному, делаем вывод, что описанная Вами «уязвимость» не может быть использована на нашем хостинге, а имеет место быть некоторое непонимание работы виртуального хостинга.
как было отмечено выше, в части случаев достаточно знать имя файла сессии, чтобы её перехватить.
Ваше мнение, что уязвимость не может быть использована, очевидно, ошибочно, так как (повторюсь) для перехвата чужой сессии может быть достаточно и имени файла. А перехват чужой сессии = получение доступа (потенциально админского) к чужой админке движка.
Ваше мнение, что уязвимость не может быть использована, очевидно, ошибочно, так как (повторюсь) для перехвата чужой сессии может быть достаточно и имени файла. А перехват чужой сессии = получение доступа (потенциально админского) к чужой админке движка.
Что Вы понимаете под «перехватом» сессии? Если Вы говорите о том, что можно узнать имя файла сессии — этого никто не отрицает. Механизм избежать этого неоднократно описан выше.
По поводу (повторюсь) я не совсем понял — это Ваш первый комментарий в данном посте.
По поводу (повторюсь) я не совсем понял — это Ваш первый комментарий в данном посте.
Избежать этого действительно можно описанным способом. Другое дело, что покупатели виртуального хостинга в большинстве своем ничего не понимают в сессиях, идентификаторах и т. д., потому что используют готовые сторонние движки. Хостеру не составит никаких проблем закрыть дыру, чтобы не напрягать конечных клиентов (в этом ведь и есть смысл клиент-ориентированного сервиса). Хотя, может быть дыра оставлена намеренно, чтобы провоцировать клиентов переходить на «выделенные решения».
Я не понимаю использование термина «дыра» в этом контексте. Оно неуместно.
Те покупатели, которые ничего не понимают в сессиях, не понимают и того, что файлы старых, никому не нужных сессий хранятся и со временем занимают все дисковое пространство, отведенное на аккаунт. Последствия — неработающий сайт, обращения в техническую поддержку, просьбы создать cron-задание, которое будет чистить папку сессий, вопросы «почему об этом должен заботиться я, а не хостер?» и так далее. Надеюсь теперь понятно, почему на виртуальном хостинге хранение файлов сессий организовано так, а не иначе.
Ваш домысел о намеренно оставленной «дыре» и провокациях в сторону клиентов — что-то из области фантастики, не имеющей отношения к нашей компании.
Те покупатели, которые ничего не понимают в сессиях, не понимают и того, что файлы старых, никому не нужных сессий хранятся и со временем занимают все дисковое пространство, отведенное на аккаунт. Последствия — неработающий сайт, обращения в техническую поддержку, просьбы создать cron-задание, которое будет чистить папку сессий, вопросы «почему об этом должен заботиться я, а не хостер?» и так далее. Надеюсь теперь понятно, почему на виртуальном хостинге хранение файлов сессий организовано так, а не иначе.
Ваш домысел о намеренно оставленной «дыре» и провокациях в сторону клиентов — что-то из области фантастики, не имеющей отношения к нашей компании.
Я сам инженер тех. поддержки и знаю, что использовать слова «дыра», «бага» и «косяк» — это плохо =)
Но тут речь как раз о дыре. Да, она обусловлена некоторыми обстоятельствами, но она все равно имеет место быть.
Что касается о намеренном оставлении, то такая мысль пришла мне после прочтения на Хабре статьи об оптимизации хостером VPS, когда кривые настройки вынудили перейти человека на VPS с большим количеством памяти.
Но тут речь как раз о дыре. Да, она обусловлена некоторыми обстоятельствами, но она все равно имеет место быть.
Что касается о намеренном оставлении, то такая мысль пришла мне после прочтения на Хабре статьи об оптимизации хостером VPS, когда кривые настройки вынудили перейти человека на VPS с большим количеством памяти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимость на виртуальном хостинге инфобокса