Client-side validation + Input sanitization = Intrusion Detection

[Cédric_Hebert]

Cloud applications are particularly vulnerable to intrusions via password reuse or via credentials found in a Github repository using said application. Such intrusions won't be detected by a Web Application Firewall. You may detect these as an anomalies with an Intrusion Detection System, maybe because the connection time or IP Geo-location is unusual, but the session will not be terminated automatically due to the high risk of a false positive.

Now, as attackers are likely to try escalating privileges or searching around for interesting information from this account, a better / complementary way to detect intrusion is to spread honeytokens: useless, deceptive elements such as cookies that hackers will have a hard time resisting interacting with and that normal users won't even notice. I talked about the efficiency of such a solution in my previous post, that you can find here: https://community.sap.com/t5/application-development-blog-posts/disinformation-for-the-greater-good/...

Listen, Cédric: I don't have the time!

Right. As a developer swamped with feature requests and tight deadlines, it's hard to find the time to think about which element to deploy, to assess the risk of a false positive, and to implement honeytokens in a secure way. Doubly so if your application relies on a set of central services already dealing with session cookies and with the login form, leaving not much room for your creativity.

Hopefully, there is one particular interesting case where intrusion detection can be baked in, basically for free. Let me explain:

Input sanitization

- as a good developer, you are already sanitizing your inputs (of course you do).
- this means that when you receive a malformed input, that input is dropped, protecting the backend.

For example, this /search/:id endpoint expecting a positive number will discard a request for id "-1" or for id "a". But it's unlikely that you log rejected requests, am I right? As if it gets logged, it's unlikely to be considered an intrusion attempt, as a failed search could very much be due to a botched copy-paste action.

+ Client-side validation

Now let's talk about client-side validation for a second. For a long time, I've disregarded client-side validation as a security feature since it can easily be bypassed. Too many times I've seen developers thinking they were secure, blindly trusting client input to be sanitized. But I revised my position: as a standalone feature, client-side validation is useless for security. But combined with backend-side validation, it becomes extremely potent as it removes the uncertainty of being under attack: this /search request for id "-1" cannot anymore be due to a botched copy-paste. It must come from a user purposefully probing the backend, as a non-malicious user's input will be blocked at the client side.

= Intrusion Detection

What this means is that since you're already verifying that your search id is a positive number on the backend side, then all that's left to do (if not already done) is to verify the same thing on the client side, and to log rejected requests as intrusion attempts.

But I'm not vulnerable, they said!

Why log in the first place, since the endpoint is not vulnerable? The reason is that this endpoint in particular might not be vulnerable, but what about all the other ones? Raising a security event will help dramatically to reduce this dwell time of 16 days*. With such a very low risk of a false positive, the user session can be locked immediately before the attacker can find a valid entry point. And as attackers begin to be wary of such alerts, they will have to rely less and less on bypassing client-side validation, which will be beneficial to all applications still missing proper backend-side validation.

A big benefit worth a small effort, don't you think?

* according to Mendiant: https://www.infosecurity-magazine.com/news/cyber-intrusion-detection-time/