2015-11-06 3 views
5

Итак, сегодня у меня был очень хороший опыт в моих построенных системах. Какой-то парень «взломал» все и сказал, что это проблема аякса. Это то, что он сказал мне:Можно ли взломать AJAX?

вы полагаетесь на AJAX
, когда у меня есть доступ в браузер пользователя у меня есть доступ ко всем функциям AJAX вы написали для него , так что я могу сделать что-нибудь написано в вашем JavaScript притворяясь, что пользователь

, и это абсолютно рискованно - как можно получить доступ к пользовательским скриптам через ajax? Также я использую узел на сервере, но не может понять, где проблема .. пример Аякса:

var transfer_data = { 
       id: jQuery(this).data('spin-id') 
      }; 

jQuery.ajax({ 
      url: init_s.forms.provably.callback, 
      type: 'POST', 
      dataType: 'JSON', 
      data: transfer_data, 
      success: function (data) { 
       console.log(data); 
       if (data.type == 'failed') { 
        jQuery('#check_modal').modal('toggle'); 
       } else { 
        // add data 
       } 
      }, error: function (e) { 
       console.log(e.message); 
      } 
     }); 

и пример выполнения сценария узла:

socket.on('new_spin_entry', function (data) { ... }); 
socket.emit('new_spin_entry', { 
          entry_id: data.user_spin_data.id 
         }); 

так что щеколда это? как это возможно?

P.S. Я забыл упомянуть, что он вставил оповещение в мой скрипт, который был загружен на страницу. Не в сценарии сервера, но сценарии, которые были загружены на пользователя

PPS: это то, что я в состоянии видеть в консоли системы ATM снизился: enter image description here

+0

И что ваша архитектура для проверки подлинности запроса к серверу узла? – codebased

+0

Если он может добавить к пользователю предупреждение, то это означает, что есть уязвимость XSS, которая является плохой. – epascarello

+0

он вставил предупреждение в файл javascript, который был загружен с помощью DOM. –

ответ

3

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

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

+0

Если хакер контролирует браузер пользователя, то у него есть cookie сеанса пользователя. – Barmar

+0

Однако переменные состояния сеанса могут сохраняться на стороне сервера, и в этом случае они не могут быть изменены через клиента, например: http://stackoverflow.com/questions/13451543/how-safe-is-it-to-use-session-variables -asp-net-c-sharp – numX

+0

о фильтрации входных данных - они фильтруются по коду при получении, потому что я использую также laravel. О переменных сеанса - вы говорите о «Подделке запросов на кросс-сайт»? –

6

Если у кого-то есть полный доступ к браузеру, они могут запускать любой код, который им нравится в нем, включая изменение или добавление JavaScript на ваши страницы. Это абсолютно не имеет никакого отношения к сайту, использующему Ajax: любая точка, в которой клиент взаимодействует с сервером, может быть уязвимой.

Если они могут изменять только страницу браузера, они сами используют, то это нормальное поведение и не о чем беспокоиться.

Если они могут вводить данные через ссылку или форму с другого сайта, то вы уязвимы для отраженных атак XSS.

Если они могут вводить данные, которые где-то хранятся на вашем сервере, что приводит к запуску скрипта для других пользователей, тогда вы уязвимы для сохраненных атак XSS.

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

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

Смотрите также:

Смежные вопросы