Вопрос по security, jquery, ajax – Риск безопасности при использовании jQuery Ajax

9

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

Я использую jQuery для многих вещей, но в основном я использую его для обработки диалоговых окон jQuery. Часто возникает необходимость получить значение из поля в форме, объединить эту информацию с помощью команды .serialize () и передать ее вызову jQuery ajax, чтобы перейти к файлам PHP для взаимодействия с базой данных.

Вот мой вопрос (наконец),

Isn't it riduclasly easy to 'guess' what the url could look like for the PHP processing?
Вы можете открыть исходный код в современном браузере и щелкнуть ссылку, чтобы посмотреть полный файл JavaScript, содержащий вызов ajax.

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

Я использую PDP для доступа к базам данных с подготовленными операторами для атак с использованием SQL-инъекций, но если кто-то потратит время на поиск, не сможет ли он просто сформировать действительный URL-адрес, отправить его в базу данных и вставить то, что он хочет?

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

Если это так же просто, как превратить запрос ajax из GET в POST и изменить мои файлы PHP?

Edit: The person is logged in and properly authenticated.

Просто интересно, что там делают другие люди.

Спасибо!

Связанные с:stackoverflow.com/questions/198462/… Rob W
Мне просто любопытно, почему php? Большую часть времени, когда я хочу позвонить в базу данных (я использую MVC3), я получаю запрос перейти к контроллеру и делать с ним то, что я хочу. Лично я могу думать о двух возможностях. Если вам нужен такой вызов, который передает информацию в базу данных через ajax, лучше всего было бы добавить одноразовый ключ к любому вызову, который вы хотите сделать. Это могло бы обеспечить это в некоторой степени. Все, что вам нужно сделать, это не иметь возможности просмотра ключа, пока не будет выполнен вызов, а затем bam, он уже используется. Хм, мне нужно больше подумать по этому вопросу. John Sykor
Это не так много, как «jQuery ajax». проблема, или проблема jQuery, или проблема ajax, в общем, пользователи могут подделывать всю клиентскую часть. . Проблема & Quot; @ Джон Сикора - Почему не PHP? Доступ к базе данных все еще происходит на стороне сервера, что эквивалентно тому, что вы делаете в MVC3. nnnnnn
Я не понимаю, почему люди думают, что ajax должен маскировать взаимодействие клиент-сервер в любой форме, это всего лишь метод связи с сервером, интерфейс - ничто иное. Использование ajax на самом деле ничего не меняет, если ваш бэкэнд безопасен, ваш веб-сайт безопасен, независимо от способа связи с бэкэндом. Вы беспокоитесь об изменении цены в вашей корзине? Я предлагаю вам вообще не обрабатывать цены, предоставленные клиентом, просто использовать идентификаторы и получить цену из базы данных ... cyber-guard
Ну, в MVC, если вы просто сделали пост формы, я не знаю, как вы собираетесь помещать вредоносные объекты в базу данных, когда она проходит через контроллер через модель, они не знают, как она обрабатывается, они не могут изменять модель, кроме того, что находится в ячейках, кроме того, она все равно должна запускаться валидатором. Мне просто интересно, где дыра существует? Кроме какого-нибудь идиота, просто добавляющего миллиард строк в вашу базу данных? John Sykor

Ваш Ответ

6   ответов
8

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

В критических ситуациях вы никогда не можете полностью полагаться на то, что вы получаете от своих клиентов.

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

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

2

поступающие со стороны клиента, не только связанные с jQuery.

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

Тип запроса (GET или POST) фактически не имеет значения, его можно легко смоделировать. После того, как пользователь попытается добавить товар на сумму 50 долларов за 25 долларов, вам следует проверить свою БД и подтвердить фактическую цену товара.

