-2

As I was working on upgrading deprecated ereg_replace() statements in an e-cart sollution I was suddenly puzzled by questions regarding how to handle the submitted data I was working with.

I was working with the add to card function, which from the backend perspective recieves an integer for how many products to add to the cart. As this number is submitted from the website its open for tampering so the data was sanitized before passed to the function. Great - no worries. However, I was wondering...

Train of thought... no sanitization needed!

We are all good people and wish no harm upon others. I am the creator of this e-commerce website so I have delivered the HTML for the form which will always return a number, this means that I should not need to sanitize the number at all I could infact drop trimming the value aswell - something I have a bad habbit of doing by default. However... we do not live in Utopia...

What if there was a problem with the data, just in case? I should make sure the data is proper so that I dont crash anything which would make me look stupid. Should't I do it anyway I think? After all the world does not work the way this train is going...

Train of thought... validating is the answer

In a production environment things are working, atleast they are supposed to do and they have to as anything else would make it unstable. This I guess is crutial for an add to cart functionality so I think I am allowed to think in black and white.

I can assume two possible states of the system, it is either working or broken. If the number submitted does not equal a number which I can typecast to an integer for safe measures after detection I must assume the system is being tampered with. The only other assumption to me has to be the system is full of errors and for the same reason It shouldnt be running at all.

Train of though... 410 Gone

Wouldnt it be better to halt or kill the entire session / IP if such a scenario exists? What is the business practise around for handling errors when sanitizating data? Is this when you fire up the honeypot-collector and proxy the user session to your dev-server for direct analyzis?

There cannot be any reason to keep going I am thinking If I detect anything else than a number in the submitted string? Broken system has no reason to continue I am thinking?

Concluding the trains of thought

Clearly one cannot and must not assume the data submitted is correct so validation of some sort has to be done. But if noone is trying to hack the system, noone is trying to alter the values then it should never be a situation where the data representing the amount is not a positive number (im using add to cart as example) - that is unless - the browser is messing up the data or maby some encoding results in wrong data or, well I do not really know.

What is the common practises to do when you detect something that has to be considered a breach of security? Or do I simply sanitize the data and pretend nothing is wrong, trying to make use of the recieved data best as possible assuming it was well intented.

This is why I wonder if I might aswell just close the session down, as any normal circumstance would never end up with wrong data. If it were the price of a product certainly one would not allow such an error and the system could not continue to operate? That is - what is the purpose of continuing when such an error is detected at all?

Thanks in advance :)

Update, clarification on people being so extremely nice and helpful :D

By no means do I belive that all people are nice or well behaved, and from a security perspective you only need one wrong to crash the system. I am also under the impression to be honest that there are lots of automated systems out there scanning the web for exploits. Dumping compendiums of hacking tactics on websites targeting a-z 24/7 for the excitement of being able to deface the site that comes up in the daily breakfast log of possible exploitable sites. I learned about Netsparker this way.

I believe I didnt ask my question correctly, I can see that from the answers given so added last point named "concluding the trains..."

Kim Steinhaug
  • 109

3 Answers3

1

We are all good people and wish no harm upon others. I am the creator of this e-commerce website so I have delivered the HTML for the form which will always return a number, this means that I should not need to sanitize the number at all I could infact drop timming the value aswell - something I have a bad habbit of doing by default.

We're not all good people, though. Plenty of people will attempt to break your system and affect your customers.

You should always assume input from the outside world is dangerous. It doesn't matter whether you encoded it onto the page or not.

I would say, on the backend, cast the value to an int and validate the int. Done.

  • Its easy to forget people are actively trying to break any systems at any time, I was trying to be ironic when writing to point out a scenario for validating data. However -I think we understand eachother. Yes, this is infact what I did - cast to int and done.And probably this is enough - as it ensures my system doesnt break so it covers my ass. But it won't let me catch the bastard nor does it block the system that clearly is breaking my system if that makes sense.On the other hand a clever hacker will always be untracable so what reason is there to try catching something you cannot? I agree. – Kim Steinhaug Apr 18 '18 at 01:03
