I was wondering whether it is possible to assign a value to an HTML text box and protect it.
What I mean is make it´s content unmodifiable, so that when the form gets submitted im "sure" it was this value which was submitted.
BTW I realize the easier way would be not to "listen" fot this input and just assign it but it would come in handy to be able to do what´s stated above.
I hope the question is clear enough, please ask for any needed clarification.
Thanks in advance!
EDIT: I was definitely not clear enough but I tried to express that i should hold the value after submitted (not modifiable in client side)
No, it's not. You should never trust user input, which includes form submissions.
The other answers tell you how to mark the field as read-only. This is useful if you want to display a particular value, while showing that it's not intended to edited.
However, it can still be modified with Firebug, DOM Inspector, etc. Or, they can just submit a HTTP request without using the browser at all.
I would recommend storing the value in a session instead.
Set the readonly property of the input element:
<input type="text" readonly="readonly" />
This will prevent any modification (except if the user edits with a DOM Inspector). Always validate input on the server. If you do not want any changes made, don't allow the user to edit it.
http://www.w3schools.com/tags/att_input_readonly.asp
Form inputs have a 'disabled' and 'readonly' attributes you can set to make them un-editable.
http://htmlhelp.com/reference/html40/forms/input.html
Though you can never be 100% sure what is getting sent from the client side. The entire DOM is editable by the client.
Just do this
<input type="text" value="VALUE" readonly />
Then itll be read only :)
<input type="text" readonly="readonly"/>. But: Never be sure, and validate data on the server side. It is very easy to request GET/POST with invalid data.
Related
I have the following html code:
<input type="text" value="test value" readonly/>
This input element is non-editable since it has the readonly attribute. But it's still possible to make this field editable by inspecting the element using the Firebug tool in Firefox. Is there any way to make this attribute non-editable?
This is really not possible. Someone will find a way around it because your code is executed on the client. Even if you secured the client (web browser) there is still a way to post back and tamper with read-only fields using a proxy server like Fiddler. You have two choices.
1)Remove the item from the field list and make it a text element. This is only a valid solution if you don't need the information back in the POST.
2) Keep the item read only (or hidden) but check the content has not changed on the server side. This is a best security practice anyway. You should always validate on the server even if you validate on the client. The reason is that people can work aound client side validation. There are different approaches for server side validation according to your back end language. In this case, if you are using PHP or ASP.NET, then you can stick the value in a session variable before you serve the page and check the POSTED value against the session value when the form is submitted.
I've researched it and cannot find a standard, dependable way to make a browser prevent autofill and not remember the password in a standard login form.
This is important to me as I'm working on a mobile web app, so if the user clicks logout and someone else gets hold of their phone, the browser shouldn't help them out by just handing them the password!
The only solution I can come up with is to make the password field type="text".
Sure, this would mean people can 'shoulder surf' and see what the user is typing in, but that same person could almost as easily just watch the user's fingers to see what password they're typing in...
I don't think spyware is a real issue here either, as I don't think a type="password" character mask is going to stop a malicious keylogger, etc. from doing its stuff.
So, I'm wondering if there are any other security concerns that I may have missed for using type="text" for a password field?
Maybe if I combined this idea with a dynamic/random 'name' attribute for the input, could I be onto a winner?
NB - The solution needs to be compliant with XHTML Mobile Profile.
Also, please refrain from advising me on what is semantically correct here. My priority is security, not semantics. :)
Bad idea - The browser will remember text fields, it just wont enter them automatically as it does with passwords. Instead it will suggest the password as an autocomplete for all to see. I also think reading a password over someones shoulder is much easier than reading their keystrokes.
The reason some browsers dont respect the autocomplete option for passwords is probably because passwords are handled by a separate (in theory more secure) method for handling/storing password data - obviously by using a text field you are bypassing this system with whatever risks that entails.
I dont think there is a definitive solution that doesnt involve js, since at the end of the day you have no real control over what their browser remembers. You can only provide hints and suggestions. Which will be handled in different ways by different browsers. Your best bet is to start by adding :
autocomplete="off"
to your form and input. Works in most browsers - but not all.
The above would go in your form tag and your password input tag, something like:
<form id="form1_randomstring" name="form1" method="post" action="process.php" autocomplete="off">
<input name="password_randomstring" type="password" value="">
As you said in your question, randomizing the form and input names will also trick some browsers into thinking it is dealing with a different form
Also, browser will be extra conservative about what they remember if you use ssl. So this may help.
Finally, as another layer of protection you could have a little onload jquery to clear the form field manually on docready:
$("input[type='password']").val('');
Obviously no help if not running js.
The Definitive solution (maybe?)
You could go a step further and inject the form field using an ajax call (plus generating the random form names + autocomplete and serving the page through ssl). Meaning js would be a requirement for logon but you could then make sure the field was clear and generate the form after page load. I would challenge any browser to complete it then.
If you went for that option both the outer page and the ajax loaded page would have to run through ssl - If you didnt want this an alternative might be to load the ssl form through an iframe (again trade-offs -user base would need to be considered.)
Depending on your requirements and userbase, this could present the most guaranteed option.
NOTE
Autocomplete="off" may not pass strict XHTML validation. An option then may be to add the autocomplete attribute after page load with jquery (again, obviously this wont work without js enabled):
$('#form1').attr('autocomplete', 'off');
As an added point, The simplest way to prevent a key logger would be to provide a select option drop down box and ask them to enter a letter/number from their password. Practically speaking you would have to limit passwords to alphanumeric and ask the user to enter at least three letters/numbers from their password in a series of drop downs.
Summary
No perfect solution but lots of options, you'll have to consider what is right for you. I would maybe go for the ajax call as the main method. You could initially load a link to the form and dynamically replace it with the ajax content so that there is still an option for non js users (less users compromised by autocomplete)
I am able to write value to an input t form type= text
for ex
<input type="text" value="xyz">
But what i want is, to write a value to input type="file" . I have tried the code below but it's not working.
<input type="file" value="something">
You cannot, for fairly obvious security reasons.
If a webpage could specify a default value for a file input, then it could (for example) specify c:\place\where\finance\software\stores\accounts\by\default (and then use JavaScript to submit the form without the user having to do anything).
PHP aside, HTML doesn't let you assign values to input type="file" elements as a security measure. If HTML had this power, you could setup several of these fields and point each one to a windows file on the user's computer. The result would be a victim submitting a form with no idea they were also submitting sensitive information. No JavaScript is required. The victim might submit such a form to log in or post a comment on a blog somewhere. Why wouldn't the victim notice they are also submitting a file? CSS can style such elements offscreen using negative coordinates so its a lot like an input type="hidden", just in this case it would submitting a file instead.
Can anyone explain how the (IE) vcard_name attribute works as applied to HTML input fields (see below)?
<input name="foo" vcard_name="bar">
I've read Microsoft's documentation but am still unclear. In the example above, does the inclusion of the vcard_name attribute mean that AutoComplete suggestions will be drawn exclusively from the Profile Assistant? Or will suggestions be drawn from both the Profile Assistant and the standard autocompletion store?
Also, does the inclusion of the vcard_name attribute mean that the user's input will be saved in the Profile Assistant when the form is submitted?
Hope this will help you.
Thanks
How It Works (Basically)
When you enter information into a form and submit it, Internet Explorer sets up what's known as a vCard. The reason the function is so successful is that Web authors tend to use the same NAME attributes for many form elements across pages.
For instance, I'll bet you've filled out a ton of forms that ask for your name. Allow me to demonstrate. Type the first few letters of your name in the text box just below. If you're using IE 5.0 or above, I'll bet your name appears as a choice you can make. Try it in the e-mail box, too. I'll bet you get your e-mail as a choice. It won't work for everyone, but I'll bet I get the majority of you:
If it worked for you, and I'll bet it did, you're probably wondering how I knew each item would come up. Well, first off, here's the code from the form above:
<FORM>
Name: <INPUT TYPE="text" NAME="name">
E-mail: <INPUT TYPE="text" NAME="email">
</FORM>
It's the NAME attribute that does the trick. I'm basically making a guess that sometime, somewhere, you filled out a form that asked for your name and e-mail address. In addition, I am guessing that the form used the NAME attributes "name" and "email". They are very common.
If it worked, then you have a couple of vCards on your system named "VCARD_NAME" and "VCARD_EMAIL". When you filled out the other form and submitted it, the card was created. Now, from that point on, whenever you run into a form that has an element with a NAME attribute set to "name" or "email," the text from that vCard will be suggested to you.
Let me attempt to prove that point again. Below is a form that looks exactly like the one above, except the first text box has its NAME attribute set to "griswald" and the second set to "ookook". Go ahead, try to put your name and email in. You'll get no help from AutoComplete.
You didn't get any help because you don't have VCARD_GRISWALD or VCARD_OOKOOK on your computer. Luckily, I didn't give you the opportunity to submit the form, or you would have.
Basically, the *vcard_name* attribute overrides the name attribute. It tells the browser to use the vcard_name value passed as the schema to look for AutoComplete suggestions. If this is not provided, the name attribute is used.
Specifies the vCard type to use for the Autocomplete box. Setting the
value of the vCard_name attribute causes the contents of the
Autocomplete window to depend on the value of this attribute only,
regardless of the value of the name attribute. If the value of the
vCard_name attribute is not specified, the contents of the
Autocomplete window depend on the value of the name attribute.
Source : http://help.dottoro.com/lhwgvcmt.php
I need a text input field which does not use the autocomplete function - If a user has submitted the form before, his previous submissions should -not- appear as he types into the form again, even if he is typing the same thing again. As far as I can tell, there are a few ways to do this:
1. <form autocomplete="off">
However, I believe this is a proprietary tag, and I am not sure how compatible it is across browsers
2. Give the input field a random 'name'
One could even use JS to set the name back to an expected value before submission. However, if the user does not have JS installed, you'd need another hidden input with the name - and the php code on the other side gets messy fast.
Do you know of any other ways? Is one of these ways the "accepted" way? Comments?
Thanks,
Mala
Lookie here: Is there a W3C valid way to disable autocomplete in a HTML form?
Stick with the random name. You can do it simply enough server and client and you meet your no-js requirement.
You can store the original and changed name in a $_SESSION variable before outputting the form, and after the user submits, just get the name from there:
$random_name = md5('original_name' . time());
$_SESSION['original_name'] = $random_name;
...output form...
And after submitting you can easily get the value from $_POST using the $_SESSION variable:
$field_value = $_POST[$_SESSION['original_name']];
Just be sure that you have sessions available by calling session_start() before any processing.
Autocomplete is something that browsers decided to do on their own, so there’s certainly no spec document to look at.