4 ms·

Why client-side verification is bad

19 points by mopoke 15y ago

chris_engel 15y ago
This is obvious, isn't it?! Everything the user has access to can be manipulated.
- wladimir 15y ago
  You'd be surprised how many applications and web sites still rely solely on client-side validation, even these days. Either don't think at all about threat scenarios ,or they trust their "Do not reverse engineer" EULA to protect them :-)
  - chris_engel 15y ago
    wow, I suppose we shouldn't begin to talk about sql sanitation...
nodata 15y ago
Does HN use client side verification for votes? Otherwise how did this get here?
robin_reala 15y ago
Sorry, what? Client-side verification is categorically not bad. It’s when you don’t combine it with a round-trip to server-side verification that you have problems.
robryan 15y ago
Words with friends really needs both, without client side it would be tedious for attempting a word, of course this could also cut down on people trying their letters just about every way they can until they get a word.
eyalbd1 15y ago
Client side verification is good to prevent unnecessary hits on the server when the input is incorrect/incomplete , its not.. in any way.. a real input validation.
Joakal 15y ago
Client side validation is good for speed, however should not be trusted when sent to server. Server side validation is for validating such information to prevent issues. eg SQL injections.
- deno 15y ago
  But you can't trust client-side validation, unless you run the client in a DRM container (client then can just sign the request and you can assume that it executed in a secure memory, unaltered).
  - masklinn 15y ago
    Is that not exactly what he wrote?
    - deno 15y ago
      It seems I got it mixed up with a different comment. My apologies.
frobozz 15y ago
This attitude throws the baby out with the bathwater. Client-side verification is Good, it saves bandwidth and reduces annoyance to the user. Client-side verification without also checking on the server is bad. Given the example of a word game to be played on a phone. I would argue that client-side verification of valid words is vital.
- mopoke 15y ago
  The title should probably read "Why relying only on client-side verification is bad". I don't think the author is suggesting that doing client-side verification is a bad thing in itself.
  - frobozz 15y ago
    That's probably what's in the authors mind, but not what's in the article. The author is not just suggesting that client side verification is bad in itself, but stating that position quite precisely. "Why client-side verification is bad.." (rather than the title you suggest) "to my surprise discovered that it did client-side verification of the words" (rather than "...that it didn't do server side verification") However, in support of your position; in his opening paragraph, he does say "you can't rely on it to do authentication", rather than "you shouldn't use it to do authentication".
    - nhebb 15y ago
      The author wrote "A common mistake is the web site that relies on javascript". I think the key word is "rely". You either rely on something or you don't. It's not a partial measure.
    - mopoke 15y ago
      Author's comment on his site: "It's not wrong to use client-side methods to do initial validation, but it's wrong to trust that validation on the server side."
      - frobozz 15y ago
steffoz 15y ago
Validation client side is just a way to make user interaction faster. Nothing more, but quite useful, indeed.
fragsworth 15y ago
Sure, we can all poke fun at them for being stupid programmers. Multi-billion dollar company and they don't even know how to do server-side verification? LOL, we're so much better than they are! But think about it for a moment. Assuming the ideal product would have both client + server verification, it's clearly less work to only do client-side verification. The product can be released quicker. Maybe they intentionally forgo the server-side verification code until they actually get cheaters. Then they implement it before it begins to hurt their bottom line. Because what if the game was an utter failure, and never got any users? How glad would you be that you spent all that time writing the server checks for every game action?
- retube 15y ago
  Yes absolutely. Programmers/devs often get way too wrapped in doing everything _right_. But doing it right takes time and money. Commercially it makes sense to get away with the bare minimum. The holes will only be an issue if the product actually takes off.
- frobozz 15y ago
  This is a very good point. After all, it is just a game, not a banking application, and a pretty simple game at that.
