I'm writing a small app that gets information from the server, allows the user to manipulate it, then saves it back to the server. When getting the information from the server, the server also gives a password. When the information gets sent back to the server, the server looks for the password, as a safety precaution.
My question is, what is a safe way to pass the password after the form submits? I considered hidden fields, but that would make it possible to find the password.
Any ideas?
You can store it in a session with a specific field defining of password and destroying after made in use.
This is much better usage.
You could give the password to Javascript/jQuery and then intercept the normal form submit, append the password to the post data, and then resubmit the form, but that may be a bit overkill...
As long as the password isn't being used for anything else (as in it's randomly generated) and it's single use, putting it in a hidden field shouldn't be much of an issue. Average users don't know how to view hidden fields. However, if you are connecting over HTTP and not HTTPS, your average hacker would be able to view the password coming over the unencrypted network and potentially use it before your user can.
Related
I have a question that is more conceptual at the moment than anything else.
Here's my situation
The school that I go to has a website for grade viewing which can be found at this link: https://grades.bsd405.org/Pinnacle/Gradebook/InternetViewer/Default.aspx
The login page presents a username and password box.
I plan on constructing a simple iPhone app that takes the resultant grades that are listed and display them in a UITableView.
However, how would I achieve getting the data from this website?
How do websites validate (authenticate) usernames and passwords and then pass on the relevant data?
Thanks for bearing through this tough question.
There are a lot of things going on in this website; i think we would need a little more info from you on your specific request. When you say Validate, do you mean validate as in check that usernames and passwords are formatted correctly or do you mean validate as in authenticate, i.e. send the resultant data to the X to determine that the username and password is correct.
Based on what I see I can partially answer your question, the asp site would send over SSL, the user name and password to the application, where I would assume the application then checks the username and password against a username and hash of the password (the hash being the calculated squish of the password which is stored as such for security and confidentiality).
In your case you wouldn't need to know any of that if you wanted to interface/integrate an app with this, you'd just need to format a request in your app and deliver it over an SSL connnection to the page. There's a caveat; and that being session stuff with ASP; its a bit more complex than just usernames and passwords.
The page generate a unique ID each time, passed as hidden field of the form. So i'm sorry but i think that you can't post nothing from the extern.
Yes, you certain can pass the hidden id.
What you need to do is follow the session stuff that ASP generates. We do this all the time with ASP sites that we 'scrape' for data with our primary application.
Your app will first need to call the site, collect the sessionid data, and return that in your form when you submit the form for authentication. After that depending on what is happening in the site, you may need to capture and send the resultant sessionid on each subsequent request.
Actually its a horrible thing when you see how much useless data is passed back and forth by ASP.
I am currently having an issue with using a nonce as a security solution in PHP
i read this post about
How to check if a request if coming from the same server or different server?
about using an hidden input form field to hash a random value and At the same time, store that random value into the session that correspond to the user.
When the form is submitted, check that the hidden field has the same value as the one that's stored in session. (I think am having a problem with this)
Example
<?
$_SESSION['formhash'] = md5('any value to be hashed');
?>
<input type="hidden" name="hashed" id="hashed" value="<?php echo $_SESSION['formhash']; ?>" />
A user having an Mozilla Firebug and inspecting the element will still find out my hidden field and then copy it. And then create his/her own form then post it to my url and the Login will still be Bypassed.
Image showing example
Is there any more secure way to do this ?
Any help will be appreciated thanks !
The bottom line is that you cannot prevent a user from manipulating the form data prior to submitting the form. What your solution does is confirms that the form data is coming from the user you sent it to.
Regardless of whether or not a user is "logged in", you will probably start a session each time a new visitor hits your site. This means you can store the hash value each time you send them a form and you should, in theory, be able to associate the hash value on the returned form data with the hash value in the session (just like your code is doing).
Armed with that knowledge, we can consider the following scenarios:
The typical use case is that a user submits a form without modifying the data. Your approach will allow you to confirm that the form has been posted by that very user. Your validation code should confirm that the POST data is acceptable.
If a user modifies the form data and submits it, your approach will allow you to confirm that the form has been posted by that user, but not that the form has been messed with. This is why you need to validate forms very, very carefully.
If a user grabs a form that was actually sent to someone else and posts it - modified or not - your system will allow you to confirm that the form did not come from the user that it was originally sent to and you should reject it.
Scenario 3 is what is known as a CSRF attack and your solution is the standard defense against this attack.
PS As #cHao says, you should regenerate the hash for every form you generate.
I implemented CSRF protection by including a token with PHP into a hidden input for every form. Each token can only be used once, of course.
However, there are tools, such as any web developer tools, which allow inputs to be changed. For example, I can change on-page input forms: I can make disabled checkboxes enabled, and I can change input boxes to textarea boxes without reloading the page or anything like that. CSRF wouldn't catch such changes.
So, how much of a form do I need to validate to stay safe? Do I need to validate every single input to make sure it wasn't altered, including selects, checkboxes, hidden inputs, etc? Surely it can't be safe to assume that these haven't been altered?
You need to validate (on the server side) everything that needs to be validated. What exactly needs to be validated depends on many factors and personal choices. Some of it may be for safety, but only a bare minimum is needed for that in many cases. For the most part validation is to improve or create user experience.
For example you can check to see whether they have entered a valid email address. If they haven't, you can give them a message. If you don't do that nothing bad will happen to your application, but the user won't be able to receive email from you.
There is also an important distinction between validation and sanitation. Sanitation is done for security (e.g. to prevent injection). Validation is done to make sure that input meets requirements to work correctly with your application although incorrect input may be benign. It's also possible for sanitized malicious input to be valid.
All input must be sanitized. No input needs to be validated, so it's really up to you.
CSRF protection has nothing to do with validation. All it does is prevent a user from making a request using your form from an external source because the only way to generate and see the token is to make a request to your site first.
What we are trying to do using CSRF is to ensure that the request IS coming from a reliable source. For e.g, your case what you need to do is ensure that the value in the hidden field is sane. And it can be sane (provided that your token is strong enough) only if it is the same as the one that was provided while the form was rendered by the server.
Now whether fields in the form changed or not, is just your application logic. It does not have anything to do with csrf. If the token is sane, then it came from the right source. Now, if it was the same person who entered values in the form for e.g. is not within the scope of csrf.
I think you are getting the wrong end of the stick here. The token is not a hash of the form when it was sent.
The way this works is to store your unique token in a hidden field on the form and into the session when you server the original page.
When you get the page POSTed/GETed back from your user you check that the token on the page is the same as the token previously stored in the session.
Changing fields must still be allowed or your user will not be able to enter any data on the form. You are just checking that you got the same form back that you sent, because the token is the same, rather than one from somewhere else, i.e. its not a cross site request forgery.
You still have to validate all the fields and do any data preparing before storing it in a database.
Reading1
Reading2
I have a form that the user needs to populate and then the form will be sent to a server.
After the user submits the form, if the server script found that the form is not correctly populated (i.e. the uploading file is too big), it should return error to the client side.
Now, my question is as follows:
How do I keep the user seeing the same page without transferring to a different page?
Because I don't want the user to waste time to reenter everything again. I just want the user to correct the wrong part.
Because I don't want the user to waste
time to reenter everything again. I
just want the user to correct the
wrong part.
This is a good intention, but the wrong solution.
To stay on the same page would mean you have to submit the form using javascript. While possible, why make things more complicated than they have to be?
Instead, submit the form to the server and when you write out the form again to the user with the error message, set what the user entered as the default value on the form. Then it will be there for them and they won't have to type it again.
Note: Don't do this for passwords tho; the page may be cached and then the users password is saved in a plain file on the hard disk. This is why most sites make users retype passwords each time.
You need to show form again and fill previously entered data in input's "value" fields. Of course, don't forget to replace special characters with html entities with htmlentities();
I also found one tutorial for you: http://evolt.org/node/60144
Question:
What is best practice for form submissions while keeping in mind security?
This may be a n00b question but I'm concerned that people might be able to alter some data as its being submitted. Take my example:
I have a form that has a hidden input that stores a user's unique Facebook ID. I take that Facebook ID and create a user account from it. If I use jQuery, won't some users be able to change the data being posted?
It is just as safe as a regular form post. Both methods can be hijacked and data injected. The key is how your server side scripts validate the data alongside authentication, session, anti forgery tokens etc
Users will always be able to post whatever data they like to your server. You can't do anything to change that with javascript. With a decent browser it's easy to find hidden form fields, unhide them, and put whatever you want in them. A more skilled user can craft an http post by hand and send whatever they like. Security must be done on the server, not on the client.