Я отправляю много данных через метод 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, который будет работать лучше, но он не существует, никаких идей?
Это только поднимает планку к взлому очень немного, но вы можете POST JSON через jQuery.ajax (это ссылка) или jQuery.post (так и есть). jQuery.getJSON – это просто оболочка для ajax (как и .post , и .get ). Из документов getJSON :
Это сокращенная функция Ajax, которая эквивалентна:
$ .ajax ({ url: url, dataType: 'json', данные: данные, успех: обратный вызов });
Таким образом, чтобы сделать свою концепцию 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, но все же довольно легко.
Вам нужно сделать несколько конкретных типов атак. Даже для очень громких сайтов это обычно достаточно. И для сайта, который не является одним из самых больших сайтов вокруг, этих вещей должно быть более чем достаточно, чтобы остановить сценаристов-детей.
По сути, это то, что вы пытаетесь указать в своем начальном посте. То, что подразумевает этот вид атаки, либо, как вы указываете, выясняет URL-адрес, который может принять какое-то конкретное действие пользователя и вызвать его напрямую. Или, и сложнее защитить, делается путем обмана зарегистрированного пользователя, чтобы щелкнуть ссылку, которая ведет к этому конкретному действию пользователя.
Первый вид может быть заблокирован путем пометки каждого вызова с помощью ключа сеанса и обеспечения его правильности. Однако это не может предотвратить второе.
Хорошей новостью является то, что эта атака может быть остановлена с секретным значением, которое является частью URL-адреса, часто изменяется, запомнилось на бэкэнд достаточно долго, чтобы обеспечить его надлежащее обращение. Мы говорим об AJAX здесь, поэтому самый простой способ сделать это – загрузить полную загрузку страницы, вы создадите секретное значение случайного числа. Это то же самое относится к традиционным формам, помните об этом и выполняйте проверку старой секретной ценности, прежде чем создавать новую. Вы сохраняете это значение в данных сеанса и добавляете его ко всем вызовам AJAX или форме с последующей страницы. Если они совпадают, это тот же пользователь. Если нет, вы просто игнорируете запрос.
Каждый раз, когда пользователь загружает целую новую страницу, создайте новый секрет для этого пользователя. Это означает, что только если злоумышленник является пользователем, он сможет найти это значение. Это означает, что вы победили этот тип атаки.
Атаки XSS отличаются друг от друга тем, что они являются противоположной стороной атак CSRF, между прочим. Это легко. Просто убедитесь, что ВСЕ данные, которые поступают от пользователя или базы данных, передаются через некоторую функцию, которая превращает html-символы в свои объекты, например htmlentities() в PHP, прежде чем вы htmlentities() их на своем сайте. Это будет сделано для того, чтобы пользователь не использовал JavaScript для перенаправления пользователей на действия или другие вредоносные действия. Это также предотвратит включение флэш-памяти и других объектов на страницу.
К сожалению, это также предотвратит использование любого HTML-кода в комментариях или в целом ряде статей. Это можно обойти либо с ОЧЕНЬ строгим белым списком тегов, либо с некоторой версией альтернативного кода. (например, этот сайт использует)
На самом деле нет хороших способов создать черный список. Я пробовал. Мы все пробовали. Они не работают.
Я не буду вдаваться в подробности здесь, однако, достаточно сказать, что вышеупомянутые атаки ничто по сравнению с ущербом, который это может вызвать. Узнайте об этом.
Помимо этого, есть только некоторые рекомендации, которым вы должны следовать. Например, НИКОГДА не попадаешь в ловушку, полагая, что данные, которые вы отправили на javascript, вернутся, как вы ожидаете. Предположим, что самое худшее. Это то же самое относится к традиционным формам. Данные, отправленные пользователю, должны обрабатываться независимо от того, как вы его зашифровали, как будто это все новые данные от пользователя.
Если у вас есть метод редактирования для сообщения в форуме. Убедитесь, что у пользователя есть разрешение на редактирование этого сообщения. Убедитесь, что они вошли в систему. Убедитесь, что тайные совпадения. Убедитесь, что введенные данные не содержат инъекций SQL.
Делайте это, и вы прекратите подавляющее большинство атак.
Не все из них. Тип атаки, который использует FireSheep, по-прежнему будет проходить, как и любая атака, подобная той, которая нацелена на пользователей, а не на ваш сайт. Вы можете защитить от FireSheep с помощью https, а не http. Но даже это не делает ничего против различных атак с таргетингом на пользователя. Такие, как кража сессионных файлов cookie с их машины или физический доступ к их машине.
Невозможно защитить данные с помощью JavaScript. потому что весь код в клиентском коде доступен злоумышленнику. Вы можете попытаться замаскировать соединение данных через сложный JSON. но каждый сценарий kiddie может легко использовать wirehark и просматривать исходный код и посмотреть, как генерируются данные или куда они отправляются.
Решение заключается в использовании флэш-памяти для хэш-данных. Создайте небольшой флеш-файл для получения данных, СОЛЬЬ и зашифруйте его с помощью MD5. чем отправить его на сервер. злоумышленник может видеть данные, но он зашифрован.
Нападавший все еще может попытаться скомпилировать вспышку.
для лучшей защиты вашего сервера от вредоносных пользователей вам необходимо проверить данные, которые поступают с каждым запросом. даже если вы обфускаете свой клиентский код, всегда можно отслеживать, куда идут запросы, используя другие средства. даже если вы переключитесь на POST-запросы, их также можно создать вручную.
Взгляните на этот вопрос для обсуждения очень похожей проблемы. Это действительно нелегко сделать, поэтому кто-то не может претендовать на роль вашего JavaScript, так как ваш JavaScript полностью открыт для всего мира.
Вы захотите посмотреть аналогичные методы, которые необходимо предпринять для предотвращения атак типа Cross Site Request Forgery (CSRF). На phpc.org есть несколько хороших примеров, которые вы можете адаптировать для своих запросов Ajax.
На самом деле довольно просто делать почтовые запросы через ajax, просто ссылайтесь на общую функцию ajax jquery. Но это не отвечает на ваш вопрос, так как почти так же легко подделывать почтовые запросы, как и поддельные запросы на получение. Вы не можете надежно скрыть URL-адреса сервера, с которыми связаны ваши скрипты. Поэтому, если это вызывает какие-либо проблемы с безопасностью, вам необходимо переосмыслить архитектуру безопасности вашего веб-сайта или приложения.
Если эти запросы AJAX возвращают конфиденциальные данные, тогда у вас будет определенная форма проверки подлинности, чтобы только настоящие запросы из вашего приложения возвращали данные; и любой, кто попадает на URL-адрес с стороннего веб-сайта, получит код ошибки.
Надеюсь, это поможет.
Метод решения из двух частей – отправить все запросы ajax / json в мои php-файлы в папке адресов переадресации psuedo. И затем проверить домен запросов.
yourdomain.com/somePsuedoFolder/?postRequestData ….
Затем вы переадресовываете в .htaccess, который сканирует «somePsuedoFolder» и перенаправляет на ваше длинное имя файла php-файла. Таким образом, о чем вы спрашиваете, таким образом люди не могут видеть расположение файла на вашем сервере.
Конечно, вам все равно нужно иметь дело с людьми, использующими ваш адрес Psuedo для отправки нежелательных запросов. Однако таким образом они имеют ограниченную информацию о структуре папок на вашем сервере и менее вероятны атаки на другие файлы в этом месте (путем выборочного тестирования случайного имени файла).
То, что я сделал для одного и того же вопроса, транскрибируется на вашем примере;
$randnum = rand(1,100000); $_SESSION['sidrandnum'] = $sid.'-'.$randnum;
в Javascript, используйте эту новую переменную, чтобы заменить ваш сид
в поставщике данных ничего не возвращает, если рандомизированная переменная не является одинаковой
function dataprovider($sidrandnum) { if ($sidrandnum != $_SESSION('sidrandnum')) return; $sidrandtable = explode ('-', $sidrandnum); $sid = $sidrandtable [0]; ...
Таким образом, данные могут быть доступны только на одном и том же сервере: вы можете увидеть источник данных, только то, что уже показано на странице конечного пользователя.