Предотвратите Прямой доступ К Файлу Под названием Функцией ajax [дубликат]
Я не рекомендовал бы просто переключиться на существующем проекте. Возможно, запустите маленький "демонстрационный" проект, который команда может использовать, чтобы экспериментировать с технологией и (при необходимости) изучить то, что они должны и демонстрируют управлению, что стоит переключиться. В конце даже команда разработчиков могла бы понять, что они не готовы, или это не стоит того.
Независимо от того, что Вы делаете, убедиться зарегистрировать его. Возможно, при использовании демонстрационного проекта запишите вскрытие для дальнейшего использования.
5 ответов
Большинство запросов / фреймворков Ajax должны устанавливать этот конкретный заголовок, который вы можете использовать для фильтрации запросов Ajax v Non-ajax. Я использую это для определения типа ответа (json / html) во многих проектах:
if( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) && ( $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ) )
{
// allow access....
} else {
// ignore....
}
изменить: Вы можете добавить это самостоятельно в свои собственные запросы Ajax, указав в коде javascript следующее:
var xhrobj = new XMLHttpRequest();
xhrobj.setRequestHeader("X-Requested-With", "XMLHttpRequest");
я использую: Сеансы PHP + хэш, который отправляется каждый раз, когда я делаю запрос. Этот хеш генерируется с использованием некоторого алгоритма на стороне сервера
Based on your description, I assume you're trying to prevent outright rampant abuse, but don't need a rock-solid solution.
From that, I would suggest using cookies:
Just setcookie() on the page that is using the AJAX, and check $_COOKIE for the correct values on func.php. This will give you some reasonable assurance that anyone calling func.php has visited your site recently.
If you want to get fancier, you could set and verify unique session ids (you might do this already) for assurance that the cookie isn't being forged or abused.
Mmm... you could generate a one-time password on session start, which you could store in the _SESSION, and add a parameter to your ajax call which would re-transmit this (something like a captcha). It would be valid for that session only.
This would shield you from automated attacks, but a human who has access to your site could still do this manually, but it could be the base to devise something more complicated.
Я хотел бы спросить, почему вы так убеждены, что никто не может напрямую посещать этот файл. На самом деле вашим первым действием должно быть предположение, что люди могут напрямую посещать страницу, и действовать в соответствии с этой возможностью. Если вы по-прежнему уверены, что хотите закрыть доступ к этому файлу, знайте, что нельзя доверять переменным $ _ SERVER для этого, так как источник $ _ SERVER может быть трудно определить и значения заголовков можно подделать. В ходе некоторых тестов я обнаружил эти заголовки ( $ _ SERVER ['HTTP_X_REQUESTED_WITH'] & $ _ SERVER ['HTTP_X_REQUESTED_WITH'