3

I have a web application that is designed to work on a internal network.

When the user logs in (using standard POST, asp.net, HTTPS) I need to store the user name and password and later use it in javascript on one particular page. (in order to access and ActiveX control)

The obvious problem with this is that when you go "view source" on that page you can see the username and password. I do not think there is a way to avoid this.

My question is: Once the user logs off...does IE7 or IE8 store this entire page information? If so, how would I view it? (to verify if that username and password is easily findable)

If the entire page content is not cached/stored in history....then using the username/pw in the javascript is not that big of a security breech as a user would already have to be logged in in order to obtain the data. am I right?

Thanks in advance for your thoughts/comments!

Andrew

elaboration: I have to create a ActiveX object,...then connect to it in javascript...I store the passwords in a Session...but I need to put them in javascript in order to connect to the control: i.e.

myactivexcontrol.credentials.username = "username";
myactivexcontrol.credentials.password = "password";

myactivexcontrol.connect();

the username and password coincide with the login to the web application...

Andrew
  • 3,650
  • 9
  • 31
  • 32
  • 1
    its toooo badd i guess... Why dont you use sessions? – Sujit Agarwal Jun 01 '11 at 18:05
  • Such a practice would make the consequences of an XSS or CSRF attack very, very serious. Forget about what's in the browser after the user logs out of your site - what's scary is what's in the browser while they're still using it! – Pointy Jun 01 '11 at 18:09
  • Pointy: i don't use GET variables for any sort of authentication...i don't see how cross-site scripting is a risk. Also, this is an internal web application.... – Andrew Jun 01 '11 at 18:39

4 Answers4

1

You could aways render your pages as "uncachable" via the headers and verify that this works on your target browsers. See: Will web browsers cache content over https

You could test this by deliberately clearing out the cache, verifying that the cache directory is empty, and then running through your use case to see what traces are left behind.

Community
  • 1
  • 1
tadman
  • 208,517
  • 23
  • 234
  • 262
1

This is a very bad practice with only limited risk because you are using it 'internally'. However, if your internal network is on a windows domain you could use windows authentication to validate your users credentials.

Another option would be to use encrypted cookies.

Either of these options is preferable to what you are doing.

Cos Callis
  • 5,051
  • 3
  • 30
  • 57
  • Given that `the username and password coincide with the login to the system...` I would narrow options to using windows authentication. – Cos Callis Jun 01 '11 at 18:25
  • Sorry by "system" i meant the web application. Even if I did mean the system,..how would I avoid actually setting the credential parameters with plain text in javascript? – Andrew Jun 01 '11 at 18:31
  • @Andrew, I haven't the time right now to find you a sample for this, but I believe it possible for the ActiveX object to be aware of the local user's credentials (including roles) such that the browser should not have to pass the credentials at all. This would be best I believe. I will look back in a few hours and see if you need me to find or create that sample for you. – Cos Callis Jun 01 '11 at 19:19
  • @Andrew...just out of curiosity, what functionality compels you to be using an ActiveX control? Can this be migrated to standard ASP.NET Web User Control? Silverlight Maybe... jquery/Ajax... ??? I am not a big fan of 'fixing what isn't broken' but I have to admit, I am not sure of the case for preserving ActiveX... – Cos Callis Jun 02 '11 at 03:40
0

If I'm you I would avoid storing passwords in javascript, then you don't have Password functionality if everyone knows it.

What would I do

I would create one page which will return data I need, And I would call that page from ActiveX control. Problem solved.

Senad Meškin
  • 13,597
  • 4
  • 37
  • 55
0

First, the password should be encrypted, if not, hashed and salted (possibly multiple times).

Can you not use SESSION to keep track of the user being logged in rather than storing a password? If for some reason you must store the password, do so in the SESSION or a database.

Fase
  • 1