I'm building a to-do list and one of the problems I'm facing is verifying that the correct to-do is checked off. I thought of using unique IDs for each and every to-do but a user can simply change the ID to that of another task. What can I do to make sure that the user does not temper with the checking off of tasks?
My flawed process:
User checks off task --> get task ID --> match ID on the backend
EDIT:
All the tasks are created beforehand. And user does not have the ability to create new ones.
If this is ever touching your backed server, you should always assume your users are sending you garbage data or trying to hack your system.
In short: Always Validate Inputs from an untrusted source.
Some languages, i.e., C#, offer model validation as part of the processing pipeline, so some initial model validation by the time it reaches your action/controller.
In this case, the user sends you an ID and an action to do with the task:
{
Id: "15f52b9f-3a09-4e56-adcf-c837ca4c92eb",
Status: "completed"
}
You should validate:
The Item Exists.
The item belongs to the user
The user has permission to edit this item
The status is a valid type (they could send you "blah" as a status)
If any of these fail, you send an error message to the user (or 400 error and a message telling them whats wrong)
Edit: After reading some comments below:
There is one simple rule. Never trust the user, the user input or anything you cannot 100% control.
In the world of web, never trust anything in, around, or sent from the browser. The user has complete control over it including cookies, DOM, localstorage etc.
When handling user input, always validate it on the server no exceptions.
You can always double validate, i.e., validate on the client side and on the server side, but the client side is limited to basic business rules of the data or data format (example, MM/DD/YYYY format for dates or numbers must be less than 1000)
You can do them on the front end, but you STILL need to validate them on the back end.
Seeing as the tasks are created before hand then each should be handed a unique Immutable ID. To implement this in Javascript use:
Object.freeze()
According to Mozilla Developer Network:
The Object.freeze() method freezes an object: that is, prevents new properties from being added to it; prevents existing properties from being removed; and prevents existing properties, or their enumerability, configurability, or writability, from being changed, it also prevents the prototype from being changed. The method returns the passed object.
A link to the documentation is here
Related
In my project a user can make a post (post a photo or some text). Technically I identify each post with a unique id in table posts where I store the user_id (owener of the post) and the id of the post is set to auto increment . Knowing the identification for each post I fetch all rows in the post table and put these post and relevant details( post_id, user_id, data, etc) inside an HTML. There are more things a user can do on that post, like discuss on the post, rate the post, and etc.
These things are done via an ajax post since I store the post_id on the HTML element attribute like ( data-p=52). sometimes I use the php base64_encode function to encrypt the post_id
Most in my application an event is acted on these post_id and user_id that is or are stored in the HTML custom attributes.
Now I am thinking of security issues and my question is : Is there a proper method or way I can hold these info in Javascript or a proper way I can encrypt these information about the post.
It is good you are thinking about the possible security vulnerabilities within your system. However, at the moment, from what I can tell, you are not quite worrying about the right thing. Data, like a user's ID, a post's ID, is not sensitive in itself. If you look at the URL of social networks, etc, it is very likely you will see user ID information, etc. What you need to think about, is how can I make sure that it doesn't matter this data is public? In other words, how can I prevent an attacker from using this data? Because this data on it's own, is just a bunch of numbers. Now, if there is a reason why these IDs are actually sensitive in your system, you should think about a slight structural rearrangement.
Take the common (or less so these days) SQL Injection technique. Where a attacker will input SQL code into a user input, and that input will then be concatenated/substituted right into a SQL query, therefore giving unwanted access to the database (see here http://www.w3schools.com/sql/sql_injection.asp). It does not matter the attacker knows the post ID, meaning oh no! He can delete the post he wants to, instead, it matters that he can delete any post he wants. So the problem is in the SQL vulnerability, not the knowing of the ID. And, to fix the SQL vulnerbabilty, you need to make sure that user input will disallow code-like characters. This is known as sanitization.
Of course I am not saying you shouldn't take care of what data is available to users. But the system itself needs to be robust.
The scenario you're worried about (that an attacker can use these IDs to send requests to your system to manipulate data in a way that you don't want) is independent of whether you expose your IDs to the client or not.
In some fashion, requests from your client will need to be handled by your server. If you have a feature where authors of posts can delete their own posts, hopefully you are validating delete requests that the user initiating the request is actually the owner of that post and not just blindly deleting data whenever someone asks your system to. Even if you introduced a surrogate key so as to prevent the actual primary key from leaking to the public, whatever route endpoint that is used to delete posts will still need to handle that data in a robust fashion that maintains the integrity of your data.
As I stated in a comment, really the only thing you should worry about are people performing maths on your IDs (such as plus and minus 1) in order to see if they can game your system and receive data back that maybe they shouldn't have. But even in that scenario whatever endpoint is responding to the request should validate that request before returning anything back. You can prevent this entirely by a) validating that the user requesting the data actually owns the data and b) by not using auto incremented integers as a primary key and instead relying on UUIDs as your primary keys.
Is it recommended to make all the necessary input validations in client side? I want to optimize the processing of the server (meaning lesser double validation so that the programmer may focus only to business logic).
Example:
On the client side, there's an 'Age' input textfield (JavaScript will not allow to submit the form unless it's within the range)
On the server side, there's no more validation of the 'Age'
// instead of validating again the age
int age = Integer.parseInt(request.getParameter("age"));
// check age if valid
if(age >= 0 ) { /* codes * / }
We can instead proceed only to
int age = Integer.parseInt(request.getParameter("age"));
because we are very sure that it is valid.
To accommodate disabled JavaScripts in Web browsers, we need to check first. If JavaScript is enabled, proceed to the application, otherwise block the application. (Just like Facebook)
Is my theory / concept acceptable?
If you need to enforce certain input patterns, you cannot rely on data that comes from the client. Folks can disable JavaScript, or simply bypass your validation completely and send whatever data they want. However, most casual users will not have this problem, and the data is coming from the client anyway.
In short, it depends.
For most of my applications, I have client-side validation and only worry about some things server-side that can throw an error condition. For example, if I have a form that sends an e-mail to someone, I will have JavaScript that checks for a valid to: e-mail address, and alert the user. Server-side, if that e-mail address isn't valid or isn't present, I will simply throw an error writing code to let the user nicely know something has gone wrong. For the message body, I'll validate client-side whether or not it has one, but server side I won't really care. Again, what you do depends on your needs.
I believe in validation EVERYWHERE
I like to have client side validation for:
required fields populated
minimum size fields (like zip)
Regex for proper character types in proper locations (eg social security numbers, new passwords, etc)
privilege enforcement (users can only see and do what their role should be allowed to)
Server Side validation for:
all client side requirements
entity associations (child-parent relationships are legit)
changes or requests are Role-Authorized
User Entry is the enemy! Users will find a way to break your site willingly or un-willingly. Things will fall through the cracks. So I strongly endorse double and triple checking.
I would believe in client side validation to save server processing, if it NOT for my fear that this kind of thinking will make me exceptions more prominent.
Overall, the reasons why I value rich Client side validation are:
one more level of checking data integrity (as well as server side)
guiding users; intelligent client side validation makes helps users make more efficient answers quicker
a better experience; If users don't have to wait for the loop back to server and returned to client to see their errors, their user experience should be better.
If security / data integrity is a concern, I would advise against this. While it'll be enough to prevent Joe Smith from entering unwanted data, you'll leave your system open to serious data manipulation from people who understand how the web works.
Let's say you have a voting system like on StackOverflow where anytime a user votes, an AJAX call is made. While the JS validation may prevent a person from using the displayed HTML to cast multiple votes on the same question or answer, it will not prevent a user from going into their browser's console and manually submitting POST or GET requests to get around the JS validation. Before you know it, you'll see Lloyd Banks with 100k reputation after answering just a few questions
I am completly new to jquery and client side programing. I am trying to figure out a way of achiving this:
On the client side I have a hidden user id/profile id, which I wanna to encrypt, but while manipulating the hidden value, I have to decrypt and perform some operation on it.
I have a global array of arrays like below:
var users=[{"u_id":"1234", "u_name":"Test"},{"u_id":"12345", "u_name":"Test1"}];
this array is used by various other compoenets, e.g. when user mouse-over on the profile-id, it will get the details from the above array and display the result to him.
In short, I want to encrypt/decrypt all my global variables inside the script.
any plugin or ways to do will be highly appricated.
Encryption/decryption on the client side is entirely pointless. Encryption is used to hide something from somebody. For that you need a secret (password etc.) that you're not giving to that somebody.
If you want to encrypt and decrypt something on the client, the client will need the secret in order to do the encryption. Therefore, the client has everything it needs to decrypt any encrypted secret. That means any user has everything he needs to decrypt data and can in fact see the process happening (try breakpoints in your browser's Javascript debugger). Therefore, the entire exercise is by definition pointless. It may deter some very unskilled poker-arounder, but anyone with the skill to actually do something with the decrypted data can get it easily.
#deceze: Yes exactly, the example you have posted, lets say user 42, trying to update his age, basicaly user will see 42 as his profile id when he logsin, and then subsequent call he will make for changes he need to pass sessionkey/apikey along with profile id and data, so basically if you will suggest me how I can manage these sessionkey/apikey, so that user/hacker from outside can't missuse.. – Jayaram Pradhan 1 min ago
It's pretty simple:
Require users to be logged in via a regular login mechanism, typically involving a session id. This session identifies the user as securely as it's feasible to do anything securely over the web. Your security focus must be here.
Knowing who the user is, you can validate any and all of his actions. If the user requests to change the profile information of some user, check whether he's allowed to do that or not. No API key or anything needed. The server receives a request for change, the server knows who the requesting user is by the session, the server can decide to accept or reject the request.
In the concrete case of updating one's own profile, if the user is only allowed to update his profile and his profile alone: there needs to be only one action/URL, when a user POSTs data to that action, the server knows who the user is and updates that user's profile. The user doesn't need to submit a user id of the profile he wants to update, in fact he can't submit a user id, only his profile will ever get updated. There's no publicly accessible action that allows him to update anyone else's profile.
There is no 3.
i know no way to perform this on client side, you can serialize and obfuscate the data (like using base 64 encoding on json string).
I'm trying to figure out a good way to prevent bots from submitting my form, while keeping the process simple. I've read several great ideas, but I thought about adding a confirm option when the form is submitted. The user clicks submit and a Javascript confirm prompt pops up which requires user interaction.
Would this prevent bots or could a bot figure this out too easy? Below is the code and JSFIddle to demonstrate my idea:
JSFIDDLE
$('button').click(function () {
if(Confirm()) {
alert('Form submitted');
/* perform a $.post() to php */
}
else {
alert('Form not submitted');
}
});
function Confirm() {
var _question = confirm('Are you sure about this?');
var _response = (_question) ? true : false;
return _response;
}
This is one problem that a lot of people have encountered. As user166390 points out in the comments, the bot can just submit information directly to the server, bypassing the javascript (see simple utilities like cURL and Postman). Many bots are capable of consuming and interacting with the javascript now. Hari krishnan points out the use of captcha, the most prevalent and successful of which (to my knowledge) is reCaptcha. But captchas have their problems and are discouraged by the World-Wide Web compendium, mostly for reasons of ineffectiveness and inaccessibility.
And lest we forget, an attacker can always deploy human intelligence to defeat a captcha. There are stories of attackers paying for people to crack captchas for spamming purposes without the workers realizing they're participating in illegal activities. Amazon offers a service called Mechanical Turk that tackles things like this. Amazon would strenuously object if you were to use their service for malicious purposes, and it has the downside of costing money and creating a paper trail. However, there are more erhm providers out there who would harbor no such objections.
So what can you do?
My favorite mechanism is a hidden checkbox. Make it have a label like 'Do you agree to the terms and conditions of using our services?' perhaps even with a link to some serious looking terms. But you default it to unchecked and hide it through css: position it off page, put it in a container with a zero height or zero width, position a div over top of it with a higher z-index. Roll your own mechanism here and be creative.
The secret is that no human will see the checkbox, but most bots fill forms by inspecting the page and manipulating it directly, not through actual vision. Therefore, any form that comes in with that checkbox value set allows you to know it wasn't filled by a human. This technique is called a bot trap. The rule of thumb for the type of auto-form filling bots is that if a human has to intercede to overcome an individual site, then they've lost all the money (in the form of their time) they would have made by spreading their spam advertisements.
(The previous rule of thumb assumes you're protecting a forum or comment form. If actual money or personal information is on the line, then you need more security than just one heuristic. This is still security through obscurity, it just turns out that obscurity is enough to protect you from casual, scripted attacks. Don't deceive yourself into thinking this secures your website against all attacks.)
The other half of the secret is keeping it. Do not alter the response in any way if the box is checked. Show the same confirmation, thank you, or whatever message or page afterwards. That will prevent the bot from knowing it has been rejected.
I am also a fan of the timing method. You have to implement it entirely on the server side. Track the time the page was served in a persistent way (essentially the session) and compare it against the time the form submission comes in. This prevents forgery or even letting the bot know it's being timed - if you make the served time a part of the form or javascript, then you've let them know you're on to them, inviting a more sophisticated approach.
Again though, just silently discard the request while serving the same thank you page (or introduce a delay in responding to the spam form, if you want to be vindictive - this may not keep them from overwhelming your server and it may even let them overwhelm you faster, by keeping more connections open longer. At that point, you need a hardware solution, a firewall on a load balancer setup).
There are a lot of resources out there about delaying server responses to slow down attackers, frequently in the form of brute-force password attempts. This IT Security question looks like a good starting point.
Update regarding Captcha's
I had been thinking about updating this question for a while regarding the topic of computer vision and form submission. An article surfaced recently that pointed me to this blog post by Steve Hickson, a computer vision enthusiast. Snapchat (apparently some social media platform? I've never used it, feeling older every day...) launched a new captcha-like system where you have to identify pictures (cartoons, really) which contain a ghost. Steve proved that this doesn't verify squat about the submitter, because in typical fashion, computers are better and faster at identifying this simple type of image.
It's not hard to imagine extending a similar approach to other Captcha types. I did a search and found these links interesting as well:
Is reCaptcha broken?
Practical, non-image based Captchas
If we know CAPTCHA can be beat, why are we still using them?
Is there a true alternative to using CAPTCHA images?
How a trio of Hackers brought Google's reCaptcha to its knees - extra interesting because it is about the audio Captchas.
Oh, and we'd hardly be complete without an obligatory XKCD comic.
Today I successfully stopped a continuous spamming of my form. This method might not always work of course, but it was simple and worked well for this particular case.
I did the following:
I set the action property of the form to mustusejavascript.asp which just shows a message that the submission did not work and that the visitor must have javascript enabled.
I set the form's onsubmit property to a javascript function that sets the action property of the form to the real receiving page, like receivemessage.asp
The bot in question apparently does not handle javascript so I no longer see any spam from it. And for a human (who has javascript turned on) it works without any inconvenience or extra interaction at all. If the visitor has javascript turned off, he will get a clear message about that if he makes a submission.
Your code would not prevent bot submission but its not because of how your code is. The typical bot out there will more likely do an external/automated POST request to the URL (action attribute). The typical bots aren't rendering HTML, CSS, or JavaScript. They are reading the HTML and acting upon them, so any client logic will not be executed. For example, CURLing a URL will get the markup without loading or evaluating any JavaScript. One could create a simple script that looks for <form> and then does a CURL POST to that URL with the matching keys.
With that in mind, a server-side solution to prevent bot submission is necessary. Captcha + CSRF should be suffice. (http://en.wikipedia.org/wiki/Cross-site_request_forgery)
No Realy are you still thinking that Captcha or ReCap are Safe ?
Bots nowDays are smart and can easly recognise Letters on images Using OCR Tools (Search for it to understand)
I say the best way to protect your self from auto Form submitting is adding a hidden hash generated (and stored on the Session on your server of the current Client) every time you display the form for submitting !
That's all when the Bot or any Zombie submit the form you check if it the given hash equals the session stored Hash ;)
for more info Read about CSRF !
You could simply add captcha to your form. Since captchas will be different and also in images, bots cannot decode that. This is one of the most widely used security for all wesites...
you can not achieve your goal with javascript. because a client can parse your javascript and bypass your methods. You have to do validation on server side via captchas. the main idea is that you store a secret on the server side and validate the form submitted from the client with the secret on the server side.
You could measure the registration time offered no need to fill eternity to text boxes!
I ran across a form input validation that prevented programmatic input from registering.
My initial tactic was to grab the element and set it to the Option I wanted. I triggered focus on the input fields and simulated clicks to each element to get the drop downs to show up and then set the value firing the events for changing values. but when I tried to click save the inputs where not registered as having changed.
;failed automation attempt because window doesnt register changes.
;$iUse = _IEGetObjById($nIE,"InternalUseOnly_id")
;_IEAction($iUse,"focus")
;_IEAction($iUse,"click")
;_IEFormElementOptionSelect($iUse,1,1,"byIndex")
;$iEdit = _IEGetObjById($nIE,"canEdit_id")
;_IEAction($iEdit,"focus")
;_IEAction($iEdit,"click")
;_IEFormElementOptionSelect($iEdit,1,1,"byIndex")
;$iTalent = _IEGetObjById($nIE,"TalentReleaseFile_id")
;_IEAction($iTalent,"focus")
;_IEAction($iTalent,"click")
;_IEFormElementOptionSelect($iTalent,2,1,"byIndex")
;Sleep(1000)
;_IEAction(_IETagNameGetCollection($nIE,"button",1),"click")
This caused me to to rethink how input could be entered by directly manipulating the mouse's actions to simulate more selection with mouse type behavior. Needless to say I wont have to manualy upload images 1 by 1 to update product images for companies. used windows number before letters to have my script at end of the directory and when the image upload window pops up I have to use active accessibility to get the syslistview from the window and select the 2nd element which is a picture the 1st element is a folder. or the first element in a findfirstfile return only files call. I use the name to search for the item in a database of items and then access those items and update a few attributes after upload of images,then I move the file from that folder to a another folder so it doesn't get processed again and move onto the next first file in the list and loop until script name is found at the end of the update.
Just sharing how a lowly data entry person saves time, and fights all these evil form validation checks.
Regards.
This is a very short version that hasn't failed since it was implemented on my sites 4 years ago with added variances as needed over time. This can be built up with all the variables and if else statements that you require
function spamChk() {
var ent1 = document.MyForm.Email.value
var str1 = ent1.toLowerCase();
if (str1.includes("noreply")) {
document.MyForm.reset();
}
<input type="text" name="Email" oninput="spamChk()">
I had actually come here today to find out how to redirect particular spam bot IP addresses to H E L L .. just for fun
Great ideas.
I removed re-captcha a while back converted my contactform.html to contactform.asp and added this to the top (Obviously with some code in between to full-fill a few functions like sendmail, verify form filled out completely etc.).
<%
if Request.Form("Text") = 8 then
dothis
else
send them to google.com
end if
%>
On the form i stuck a basic text field with the name text so its just looks like anything not specifying what its for at all, I then stuck some text 2 lines above in red that states enter what 2 + 6 = in the box below to submit your request.
I'm not sure what is the best practice.
I have some big and complex objects (NOT flat).
In that object I have many related objects - for example Invoice is the main class and one of it's properties is invoiceSupervisor - a big class by it's own called User.
User can also be not flat and have department property - also an object called Department.
For example I want create new Invoice.
First way:
I can present to client several fields to fill in. Some of them will be combos that I will need to fill with available values. For example available invoiceSupervisors. Then all the chosen values I can send to server and on server I can create new Invoice and assign all chosen values to that new Invoice. Then I will need to assign new supervisor I will pull the chosen User by id that user picked up on server from combobox. I might do some verification on the User such as does the user applicable to be invoice supervisor. Then I will assign the User object to invoiceSupervisor. Then after filling all properties I will save the new invoice.
Second way:
In the beginning I can call to server to get a new Invoice. Then on client I can fill all chosen values , for example I can call to server to get new User object and then fill it's id from combobox and assign the User as invoiceSupervisor. After filling the Invoice object on client I can send it to server and then the server will save the new invoice. Before saving server can run some validations as well.
So what is the best approach - to make the object on client and send it to server or to collect all values from client and to make a new object on server using those values ?
Think in terms of complexity of your business processing.
What you need is the client creates a new invoice. To do this, the client provides several different input parameters, calls the process and gets the response. This is your first scenario. Simple and clear.
On the other hand, the second approach involves a communication protocol - give me this, I give you something as a response, then give me something else. This sounds unreasonably complicated. You'd have to carefully inspect what happens when the communication breaks at some point. Should a distributed transaction be involved? If yes, do you really need such complexity?
I would opt then for the first scenario. You don't unnecessarily complicate the contract between the client and the server.