Безопасно ли делать файлы исходного кода доступными для записи веб-сервером?

Об этом уже спрашивали два дня назад и есть ответ, что-то изменилось с тех пор?

@brombeer вопрос, заданный два дня назад, помечен как «мнение» и закрыт. Как вы думаете, может ли быть 2 мнения по этому вопросу?

Правильное разрешение — 755 (drwxr-xr-x) для каталогов и 644 (-rw-r--r--) для файлов.

@LK77 LK77 Спасибо за предложение. А вот если для файлов выбрать 644. 6 означает чтение и запись. Это означает, что вы оставляете возможность записи для владельца, а владельцем в этом примере является www-data.

Это не предложение, это стандартное разрешение в экосистеме PHP, куда бы вы ни посмотрели, оно всегда 755/644, иногда 750/640, но это все. Я предполагаю, что если никто не удаляет разрешение w, это потому, что оно не повышает безопасность. Если у пользователя уже есть доступ к www-данным, у вас, я думаю, более серьезная проблема.

@ Lk77 перечитай мой комментарий еще раз. Вы ошиблись в своем предложении - 644 означает: 6 - читать и писать. первое число описывает разрешения владельца. владелец - www-data. Это означает, что вы собираетесь предоставить права на запись исходному коду веб-сервера.

@YanDatsiuk Я правильно прочитал, 6 означает rw для www-данных, и это так и есть, и это означает, что исходный код действительно будет иметь разрешение на запись, я только предполагаю, что это не рассматривается как проблема безопасности

@ Lk77, значит, вы утверждаете, что разрешение на чтение и запись для www-данных нормально и безопасно? Вы прочитали название этого вопроса?

Давайте продолжим обсуждение в чате.

@ Lk77, это звучит как плохой дизайн. Разрешений на чтение и выполнение должно быть достаточно. Исходный код не должен быть доступен для записи веб-серверу. Для этого редко, если вообще когда-либо, есть веская причина.

@ADyson в моих тестах владелец файла в любом случае сможет изменить права доступа к файлу, поэтому в этом случае веб-сервер не должен быть владельцем файла. Возможно, это звучит плохо, но это то, что я нашел в качестве рекомендуемого разрешения для php-файлов в Интернете, я не нашел ни одной статьи, рекомендующей устанавливать разрешения ниже 640. Возможно, лучше установить право собственности как root:www-data

@ Lk77 Lk77 Я не говорил о конкретном коде разрешения, который нужно использовать, а только об общем принципе, согласно которому веб-сервер не должен иметь возможности записывать в файлы. Однако ФП хочет, чтобы это произошло, зависит от них. Однако я предполагаю, что учетная запись веб-сервера, вероятно, не является хорошей идеей владеть файлами, она должна просто иметь возможность читать и выполнять их. И если учетная запись веб-сервера не является владельцем, то с 640 он не сможет их выполнить.

php-файлы не являются исполняемыми файлами, поэтому разрешение x не требуется, я пробовал с -r--r----- 1 lk77 www-data 20 Sep 18 11:13 test.php и sudo -u www-data php test.php работает нормально, поэтому минимальное разрешение — 440

Я суммирую все вышеизложенные идеи: лучшее решение на данный момент — установить разрешения 440, а также сменить владельца на другого пользователя: -r--r----- 1 root www-data 1883 Sep 18 11:34 index.php

@ADyson -- Source code should not be writable by the webserver -- Я могу вспомнить два конкретных случая (1) при автоматических обновлениях Wordpress: код изменяет код; но (2) в более широком смысле, где пользователю веб-сервиса нужен доступ, это действительно зависит от вашего приложения и дизайна. Например, Laravel и многие другие системы (небольшие по масштабу) используют файловую систему для таких вещей, как ведение журнала и кэширование, и даже загрузка хранилища или создание отчетов. В более крупных приложениях имеет смысл использовать Redis для кэширования или S3 для хранения файлов. Но не в небольших приложениях.

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

Почему именно требуются разрешения на выполнение? Это кажется ненужным и допустимым для PHP. Кроме того, этот подход предполагает (без указания/спрашивания?), ведут ли они журналирование на основе файлов (по умолчанию в Laravel), разрешают загрузку или любое количество других вещей, при которых существует намеренный доступ к локальному диску из приложения. Одним из основных модулей Laravel является компонент файловой системы, который, хотя и не является исключительным для локального хранилища, безусловно, иллюстрирует тот факт, что многим сайтам требуются системы хранения.

@JasonOlson Why exactly does it require execute permissions Для правильной работы каталогам необходимы разрешения на выполнение, но PHP этого не делает... поэтому мы не предоставили PHP выполнение. (644 не позволяет выполнить.) --- RE: Остальное - Да, эти настройки предназначены для типичной настройки. Я полагаю, что ВОЗМОЖНО, например. ОП не хочет разрешать администраторам добавлять изображения на веб-сайты, но большинство веб-сайтов выглядят лучше с изображениями, а это означает, что им необходимо разрешить загрузку файлов или всегда находиться рядом с редактором контента. (Полагаю, если только все не делается в STAGE.)

@JasonOlson Если вы чувствуете необходимость отключить функции, которые вам не нужны, и хотите дополнительно детализировать свои разрешения, я полагаю, вы МОЖЕТЕ использовать laravel.com/docs/10.x/structure для просмотра каждой каталог и решите, нужен ли он вам. Но многие разработчики не уверены ТОЧНО, какие каталоги им нужны, поэтому настройки «Разрешить Laravel писать в те каталоги, в которые он хочет, и блокировать все, в что Laravel не хочет писать» являются стандартной практикой.

Ирония вашего заявления заключается в том, что если вы отключите доступ для записи, вы фундаментально нарушите встроенные функции автоматического обновления Woocommerce. Таким образом, тем самым вы будете продвигать отсутствие возможности автоматического обновления сторонних плагинов. Более того, большинство крупных взломов Woo привели к утечке данных независимо от доступа на запись к пути.

@JasonOlson: На самом деле автоматические обновления (также WordPress) небезопасны, поэтому ирония заключается в формулировке вашего заявления. Но это более длительное обсуждение, вероятно, выходит за рамки данной темы, так что, к вашему сведению и без обид, мы не можем решить все проблемы сразу для программного обеспечения, которое мы представляем, только в их начале.