3

I am creating a site using AngularJS that will allow users to create accounts on the site and login seamlessly with no page reloads. To create a site like this I am using the AngularJS routing to load in different partials and $http to access php scripts via xhr. As already mentioned I use php for server side scripting and I am using mysql to store my data.

My problem is without page reloads data thats submitted to the server via $http service will show up in firebug's (or equivalent tool's) network tab. This means that private data such as passwords can be exposed through these tools until the page is closed. Now I would like to find a way to stop users from being able to view this data in any tools. I could encrypt data client side. The problem with that is that the scripts are still exposed. Has anyone else seen this as a problem and found any way of getting around it?

Another thing I need to consider is what is the best way of storing users sessions in angular? Would it be best to use php's sessions and getting the status of it using $http or using cookies? Again both methods have problems related to security. For cookies I will need to encrypt the contents and with passing data back and forth through ajax using session variables it everything can be accessed using firebug. So again I would like to know peoples opinions on this.

Graham
  • 7,431
  • 18
  • 59
  • 84
Lightbulb1
  • 12,882
  • 6
  • 22
  • 23
  • 3
    I'm not sure why this is any more of a security risk than a standard HTTP POST. If someone opens Firebug and clicks "persist" on the Network tab, they will be able to track all the data going back and forth whether it is AJAX or page reloads. – IMSoP Aug 06 '12 at 04:20
  • I just saw this again because of the edit. I find it really funny I even wrote this question now. It's not something I ever think about anymore. Also, who uses Firebug anymore. I don't even remember the last time I did. – Lightbulb1 Aug 19 '17 at 10:04

1 Answers1

2

For the password visibility problem you could do the password hashing client side. The javascript code is visible yes, but this does not pose a problem. A hashing function is one-way so your password can not be retrieved based on the hash result. The javascript can have the salt hardcoded because it is not a secret (https://stackoverflow.com/a/536756).

Optionally you could implement a second hash on the server side before comparing it with the database value. But this only offers protection in cases where you have a vulnerability that leads to password value reads, but the same vulnerability does not allow database updates.

For other data you can consider diffie-hellman key exchange.

To ensure that the javascript being executed client side really is the script which you served, you need https. It also protects your channel, but does not affect your browser or firebug (Is this correct? Should firebug see SSL-protected AJAX?).

I am implementing something similar with angularjs and php, but decided not to use client side hashing or diffie-hellman key exchange. The scenario you are protecting yourself against is quite difficult to pull off. The intruder needs to have access to your browser before and after you log in.

Community
  • 1
  • 1
Tojins
  • 36
  • 1