kieranyo 15y ago
Surely this is just common sense at this point?
lurchpop 15y ago
it is very annoying to have to duplicate validation logic though.
dclaysmith 15y ago
"It wasn't very hard to circumvent this, resulting in a version which accepts moves like the above one.." I'm more curious as to how you go about circumventing this. I would imagine that it probably IS very hard.
masklinn 15y ago
Not bad, insufficient.
corin_ 15y ago
There was a competition for university students in the UK a few months ago from some investment company, trying to raise interest for post-grad careers with them, basically a several-stage speed test, top five speeds at the end of the time period would get to choose a prize, iPhone, cash, few other things. A friend of mine (a student) asked me if it was possible to create macros in a browser to help go faster, and since I was bored and lack morals in this area... just took a look through the JS, and fifteen minutes later and an injection for him to paste into the URL bar and skip through each stage, making the game think he had completed it, as fast or slow as he wanted. So he got a free iPhone.
andrewcooke 15y ago
(thinking more about web pages than apps here) are there any frameworks that let you re-use the same verification code on both client and server? i'm imagining some way to decouple the validation from the presentation and then run the validation part on both sides - i don't see why this wouldn't be possible with something like Node.js. related, i guess that some frameworks (particularly ajax) support duplicating validation on client and server by automatically generating (different) client (javascript) and server-side code (python/ruby/java/...) from simple specifications (eg regexps). does anyone have good experiences with any of these?
- sequence7 15y ago
  Well it's not a framework but asp.net mvc can actually do pretty much exactly this with data annotations. http://www.asp.net/mvc/tutorials/mvc-music-store-part-6 http://www.asp.net/mvc/tutorials/mvc-music-store-part-6
ragmondo 15y ago
Wanted to comment on the article but all I could think about was "READ THAT EMAIL IN YOUR STATUS BAR"
avstraliitski 15y ago
Fundamental truth = no code should ever trust its input. Break this rule never. If you have optimization problems, then don't worry because they're better than security problems and the hardware will likely solve it for you by the time you release. Trust relationships between bits of any codebase mean 'not loose coupled' = fundamental design flaw for simple, maintainable and secure code. Unix design philosophy: "do one thing and do it well" (and that means checking all your input religiously for every function)

19 points by mopoke 15y ago

chris_engel 15y ago

This is obvious, isn't it?! Everything the user has access to can be manipulated.

wladimir 15y ago
You'd be surprised how many applications and web sites still rely solely on client-side validation, even these days. Either don't think at all about threat scenarios ,or they trust their "Do not reverse engineer" EULA to protect them :-)
- chris_engel 15y ago
  wow, I suppose we shouldn't begin to talk about sql sanitation...

nodata 15y ago

Does HN use client side verification for votes? Otherwise how did this get here?

robin_reala 15y ago

Sorry, what? Client-side verification is categorically not bad. It’s when you don’t combine it with a round-trip to server-side verification that you have problems.

robryan 15y ago

Words with friends really needs both, without client side it would be tedious for attempting a word, of course this could also cut down on people trying their letters just about every way they can until they get a word.

eyalbd1 15y ago

Client side verification is good to prevent unnecessary hits on the server when the input is incorrect/incomplete , its not.. in any way.. a real input validation.

Joakal 15y ago

Client side validation is good for speed, however should not be trusted when sent to server. Server side validation is for validating such information to prevent issues. eg SQL injections.

deno 15y ago
But you can't trust client-side validation, unless you run the client in a DRM container (client then can just sign the request and you can assume that it executed in a secure memory, unaltered).
- masklinn 15y ago
  Is that not exactly what he wrote?
  - deno 15y ago
    It seems I got it mixed up with a different comment. My apologies.

frobozz 15y ago

This attitude throws the baby out with the bathwater. Client-side verification is Good, it saves bandwidth and reduces annoyance to the user. Client-side verification without also checking on the server is bad. Given the example of a word game to be played on a phone. I would argue that client-side verification of valid words is vital.

