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

6

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

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

Просто использовать пример GET проще, я бы в любом случае использовал POST. Peteris
возможный дубликатPrevent Direct Access To File Called By ajax Function IMSoP
К сожалению, криптография - это не волшебная палочка, которую можно взмахнуть чем угодно, чтобы она делала только то, что вы хотите. Некоторые люди тратят миллиарды долларов, чтобы понять это (вся индустрия DRM очень, очень старается выровнять этот конкретный круг). Не те люди. Enno
уточни свой вопрос пожалуйста .... Sameh Serag

Ваш Ответ

8   ответов
0

авторизация при входе, проверьте реферал.

Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Peteris
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Peteris
Error: User Rate Limit Exceededstackoverflow.com/questions/7127686/…Error: User Rate Limit Exceeded
1

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

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

6

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

Error: User Rate Limit Exceeded Peteris
0

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

Ajax Call

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
}
Error: User Rate Limit Exceeded Peteris
1

Запретить прямой доступ к файлу, вызываемому функцией ajax кажется, для решения вопроса.

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

use session management (log in to create a session); send a unique key to the client which needs to be returned before it expires (can't be re-used, and can't be stored for use later on); and/or set headers as in the linked answer.

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

1

используйте токен в AJAX-запросе, который вы предварительно сохранили в другом месте (или можете восстановить, например, путем шифрования параметров с использованием идентификатора sessin в качестве ключа).Крисс Шифлетт имеет некоторые заметки по этому поводу, и естьПроект OWASP для обнаружения CSRF с PHP

Error: User Rate Limit Exceeded Peteris
Error: User Rate Limit Exceeded Peteris
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
3


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

2

t really need to restrict access to the server (although that would be great), I'm looking for a cryptographic trick that would allow the server to know when things are coming from the app and not forged by the user using a sniffed token.

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

Error: User Rate Limit Exceededstackoverflow.com/questions/1756591/…Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded

Похожие вопросы