Форум PHP

как защитить файл чтобы его могли инклюдировать токо определенные страницы а то кто нидь инклюднет конфиг и выкачает базу;-)

...

как вариант можно так:

$proverka=md5("проверочное слово"); include("file.php");

а в начале file.php вот так:

if (!($proverka === md5("проверочное слово"))) exit("низя инклудить");

спасибо:-)

Очень удобно это делать константами...
Пример:
в файле каторый инклудим пишем:

if(!define("include"))die();

в файлах откуда инклудим пишем:

define("include");

Леха, "include" не есть хорошее название. Парсер вызов (прямой) не пропустит.

>Леха, "include" не есть хорошее название. Парсер вызов (прямой) не пропустит.
ну уж нашёл к чему придраться... бебе...

if(!define("fsdhjfhsdjkfhsd"))die(); define("fsdhjfhsdjkfhsd");

СДЕЛАЙТЕ ВЫ ЗАЩИТУ ОТ ПОВТОРЕНИЙ ИЛИ НЕТ КОГДА НИТЬ???

а если немного подумать, то условие придется записать так:

<? // index.php $signature = "signature"; include("protected.php");

<? //  protected.php: if (md5($signature) != ".....hash of signature....")) exit("нельзя  инклудить");

ну практически тоже самое что и я написал, только хэш уже готовый должен храниться, на мой взгляд лучше получать хэш динамически, тогда в качестве проверочного слова можно будет использовать какой-нибудь набор символов, который будет одинаковый в пределах главного файла и подключаемого, например что нибудь вроде

$proverka = md5($_SERVER['remote_addr']." bla bla bla ". $_SERVER["SERVER_SIGNATURE"]."bla".$_SERVER["UNIQUE_ID"]);

, но подобрать такое проверочное слово помоему уже труднее

Не то же самое. Принципиальзая разница в той строке, где if.

Вы извратили саму идею пррименения криптохеша для подписи содержимого.
На потенциально открытой стороне секретных компонент подписи видно быть не должно.

Откуда возмётся разница в "открытости" сторон?

Я предположил, что она может возникнуть. Потому, что parczynski применил одну из криптофункций.
Откуда она возьмется - несущественно.
Кстати предположение не выглядит надуманным, если автор темы беспокоится о том, что скрипты нужно защищать от включения в чужой код.

>Я предположил, что она может возникнуть. Потому, что parczynski...

Вопрос задал winflip.
У parczynski скорее всего нет никакой дополнительной информации о структуре сайта winflip.

Может быть это выглядит разумно ещё с каких-то позиций?

Вообще это возможно?
Я себе представить не могу.

>>Я предположил, что она может возникнуть. Потому, что parczynski...
>Вопрос задал winflip.
>У parczynski скорее всего нет никакой дополнительной информации о структуре сайта winflip.

По-моему, у Вас её не больше, чем у него.

>Может быть это выглядит разумно ещё с каких-то позиций?
Да. Я назвал - а Вы не включили в цитату.

>Вообще это возможно?
>Я себе представить не могу.

Я могу чем-то помочь?

Да дополнительной информации нет, и я соглашусь с Trianon, в приведенном мной примере нет смысла от того что ключ доступа шифруется. Признаю немного сглупил, но суть защиты я указал правельно. а владение дополнительной информацией о структуре сайта тут ни при чем

Тогда уж с одной стороны напрашивается ещё и такая проверка во включаемом файле

if ($_SERVER["DOCUMENT_ROOT"] != “My real server root”) die(«Нечего с чужого сайта ко мне заглядывать!»);

С другой стороны если ничего не мешает инклудить, то что мешает просто прочитать конфигурационный файл и отредактировать его чтобы не упирался?

Или на хостинге существует какая-то защита от соседских сайтов?
Может быть скрипты сайта принадлежат одной группе, и чтение ими друг друга разрешено только внутри этой группы? Как это реально на хостингах делают?
Особенно было бы интересно узнать как но softtime это сделано. Раз уж вы такие отъявленные хостеры – объясните! Каждый день ведь вашу рекламу читать приходится!

И ещё. Напишите, пожалуйста, у кого на хостинге СОСЕДСКИЕ САЙТЫ ДОСТУПНЫ! Хоть как-то ситуацию это прояснит. Минимальная, но всё ж статистика!

