Order
Before writing the article, first to recognize a mistake, in fact, this article and the next article will be written should be completed last month. But, for some reason, not to come and finish. Therefore, the debt owed last month is now made up. Nonsense not much to say, directly on the content.
Problem
Children who have done web development know that after opening the site, it is generally necessary to enter the user name, password. However, this simple operation, when submitted, may expose some problems, of course, these problems will be detected by the security vulnerability testing software. If there is no related processing, there will be some sensitive information in forms, pages, or local cookies, which can be exploited by hackers. The following is a brief talk on how to avoid such problems.
Solution Solutions
Here are a few of the more commonly used solutions, each with their own pros and cons, and different scenarios, let's take a look at it:
Ⅰ, remembering passwords for browsers
First of all, most browsers are based on the form field type= "password" to determine the password domain, so for this situation can take the "Dynamic Set Password Domain" method:
The code is as follows:
<span style= "Font-family:comic Sans MS;" ><input type= "text" name= "password" onfocus= "this.type= ' password '"/> </span>
Note: When this document box gets the focus, it becomes the password field, so the browser will not remember the password, of course, in order to be more perfect, you can also add the autocomplete= "off" attribute.
Ⅱ, in the OnLoad event, the value of the password box is emptied, namely:
The code is as follows:
<span style= "Font-family:comic Sans MS;" ><script language= "JavaScript" > Window.load = function () {document.getElementById (' Password domain ID '). value= ';}; </script> </span>
Note: or use JQuery for the corresponding method.
Ⅲ, the page uses the HTTPS protocol, because HTTPS does not save information on forms.
Ⅳ, using Flash to do a login form, in which case the browser will not record the form information.
Ⅴ, again a perverted good, is can type= "password" change to type= "text", because the type is not password will not appear remember password function, and then set a variable such as: Var val= "" or set a hidden field < Input type= "hidden" Name= "Val", and finally used Onpropertychange to change the password to a line of dots, and assign the value to Val, when the value of the Val to restore back, because the effect and * number, the user is not visible.
Contrast
So, the problem is, if the project has been developed and is in the process of testing, after encountering such a problem, then you can not refactor the code, but the so-called patching, through the patch to solve the vulnerability. So, the available scenarios are I and Ⅱ, of course, if you're not afraid of trouble, then we recommend using Ⅳ and Ⅴ.
The Ⅲ scheme is certainly not possible, as the protocol in the project has been established at the end of the development, and it is much easier if there is an interface in advance. However, this requires a good design to be achieved.
When you choose the Ⅰ scheme, you will find that, in fact, there is a problem, because I am doing, it has been tested, the Ⅰ program in IE 10 and above will not have a problem, but in the version of IE 10 below the clear text, this.type= ' password ' It doesn't work at all. If you need compatibility with multiple versions of IE in your project, this option will be pass.
and as for the Ⅱ scheme, through the test you will find, in fact, its role is icing on the cake, with the Ⅰ program together or can be, but the Ⅰ scheme has been passed, only use the Ⅱ scheme is only a palliative, so, the same pass.
if the project is under development, then the Ⅲ and Ⅳ options can be tried.
and I choose the solution, is to use the Ⅴ, this way is implemented using JS, the text box after the focus, the text box to replace the password box, this way in various versions of IE can be done. And, if your project is under development stage, then, I recommend you use this way, in the future maintenance, will not have to worry about.
As for the code, it is not posted here, it is not difficult, but also on the Internet. If you need to send me a private messages, I will send you the code.
Concluding remarks
for the entire WEB security system, this vulnerability is not fatal, here is to mention also just let everyone have a knowledge, fill loopholes is not our goal, important is how to avoid such loopholes in the development, so-called "prevention", this is the truth.
Web security Combat (vi) Prevent browsers from remembering usernames and passwords
