Как заблокировать внешние HTTP-запросы? (обеспечение вызовов AJAX)

Question

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

Скажем, я выдаю запрос GET для ввода нового пользователя в мою базу данных по адресу site.com/adduser/<userid>. Кто-то может перенаселить мою базу данных, выпустив поддельные запросы.

Answer 1

В этом случае невозможно избежать кованых запросов, поскольку клиентский браузер уже имеет все необходимое для выполнения запроса; это только вопрос некоторой отладки для злонамеренного пользователя, чтобы выяснить, как делать произвольные запросы на ваш сервер и, возможно, даже использовать свой собственный код, чтобы упростить его. Вам не нужны «криптографические трюки», вам нужно только обфускацию, и это только сделает ковку немного неудобной, но все же не невозможной.

Answer 2

Он работает как любая другая веб-страница: авторизация входа в систему, проверьте реферер.

Answer 3

Prevent Direct Access To File Called By ajax Function, похоже, вопрос.

Вы можете (среди других решений, я уверен) ...

• управление использование сессии (войти создать сеанс);
• отправьте уникальный ключ клиенту, который должен быть возвращен до истечения срока его действия (не может быть повторно использован и не может быть сохранен для использования позднее);
• и/или установить заголовки как в связанном ответе.

Но все может быть подделано, если люди очень стараются. Единственная полностью безопасная система - это та, которую никто не может получить вообще.

Answer 4

Это ту же проблему, что и CSRF - и решение одинаковое: используйте токен в запросе AJAX, который вы предварительно сохранили в eslewhere (или можете регенерировать, например, путем шифрования параметров с помощью идентификатора sessin в качестве ключа). Chriss Shiflett имеет некоторые разумные примечания по этому вопросу, и есть OWASP project для обнаружения CSRF с PHP

Answer 5

Решение добавляет жирную строку в запросы ajax. Также вы должны посмотреть на базовую аутентификацию, это не будет единственным защитником. Вы можете поймать доходы с этим кодом со страницы АЯКС

Ajax Позвоните

function callit() 
{ 
if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");} 
xmlhttp.onreadystatechange=function(){if(xmlhttp.readyState==4&&xmlhttp.status==200){document.getElementById('alp').innerHTML=xmlhttp.responseText;}} 
xmlhttp.open("get", "call.asp", true); 
**xmlhttp.setRequestHeader("X-Requested-With","XMLHttpRequest");** 
xmlhttp.send(); 
} 

PHP/ASP запрошенной страницы Ответ

ASP

If Request.ServerVariables("HTTP_X-Requested-With") = "XMLHttpRequest" Then 
'Do stuff 
Else 
'Kill it 
End If 

PHP

if(isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest')) 
{ 
//Do stuff 
} else { 
//Kill it 
} 

Answer 6

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

Вы не можете этого сделать. Это почти одна из основных проблем с клиент-серверными приложениями. Вот почему это не работает: скажите, что у вас есть способ для вашего клиентского приложения аутентифицироваться на сервере - будь то секретный пароль или какой-либо другой метод. Информация, необходимая для приложения, обязательно доступна для приложения (пароль скрыт где-то там или где угодно).Но поскольку он работает на компьютере пользователя, это означает, что они также имеют доступ к этой информации: все, что им нужно, - это посмотреть на источник, или на двоичный, или на сетевой трафик между вашим приложением и сервером, и в конечном итоге они выяснят механизм аутентификации вашего приложения и его тиражирование. Возможно, они даже скопируют его. Может быть, они напишут умный взломать, чтобы ваше приложение сильно поднялось (вы всегда можете просто отправить поддельный пользовательский ввод в приложение). Но как бы то ни было, у них есть вся необходимая информация, и нет способа остановить их от ее использования, что также не помешает вашему приложению иметь ее.

Answer 7

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

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

Answer 8

Этого можно достичь.
Всякий раз, когда вы создаете страницу, которая должна сделать такой запрос. Создайте случайный токен и сохраните его в сеансе (для аутентифицированного пользователя) или в базе данных (если этот запрос разрешен публично).
и вместо вызова site.com/adduser/<userid> вызов site.com/adduser/<userid>/<token>
всякий раз, когда вы получаете такой запрос, если маркер является действительным или нет (от сеанса или базы данных)
В случае лексемы является правильным, процесс запроса и удалить используемый маркер из сессии/дб
Если маркер неверен, отклоните запрос.