I am building an appointment app where each appointment when stored in the database an ID is created to uniquely identify it.
When the user is about to delete an appointment its respective ID is sent to the server where PHP code is found with an SQL statement so that deletion takes place.
The question is if sanitizatio/validation is required here as we are not dealing here with user supplied data.
The ID is just a string,“5” for example…which increments by one every time an appointment is added to the database
What ever is used to get the particular record needs to be sanitized or use of prepared statements. The id still needs to be validated and if you think it can be altered by the user then sanitized; however, if you are absolutely sure it can’t be changed by the user it doesn’t. I have a motto, “When in doubt sanitize”.
Prepared statements certainly aren’t taking care of validation for you, but it’s more a matter of if you think it needs it. I think @Pepster has it right in “when in doubt…”
The fact that it comes from a backbone model and not a HTML form is irrelevant. What is relevant is that the client is not under your control and cannot be trusted. There is no way for the server to determine where exactly the request came from. It could be sent by your backbone client, but it can just as well be manually crafted and sent by cURL or some other HTTP client.
You control the server. The business logic is on the server. You must validate and sanitize any and every input coming from outside. There is a reason why injections are #1 in OWASP top ten list.
Nope, you should validate the ID, not sanitize it.
Validation is binary, the answer is either yes or no. Sanitization is different. It never gives you a “no”. It cleans up the data and moves on to work with it.
When you need a valid ID to perform some action on behalf of the user you must be absolutely sure that the data is correct. You cannot be sure that your sanitization code cleans up the data correctly in all circumstances. It is especially important in your case when you try to do something destructive like deleting data. Until there is no doubt that the data provided is correct and the user is authorized to make a request with that data your back-end must refuse to do anything with it.
I would imagine you also have other fields in the appointment table to help identify the client like client_id so I would use both an appointment id and the client id. Anyone can say delete appointment id 26 for example, but having a matching client id would help identify a legitimate request. As SpacePhoenix suggested, use is_numeric on both these values before making any DB query.
Well I assume that if you are making an appointment table, there would be some field to assign who the appointment is for, i.e. a client_id, var(12). So somewhere in your system you are identifying the client, be it client logging in, a employee selecting the client etc. This client_id along with the appointment id would be sent for validation and if passed sent to query.
Using prepare statements has nothing to do with sanitizing or validating. Using prepare means you don’t need to use an OUTPUT function to escape values. Both sanitizing and validating are INPUT functions.
You validate all values entered directly by the user.
You sanitize all values not entered by the user but where there is a possibility that the value could be tampered with.
For numeric fields using is_numeric() validates it, casting it to a number sanitizes it.
So I should sanitize the data(“clean” it)…proceed with validation(is_numeric…cross check with client) and finally write a prepare statement after the above.