I have a contest entry page on my company's website. In order to enter the contest, you create a login, which is just an email and a 4-digit pin. Here's the PIN field:
<input type="password" name="contest_pin" id="contest_pin" maxlength="4" />
When users submit the form, the account is created in our database, and then they get an email (which I'm copied on) that contains the email address and PIN they created.
Here's the issue: in every browser I've tested (Safari/Chrome/Firefox on Mac, Chrome/Firefox on Linux, IE7/8/9 on Windows) I CANNOT enter more than 4 digits into that PIN field. And yet, several of the emails I've received show that the user has created a pin with more than 4 characters.
How is this possible? Are there browsers that don't support maxlength? I haven't tested in Opera, or on any of the mobile browsers. It's not a huge deal if their pin is longer than 4 digits; the database will accept more. I'm just wondering how they managed to get around maxlength.
EDITED TO ADD
There are too many answers basically saying the same thing for me to respond individually to all of them. I KNOW that I should always do server-side validation for anything important, and we do have PHP code in place sanitizing our data, and if it was hugely important I would also have PHP code enforcing the 4-digit limit. It's not that important to us that they be only 4 characters, so I haven't enforced it. I'm just wondering why the maxlength property is not doing what it's designed to do, which is prevent users from entering more than a certain number of characters. For those of you that suggested malicious scripts or Firebug, I can be 100% certain this is not the case. Only registered users of our site (which is limited to a very specific corporate membership list) can even get to the contest entry page, and I can guarantee that none of the approximately 100 people on that list are going to be deliberately trying to circumvent an input type property.
They very likely are bots that read field names and create GET and POST requests based on those rather than using the HTML form like a normal human user would.
This is why client-side validation of form is never enough to ensure data is correct. Client-side validation is nice as it's responsive for end users, but it's not able to prevent bad data from arriving at your server's doorstep.
As an example, let's say I have an input field in a form whose action is GET. My input field's maxlength is 4. When I press submit, I see the URL ending with ?field=1234. There's nothing stopping me from updating that URL to ?field=123456789 and pressing enter. Similar things can be done with POST actions, but a tool is needed to do it.
I believe that every browser supports it, here's a few links for reference :
Maxlength | SitePointReference
Maxlength | W3 Schools
Obviously there are way around this - you should ensure you ALWAYS have adequate server-side validation, as client-side usually isn't enough on it's own.
All browsers support maxlength. However, this attribute can easily be removed/changed using DOM methods or, for example, with Firefox's Web Developer Toolbar.
several of the emails I've received show that the user has created a pin with more than 4 characters.
How is this possible? Are there browsers that don't support maxlength?
I would investigate the USER_AGENT and REFERER headers related to those user activities. Perhaps a malicious user submitted forms programmatically circumventing the browser restrictions, just to check your perimeter defense. If so you should see some patterns there.
Anyway these educated guesses aside, maxlength should not be treated as a means of securing the input. Anything client-side is not under your control, it exists merely to make user interface more intuitive, interactive. You should always check everything on the server. In that case, the PIN being composed of 4 digits, otherwise reject the input. The golden rule is to treat all user input as hostile and thoroughly validate it on the server.
In general, trying to enforce rules for user input done client-side is a bad idea. I had an experience where we had contracted out some work to some programmers and their idea of sanitizing user input was making it so that users couldn't input more than 10 characters in any given field. A quick firebug change and, oh look, I can drop the server's database with some minimal SQL injection.
If I were you I'd check maximum lengths with whatever script adds user information to your database and return form validation errors if the user input exceeds the maximum specified length.
This is the type of thing that you should still validate server side, even though the clients will almost always support it. It is very easy to get around a maxlength -- Firefox Developer toolbar includes an option to "Remove Maximum Lengths", or a request can very easily be hand-edited. I almost think that in the past you could get around a maxlength in one of the browsers simply by using cut and paste(eg, the browser wouldn't let you type more characters, but if you pasted a value that was 5+ characters it would enter them all), though I can't remember specifically which browser I saw that on...
Related
I am doing some volunteer work for a charity that is using a couple online systems that store their donors and related data. I would like to find a way to store a URL as a custom field in such a way that they can put corresponding links between donors in one of the systems in order to quickly find the same donor in another system. The only built-in method in the products being used is to store a single value in a field labeled "website" which is originally intended to store a value for any website associated with the donor. I would like to avoid using this field if possible and instead create a custom field.
However, the rub is the custom fields only have a handful of options (clear text, date, currency, etc). There is no option to store a URL or something like rich text). I've thought of a couple less optimal ways to make the values stored in those fields clickable (a browser plugin or a proxy) however both of those have obvious drawbacks that I would like to avoid.
What I am wondering and hoping someone has a possible answer for, is if there are an ways of storing a value in a clear text field that might disrupt or escape the underlying html encoding such that the displayed link is clickable. I already control the values being put into these fields (users cannot enter their own values, they are essentially read-only), so security isn't much of a concern.
I have very limited access or influence to have any system level changes, however I would like to make this possible as it would help them a great deal (their users are all volunteers with limited time and education). I've tried a few tricks but havn't found anything that doesn't get converted to unicode or escaped (it could be that it's completely controlled for at output, i simply don't know).
My current attempts have been limited to using the built in forms submission, I may explore their import and/or API methods on the theory that might allow better low-level access to storing the actual values in the system, however I'm still not certain what to try other than adding .
I have also tried an inline script to add the corresponding tab, however that seems to break the form submission method (perhaps it'll work via csv import or via the API)
Does anyone have suggestions for other things I could try before I go any further? I'm a bit of a novice and feel like there may be something else obvious I haven't tried.
After sitting for hours on end with what, in my mind anyway is the simplest of requirements, I am giving up.
The need is that a shared computer browser will be used by various personnel to login, do what they need to, and log out again.
It is hence imperative that the user's details NEVER be populated into the user name and / or password fields.
I have tried scripts and attributes on the HTML from various stackoverflow threads... to no avail. To make matters worse, even clearing ALL history for Firefox and Chrome does not clear previously entered values (how can this be?). Note that in Chrome it autofills it and in Firefox I can see all previous logins by double clicking the user name box.
I do know... that when you change user that the browsers ask you whether you want for it to remember these details for you.
It is however important to note that the defaults for this in all major browsers are to "Remember!". For hectic workplaces it is just so easy for a user to accept this without thinking about it (and sadly, these users are not browser experts but simply trying to do their job)... leaving the user (and the system) at serious risk. I also don't think that for these situations that it is the decision of the user - but from a systems point of view the developer should be able to limit it.
I find this behavior for browsers not only impossible for the implementation mentioned - and cannot believe there to be no programmatic answer to this? I furthermore find this behaviour of the browser to be more distracting than helpful, even to myself as a more literate user.
If there is anybody there that has a technique that works... then please share.
Unfortunatelly (some) recent versions of browsers seem to ignore even the autocomplete="off" tag due to the users comfort, but as your example shows there are situations that security matters are far more important than user comfort. Maybe this will be somewhat helpful to you (if using the jQ plugin is allowed in your case):
https://github.com/say2joe/jquery.disable-autocomplete
In the html of client side. If we change the type="password" into type="text", the password is displayed as plain text in browser. Is there any security issue about this? If it is, what is the solution to this issue?
Example as follows:
type="password"
type="text"
There are two rather different security issues involved.
One of them is the one so often mentioned as a reason for using input type=password: to protect the user against prying eyes. This is seldom relevant, since passwords are normally typed (and should be typed) so that there is nobody else looking at your screen or your hands.
The other one is different treatment of input type=text and input type=password by browsers in their histories and in using previously entered data as defaults or as selectable options. This varies by browser, but quite often, input type=text causes an automatic prefill if data has previously been entered in a field with the same name. Using the autocomplete=off attribute usually prevents this in modern browsers. On the other hand, browsers may store username/password pairs to make frequent visits to a site more comfortable; this can be an essential usability improvement and an essential security threat. It is typically based on recognizing a pair of input type=text and input type=password.
You could leave the decision to the user by offering both options. Perhaps the least distract way to do that is to have an input type=password with a checkbox “Show password when typed”, JavaScript-driven of course, which when checked turns type=password to type=text.
There is no difference between input type=text and input type=password.
in handling the data, once it has been read. In both cases, the data will be sent to the server as unencrypted, unless the entire form data is encrypted.
Well, the issue is that the password is displayed in plaintext on the screen. This gives anyone shoulder-surfing the opportunity to see the password. It's typically hidden so people who just happen to stand around cannot see the password being typed in and one can type in a password even with not-so-trusted people nearby.
2017 here and the question is pretty popular and I think very important.
Technically there is no difference in handling data, but password fields are the flag for different analytics plugins/dictionary extensions/autocomplete tools etc. to not analyze and track such fields. For example, when you type in text field hotjar tracks it's content and sends to their servers, but they skip sending when they see password or credit type number.
Are there any security issues when your users' passwords will be sent to third party companies?
There is no such security issue in having the password field as type text. It is done only to prevent people sitting beside you or "physically" spying on you to find out about your password.
Is there any security issue about this? If it is, what is the solution to this issue?
Yes, there is a security issue. Mostly of 2 types:
Shoulder Surfing.
Save Password on Browser or from history.
For Type 1, the user needs to be discrete and manage his environment better.
For Type 2, the user could walk away from his computer and another user could basically type out the username, the browser could prompt the user to autofill the password and you are through.
Now to close this security. Turn off the saving password at your browser end. The browser will not be able to save the password. So it's not exposed to other users if they change it from text to password.
Ideally, no autofill should be available for Security.
This is a serious security flaw from the user's standpoint
Consider this scenario:
Chrome or Safari save password/usernames and automatically fills them when you visit the designated website. What if you left your computer open in a public place? It would be so easy for a 3rd person to reveal your passwords.
Macbook's keychain app requires you to enter the computer password to reveal the internet passwords (safari passwords), right? But if somebody opens the the website from your computer and navigate to the login page, the password and username/email are there. If you have already signed in, then they just need to first log you out and re-open the login page. Then; all they have to do is to change the input type from password to text to reveal your password. That's it!
If this was not a security flaw, then why Macbook Keychain Access App requires you to enter computer's password to reveal the internet passwords? Are they basically not the same thing?
You must protect the password fields from changing their types via dev tool!
I created a simple javascript snippet to protect password inputs against changing their types using dev tool (i.e: chrome dev tool). See live demo and test it out:
- https://codepen.io/mcakir/pen/zpZXxe
Note: It is written using vanilla javascript so it doesn't depend on any library (i.e: jQuery)
i can't find any information inside the w3c html strict spec
http://www.w3.org/TR/html4/sgml/dtd.html
PHP USERS:
If you are using php to process your form take note that php has a max_input_vars setting in the php ini file. I believe the default is 1000.
I ran into this while building a cakephp app. To see if this is affecting your post, count how many rows of data you are putting into the form and then count how many rows are actually posted back.
So essentially your form would be limited by the number of input vars you have.
This isn't really an direct answer to the OP but I think it would be helpful for anyone searching for a limit on input fields.
To my knowledge, there is no upper limit to the number of form elements (<input> or otherwise) in an HTML document.
However, if you have a huge number of form elements on your page, you might end up with a POST request that is too large to be processed by the web server (the maximum size of POST requests depends on the server configuration).
I don’t think there’s a maximum number of input elements in a form given by the spec, if that’s what you are asking. If you have many inputs and want to make sure the form works, you’ll have to try on the clients you support. And of course, it would be much better to redesign the form, if that’s possible.
I don't think that there is a limitation on the number of unput fields in the standards.
There are two practical limitations that you need to consider:
Some browsers start to act up if there are too many input fields on a page. I haven't tried this with recent versions, but I remember testing this a few years back, and then I found that Internet Explorer behaved badly when the number of fields was closing to a hundred.
Too many input fields on a page is just inconvenient, and perhaps a bit scary, to the user. Split the input on several pages, or show placeholders and add input fields dynamically only where they are actually used.
Technically, there is no maximum number of input fields that can be put on a page. Practically, for a user, it is a bit inconvenient for a user to use/see all of the input fields if a web page has a large number of input fields.
I was encountering a similar problem in an old application.
I thought it was a limit to the number of HTML input elements or PHP ini configuration for max_input_vars.
But after more investigation, it turns out it was Suhosin that was installed on my production machine which over wrote the PHP.ini config value with a much lower limit.
suhosin.post.max_vars = 400
Please note that we cannot set this max_input_vars directive in run-time with function ini_set. We can change it directly in php.ini file.
; How many GET/POST/COOKIE input variables may be accepted
max_input_vars = 2000
Don't forget to restart web server. Sometimes we need to reboot the server to take effect.
My organization has a form to allow users to update their email address with us.
It's suggested that we have two input boxes for email: the second as an email confirmation.
I always copy/paste my email address when faced with the confirmation.
I'm assuming most of our users are not so savvy.
Regardless, is this considered a good practice?
I can't stand it personally, but I also realize it probably isn't meant for me.
If someone screws up their email, they can't login, and they must call to sort things out.
I've seen plenty of people type their email address wrong and I've also looked through user databases full of invalid email address.
The way I see it you've got two options. Use a second box to confirm the input, or send an authentication/activation email.
Both are annoyances so you get to choose which you think will annoy your users less.
Most would argue that having to find an email and click on a link is more annoying, but it avoids the copy/paste a bad address issue, and it allows you to do things like delete or roll back users if they don't activate after say 48 hours.
I would just use one input box. The "Confirm" input is a remnant form the "Confirm Password" method.
With passwords, this is useful because they are usually typed as little circles. So, you can't just look at it to make sure that you typed it correctly.
With a regular text box, you can visually check your input. So, there is no need for a confirmation input box.
I agree with you in that it is quite an annoyance to me (I also copy and paste my address into the second input).
That being said, for less savvy users, it is probably a good idea. Watching my mother type is affirmation that many users do not look at the screen when they type (when she's using her laptop she resembles Linus from Peanuts when he's playing the piano). If it's important for you to have the user's correct email address then I would say having a confirmation input is a very good idea (one of these days I'll probably type my email address wrong in the first box and paste it wrong into the second box and then feel like a complete idiot).
While the more tech-savvy people tend to copy and paste, not technical people find it just as annoying to have to type something twice. During a lot of user testing I've down, the less tech-savvy - the more annoyed they seem with something like this... They struggle to type as it is, when they see they have to type their email in again it's usually greeted with a strong sign.
I would suggested a few things.
Next to the input box write the style of the information you are looking for so something like (i.e. user#domain.com). The reason this is important is you would be surprised how many of the less tech-savvy don't really understand the different between a website and an email address, so let them know visually the format you want.
Run strong formatting test in real time, and visually show a user that the format is good or bad. A green check box if everything is okay comes to mind.
Lastly, depending on your system architecture I often use a library to actually wrong a domain in the background. I don't necessarily try to run a VRFY on the server - I often use a library to check to make sure the domain they entered has MX records in it's DNS record.
I agree with Justin, while most technical folks will use the copy, paste method, for the less savvy users it is a good practice.
One more thing that I would add is that the second field should have the auto-complete feature disabled. This ensures that there is human input from either method on at least one of the fields.
Typing things twice is frustrating and doesn't prevent copy&paste errors or even some typos.
I would use an authenticate/activate schema with a roll back to the old address if the activation is not met within 48 hours or if the email bounces.
As long as a field is viewable, you do not need a confirm box. As long as you do some form validation to be sure that it is at least in valid format for an email address let the user manage the rest of the issues.
I'd say that this is ok but should only be reserved for forms where the email is essential. If you mistype your email for your flight booking then you have severed the two-way link between yourself and the other party and risk not getting the confirmation number, here on StackOverflow it would only mean your Gravatar would not be loaded ...
I'd consider myself fairly techie but I always fill in both fields /wo cut-paste if I regard it to be important enough.
I tend to have it send a verification code to the email address specified (and only ask for it once), and not change the email address until the user has entered the code I sent them.
This has the advantage that if they try to set it to a dozen different addresses in quick succession, you'll know which ones work by which verification code they put in.
Plus, if I am presented with a "confirm email address" box, I just copy and paste from the previous one, and if I'm guilty of that, I'm sure that other less careful users will do the same.