mopoke 15y ago
The title should probably read "Why relying only on client-side verification is bad". I don't think the author is suggesting that doing client-side verification is a bad thing in itself.
- frobozz 15y ago
  That's probably what's in the authors mind, but not what's in the article. The author is not just suggesting that client side verification is bad in itself, but stating that position quite precisely. "Why client-side verification is bad.." (rather than the title you suggest) "to my surprise discovered that it did client-side verification of the words" (rather than "...that it didn't do server side verification") However, in support of your position; in his opening paragraph, he does say "you can't rely on it to do authentication", rather than "you shouldn't use it to do authentication".
  - nhebb 15y ago
    The author wrote "A common mistake is the web site that relies on javascript". I think the key word is "rely". You either rely on something or you don't. It's not a partial measure.
  - mopoke 15y ago
    Author's comment on his site: "It's not wrong to use client-side methods to do initial validation, but it's wrong to trust that validation on the server side."
    - frobozz 15y ago

steffoz 15y ago

Validation client side is just a way to make user interaction faster. Nothing more, but quite useful, indeed.

fragsworth 15y ago

Sure, we can all poke fun at them for being stupid programmers. Multi-billion dollar company and they don't even know how to do server-side verification? LOL, we're so much better than they are! But think about it for a moment. Assuming the ideal product would have both client + server verification, it's clearly less work to only do client-side verification. The product can be released quicker. Maybe they intentionally forgo the server-side verification code until they actually get cheaters. Then they implement it before it begins to hurt their bottom line. Because what if the game was an utter failure, and never got any users? How glad would you be that you spent all that time writing the server checks for every game action?

retube 15y ago
Yes absolutely. Programmers/devs often get way too wrapped in doing everything _right_. But doing it right takes time and money. Commercially it makes sense to get away with the bare minimum. The holes will only be an issue if the product actually takes off.
frobozz 15y ago
This is a very good point. After all, it is just a game, not a banking application, and a pretty simple game at that.

kieranyo 15y ago

Surely this is just common sense at this point?

lurchpop 15y ago

it is very annoying to have to duplicate validation logic though.

dclaysmith 15y ago

"It wasn't very hard to circumvent this, resulting in a version which accepts moves like the above one.." I'm more curious as to how you go about circumventing this. I would imagine that it probably IS very hard.

masklinn 15y ago

Not bad, insufficient.

corin_ 15y ago

There was a competition for university students in the UK a few months ago from some investment company, trying to raise interest for post-grad careers with them, basically a several-stage speed test, top five speeds at the end of the time period would get to choose a prize, iPhone, cash, few other things. A friend of mine (a student) asked me if it was possible to create macros in a browser to help go faster, and since I was bored and lack morals in this area... just took a look through the JS, and fifteen minutes later and an injection for him to paste into the URL bar and skip through each stage, making the game think he had completed it, as fast or slow as he wanted. So he got a free iPhone.

andrewcooke 15y ago

(thinking more about web pages than apps here) are there any frameworks that let you re-use the same verification code on both client and server? i'm imagining some way to decouple the validation from the presentation and then run the validation part on both sides - i don't see why this wouldn't be possible with something like Node.js. related, i guess that some frameworks (particularly ajax) support duplicating validation on client and server by automatically generating (different) client (javascript) and server-side code (python/ruby/java/...) from simple specifications (eg regexps). does anyone have good experiences with any of these?

sequence7 15y ago
Well it's not a framework but asp.net mvc can actually do pretty much exactly this with data annotations. http://www.asp.net/mvc/tutorials/mvc-music-store-part-6 http://www.asp.net/mvc/tutorials/mvc-music-store-part-6

ragmondo 15y ago

Wanted to comment on the article but all I could think about was "READ THAT EMAIL IN YOUR STATUS BAR"

avstraliitski 15y ago

Fundamental truth = no code should ever trust its input. Break this rule never. If you have optimization problems, then don't worry because they're better than security problems and the hardware will likely solve it for you by the time you release. Trust relationships between bits of any codebase mean 'not loose coupled' = fundamental design flaw for simple, maintainable and secure code. Unix design philosophy: "do one thing and do it well" (and that means checking all your input religiously for every function)