Should I add protections where I dont understand how hacker can break system?

Question

Lets say there is an AJAX application where the user can submit items - buy them.

And there was a code

IF ($_POST[items] > 20) {
   echo 'error';
}
else {
   do_buy($_POST[items]);
   echo 'success'
}

Here, there is a check if items is not more than 20. On client side, it should not be possible to choose more than 20 items.

The system would work without problems even if 21 (or more) items were submitted (the user would simply pay for each item). While I realize you must want to yell don't trust the client, is there any harm in doing so if there are no consequences, as is the case here?

One could make the argument that overloading the cart might cause instability in the system but it seems as though the worst case would be that some script times out. If errors are disable, the user will just not get back any response.

In general: Does it make sense to code protections for an attack which violates an invariant of your system?

Update:

$_POST['items'] I meant that is array, not an integer. And each item how own properties - id and quantity, which are checked later before completing the buy operation.

About sql injection - I usually use frameworks, and they take care of injection protection.

Update

One more reason why I ask this is I want as much clean code as possible and also when someone reads it - will think why the hell this is needed, this programmer does not know what he is programming and why. So for all code I want to have clear reason why that piece of code exists and so if not in comment, then at least myself that I would have clear understanding why I make this check so I could explain if another programmer asks.

Answer 1

Yes, you should add protections, but they need to be appropriate for the situation.

All user input must be validated. The fundamental principle is that you do not define what "bad" input is, you define what "good" input is and reject everything else. To take your example, you've defined "items > 20" as bad. But what if "items" is -1? What if it's the quantity );DROP TABLE Orders;--?

The basic technique is that you look at each user input field and define what a "good" value looks like, taking into account both your software's capabilities and your business rules. For example, "items" might be "an integer, greater than 0, less than 20, and less than or equal to the amount in stock" -- this rejects too-large orders, too-small orders, and exotic inputs such as SQL injection, without needing to worry about what an attacker might be trying to do or how your software might react.

This must be done server-side. Client-side validation is there to help the honest user; a dishonest user can only be stopped server-side, since they control the client.

To use your house analogy, all user input is part of the door.

Answer 2

You can't always know how things really can go bad. In your current example the attacker can send a very large value causing an arithmetic- or stack overflow or an unhandled exception causing the server to shut down and lead to an availibility problem.

So always do the checks, always consider the worst can happen and think of the attacker as someone who is capable of doing "anything". Always make white lists, not black lists. At list consider the standard attack methods (XSS, CSRF, Injection, etc) and check the ranges.

Seal the doors and windows as tight as you can and always review your design, your code AND your environment.

Answer 3

Short answer: no, and take a crash course on security urgently if you're making a sales website!

You should not add arbitrary restrictions and checks and "protections" just because you don't know what's going on. If you do that you're more likely to add problems and leave security vulnerabilities open than anything. Obviously, the reason why there are security professionals is because they're trained to identify the needed protections.

Start by defining the assets in your system, both yours and your clients'. You need to know what's valuable because this is what hackers will come for. It includes personal data, data of a financial value (bank account information, etc.), the goods you sell, your clients' computers (which can be used in a botnet in case of e.g. cross-site scripting attacks) and also your own server, database, and Web server.

Once you know what's there to protect, you need to define what needs to happen to it for your system to function properly. Essentially you need to list what you allow your clients to do on your website. For instance this arbitrary 20 items limit is completely unjustified.

The second step will be to understand who your adversaries could be and what they can do. Be creative but stay realistic. You're less likely to interest the NSA than a lone financially-interested hacker for a sales website. This process is called threat modelling. You must:

• define your adversaries for each asset
• define their capabilities (which requires a lot of security knowledge)
• define the threats to your assets (what can those capabilities allow an attacker to do to you)

Now that you know what could happen to you, you need to define the Security Properties that must hold on your assets, and you must then choose the mechanisms that guarantee those properties. Those mechanisms, in turn, become critical assets of your system that must equally be protected. This is referred to as a Trusted Computing Base.

When you're there you can start about thinking moving to beta. You'll have to evaluate your security, through penetration testing usually done by a third-party company. But that should already keep you busy ;)

Edit: please do spend some time reading up the most common software programs that turn into vulnerabilities. Allowing users to purchase more than 20 items isn't one of them.

Answer 4

If some malware on the user side makes the client buy 2 millions of items on your site, and your site performs the transaction without raising any alert, then some people, in particular the defrauded customer, may complain quite loudly and assert that your server is a bit lax. It could be argued (in court !) that you would be at fault for not making some "sensible" checks. There may even be some applicable regulations that mandate doing some server-side verifications (at least banks make checks for "abnormal activity" on credit cards and block transactions which look particularly weird).

In the general case, adding extra checks for abnormal situations is sane programming practice. You know that the client side should not allow for more than 20 items. If some bug on the client side interface allows a client to put 21 items, then it should be fixed, and it will be easier if you are warned about it as soon as possible, e.g. with a server-side check.

(There is a dark side to it, though: if you add the check on the server side, then later on decide to raise the limit to 25, you have to modify the client and the server. This should, however, be easily detected during pre-deployment tests, so don't refrain from adding sanity tests.)

Answer 5

Only addressing the first question, which is essentially "Is it okay to code client-side validation?".

Yes its a good user experience, immediate feedback is nice. Client-side validation isn't actually security however, its more of a convenience. Its purpose is to speed up the process, to put the form in a state that will pass validation.

As you probably know, client-side validation should always be secondary to server-side validation. If the client-side and server-side validation mismatch, the server is ultimately the source of truth. If the server doesn't validate it, then it isn't really being validated.

Anyways, yes, client-side validation is perfectly legit and is a big improvement in UX.

And for sql injection protections, it sounds like you're already treating user input as hazardous materials there and scrubbing it with a tried and trusted framework, so you're good to go there. Just be wary of anything derived of user input, not just when saving/updating. Even other variables/logic can be manipulated by user input if they have intimate knowledge of your system.