Как опубликовать пароль с помощью функции jjery ajax ()

Question

У меня есть текстовое поле Пароль, которое будет иметь пустое значение.Когда пользователь нажимает на него и вводит пароль, onblur из текстового поля, пароль будет обновляться в базе данных.

Я сделал это с помощью ajax, но я хочу знать, есть ли дыра в безопасности в этом скрипте.Боюсь, что данные, которые мы отправляем из функции ajax (), могут быть изменены с помощью некоторых хакерских утилит, таких как FIREBUG.Пожалуйста, посоветуйте мне несколько моментов.Любые пункты будут оценены

Мой код ниже:

//Code inside blursave() javascript function
    newName = $j('[name=abs]').val(); 
    var thedata = 'nam=' + newtval;
                   $j.ajax(
                            {
                                type: "POST",
                                url: "save.php",
                                data: thedata,
                                cache: false,
                                success: function(html)
                                {
                                    {
                                        $j("#update").empty();
                                        $j("#update").fadeIn("slow");
                                        $j("#flash").hide();
                                        //$j("#update").hide(2000);
                                        $j("[name=abs]").fadeOut(2000);
                                        $j("#update"). append(html);
                                        }
                                    }
                                 });

HTML CODE

<div id="flash"></div>
<div id="update"></div>
<div >
    <a href="#" id="edit">hello</a>
</div>
<div id="editbox" style="display: none">
    <input type="password" name="abs" id="abs" onblur="blurSave()">
</div>

Answer 1

Выполнение Ajax-запроса не сильно отличается от стандартного запроса браузера. Все, что вы можете манипулировать средствами разработки, такими как Firebug, будет применяться независимо от того, используете вы Ajax или нет.

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

1. Ваш бэкэнд. Если ваш PHP-бэкэнд безопасен, не имеет значения, является ли запрос Ajax или обычным запросом браузера. Это означает, что вам нужно проверить такие вещи, как входная санитария, чтобы защитить себя от уколов.

2. HTTPS. Независимо от того, насколько безопасен ваш бэкэнд, он может ничего не значить, если вы не используете HTTPS. Если вы этого не сделаете, пароли будут отправлены с клиента на сервер в виде обычного текста, что позволит относительно легко его "понюхать". Опять же, это то же самое, если вы используете Ajax или нет.

Answer 2

Мой совет: не believe никаких данных, хранящихся в javascript, куки или любом другом локальном хранилище, к которому у пользователя есть доступ. Все проблемы безопасности должны поддерживаться на стороне сервера, и любые изменения (я не имею в виду session id, например, потому что трудно узнать действительный sid взломать его) локальных данных не должны предоставлять больше привилегий или доступа к защищенным данные. В вашем случае - что произойдет, когда пользователь изменит данные в вызове ajax? Что находится в newtval переменной?

Answer 3

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

Лучшее решение - использовать HTTPS, который может быть таким же простым, как открытие заявки, или может потребовать небольшого труда и получения сертификатов на покупку.

Как только вы получите сертификат, вам нужно будет использовать эту страницу как HTTPS (и тоже save.php).Вам придется обслуживать страницу формы, даже если она не имеет секретов: для того, чтобы запросить HTTPS Ajax, вам нужно быть на странице HTTPS.

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

Для общей безопасности есть много других вещей, о которых стоит подумать.Я думаю, что руководство по безопасности rails дает хороший обзор этих проблем.Некоторые из них специфичны для рельсов, но совсем немного относятся и к PHP.Может быть, есть эквивалентный документ PHP.

Answer 4

Нет разницы, если вы используете AJAX или простой старый POST для веб-сервера. Если пароль не зашифрован, его могут прочитать третьи лица.

Что вы можете сделать, это вычислить контрольную сумму SHA-1 на клиенте (например, http://plugins.jquery.com/files/jquery.sha1.js.txt), а затем отправить значение хеш-функции на сервер вместо простого текста. Это становится немного лучше, поскольку наблюдатели не Сам пароль не получается, просто хеш.

Answer 5

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

Это в стороне ...

1) Используйте HTTPS, если пароль вообще важен.

2) Убедитесь, что ваш запрос к базе данных параметризован, чтобы избежать атак с использованием SQL-инъекций.

3) Независимо от способа отправки, всегда полезно, чтобы пользователь повторно вводил свое имя и парольдо того, как им позволят сменить пароль.И / или сервер должен всегда проверять подлинность и авторизацию пользователя при каждом запросе.

Пока сервер соответствует передовым методам, вопрос о том, как данные попадают на сервер, не должен быть проблемой.

Answer 6

Интернет очень забавное место. Я считаю, что W3C сказал, что нет смысла пытаться зашифровать пароль на клиенте. Я предполагаю, что они думают, что это даст людям ложное чувство безопасности?

1. HTTPS предотвратит появление пипеток накануне. Как упомянуто JTPRESTA.
2. Обычная отправка формы в виде простого текста, поэтому ваша реализация AJAX также отправит данные в виде простого текста, поэтому на самом деле нет разницы с или без ajax.
3. Если вы действительно хотите, вы можете javascript MD5 хэшировать пароль в браузере, но это своего рода дает вам ложное чувство безопасности, особенно если вы все еще отправляете пароль через HTTP.
4. Последняя проблема, о которой я могу подумать, это защита вашего javascript от атаки межсайтовых скриптов. Где кто-то может внедрить javascript в вашу систему, который украл пароль, но это вряд ли из вашего кода.

В целом, я думаю, что ваш код в порядке. Пока вы делаете безопасные вещи на сервере, такие как безопасное экранирование строки для SQL-инъекции. Есть некоторые действительно хорошие темы по наиболее распространенным проблемам безопасности сервера, которые также могут быть хорошо прочитаны в stackoverflow.

JB.