2012-03-12 2 views
1

На моем сайте, у меня есть search.php страницу, которая делает $.get запросы на страницы, такие как search_data.php и search_user_data.php т.д.Как защитить конфиденциальные файлы PHP, обрабатывающие данные JQuery?

Проблема в том, все эти файлы находятся в моей публичной папки HTML.

Несмотря на то, что кто-то мог перейти на www.mysite.com/search_user_data.php, все обработанные данные были надлежащим образом экранированы и обработаны, но на профессиональном уровне это неадекватно, даже если этот файл находится в пределах досягаемости общественности.

Я попытался переместить чувствительные файлы в свой веб-корень, однако, поскольку JQuery делает $.get запросов и передает переменные в URL-адресе, это не работает.

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

+0

@zerkms Итак, все файлы на каждой существующей веб-странице не должны иметь никакой конфиденциальности? – Norse

+2

PHP не подвергается публике, поэтому «язык на стороне сервера». Он выполнен, и результаты выводятся. – Shea

+0

@andrewjackson Правильно, но я бы предпочел не давать кому-либо возможность играть с URL-адресом, выполняя такие вещи, как 'search_data.php? Id = 394 & pass = 493202'. Разве это не разумно? – Norse

ответ

2

Что вы описываете, это нормально.

У вас есть файлы PHP, которые доступны в вашем каталоге www, поэтому apache (или ваш любимый веб-сервер) может читать и обрабатывать их. Если вы их вытащите, вы не сможете связаться с ними больше, так что нет реальной возможности такого рода.

В конце концов, ваши PHP-файлы для AJAX - это просто обычные php-файлы, скорее всего, ваш другой проект также содержит php-файлы. Правильно ? Они не более или менее подвержены риску, чем любой скрипт на вашем сервере.

Убедитесь, что вы запрограммировали «чистый». Подумайте о злых запросах при написании своих php-функций, а не после их написания. Как вы уже это сделали: правильно укажите весь входящий вход, который может попасть в базу данных или чувствительную функцию.

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

Помимо написания вашего кода как «безопасного», как вы можете, вы можете добавить проверку референта в свой код. Это означает, что ваш PHP-файл будет реагировать только в том случае, если ваш сайт был предоставлен в качестве референта при доступе к нему. Этого достаточно, чтобы заблокировать 80% детей. Но с другой стороны: несколько интернет-пользователей не отправляют рефери вообще, некоторые прокси фильтруют это.(Я лично проигнорировал бы их, половина интернет-перерывов на них в любом случае)

Еще один уровень защиты может быть добавлен htaccess, вы можете сделать больше всего в PHP, но он все равно может представлять для вас интерес: http://httpd.apache.org/docs/2.0/howto/htaccess.html

+0

Я должен добавить: Когда я делаю запросы ajax, а пользователи имеют учетную запись на моем сервере, я обычно передаю идентификатор пользователя и пароль md5 (и некоторую соль). Это можно легко увидеть, если запрос ajax исходит от законного пользователя. – John

2

Вы можете сохранить uid каждый раз, когда ваша страница загружена и сохранить ее в $ _SESSION ['uid']. Вы даете этот UID на JavaScript, выполнив:

var uid = <?php print $_SESSION['uid']; ?>; 

Затем вы передаете его с вашим запросом GET, сравните его с вашим $ _SESSION:

if($_GET['uid'] != $_SESSION['uid']) // Stop with an error message or send a forbidden header. 

Если это нормально, делать то, что вам нужно.

Это не идеально, так как кто-то может запросить search.php и получить текущий uid, а затем запросить другие страницы, но это может быть наилучшим решением.

+0

Это очень полезно спасибо – Norse

+0

Если бы вы использовали этот метод, но с '$ _POST', это было бы намного безопаснее? – Norse

+0

Не совсем. Это было бы тяжелее для новичков, но для других это было бы совершенно просто. – Alytrem

Смежные вопросы