Согласен. Это был основной пример, пытающийся проиллюстрировать точку зрения. Kris.Mitchell
Я знаю, и это было основное предложение для базового примера :)
Я согласен, если бы я когда-либо передавал информацию о ценах, я бы уже чувствовал, что она не обеспечена. Если ценообразование или общая сумма счета когда-либо были пройдены, вы хотели бы зашифровать его, чтобы в него не просто добавлялось случайное число и выполнялась проверка dbl товаров по цене. В противном случае наиболее эффективная вещь - всегда сохранять значение на стороне сервера и никогда не получать его от клиента. возьмите только предметы, которые были приобретены, и взимайте за них плату. Кроме того, вы явно не хотите, чтобы продукты в списке были изменены после окончательного подтверждения. только если они должны были вернуться на шаг и добавить или удалить товар
12

любой, кто немного разбирается в технологиях, может определить конечные точки публичного сервера для любого веб-приложения. Им даже не нужно смотреть на код. Они могут просто использовать свой webkit / firebug для отслеживания запроса или программу типа Charles, которая отслеживает сетевую активность.

Вот почему вам нужноauthentication а такжеauthorization обработка в вашем коде на стороне сервера.

Authentication обычно обрабатывается именем пользователя и паролем; это акт проверки пользователя, кто он есть.

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

Какие два механизма существуют, даже если пользователь знает URL-адрес, ему все равно нужно «войти» в систему. и иметь разрешение делать то, что они хотят.

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

1

вам нужна защита на стороне сервера, чтобы убедиться, что все нные были отправлены на ваш сервер. Например, вы проверяете нные в javascript / jquery:

if($(this).val() != ""){
   // post to my server page (mypage.cfm/php/asp)
}

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

<cfif val is "">
  //dont post to my server ...
</cfif>

иног это двойная работа, но мы все иног сталкиваемся с этим ....

1

цена передается от клиента отдельно, потому что любой может отправить данные с ценой = 0 или 0,01 для любого количества товаров / услуг или чего угодно.

Более общий: никогда не доверяйте данным клиента.

& quot; если кто-то потратил время на поиск, он не может просто сформировать действительный URL-адрес, отправить его в базу данных и вставить то, что он хочет & quot ;. Да, они могли. И они будут.
1

вредоносные данные, SQL-инъекция, CSRF.

Сокращение / уменьшение вашего javascript может помочь. Но ваш пользователь может легко получить свои собственные данные запроса, независимо от того, что вы делаете. И нет никакого определенного способа препятствовать тому, чтобы пользователи проходили грязный код.

Безопасность верна только тогда, когда пользователи не могут взломать вас, несмотря на знание всего вашего исходного кода и конфигураций.

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

Use HTTPS, and POST requests. При запросах POST через HTTPS данные запроса шифруются. URL открыт, но обычно все в порядке. Это предотвращает атаку «человек в середине» и значительно уменьшает проблемы с конфиденциальностью (например, утечка пароля / кредита). Если вы используете запрос GET, все ваши данные передаются в виде строки запроса в URL. Это означает хороший шанс изменить ваши данные для третьих лиц.

Server side verification Всегда проверяйте данные на стороне сервера. Пользователь может быть злонамеренным, и на стороне клиента могут быть ошибки. Например, рассчитайте общую стоимость на стороне сервера, а не на стороне клиента. В противном случае пользователь может поставить 0 там.

Access right control AKA Authorisation Установите ограничения на разрешенные действия и ограничьте их эффективную область действия. Например, не позволяйте пользователям размещать заказы от имени других. И не позволяйте им удалять историю своих действий.

Generate tokens to prevent CSRF некоторые библиотеки могут защитить от CSRF. Или вы можете реализовать свой собственный. Основная идея заключается в том, чтобы сгенерировать случайный токен и попросить клиента передать его обратно. Это препятствует тому, чтобы другие веб-сайты инициировали запросы к вашему серверу (с вашими учетными данными клиентов)

Proper back up and loggin Регулярное резервное копирование вашей базы данных поможет восстановиться после сбоев (да, они произойдут) и отследить, что пользователи сделали с помощью модулей регистрации.

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