Подтвердить что ты не робот

Как я могу лучше защитить свои запросы php, jquery, ajax от злонамеренных пользователей

Я отправляю много данных с помощью метода jQuery getJSON, примером функции является

function doSomething(sid){
    if(sid){

    $.getJSON("ajax/ajaxDoSomething.php",{sid:""+sid+""}, function(data){
        //alert(data);
        if(data.success == true){
            $('#add_vote_div').html('vote received');
            $('#list_data_div').html(data.html);
        }
        else{
            $('#add_vote_div').html(data.message);
        }
    });
  } 
}`

Проблема в том, что любой может посмотреть на источник и увидеть, что местоположение файла php отправляет данные GET, поэтому вы можете просто указать свой браузер там и добавить данные в URL. Я проверяю данные, чтобы убедиться, что у них правильный тип данных, но я не хочу, чтобы пользователи могли вообще обращаться к URL.

Я думал, может быть, все файлы ajax за основным корнем документа будут работать, но jquery не может ссылаться на абсолютные пути, например

$.getJSON("var/www/ajax/doSomething.php",{sid:""+sid+""}

(основной корень документа - var/www/html/)

если они сделали $.postJSON, который будет работать лучше, но он не существует, какие-либо идеи?

4b9b3361

ОТВЕТЫ

Ответ 1

Он лишь слегка поднимает планку, но вы можете POST JSON через jQuery.ajax (ссылка) или jQuery.post (так что). jQuery.getJSON - это всего лишь оболочка для ajax (as .post и .get). Из getJSON docs:

Это сокращенная функция Ajax, которая эквивалентна: 

$.ajax({
    url:      url,
    dataType: 'json',
    data:     data,
    success:  callback
});

Таким образом, чтобы сделать вашу концепцию postJSON, вы просто добавили к ней параметр type:

$.ajax({
    url:      url,
    type:     'POST',   // <== the new bit
    dataType: 'json',
    data:     data,
    success:  callback
});

Если вы действительно этого захотите, вы можете добавить объект postJSON в объект jQuery, предварительно обработать аргументы и затем вызвать $.ajax. Это в основном копия и вставка из источника jQuery, но переключение .get на .post:

if (!jQuery.postJSON) {
    jQuery.postJSON = function( url, data, callback ) {
        return jQuery.post(url, data, callback, "json");
    };
}

Имейте в виду, это все еще довольно легко подделать POST. Не так просто, как GET, но все же довольно легко.

Ответ 2

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

Подделка запроса на межсайтовый запрос:

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

Первый вид может быть заблокирован путем пометки каждого вызова с помощью ключа сеанса и обеспечения его правильности. Однако это не может предотвратить второе.

Хорошей новостью является то, что эта атака может быть остановлена ​​с секретным значением, которое является частью URL-адреса, часто меняются, запомнилось на бэкэнде достаточно долго, чтобы гарантировать, что он был правильно вызван. Мы говорим об AJAX здесь, поэтому самый простой способ сделать это - загрузить полную загрузку страницы, вы создадите секретное значение случайного числа. Это то же самое относится к традиционным формам, помните об этом и выполняйте проверку старой секретной ценности, прежде чем создавать новую. Вы сохраняете это значение в данных сеанса и добавляете его ко всем вызовам AJAX или форме с последующей страницы. Если они совпадают, это тот же пользователь. Если нет, вы просто игнорируете запрос.

Каждый раз, когда пользователь загружает целую новую страницу, создайте новый секрет для этого пользователя. Это означает, что только если злоумышленник является пользователем, он сможет найти это значение. Это означает, что вы победили этот тип атаки.

Скрипты на сайте:

Атаки XSS отличаются друг от друга тем, что они являются противоположной стороной атак CSRF, среди прочего. Это легко. Просто убедитесь, что ВСЕ данные, поступающие от пользователя или базы данных, передаются через некоторую функцию, которая превращает html-символы в свои объекты, например htmlentities() в PHP, перед тем, как вы покажете их на своем сайте. Это будет сделано для того, чтобы пользователь не использовал JavaScript для перенаправления пользователей на действия или другие вредоносные действия. Это также предотвратит включение флэш-памяти и других объектов на страницу.

К сожалению, это также предотвратит использование любого HTML-кода в комментариях или в целом ряде статей. Это можно обойти либо с ОЧЕНЬ строгим белым списком тегов, либо с некоторой версией альтернативного кода. (например, этот сайт использует)

На самом деле нет хороших способов создать черный список. Я пробовал. Мы все пробовали. Они не работают.

SQL Injection:

Я не буду вдаваться в подробности здесь, однако, достаточно сказать, что вышеупомянутые атаки ничто по сравнению с ущербом, который это может вызвать. Узнайте об этом.

Помимо этого, вы должны следовать только некоторым рекомендациям. Например, НИКОГДА не попадаешь в ловушку, полагая, что данные, которые вы отправили на javascript, вернутся, как вы ожидаете. Предположим, что самое худшее. Это то же самое относится к традиционным формам. Данные, отправленные пользователю, должны обрабатываться независимо от того, как вы его зашифровали, как если бы это были все новые данные от пользователя.

Если у вас есть метод редактирования для сообщения в форуме. Убедитесь, что у пользователя есть разрешение на редактирование этого сообщения. Убедитесь, что они вошли в систему. Убедитесь, что тайные совпадения. Убедитесь, что введенные данные не содержат инъекций SQL.

Сделайте это, и вы прекратите подавляющее большинство атак.

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

Ответ 3

Невозможно защитить данные с помощью JavaScript. потому что весь код в клиентском коде доступен злоумышленнику. Вы можете попытаться замаскировать соединение данных через сложный JSON. но каждый script kiddie может легко использовать wirehark и просматривать исходный код и видеть, как генерируются данные или куда они отправляются.

Решение заключается в использовании флэш-памяти для хэширования данных. Создайте небольшой флеш файл для получения данных, СОЛЬЬ и зашифруйте его с помощью MD5. чем отправить его на сервер. злоумышленник может видеть данные, но он зашифрован.

Нападающий все еще может попытаться декомпилировать вспышку.

Ответ 4

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

Ответ 5

Посмотрите этот вопрос для обсуждения очень похожей проблемы. Это действительно нелегко сделать, поэтому кто-то не может претендовать на роль вашего JavaScript, так как ваш JavaScript полностью открыт для всего мира.

Ответ 6

Вам понадобятся аналогичные методы, которые необходимо предпринять для предотвращения атак типа Cross Site Request Forgery (CSRF). phpsec.org имеет несколько хороших примеров, которые могут быть адаптированы для ваших запросов Ajax.

Ответ 7

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

Ответ 8

Если эти запросы AJAX возвращают конфиденциальные данные, тогда у вас будет какая-то форма проверки подлинности, чтобы только настоящие запросы из вашего приложения возвращали данные; и любой, кто просто ударил URL-адрес с стороннего веб-сайта, получит код ошибки.

Надеюсь, что это поможет.

Ответ 9

Метод решения двух частей - отправить все запросы ajax/json в мои php файлы в папке адресов переадресации psuedo. И затем проверить домен запросов.

yourdomain.com/somePsuedoFolder/?postRequestData....

Затем вы помещаете перенаправление в .htaccess, который сканирует "somePsuedoFolder" и перенаправляет на ваше длинное имя файла php файла. Таким образом, о чем вы спрашиваете, таким образом люди не могут видеть расположение файла на вашем сервере.

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

Ответ 10

Что я сделал по одному и тому же вопросу, расшифрованный на ваш пример,

  • генерирует случайное число в контроллере PHP, вызывающем Javascript; соедините его с переменной, которую вы передаете на Javascript, и поместите ее в сеанс, например:
$randnum = rand(1,100000);
$_SESSION['sidrandnum'] = $sid.'-'.$randnum;

  • в Javascript, используйте эту новую переменную для замены sid

  • в поставщике данных ничего не возвращает, если рандомизированная переменная не совпадает с

function dataprovider($sidrandnum) { 

if ($sidrandnum != $_SESSION('sidrandnum')) 
    return;
$sidrandtable = explode ('-', $sidrandnum);
$sid = $sidrandtable [0];
...

Таким образом, доступ к данным может осуществляться только внутри одного и того же сервера: вы можете увидеть источник данных, только то, что уже показано на странице конечного пользователя.