Редактировать на месте Обновление скрипта безопасности - PullRequest
Новая
       33

Редактировать на месте Обновление скрипта безопасности

2 голосов
/ 28 октября 2008

Я использую Edit in Place плагин jquery, который должен отправить данные в скрипт, который будет выполнять обновление базы данных.

URL-адрес этого сценария обновления легко просматривается в источнике html, а также в Firebug, поэтому мне нужно добавить какую-либо проверку подлинности перед обработкой обновления. Это, конечно, так что пользователь не может просто передать любой старый идентификатор пользователя / поле / значение, которое он хочет, и связываться с записями других людей.

Сначала я также передавал их имя пользователя и пароль, но это не идеально, так как это в GET-запросе, поэтому все это в URL. Сам сайт, по крайней мере, SSL, но, тем не менее, не является лучшей практикой.

Каков наилучший способ проверки подлинности этого типа обновления?

FWIW, скрипт обновления на PHP и плагин Edit in Place: jeditable .

Редактировать: Чтобы уточнить: фактическая полезная нагрузка данных помещается в сценарий, но плагин редактирования на месте не имеет явного метода аутентификации, поэтому я передавал аутентификацию как часть URL-адреса обновить скрипт, который затем брал эти переменные через GET и использовал их для проверки.

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

Ответы [ 4 ]

3 голосов
/ 28 октября 2008

Я думаю, вам лучше всего переключить сценарий на метод POST, так как большинство применений редактирования на месте будут слишком большими, чтобы использовать GET практически. Вы никогда не должны использовать SessionId или пароль в качестве параметра URL, и я не буду использовать имя пользователя ни для чего, кроме просмотра общедоступного профиля. Если ваш AJAX-URL является файлом PHP, я вполне уверен, что должен иметь возможность доступа к сеансу без необходимости передавать его в массиве GET или POST. Как дополнительное примечание, убедитесь, что вы проверяете и дезинфицируете всю информацию перед обновлением базы данных.

2 голосов
/ 18 декабря 2008

Разве сайт по-прежнему уязвим для подделки межсайтовых запросов, если вы просто ищете пользователя в сеансе?

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

Пример: 

$(".edit_area")
  .editable("http://www.example.com/save.php", { 
    submitdata: { 
      userid: 'johnsmith',
      pageid: '123',  // or other value unique to the page
      timestamp: '1324354657',  // time when page loaded
      hash: '0bee89b07a248e27c83fc3d5951213c1' }
    // ..other settings, etc.
});

Хеш может быть, например, MD5 'johnsmith$123$1324354657$' + $secret_salt. Убедитесь, что это соответствует перед сохранением. При желании отклонить, если прошло слишком мало или слишком много времени.

В ветви ditch-pycrypto django-magicforms реализовано это как базовый класс многоразового использования для Django. Он не применим напрямую к запросам AJAX, но документация и модульные тесты должны послужить хорошей основой для других реализаций.

2 голосов
/ 28 октября 2008

Обновление (на основе комментариев и обновлений вопросов): Вы можете передать имя пользователя / пароль как параметр submitdata в Jeditable, например: 

$(".edit_area")
    .editable("http://www.example.com/save.php", { 
         submitdata: { userid:'johnsmith',  passwd:'god' }
         // ..other settings, etc.
      });

Быстрое и грязное решение - грязное, потому что оно предоставляет рядовые данные пользователя в виде открытого текста (через View Source).

Поскольку у вас do есть доступ к идентификатору пользователя / sessionid на сервере, используя его, безусловно, самый разумный вариант.

Хм ... поскольку вы говорите, что Jeditable использует GET, я могу только предположить, что вы используете опцию loadurl (поскольку Jeditable использует $.post() для сохранения изменений и $.post() всегда использует POST).

Итак, вы пытались переключить настройку loadtype в Jeditable на "POST" и отправить имя пользователя / пароль, как раньше? 

$(".edit_area")
    .editable("http://www.example.com/save.php", { 
         loadurl: 'http://www.example.com/load.php',
         loadtype: 'POST'
         // ..other settings, etc.
      });

Это звучит как быстрое и грязное решение - при условии, что у вас нет стандартной обработки пользователя / сеанса на стороне сервера.

0 голосов
/ 28 октября 2008

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

Я полагаю, что в javascript вы можете получить идентификатор сеанса, чтобы его не пришлось передавать открыто.

...