Is there a way to post some values in a form without using hidden fields?
The user should not be able to read these values by checking the DOM.
You can use hidden fields for posting data. But if you want that the user should not be able to read the values set in hidden field, you can encrypt the value before setting in the hidden field and then set it.
In this way nobody except you, who knows how to decode the value, would be able to read it.
Hope this helps.
AJAX can post any values you like, whether or not they appear in the form.
Well, whatever method you use the data is visible. The way sensitive data can be handled 'safely' on a public webpage is twofold.
Encrypt the data, as other poster mentionned.
Use ssl ( https:// ) for the pages you want secured. This prevents any 3rd party from sniffing the traffic generated by your users requests.
With these 2 simple steps properly implemented, the data, though not 100% secure ( nothing is secure on the net ), it is a lot harder to attain.
Using this two way passworded encryption class
http://www.tonymarston.net/php-mysql/showsource.php?file=std.encryption.class.inc
and following the usage example
http://www.tonymarston.net/php-mysql/showsource.php?file=encryption.php
you can get something like this
http://www.tonymarston.net/php-mysql/encryption.php
Then in your situation you can do this:
<form >
<input type="hidden" name="data value="<?php echo($encryptedData); ?>" />
</form>
or you could do this
<?php setcookie("formdata", $encryptedData, time()+3600); /* expire in 1 hour */ ?>
Then on the other end you can decrypt the data using your password.
If I'm reading your question correctly, no, not really.
If you give something to the user and get it back, the user can modify it.
Why are you in need of this functionality? If you give us some context, I bet you'll get a definitive answer.
Related
I tried to look through SO for similar question but I couldn't find one, also searched through the web with my best effort, sorry if it's a silly/duplicate question
The focus of my question is :
If I have a form with a unencoded password in it, is it "safe" to pass the form back to [self] i.e. <form action="">
EDIT: I would like to focus on security regarding third parties, assuming the user himself is NOT the hacker.
I this is a broad question, so I would like to narrow it down to:
does server handle submit form to self as a internal-forward thing or do it actually treat is as a normal server-to-server http call?
Is it possible to somehow intercept the form submit and extract the password from this action? (including things like tapping the connect between server and client??)
If anyone knows any potential security problem in general for [submit to self], feel free to leave it as answer so that future SO user might benefit from it, thanks.
The only thing safe regarding submitting data to a webpage is to never trust the users input.
Now regarding your 2 questions:
submitting the form will be handled as a regular request, albeit a POST request probably.
internet traffic can be captured, so if you're sending password data over the internet you'd better make sure it's over HTTPS.
Using a developer tool like Mozilla's FireBug it's pretty easy to change all the data that is submitted through the form. You don't even have to use your webpage, one can easily spoof a POST request to your page by using a tool like Telnet.
So I'd say it doesn't really matter what the action of the form is; use HTTPS if possible and always validate the input...
Whether you submit your form to the same page or not has no security implications. There are many other things you can/should do to secure your forms. Submitting-to-self is irrelevant. It could however pose a UX annoyance. Have you ever tried refreshing a page only to have the browser try to resubmit the form.
Not a redirect. Normal post. However to mitigate this UX annoyance I
mentioned, you would redirect to the same page after doing whatever
you need to to with the data.
It depends on many other things other than whether the form submits to itself or not. Starting with is your form on a secure (https) server.
I was just searching for this types of posts.
Yeah..
As far as i know, this is not a valid approach,
attacker can change the methods to download the content like he can use the parameters from POST to GET.
We actually have tools like tamper data which is an addon to the firefox browser. We can post the data or tamper the data which is in form submit. You can add this addon to your browser and you can check out that the data can be modified by clicking tamper before submitting the form. You can also check out the online http tampers, tamper data, modifying live headers to change your data. This may also result in sql injection.
Correct me if im wrong. :)
Cheers.
After many updates:
The action="" is the same as action="somefile" in sense of security. So there is nothing wrong with action="", and as far I know most websites treats forms like that. The most popular solution is to:
At first check with PHP if there is any post data
Check if this data is OK (safety, server side verification)
Make something with data (save to database, mail to someone)
Render the form with action="".
A quick example:
<?php
$name = '';
if (isset $_POST['name']) {
$name = $_POST['name'];
if (ctype_alpha(str_replace(' ', '', $name)) !== false) { // verify data
// in that case name consist only letters and spaces, it is ok.
// do something with data here, for example save to database
header('Location: successfile'); // Remove post data after all
}
}
// render form
$name = htmlspecialchars($name); // if name was in POST, here it is!
echo '<form action="" method="post" />'
echo '<label id="name" name="name" value="'.$name.'" />';
echo '</form>';
?>
In that case one file is doing two jobs. It checks for data and do something with it, and render form.
Please, remember that the form can be rendered using the "partly" data from submit (POST). So for example if someone enter his name with special characters, while you need name only with letters and spaces, the data is not missed. You can render form, and in input name value, you can enter the wrong posted data.
So the form "remember" what was filled, and what was not filled.
Hope it helps
I have many websites like Facebook where we write a email address and we just click a button, from this a list of email address's rolls down.
Can anyone tell me how this is achieved? Can it be done with just HTML or do i need to learn any other language?
This is accomplished using Javascript or AJAX requests to query the databases "live" and the return a data set. If I understand you correctly like on Facebook where you type in a Friends name and it will pull back a full list of names which may be your friends.
Jquery, Ajax, Javascript, PHP and Mysql would be some good researching points.
It would be worth searching for "How to create a PHP Ajax request to auto populate HTML fields"
If you are referring to Auto Complete within a browser this is a local setting which is controlled by the end user or their administrator and from what I am aware from HTML alone you can not manipulate this.
I fully agree with Steve's answer. In addition you might want to check out the following:
http://ajaxdump.com/2010/08/11/10-cool-auto-complete-scripts-using-ajaxjquerymootoolsprototype/
http://www.freshdesignweb.com/jquery-ajax-autocomplete-plugins.html
Hope it will help you
Well i go on and search a lot and then i found this is very simple!!
you just need is to type autocomplete = "on" and give it a name and then make a submit button
the code goes here:
<input type="text" name="Name" autocomplete="on" />
<input type="submit" />
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 certain the answer will be 'NO', but I wanted to ask anyway just
incase I have missed something.
Everyone knows that one pass data to a page in an anchor tag by using
the GET method:
What I am wondering is if there was a way to do the same thing, but use
the POST Method instead?
My purpose in doing so is to keep the URLs the user sees clean by not
putting anything in them that they do not need to see.
This has nothing to do with security concerns as I already know there
would be ways to obtain the data being passed.
If the answer is indeed no, then what methods do people use to pass data
when there is a desire to keep the URLs clean? Cookies? Something else?
and how to deal with the scenarios when the URL length exceeds the permissible GET request length
I am facing this issue while implementing sorting/pagination with displaytag, all the request parameters are appending in the sort/pagination url which is more then the permissible length of the GET request.
You could do something like this:
<form method="post" action="target.html">
<input type="hidden" name="name" value="value" />
<a onclick="this.parentNode.submit();">click here</a>
</form>
This behaviour is specific to display tag library. It allows for easily bookmarkable search results. If you really intend to change this to make use of POST, then you'd need to rewrite the display tag library or bring in some jQuery to manipulate the links.
The remnant of your questions boils nowhere. If you want GET (idempotent requests, bookmarkable URLs, searchbot-crawable URLs, etc), then use GET. If you want POST (non-idempotent requests, non-bookmarkable URLs, non-crawlable URLs, etc), then use POST.
Usually, POST is mandatory when the request can modify the data in the server. Think of a SQL INSERT, UPDATE, DELETE, etc. You certainly won't make this kind of requests GET. Imagine that you've a table with all "delete row" links which do GET and then a searchbot comes along...
You can use javascript. On onclick of link do form.submit
The only way I know of to deal with lenghty URL is to instead use POST.
You may create a temporary form and submit it while onclick event of <a> tag.
It will work as post ,the name value can be through anchor tag and value of name="" can be access to $_POST[] globl var
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.