How to Post the password using ajax() function of jquery

I am having a Password textbox which will have empty value. when the user clicks on it and enter password, onblur of the textbox, the password will be updated the database.

I have done that using ajax but i want to know whether any security hole in this script. am afraid the data we are sending from ajax() function can be changed using some hacking utilities like FIREBUG. Plz advice me some points. Any points will be appreciated

My code below:

//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>

Making an Ajax request is not that much different from a standard browser request. Anything you can manipulate with development tools like Firebug would apply regardless of whether you use Ajax or not.

In this case, the security of your application will depend largely on two things, neither of which are related to Ajax.

1. Your backend. If your PHP backend is secure, it doesn't matter if the request is Ajax or a normal browser request. This means that you need to check for things like input sanitation to protect yourself from injections.

2. HTTPS. Regardless of how secure your backend is, it might not mean anything unless you use HTTPS. If you don't, the passwords will be sent from the client to the server in plain text, making it relatively easy for anyone to "sniff" it. Again, this is the same if you use Ajax or not.

My advice is: Do not believe any data stored in javascript, cookies or any other local storage where user have access. All security issues have to be maintained on server side and any changing (I do not mean session id for example, because it is hard to know valid sid to hack it) of local data must not grant more privileges or access to protected data. In your case - What will happen when user will change data in ajax call? What is in newtval variable?

There is no difference, if you use AJAX or simple old POST to the web server. If the password is not encrypted, it can be read by 3rd parties.

What you can do is calculate a SHA-1 checksum at the client (for instance, http://plugins.jquery.com/files/jquery.sha1.js.txt) and then send the hash value to the server instead of plaintext password. It gets a little better, since observers don't get the password itself, just a hash.

Yes, this is a security hole, as someone with a packet sniffer can grab the user's password.

The best solution is to use HTTPS, which may be as simple as opening a request ticket, or may mean a little leg work and purchasing certificates.

Once you get the certificate, you'll need to serve this page as HTTPS (and save.php too). You'll have to serve the form page, even though it has no secrets: in order to may an HTTPS Ajax request, you need to be on an HTTPS page.

There are less secure solutions, such as somehow obscuring the password before you transfer it. This isn't that cool, as people expect that we are protecting their information in a secure way.

For general security, there are lots of other things to think about. I think the rails security guide provides a great overview of these. Some of it is rails specific, but quite a bit applies to PHP as well. Maybe there is an equivalent PHP doc.

The web is a very funny place. I believe that the W3C said that there is no point in trying to encrypt the password on the client. I assume that they think it would give people a false sense of security?

1. HTTPS is going to prevent eves droppers. As mentioned by JTPRESTA.
2. A normal form submit is in plain text so your AJAX implementation is also going to send the data in plain text so there really is no difference with or without ajax.
3. If you really wanted to, you could javascript MD5 hash the password in the browser, but that is sort of giving you a false sense of security especially if you still send the password via HTTP.
4. The last issue I can think of is protecting your javascript from a cross site scripting attack. Where someone can inject javascript into your system which steals the password but that doesn't look likely from your code.

Overall I think you code is fine. As long as you are doing secure things on the server like safely escaping string for SQL injection. There are some really good threads on the most common issues on server security that might also be of a good read on stackoverflow.

JB.

From a usability standpoint, these seems confusing to me. It could also play havoc with atypical user interfaces such as touch screens or browsers for the visually impaired.

That aside...

1) Use HTTPS if the password is at all important.

2) Make sure your database query is parameterized to avoid SQL injection attacks.

3) Regardless of the submission method, it's always a good idea to make a user re-enter their name and password before being allowed to change their password. And/or the server should always validate the user's authentication and authorization upon every request.

As long as the server conforms to best practices, how the data gets to the server should not be an issue.