jimfog Posted February 11, 2015 Share Posted February 11, 2015 I am building an appointments app where each appointment is associated with an id....in the database. When an appointment is going to be deleted its ID, is sent to the server and then the PHP code handles the rest. This ID is created from the application....the question is if it is necessary to use validation rules in the PHP script in such a case? The ID is not provided by the user.... Link to comment Share on other sites More sharing options...
justsomeguy Posted February 11, 2015 Share Posted February 11, 2015 Anything sent to the server should be considered user-supplied data, regardless of how it gets sent. If you build a script that can possibly accept user-supplied input then treat it as if it was user-supplied. Link to comment Share on other sites More sharing options...
davej Posted February 11, 2015 Share Posted February 11, 2015 Tamper Data? See... http://netsecurity.about.com/od/hackertools/a/What-Hackers-Do-Not-Want-You-To-Know-About-The-Tamper-Data-Firefox-Add-on.htm Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 (edited) Ok I got the picture... The next question is how I could possibly validate this? It is just a string,,,"5" for example. I do not use any framework. Sorry...I have forgotten some staff I new about validation Ok I used a sanitize filter....what else can I do for validation? And real_escape_string also... But I do not know if these 2 are sufficient if the attacker tries to change "5" into "10" for example. Edited February 12, 2015 by jimfog Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 If the string they give you is supposed to represent a positive integer between 1 and 10000 (depending on the access rights of this particular user and their privilege level) then simply verify that it parses to a positive integer in the legal range -- using server-side code. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 If the string they give you is supposed to represent a positive integer between 1 and 10000 then simply verify that it parses to a positive integer in that range. I understand your logic but this string increases appointments increase....and there is no limit to it as you can understand. It increments by one every time a new appointment is booked. Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 If they are giving you an integer to request information on a particular appointment then you would simply make sure it corresponded to a valid appointment -- and that they had the rights to see that appointment. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 So then why are they giving you an integer? Wouldn't they merely request the next available integer? I do not understand what are you saying... First of all the user gives nothing...he does not fill anything When an appointments is created,enters the db and at that point the ID is created....which identifies uniquely every appointment. When the appointment is fetched to the client(to be displayed to the user) by the db(its ID is also fetched)-stored in a Backbone model. The user then might choose to delete the appointment at which point the ID corresponding to that appointment is sent to the database-where code resides for deletion. So...as you see this ID is not generated by the user. Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 Let's review what a hacker might want to do: 1. cause a system error -- especially if the error might reveal information about the system (such as a raw database error msg). 2. access information outside of what they should be allowed to see. It certainly doesn't matter how the ID is generated. It matters how it is used. The system generates cookies -- but a hacker can MODIFY the cookie and attempt to cause an error. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 (edited) and what is the solution.... from a developer's point of view. apart from the various available sanitize/validate functions...do I need to write some custom code here? Edited February 12, 2015 by jimfog Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 You write server-side code that... 1. does not reveal information about the system (for example any raw database error messages) 2. does not accept any external data without sanitizing and validating the data 3. does not allow a user to do anything outside their established privileges 4. records suspicious activity to a log 5. uses principle of least privilege http://en.wikipedia.org/wiki/Principle_of_least_privilege Even if your system doesn't contain any private information you still don't want it to be infected and turned into a malicious host. See... http://en.wikipedia.org/wiki/Cross-site_scripting Link to comment Share on other sites More sharing options...
justsomeguy Posted February 12, 2015 Share Posted February 12, 2015 The solution is authorization. You need to be able to look up in the database to verify that the particular user is authorized to take whatever action they are trying to take. In that case, you need to verify that they are allowed to delete that item. Authorization should be just as much a part of application security as authentication. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 The solution is authorization. You need to be able to look up in the database to verify that the particular user is authorized to take whatever action they are trying to take. In that case, you need to verify that they are allowed to delete that item. Authorization should be just as much a part of application security as authentication. Τhat is just a privilege issue....I am talking here about server-side code and what that might be. Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 I am building an appointments app where each appointment is associated with an id....in the database. When an appointment is going to be deleted its ID, is sent to the server and then the PHP code handles the rest. Going back to your original question... when an appointment is going to be deleted... Do you have multiple users? Do you want to prevent one malicious user from deleting all of the appointments? Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 Ι just want to prevent a hacker from tampering with ID.... real_escape_string and sanitization I thought it would suffice. I see that this discussion goes nowhere....my search about validation had as a result to use the above two solutions... Apart from that I do not know what else can be done. As I already said the user fills no field in this situation... Going back to your original question... when an appointment is going to be deleted... Do you have multiple users? Do you want to prevent one malicious user from deleting all of the appointments? This a scenario I had not thought....and certainly we can find numerous others....but my search here is just for some basic security foremost and when in production I see what else I can do Link to comment Share on other sites More sharing options...
justsomeguy Posted February 12, 2015 Share Posted February 12, 2015 Ι just want to prevent a hacker from tampering with ID....What do you mean by that? You can't really detect when someone changes one number to another number. What you should be able to detect is whether any given user is allowed to take whatever action they are trying to take. If all you want to do is make sure that it is actually a number then you can use intval to convert it to an integer. I'm talking about application security, authentication and authorization.As I already said the user fills no field in this situation...That is not relevant. If you are getting the value from $_POST, $_GET, $_COOKIE, etc then it is user-supplied data, those values are sent by the browser. If you're just going to trust that no one will substitute those values for anything they want just because there isn't a field on a form, then your security model is just "trust the user". That's not security. Authentication and authorization is security.but my search here is just for some basic security foremost and when in production I see what else I can doFamous last words. Remember, you can either take the time to do it right, or make the time to do it over.You need to think like an attacker. If I wanted to attack a site the very first thing I would do is use my browser's developer tools to figure out what data my browser is sending to the server (regardless of what fields appear on the page). Once I know the set of inputs that the server expects then I'll start to change them and see what happens. It is trivially easy to create a post or get request with any data I choose. Don't think that just because there isn't a field on the page then that's going to stop an attacker. It doesn't matter what is on the page, what matters is the data that the browser actually sends to the server. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 What do you mean by that? You can't really detect when someone changes one number to another number. What you should be able to detect is whether any given user is allowed to take whatever action they are trying to take. If all you want to do is make sure that it is actually a number then you can use intval to convert it to an integer. I'm talking about application security, authentication and authorization.That is not relevant. If you are getting the value from $_POST, $_GET, $_COOKIE, etc then it is user-supplied data, those values are sent by the browser. If you're just going to trust that no one will substitute those values for anything they want just because there isn't a field on a form, then your security model is just "trust the user". That's not security. Authentication and authorization is security.Famous last words. Remember, you can either take the time to do it right, or make the time to do it over.You need to think like an attacker. If I wanted to attack a site the very first thing I would do is use my browser's developer tools to figure out what data my browser is sending to the server (regardless of what fields appear on the page). Once I know the set of inputs that the server expects then I'll start to change them and see what happens. It is trivially easy to create a post or get request with any data I choose. Don't think that just because there isn't a field on the page then that's going to stop an attacker. It doesn't matter what is on the page, what matters is the data that the browser actually sends to the server. All these are helpful but they do not help solving the issue. Link to comment Share on other sites More sharing options...
davej Posted February 12, 2015 Share Posted February 12, 2015 Ι just want to prevent a hacker from tampering with ID.... real_escape_string and sanitization I thought it would suffice. There is no need to "sanitize" an integer. You simply parse it to integer. However you could have a malicious user supply any integer -- so if each user is only allowed to delete or view certain appointments then you cannot trust this integer value. --- You have not explained how your system works in enough detail for us to understand what to suggest. Link to comment Share on other sites More sharing options...
jimfog Posted February 12, 2015 Author Share Posted February 12, 2015 .... you cannot trust this integer value. And what do you suggest about it. Link to comment Share on other sites More sharing options...
justsomeguy Posted February 12, 2015 Share Posted February 12, 2015 AUTHORIZE Link to comment Share on other sites More sharing options...
thescientist Posted February 12, 2015 Share Posted February 12, 2015 I think the point your missing is that your so focused on validating the data that you're not focusing on whether or not the user actually has permissions to do what they are doing with that data. Since most applications care about interactions coming from the outside world, especially when user login / accounts are involved, things like SESSION, permissions, and user roles are created to make sure that, in this case, a person can only delete appointments from their _own_ calendar. If you all you pass is an appointment ID to the back end and just make sure it's an integer, what's to stop me from logging into your site with my own account, looking at the request in network tools, and recreating that request using something like cURL (or even just live editing IDs right on the page) to send a request with an arbitrary appointment ID that could belong to another user? Sure It may be an integer, but without authorizing my access to that appointment, you've basically created an environment where anything goes. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now