Например, если у меня есть почтовый скрипт или сценарий, который записывает в базу данных – скрипты, которые не отражают ничего важного (кроме благодарения или сообщения об ошибке), но делают много важной работы на заднем плане.
Каким образом возможные проблемы безопасности могут быть напрямую связаны с ними?
Стоит ли препятствовать прямому доступу к таким файлам?
Они получают данные с использованием $_POST / $_GET отправленных корытных контактных форм, а затем отправляют их по почте или записывают в БД (в обоих случаях после хорошей проверки).
Тем не менее, можно ли каким-либо образом получить доступ к данным, которые работают с ними (кроме взлома моей учетной записи и их загрузки :)), поскольку, очевидно, открытие таких файлов в браузере не даст никаких результатов злоумышленнику?
Риск безопасности заключается в том, что веб-сервер не сможет выполнить файл php (поскольку конфигурация была сброшена), исходный код будет отображаться внутри браузера как обычный текст. И вы, вероятно, хотите это предотвратить.
Рядом с этим сценарием возникает другая проблема: если файл действительно что-то делает с вашими данными базы данных, например, вызов файла, даже без прямого выхода, будет иметь влияние непрямого вывода. Это обычно нежелательно.
В вашем случае он отправляет электронное письмо даже, поэтому для отправки электронных писем могут использоваться прямые запросы. Возможно, это тоже нежелательно.
Не говоря уже о рисках, которые это может иметь для проникновения ваших вещей. Не то, чтобы это было единственное место, где это возможно, но вы должны держать поверхность маленькой.
Однако лучший подход заключается в том, чтобы хранить код приложения за пределами веб-корня, чтобы эти файлы никогда не были доступны прямым HTTP-запросом.
Вы просто не знаете, что сценарий будет делать, когда выполняются вне контекста, поэтому, прежде всего, хорошо предотвратить это. Предпочтительно это делается путем установки переменной (или, скорее, DEFINE) на вашей странице входа и проверки всех остальных файлов, если она установлена.
Тогда, это хорошая вещь, чтобы поместить другие файлы в отдельный каталог, вне вашего корня документа. Это предотвратит загрузку скриптов. Это никогда не должно происходить, потому что они обычно анализируются, но одна ошибка может привести к тому, что PHP будет отключен, и в этом случае php-файлы будут передаваться через Apache, как если бы они были текстовыми файлами.
Если люди могут просматривать ваш код, они могут узнать о структуре данных, возможно, паролях и уязвимостях в вашем коде.
Поэтому, если это возможно, поместите свои файлы вне корневого каталога. Если вы это сделаете, вам не нужно будет проверять это определение, но это не повредит, если вы это сделаете.
Как сказал Крис, если сценарий принимает любые параметры $_GET , $_POST или $_COOKIE , существует риск того, что кто-то сможет легко проникнуть на ваш сервер.
Если сценарий фактически выполняет любые действия, которые могут вызвать проблемы, если они выполняются слишком часто или слишком быстро (например, длительный почтовый сценарий), вы можете стать легкой целью для атаки DOS.
В принципе, если скрипт что-то делает с чем угодно и должен быть вызван только из другого скрипта, не позволяйте ему работать при каких-либо других обстоятельствах. Некоторые проекты OSS (Joomla, WordPress и т. Д.) Используют константу для проверки того, что файл фактически вызывается из приложения. Константа не будет существовать, если скрипт вызывается пользователем непосредственно из браузера.
Если вы не намерены напрямую обращаться к вашим сценариям, то вам, вероятно, следует запретить доступ. Независимо от того, откликаются они или нет, это не относится к делу. Большая проблема заключается в том, что они все равно могут принимать входные данные от пользователя в виде $_GET , $_POST , $_SESSION или $_COOKIE . Это может привести к внедрению SQL среди других проблем. Кроме того, без указания главной страницы frontend скрипты бэкэнд могут не знать, как правильно выполнять свою работу (некоторые варны не могут быть установлены и т. Д.), Поэтому может возникнуть очень странное поведение.
Лучшее, что вы могли бы сделать, это поставить тревожные php-файлы за пределы каталога htdocs, а затем использовать их, чтобы втянуть их. Очевидно, вам нужно будет настроить свои пути.