Чёт не понял про вынесение директории на поддомен. Вы это про CDN или про что?
Делаете поддомен к своему сайту, например, upload.site.com. Его корневой каталог будет директория upload.
Для основного домена site.com директория upload будет выше корневой директории. Для основного сайта openbasedir должен быть установлен родителем к категории upload и к корневой директории сайта.
Надеюсь понятно объяснил)
Что даст перенос /upload на другую директрою (поддомен)? Скажите пожалуйста)
Что даст перенос /upload на другую директрою (поддомен)? Скажите пожалуйста)
Подобное реализовано на PrestaShop. Это возможность отдавать статику, правда частично, в случае ICMS т.к. css, js и прочее из папки templates всё равно грузится с основного домена.
Вкратце:
1. Когда браузер обращается на сервер за какой-нибудь картиночкой — он отправляет cookie в запросе. Если домен отличается, cookie — не отправляются, что несколько уменьшает объем переданного трафика.
2. Домен для отдачи статики можно настроить без выполнения PHP. Тогда даже если вам в upload кому-то удастся загрузить web-shell — он всё равно не будет выполнен при попытки его запуска из адресной строки, впрочем, он всё равно не будет выполнен т.к. .htaccess запрещает, но я бы на один лишь .htaccess не рассчитывал)) Это если мы говорим об Apache.
Домен для отдачи статики можно настроить без выполнения PHP.
А как у вас тогда будут грузится изображения на этот домен?
А как у вас тогда будут грузится изображения на этот домен?
Так штатно же
Я имел в виду, что сможет ли PHP создавать на этом домене изображения, если ему там работать нельзя?
сможет ли PHP создавать на этом домене изображения, если ему там работать нельзя?
Вы не поняли. Изображения кладёт в директорию основной сайт.
Вы не поняли. Изображения кладёт в директорию основной сайт.
Да, но у PHP, который работает на основном сайте должно быть право писать на домен со статикой?
Да, но у PHP, который работает на основном сайте должно быть право писать на домен со статикой?
Да при чём тут домен :) Речь про соседнюю директорию (или на два, три, etc уровня выше) основного сайта, которая для поддомена картинок является корневой. Я выше же дал линк на доку.
Тут наверное стоит дополнить, что в случае использования виртуального хостинга — некоторые хостеры изолируют сайты друг от друга в рамках одного юзера. Beget, IHC и ряд других. В таких случаях, надо смотреть по ситуации.
А что касается, ICMS — upload на др.домене — всё чётко работает — я тестил) Видимо, изначально задумывалось под мультисайт) В любом случае, очень хорошо что это есть и проработано.
На Sprinthost можно так сделать, спросил сейчас… И, видимо, так и сделаю. А как потом обновляться?
На Sprinthost можно так сделать, спросил сейчас… И, видимо, так и сделаю. А как потом обновляться?
Так вы принципиально ничего не меняете в движке. Прописали в config.php значения ключам upload_root, upload_host, затестили и забыли.
На Sprinthost можно так сделать, спросил сейчас… И, видимо, так и сделаю. А как потом обновляться?
Так вы принципиально ничего не меняете в движке. Прописали в config.php значения ключам upload_root, upload_host, затестили и забыли.
Все старательно записываю в блокнотик! Спасибо! ) Тема крайне интересная...
Может кто за WAF с icms работал и поделится опытом? Нет таких?)
Первый блин комом (хотя, любой опыт полезен, считаю)) Три дня барахталась ТП хостера с моим поддоменом. В итоге — мягкий самоотвод, по сути, в последнем ответе:
«Изучил тему безопасности на форуме. Насколько я понял, вас заинтересовал момент с возможность загрузки php скриптов в директорию upload с дальнейшей возможностью их запуска из браузера. Но в этом же посте было сказано, чтобы закрыть уязвимость, нужно отключить выполнение php скриптов для новой директории (поддомена), однако без .htaccess это получится реализовать, только разместив поддомен (добавив отдельным сайтов) на отдельном веб-сервере с другим интерпретатором.
Исходя из вышесказанного, не уверен, что реализация изменения отдачи статики окупит потраченное время и действительно обезопасит сайт. К тому же в upload уже есть .htaccess с запрещающей директивой php_flag engine 0, которая закрывает уязвимость.»
Поскольку я некомпетентен в вопросах веб-безопасности настолько, чтобы давать им советы как и что надо сделать, да и терпением не отличаюсь (увы), решил не испытывать больше ни свое, ни их. Может быть, позже, когда-нибудь… )
Первый блин комом (хотя, любой опыт полезен, считаю)) Три дня барахталась ТП хостера с моим поддоменом. В итоге — мягкий самоотвод, по сути, в последнем ответе:
«Изучил тему безопасности на форуме. Насколько я понял, вас заинтересовал момент с возможность загрузки php скриптов в директорию upload с дальнейшей возможностью их запуска из браузера. Но в этом же посте было сказано, чтобы закрыть уязвимость, нужно отключить выполнение php скриптов для новой директории (поддомена), однако без .htaccess это получится реализовать, только разместив поддомен (добавив отдельным сайтов) на отдельном веб-сервере с другим интерпретатором.
Исходя из вышесказанного, не уверен, что реализация изменения отдачи статики окупит потраченное время и действительно обезопасит сайт. К тому же в upload уже есть .htaccess с запрещающей директивой php_flag engine 0, которая закрывает уязвимость.»
Поскольку я некомпетентен в вопросах веб-безопасности настолько, чтобы давать им советы как и что надо сделать, да и терпением не отличаюсь (увы), решил не испытывать больше ни свое, ни их. Может быть, позже, когда-нибудь… )
Видимо, издержки виртуального хостинга)
В том же ISPmanager и других панелях — PHP для домена отключается довольно элементарно.
Ну хотя бы вот: docs.ispsystem.ru/ispmanager-lite/php/reyoimy-raboty-php
Или FastPanel: fastpanel.direct/wiki/ru/site-settings#php-settings