2010-09-23 3 views
0

У меня есть текстовое поле Password, которое будет иметь пустое значение. когда пользователь нажимает на него и вводит пароль, начертание текстового поля, пароль будет обновляться в базе данных.Как отправить пароль с помощью функции ajax() jquery

Я сделал это с помощью 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 КОД

<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> 
+0

Вы используете протокол HTTPS? – JTP

+0

Нет, я не использую протокол HTTPS – Rajasekar

+2

В принципе, отправка любой транзакции проверки подлинности по незашифрованному каналу является ядром безопасности сама по себе, в первую очередь из пакетов снижений пакетов вверх. Что касается самой формы, пока save.php подтверждает, что введен пароль, существует минимальная мера безопасности. – JTP

ответ

5

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

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

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

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

0

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

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

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

JB.

2

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

1

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

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

+0

Если захвачен 'SHA-1 (пароль)', система уязвима для повторной атаки без необходимости знать фактический пароль. – GeriBoss

0

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

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

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

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

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

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

1

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

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

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

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

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

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