PHP Lang
  1. PHP Lang
  3. Как защитить файл php
Intereting Posts
Поведение Yii2 Timestamp возвращается 0000-00-00 00:00:00 Плагин WordPress – добавьте новую страницу Symfony2 REST API – частичное обновление Загрузка изображения с URL-адресом в Codeigniter Каковы различные способы написания условных операторов if, использующих PHP? Как получить имя столбца, значение которого не равно null в mysql Apache переписывается для Laravel / public Объявляет ли ненужную переменную в PHP память? Группировать многомерный массив по определенному значению? Пользовательский агент SimpleXML Избегайте повторения уведомлений по электронной почте о некоторых завершенных заказах Создание одного-много полиморфных отношений с доктриной Установка расширения PHP Zip Загрузка файла Ajax с данными формы Laravel 5.3 Сравнение строк и значений Оптимизация запросов MySQL

Как защитить файл php

Я сделал интеграцию платежных шлюзов на существующем веб-сайте. Платежный шлюз дал мне API, который я использовал, и сделал кодировку и сохранил ее в php-файле pay.php

У меня есть форма pay.php на главном веб-сайте и при нажатии submit, он отправляет все необходимые данные в pay.php через post а затем этот файл делает все остальное и отправляет данные на платежный шлюз.

Так как этот файл pay.php хранит чувствительные данные, я хочу его защитить, чтобы никто другой не мог получить к нему доступ через веб-браузер, например, через http://domain.com/pay.php или загрузить его.

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

Также каждый раз, когда pay.php файл pay.php создается ссылка на платеж, поэтому мне нужно убедиться, что только сайт http://www.domain.com может использовать этот файл и не имеет стороннего партнера.

У меня уже есть несколько идей в моей голове, таких как ограничение доступа с использованием удаленного IP и т. Д., Но хотелось бы знать, как наилучшим образом решить проблему.

Related of "Как защитить файл php"

Чтобы добавить к ответу Commusoft и дать небольшую альтернативу.

Этот фрагмент .htaccess запрещает запросы файла php через браузер и гарантирует, что вы можете включать только файл из другого php-файла. 

 <Files *.php> Deny from All </Files>

Поместите это в отдельный каталог, где находится pay.php .

Я думаю, что лучший способ справиться с этой проблемой платежа – превратить pay.php в полный класс и использовать его объектно-ориентированную. Таким образом, вы можете использовать функциональность в любом месте и легко передавать переменные.

  1. Вы можете выполнять только POST-запросы в этом файле (также вы должны проверять даже POST-запросы). Запрос GET не вернет ничего или ошибку.
  2. Обычно вы не можете скачать php-файл простым способом. Для этого нужны некоторые дыры в безопасности сайта.
  3. Вы можете направлять весь запрос в один файл php. Обычно это index.php. Попробуйте посмотреть, как настроить его с помощью .htaccess . И пользователи не будут знать о ваших реальных файлах PHP.
  4. При необходимости вы можете защитить свои файлы через разрешения.

  • Если вы правильно настроите свой веб-сервер (Apache, …), веб-сервер будет отображать PHP, поэтому никто не сможет увидеть исходный код файла . Таким образом, существует некоторая неотъемлемая защита . Но, разумеется, его можно взломать .

  • Теперь хакеры, конечно же, хотят взломать веб-сайт. И у вас нет информации о том, какие данные будут опубликованы: это зависит от браузера. Хакеры иногда изменяют контент до отправки запроса в надежде, что скрипт PHP каким-то образом потерпит неудачу и покажет, например, SQL-запросы и т. Д. Первое, что вам лучше сделать, это отключить отчет об ошибках : 

     error_reporting(0);

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

  • Кроме того, вы должны убедиться, что у пользователя нет прямого доступа к конфиденциальным данным. Это может быть достигнуто путем помещения конфиденциальных данных в отдельный файл (например, secure.php ) и include_once() чтобы вы могли прочитать его данные.

  • Как говорят @Havenard и @AlexHowansky, вы также можете хранить такие файлы ( secure.php ) лучше за пределами общедоступных каталогов . Например, выше public_html . Это не всегда полностью решает проблему, потому что некоторые веб-серверы чувствительны к URL-инъекции (указав http://www.domain.com/../securefolder/secure.php , иногда вы можете получить доступ к файлу над общедоступным каталогом ).

  • Как говорит @TomKriek, вы также можете предоставить дополнительную защиту «безопасной папке», вставив файл .htaccess который содержит следующие строки: 

     <Files *.php> Deny from All </Files>

    Это означает, что веб-сервер – опять же, если он настроен правильно – предотвратит доступ пользователей из всех .php файлов в каталоге.

  • Наконец, вам лучше предоставить файлы надлежащим разрешениям : если PHP-движок работает как тот же пользователь, что и владелец файлов, вы можете предоставить ему 600 прав доступа ( chmod 600 secure.php ) или 640 если PHP-движок работает на другой пользователь, чем владелец файла, но в той же группе пользователей или в худшем случае 644 чтобы хакер не мог изменить файл (или, по крайней мере, не должен). Вы также можете изменить владельца файла на www-data , запустив chown www-data secure.php чтобы владелец был веб chown www-data secure.php , и вы можете сделать его более жестким. Эмпирическое правило всегда дает ему наименьшие права доступа для правильной работы .

  • Вы также можете сделать файлы доступными только для чтения, как только они будут реализованы, установив права на 400 , 440 или в худшем случае 444 . В этом случае, по крайней мере, хакер не может ввести свой банковский счет в качестве получателя платежа;).

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