1

The right answer depends on your client's policies. It could be a mission critical app where if anything goes wrong people die (i.e. medical systems, flight control, etc.). It could be something a little less grave, but still quite serious (i.e. where lots of money is involved). Finally, your app might be something that people use for recreation (i.e. social media). The types of controls you use and how harshly you enforce them need to be informed by the type of problem being solved.

That said, never assume everyone is nice. You only need to read youtube comments to find out that is false. Just balance risks vs reward for solution. However, there are a few things to keep in mind:

  • The server should always validate what it receives. There are too many horror stories of bad people who have "purchased" an expensive product for $1 or less just because the server trusted that the dollar price received from the browser was correct. Don't do that.
  • The browser can clean up data or help the user provide good data. It only helps you later, but the importance of this step depends on what you are doing with the data and how critical it is to the app's reason for existing.
  • Your application should be able to track who is doing what. That way if you do find a bad person, you have a means of building up your case to terminate their account (or press formal charges if their actions are illegal). The granularity of that tracking depends on policies, and what your client cares about.

Beyond that, you need to discuss the controls with your client. There's always a tradeoff. The more strict you make the application, the fewer people will want to use it. Obviously harsh actions like terminating a session or preventing access to your application need to be justifiable in some way.

That's all policy.

Berin Loritsch
  • 46,104
  • Check update :) Very interesting point on the tracking. As for the justification part I was wondering if detecting errors in the submitted data as justification enough. If a system is running in a way it isnt supposed to do - what is the justification to even continue - think of all the problems one could have missed now that one problem is detected. But I understand this is something that should be discussed with the client, and until then your three points will be more than enough for a good system in place where its possible to backtrack. Thanks. – Kim Steinhaug Apr 18 '18 at 00:55
  • @KimSteinhaug, that tracking usually is an audit log of the application functions that someone is using. Sometimes it takes a bit of recording to tell the difference between someone who accidentally clicked on a link to do something they weren't supposed to be able to do, and someone who is systematically testing your application for vulnerabilities. Audit logs help determine what people are doing, and are essential forensic evidence if you ever need to take someone to court. There are tradeoffs, and you and your client need to agree on what's right for this app. – Berin Loritsch Apr 18 '18 at 12:34
  • It also may not be necessary if your app is purely for entertainment value. – Berin Loritsch Apr 18 '18 at 12:35
  • Thanks for great feedback, I have been looking at intrusion detection systems already so I believe my missing piece here is the audit layer. I like the point you mentioned with being atleast able to backtrack should there be a problem. I have concludet that killing session is over the top, if I detect maliciouis data or anomalies in data I will trigger the super-audit/intrusion system while sanitizing the data and let the system assume everything is ok. Or basically same as saying just cast number to int and be done with it - from example - just with added intrusion / audit logs. Thank you! – Kim Steinhaug Apr 18 '18 at 16:40
-1

I think it's both. If I understood you correctly, "sanitization" means - at the frontend, and "validation" is at the backend, right?

If so, there could be a big, single "message from client" validator as you mentioned in third paragraph. But how to make it.. depends on tools you use. But, imo, it's better to check (validate) once at the back-end and implement more detailed/individual checks (sanitizers) in the front-end (UI).

Michael Quad
  • 11
  • I have always made my software in this principle, checking fixing making sure everything is working. Even when things are wrong I apply fuzzy logic making sure even that works, whatever it was. Just recently I have started thinking on possible attackers. But what do you do when you - and I am thinking in the programming logic here - when you detect something that has to be wrong? I personally think that a big message sounds legit and great - down for maintenance or something. I am thinking saving the serverload from a hacker is perfectly justifiable, unless logging is more valuable that is. – Kim Steinhaug Apr 18 '18 at 01:10