>С другой стороны если ничего не мешает инклудить, то что мешает просто прочитать конфигурационный файл и отредактировать его чтобы не упирался?

Потому что для инклуда нужна дыра одной ширины.
А для редактирования конфигов - совсем другой.

Бредовый какой то спор выходит.

Я пытаюсь максимально дырки закрыть, а Вы доказываете, что в большинстве случаев эта работа не возымеет толка.

Да, черт подери, не возымеет! В большинстве.
Сайты взламывают не через большинство случаев.
А через оставшиеся от этого большинства прорехи.

>Бредовый какой то спор выходит.

Может для вас это спор, но не для меня.
Я 100% чайник в этой теме. Поэтому я основываюсь на логике ваших же высказываний, а не на знаниях. И не спорю, а задаю, как мне кажется, чёткие вопросы. (Хотя это вполне может быть одной из распространённых иллюзий чайников) Так что именно ваша открытость:

>Я могу чем-то помочь?

Для меня и важна.

Но вот ответ:

>Потому что для инклуда нужна дыра одной ширины.
>А для редактирования конфигов - совсем другой.

Не добавляет абсолютно никакой новой информации. Он подразумевается в самом моём вопросе:

>если ничего не мешает инклудить, то что мешает просто прочитать конфигурационный >файл и отредактировать его чтобы не упирался?

Мне как раз крайне интересно узнать о какой «дыре» идёт речь и как она заделывается. Как после её заделки закрыть ещё и «дыру» с инклудом – прочитал. Спасибо всем! Как же обстоит дело с первой? Кто-нибудь подскажет?

И ещё.

Думаю, что всем, кто рассматривает всерьёз идею размещения своего сайта на softtime, будет интересно узнать:

Какие именно настройки сервера и операционной системы позволяют обезопасить свой сайт от вмешательства со стороны соседских по файловой системе сайтов, и какие ещё специальные меры требуется применять владельцу сайта, расположенного на softtime, чтобы обеспечить наиболее уместный уровень защиты.

Не знаю, уместен ли сам вопрос, но…

Хорошо бы услышать официальный ответ.

>Думаю, что всем, кто рассматривает всерьёз идею размещения своего сайта на softtime, будет интересно узнать:
>
> Какие именно настройки сервера и операционной системы позволяют обезопасить свой сайт от вмешательства со стороны соседских по файловой системе сайтов, и какие ещё специальные меры требуется применять владельцу сайта, расположенного на softtime, чтобы обеспечить наиболее уместный уровень защиты.

Такой запрос лучше сразу адресовать в службу технической поддержки support@st-host.ru. Здесь могу лишь заверить, что любой вменяемый хостер - в первую очередь обеспечивает разделение пользователей и системы (чтобы пользователи по системе шуровать не могли), а во-вторую разделяет пользователей друг от друга (чтобы пользователи не могли шуровать друг у друга). Потом занимается всем остальным. Достигается это директивой open_basedir и несколькими модулями для ядра операционной системы.

>Здесь могу лишь заверить, что любой вменяемый хостер - в первую очередь
>обеспечивает разделение пользователей и системы (чтобы пользователи по системе
>шуровать не могли), а во-вторую разделяет пользователей друг от друга (чтобы
>пользователи не могли шуровать друг у друга).

Приятно конечно, слышать такой ответ, хоть и отвечает он лишь на первую половину моего вопроса. :)
(Интересно, тех. поддержка тоже себя так ведёт?)
Если я правильно понял ответ, то если я расположу свой сайт на softtime, то мои файлы соседи не смогут ни инклудить ни читать как-то иначе. :)

Прекрасно! Тогда я не буду засорять их тем кодом, который упоминается в данной теме.

Однако, неужели вы не замечаете двусмысленности создавшегося положения?!

В обсуждение было вовлечено довольно много народа, а Trianon так вообще пишет прямо: «не выглядит надуманным» - про детали этого обсуждения. Отсюда следует, что всем им приходится хоститься именно у, следуя вашей терминологии, не «вменяемых» хостеров.

Ну, если так случилось на самом деле, то для «вменяемого» владельца сайта – это достаточный повод не полениться переехать к вам.

Пожалуйста, не оставляйте тему на этой двусмысленности!

Либо покажите, аргументировано и убедительно, что ваши слова правомочны, так, чтобы это признали и специалисты. Либо читателям форума останется домыслить что у вас видимо нет, как и у многих других хостеров продуманной системы безопасности, а лишь, извините, фиговый листочек.

