If you create a form using HTML inputs and make the input required using the "required" attribute (<input type="text" required>), what is stopping a user from manually deleting the attribute by using their web browser's built in developer tools or by loading JavaScript by some other means (such as a bookmarklet)?
In other words, how can you ensure the required input remains required?
The client/browser has little control over the request that is sent to the server. A request can be constructed and passed to the server without involving a browser, therefore its the server side code's responsibility to ensure that the required parameters were provided with the request (as well as validate the parameters).
You need to consider a few things:
Everything on the client side can be modified by the client: nothing is stopping me from using my browser console or modifying the source code to change parts of your page, and you can't do anything to stop that. For instance, look how many upvotes your question has:
Obviously that doesn't actually do anything, but that's because all of the heavy lifting is done by Stack Exchange's servers.
Even if you make a field required, people can still fill in the field with a space or asdf and move on. Just because input is required doesn't mean that it is valid.
So, with that in mind, realize that you'll need to work on the server side to validate input. People can't mess with servers (easily) and it's the safest way to validate input. You'll need to deal with validation when your server receives the data because the client side is always vulnerable to user modification.
Related
I allow my users to favorite an update or a forum topic.
So when a user tries to favorite one of these i will send via Ajax 2 things, the item_id(update or topic) as id(ex. 1321313213) and its type("update" or "topic") as string.
However lets say someones tries to favorite an update with the id untouched but the type is changed to "topic"(via firebug or whatever else)...
This should not procceed since this combination is not correct... how can i assure that the item_id being sent is an update or a topic since this ID might co-exist in both tables???
Current solution:
Create a hidden input element and add as value 5 random characters (a-zA-Z0-9) and md5 type name(update or topic)
like:
$random_str = $this->my_model->generateRandomString(5);
<input type="hidden" value="<?php echo $random_str.md5("update"); ?>" id="type" />
so when i try to validate the data to check if it is an update or topic i split the type on the first 5 characters and later and check if the later characters are md5 hashed are update or topic and continue validation
I would like some help in case this can be altered as well...
Your server side script (PHP) must always assume it's getting bogus data. Never rely solely on javascript to handle any sanitization / verification.
If your javascript can determine if the job should be "update" or "topic", I'm sure your PHP can do that as well. Probably using a few more DB queries or some such, but that's the price you've got to pay.
Your are looking at the problem from the wrong perspective. Especially from You server side (PHP) code.
Your server gets data. It gets data which is something like that: user (from session), id and type. Your server needs to ask a question: is it valid data? If it is -- save it to DB; If it is not -- do not save it to DB. It is that simple.
You can look from this perspective: Your client side code is just one way to communicate with Your server. Another way is using web browser + firebug. It is perfectly valid usage of Your server side application. And Your PHP code should not care how request reaches it.
So if Your current code does not allow You in Your PHP code feel comfortable and freely decide if is it update or topic creation than Your need to change Your server side code (and perhaps DB schema) as well.
Your current solution is not good, because if I know how to use firebug I would probably find out that "9d9b68ac2b1de18d3712096354b3c3a5" means "topic" and "3ac340832f29c11538fbe2d6f75e8bcc" means "update".
I think Your are trying to invent Your own CSRF protection. So go on Internet and read about it.
A simple user registration may be completed by PHP (framework: Codeigniter,etc..) and Javascript.Following is simple flow:
PHP
A registration view with form input(user_name,e-mail,password)
post the data to an controller to validation
-Pass, redirect to a completion view
-Failed, go back to the registration view with some alert strings.
Javascript
A registration html with input text(user_name,e-mail,password)
Validation could be done by Javascript directly before submit; Alert strings could be
generated by Javscript. Even submission could be done by ajax. Then redirect to the
completion page.
I found myself code more javascript less PHP. Even the user registration could be done without the "form" tag,right? I am afraid of some parts I had miss or ignore.
Could someone gives me an simple comparison of good/bad parts about these two methods?
User registration details have to be stored on the server. You can use any language you like there, JavaScript (node.js is the current preferred way to achieve that), Perl (PSGI/Plack), Python (WGSI), C# (ASP.NET), PHP (mod_php), whatever. If you did it entirely with client side JavaScript, then the registration would exist only for a particular browser (which makes it rather pointless for almost anything on the WWW).
You can do a lot of things with client side JavaScript.
You can test if the data enter by the user conforms to the requirements you've set (such as "usernames contain only ascii alphanumeric characters").
You can't stop data that doesn't conform to those requirements being submitted to your server though - everything outside your server is beyond your control. Users can edit your pages in their browser as much as they wish. Client side validation is a convenience to the user (giving feedback without a server round trip and page reload), nothing more.
You can use Ajax instead of an HTML form … but there is no reason to do that. It just adds an unnecessary dependancy on JavaScript. That doesn't mean Ajax can't be useful, you could use it to ask the server if a username was already taken while the user is filling out the rest of the form.
Before submitting a form, i use javascript code (surrounded in PHP) in order to make locally some controls but sometimes javascript may not be enabled client-side.
The fact is that I have to check by pattern/regex each control of the form for example checking email, phone number,.. format so that user cannot enter anything haphazardly. Therefore, if javascript is not enabled, the form must not be submitted, even if all field are fulfilled out.
Therefore my question is to know if there is a tag or function which allow to perform what i want to?
Thank for your help
JavaScript runs client-side.
That means that users have FULL CONTROL over it.
Then, if they want to disable it, you can't do anything about it.
The only thing you should do is be sure that users with JS disabled will be able to submit the form too.
If you use JS to validate the form, be aware that users have FULL CONTROL over it, so they can send the form if they want, even if your code says that it's invalid.
The right way to do it is:
Be sure users without javascript can send the form
Implement client-side validation for users with javascript activation. This way they will have a better user experience (because can know if the data is invalid immediately) and is less server intensive (your server will have to validate less invalid forms).
ALWAYS validate the submited form server-side. Data coming from a client is always UNTRUSTED, even if you think you have validated it.
I just realized while testing an onClick function with firebug that it would be really easy for a user to change the value of the arguments being passed. This could mess thins up.
Is there any easy way to prevent this, especially when arguments need to be passed?
It is impossible. The code is executing on the user's computer. They are in control.
If they edit it and "mess it up", then that is on their head.
If they edit it and it submits an HTTP request to your server, and your server allows (for instance) that request to delete data belonging to another user then the problem is that your server didn't check that the user submitting the request had permission to delete that data before following through.
You cannot trust anything sent from the client. The user might hand-edit the URL arguments, or a script kiddie could send you a request not even using a browser at all. You must validate everything server-side.
No, this simply can't be done.
Once the script is loaded to the client's machine. He can use/modify it, as he wants.
I'd recommend validating the arguments against expected set of values, and/or business rules wherever the results are being processed (client/server). Ideally validation checks happen on the server where the user has no control. Validation on the client side could even be modified to allow invalid data entry.
There is no way to completely control it - only validate it based on criteria.
You can't prevent this action because JavaScript is a client side . Also you can never trust the client .
You should make a validation for any request at server side to protect your data against client misuse .
you can somehow make it hidden from client eyes
by using .delegate()
EX.
$("table").delegate( "td","click", function() {<br>
// write here your function<br>
});
The client can execute this script but it isn't direct in front of his eyes ..
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).