This seems like a silly question, but recently I've been more and more in need of a quite common feature, that I can't find anywhere: I need to do some manipulation with the form data before sending it, but I don't want to show this to the user - I don't want to set the text of the field on the screen, but rather access the place where the values are stored and change one of them right before submit. Normally I'd leave the text field without name, and create a hidden field that would be sent. Upon submit, I copy the text of the nameless field, using it's id, parse it, and then set that to the hidden field, that is finally post. But that seems quite a bit of effort to do something so simple. There are plenty of reasons why one would do such a thing: remove masks, encrypt a password, change a date from local native format to database... All this things can be done server side, of course, but most of them would be way better client side: you'd need to send less data over network, it'd greatly simplify posterior server-side validation... Anyway, is there a simpler way to do it?
Related
We have a page which contains a lot of user editable data that is populated from various tables in a database. The data is in all different forms, dropdowns, checkboxes, input boxes, text areas, etc...
There have been some conflicts where two users load a record around the same time, one makes changes, and then another makes a set of changes. When they save they are unaware someone else made a change and may have just broken a change they made or overwrote their change.
I am trying to implement a solution to mitigate this problem, such as flashing the user an error when the data was changed by someone else.
I am wondering if there is a best practice way to check for this problem? Some ideas I had are
Submit both 'current' data present in the field, and the 'original' data. Then check which are changed and compare them in the database to see if the defaults differ from what is currently saved. This would work, but seems to be the least performance friendly.
Use jquery/javascript to detect when a field has been edited, and if it has changed from defaultValue then set a hidden field which will be submitted to indicate it's original value. Then it would do similar to what the previous idea did.
Set a hidden field with a timestamp of when the user loaded their page. When they submit, use that timestamp and check our history table to see if any data on the page was changed since that timestamp. This seems to be the most efficient idea and likely easiest to implement.
Are there any better options or a best practice way to do this? I feel like I am reinventing the wheel for a common problem.
You are solving a common problem. But it's common because it needs repeatedly solved so frequently. "Optimistic Record Locking" is your path forward. It looks like yii (which I am not familiar with) has capabilities to incorporate handling this. I found this link.
Whether the yii infrastructure does this for you, or you have to build it yourself, what you want to do (to support Optimistic Record Locking) is the following:
Make and Keep an unchanged copy of your data when you retrieve it to the Client.
The Client must submit the changes together with the unchanged copy of the data back to the server.
The Server's 'update' routine compares the unchanged
copy to the current record(s). If something has been changed, then it must
return an error msg and the 'new' current record.
If nothing was changed, then the Server does the update.
The alternative is Pessimistic Record Locking, which you can check out. I avoid it due to other issues it has, but there are scenarios where it is more appropriate.
I've been freelance working on the development of a web app for a company, and I realised that in any of the textboxes you can just type html tags or lines of javascript, which is obviously very problematic as I don't want the users to be able to do things that mess how it looks or functions. Is there a way of making sure html/javascript can't be written into text boxes?
The best approach is to assume that all data being POSTed, or sent via the URI to the server is malicious, until you check explicitly that it is not (Perl actually has a taint mode to enforce this), and validate the data received is valid for the data type you're expecting. You shouldn't rely on validation (only) on the client, as a malicious user may craft special requests without actually using your front end.
Despite the fact that I dont have a lot of info for the problem I will give a try, so be nice to me!! (please provide some more info)
Html or Javascript they have some common expressions, you can exclude those from the textfields by writing a custom javascript validator.
You should validate any user input (textboxes, etc.). This means in example that if you are asking for a number, then you check that the user input is a number, and reject anything else.
You can't (and you should not) "forbid to write HTML/JavaScript", you must "check that the input is valid against what you are expecting".
You should validate the input as soon as you want to use it. If you have some sort of input, keypress, keyup or similar event handler, you should validate the data before using it.
Also you should not inject user data as HTML. In example, don't use element.innerHTML = data; but instead use element.textContent = data; so the data are not parsed as HTML but just injected as text. (if you are using jQuery, use $(...).text(data) instead of $(...).html(data).
I am going to be processing a lot of form data from the client using Ajax. Right now, my way of validating input is to add a 'validate' class to each form control that needs to be checked. When the user enters information (or submits the form) the script looks at the input of each control with that class and verifies its contents before moving to the next tab (or sending it to the server). The issue, of course, is that a user can easily remove the class and the item wouldn't be looked at.
While I will of course be validating the input on the server-side (client data can never be trusted!), a lot of the user-side content generation [new inputs, dynamic forms, removing/adding validate classes, etc.] depends on people not tinkering with the classes. While I know that the client can ultimately do whatever they want, what are some ways to make this process difficult for the client to manipulate?
So far I have thought about:
Running a script at the beginning of the page load that grabs all the HTML inputs with the 'validate' class and stores them in a variable. When the user submits the data or moves to the next tab, instead of looking at the elements with the class 'validate', I instead look to validate the data compared to the contents of the variable.
Adding data-validate HTML attributes to each input and doing the same thing as above (running a script and grabbing the inputs that need validation before the client has time to tinker with the settings)
Is there anything else that can be done? I am a little hesitant to use the above approaches because there may be new, dynamically generated form elements that need to be added/removed to the list; and this + grabbing the data at the beginning of the page load could cause a little unnecessary overhead.
"While I know that the client can ultimately do whatever they want..."
You just answered your question. If that's your starting point, why are you trying to make it harder? Is it worth my while to actually try to hack your site? If it is, I don't care that it's harder. Also, how hard can it be? Are you going to make it so hard to figure out the JavaScript that the next developer who looks at this code also won't be able to figure out what's going on?
Also, you're adding more code. Have you ever written code without bugs? I haven't. So, guaranteed, there are going to be bugs in this thing. So, in the off chance that 1 in a million users might try doing something bad, you'll end up stopping lots of legitimate users who get errors when they're using the site like they should.
Client side checking is ONLY meant to be nice to the end user, to give them immediate feedback. Period.
Might not be the answer you like, but it is the answer. :)
Edit: One last comment. Let's say you did make it REALLY hard. Would you then not do server side checking? Would you say to your boss, "Oh, we made it pretty hard to hack on the client side. They still can. We just made it hard. So no need to do server side checks." Of course not. So, if you're doing server side checks no matter what, you don't gain anything from trying to obfuscate on the client side.
I have a simple textarea which people can insert a paragraph of text. A user doesn't have to be logged in to submit, and the submit will be displayed in the browser straight away.
My question is around validating the text in the client. I am planning to use .allow then insert in the client. What is the best way to check that the text is not something which will do something harmful in the database once the data is committed?
I am new to web development, so I am not sure if anyone can write some harmful text which when submitted will delete the entire database once it is inserted, or do something else harmful.
It may be impossible, but I was wondering if anyone checked the schema for anything harmful before submitting.
I think this is really two questions.
One: Can someone insert malicious text into the database (like SQL injection)?
The answer to this is no, nothing they write can get directly executed. For instance, they could enter the text: "function(){ /do some naughty things/ }", which would just end up as a string in whatever document you store it in.
Two: How do I validate data before inserting into the database?
Regardless of whether query injection attacks are a significant risk or not, any web-application should always expect and deal with bogus form entries. In terms of validation, you have a lot of options out there. My personal favorite is Collection2, which will automatically validate all data against a schema you define when creating the collection.You can easily define min/max lengths, type restrictions, or use the custom option to define a custom function to validate a field. This is a really easy way to make sure all your data get's validated before inserting into the database.
I'm initiating my first start-up. I can't stand attempting to read captchas when signing up for websites, don't want my users to. I looked for alternatives, and I found the checkbox captcha. How is this done, using JavaScript to load a checkbox, and validate it with the same code as would normally be used to make a sign up form?
Thanks.
I looked at the example linked from the article you posted. At first glance, it seems like this can be easily bypassed.
The checkbox captcha works on the basis that spam-bots don't parse or use JavaScript code embedded in webpages. Because of this, they will not find the captcha checkbox element within the form it is searching, and therefore will not send a post value for the checkbox along with the form, and on the server side, you would reject the form if the checkbox value wasn't sent.
The problem with this is:
The checkbox name is always the same (gasp_checkbox)
A bot could easily be "trained" to detect this javascript on your page and act accordingly
Even if you output a random name and value that must be used for the checkbox, it could still be detected
The outcome of those 3 problems means that this is much easier to break than image captchas or other methods. All a bot has to do when they submit your form is add: gasp_checkbox=on to their HTTP request.
That said, if you implement this for yourself on your own site, it is unlikely that any bots will able to get past it because its use is not widespread.
You could make it more secure by doing the following:
Generate unique name/value pairs for the checkbox on the server side, and output those values in obfuscated javascript to the client
Serve the script away from your form, preferably in an external javascript file that is generated by a script.
Verify that the values sent for the checkbox match a pair that was previously generated, and not used before.
If you do those things, I think you could have an effective checkbox captcha. If someone does catch on to it on your site, it may still be trivial to defeat, even with the above safeguards in place, but it may take a while, and still be effective for you most of the time.