Для меня лично такое рассмотрение было бы много эффективнее любой рекламы. Деловые решения принимаются не на эмоциях, а на основе точной информации. Хостинг – это же не подарок жене. Поэтому для его продвижения нужен совсем другой подход! Вот вам и повод… Я лично склонен судить о работе хостинговой команды по тому, как полно собрана и чётко структурирована объективная информация о работе хостинга. По этому признаку как раз и можно понять насколько они ясно мыслят и насколько всё предусмотрели.

>Однако, неужели вы не замечаете двусмысленности создавшегося положения?!

>В обсуждение было вовлечено довольно много народа, а Trianon так вообще пишет прямо: «не выглядит надуманным» - про детали этого обсуждения.
>Отсюда следует, что всем им приходится хоститься именно у, следуя вашей терминологии, не «вменяемых» хостеров.

Откуда следует? Почему следует?
Владелец сайта может хоститься где угодно. Даже у лучшего хостера. И тот факт, что он такового выбрал, не избавляет его автоматически ни от дыр в собственных скриптах, ни от дыр в скриптах сторонних авторов, которые он решил на своем хосте применить.

>Ну, если так случилось на самом деле, то для «вменяемого» владельца сайта – это достаточный повод не полениться переехать к вам.

Пожалуйста, не надо втягивать меня в диспут о том, насколько хорош хостинг на softtime.
У меня никакой прямой информации по этому вопросу нет.

Уважаемый Трианон!
Если вы не хотите втягиваться в диспут – пожалуйста – не втягивайтесь!
Но не создавайте, пожалуйста, лишнего тумана!
Вы пишете:

>Владелец сайта может хоститься где угодно. Даже у лучшего хостера. И тот факт, что он такового
>выбрал, не избавляет его автоматически ни от дыр в собственных скриптах, ни от дыр в
>скриптах сторонних авторов, которые он решил на своем хосте применить.

Это тема изначально не касалась неких таинственно умалчиваемых вами дыр. Речь шла о возможности сторонним скриптам инклудить чужие файлы. Я добавил вопрос о их прямом чтении (поскольку до сих пор не понимаю разницу в происхождении этих двух потенциальных дыр). Я полагаю, что это дыры не в скриптах, а в хостиге. И, разумеется, глупо лечить их средствами PHP, лучше уж выбрать нормальный хостинг. Но вы горячо обсуждали эту тему именно в рамках PHP, делая акцент на наиболее надёжных способах применения кодирования… где логика в ваших действиях? Зачем вы теперь переводите разговор на некие неизвестные дыры, которых никто в теме не касался?

Разумеется, вы можете ничего не разъяснять. Можете и посмеяться. Это может и вообще не ваша тема. Но softtime вполне может счесть мои аргументы из предыдущего поста разумными. Ну, если нет… То будем знать, что они в своей работе делают больше ставки на эмоциональную рекламу, а не на структурный анализ… Ну, как работают – такой и результат получат. Тоже, их дело – выбирать – не моё. Я в маркетинге ничего не смыслю.

>Либо покажите, аргументировано и убедительно, что ваши слова правомочны, так, чтобы это
>признали и специалисты. Либо читателям форума останется домыслить что у вас видимо нет,
>как и у многих других хостеров продуманной системы безопасности, а лишь, извините, фиговый
>листочек.
Какие слова и о чём? Хостинги, не использующие chroot, разграничение прав доступа и basename вымерли несколько лет назад. Вы ненайдёте ни одного хостинга у которого бы была возможность чтения соседних аккаунтов. Могу поделиться скриптом, который осуществляет поиск и чтение соседних аккаунтов, если у вас вызывает затруднение его создание.

PS Имеются некоторые правила игры - если вам нужна информация - вы запрашиваете её в службе технической поддержки. Данный форум не предназначен для обсуждения и решения технических вопросов на хостинге, так как ответить на все вопросы посетителей сотрудники не смогли бы, а выделять клиентов и посетителей форума нам не хочется - для нас все дороги.

Поэтому если вас интересуют особенности хостинга лучше обратиться в службы технической поддержки support@st-host.ru. Более того, вы можете запросить тестовый аккаунт на 7 дней и самостоятельно потестировать хостинг на предмет уязвимостей, попытаться погрызть соседние аккаунты, например, softtime.ru.