1

Our company provides omnichannel (web, mobile, etc.) solutions for the banking industry.

One of our customers is pushing for obfuscating or encrypting the contents of the form fields (client-side, on the fly) in its HTML apps (ie. web banking), they argue that this prevents users from "seeing" the field values when inspecting the web page using Firebug and similar tools.

I cannot see or imagine a valid reason for this. Can anyone argue in favor of this?

  • 1
    Surely anyone who was in a position to look at the form fields has just put whatever is in them, in them? – Matthew Apr 4 '17 at 12:58
  • Yes, exactly my reasoning. It serves no real purpose if the app is properly designed. – Ricardo Zuasti Apr 4 '17 at 13:18
  • 2
    In response to "this prevents users from "seeing" the field values", did you ask "... and why do you want to do that?" Always bring it back to the threat model, what risk they are mitigating, etc. Otherwise its just throwing gold dust in the wind. – AviD Apr 4 '17 at 13:55
  • It sound more like they are trying to prevent CSRF attacks which seems easier to just use a token. – Shane Andrie Apr 4 '17 at 16:06
2

I can absolutely see the value in this: if you are supplying sensitive information to the client-side that you hope the client never sees.

One used to see this when you had hidden form fields, like "sale_pct". If a user was able to see that field, they could modify the sale price, and potentially buy product at a negative price. Don't laugh. It happened.

The much, much, MUCH bigger question is why one would rely on obscurity on the client side at all. Don't send it to the client if you don't want them to see it. But maybe the business has a legitimate reason to rely on this ... I doubt it

  • I agree with you in the case the app sends sensitive data to the browser and then relies on it when posted back to the server. But this is a bad app design, you shouldnt do it and can avoid it in every use case scenario. – Ricardo Zuasti Apr 4 '17 at 13:20
  • Right, so the real question is: what is your client sending to the browser and what happens if users see it? – schroeder Apr 4 '17 at 13:21
  • 3
    this is a joke, what you mention is client-side validation only (instead of server validation) which is just entirely unsecure. A good design would mitigate that quite easily – niilzon Apr 4 '17 at 14:13
  • @niilzon exactly - that is my entire point. If they require client-side validation, then they would also require obfuscation and encryption. But they shouldn't be relying on client-side validation. They shouldn't be using client-side validation, but if the reality is that they are, then there is a use case. – schroeder Apr 4 '17 at 14:25
  • how dows "Don't send it to the client" jive with "the value in this"? – dandavis Apr 4 '17 at 18:10
1

From a security standpoint, I can't think of a single reason this actually adds any security to the design. As @schroeder pointed out, any design in which you're passing information to the client that you don't want the client to see, is data that can stay on the server and be processed there instead where it's "safe".

My suspicion is that they are really asking for fields to be masked so people cant screen look at their customers' information. I've been requested to do similar to a health information system, and it ultimately came down to non-technical people throwing around technical words that didn't actually describe their need.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.