9 ms·
"Never trust the client" is good advice for every kind of application. Clients are filthy liars. Clients have bugs. Old clients don't upgrade. Packets arrive o
by xenadu02 11y ago
"Never trust the client" is good advice for every kind of application. Clients are filthy liars.
Clients have bugs. Old clients don't upgrade. Packets arrive out of order. ACKs never make it to clients, causing clients to repeat what the client believes to be a failed operation. All of this is before even considering an attacker actively trying to subvert you.
The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well.
Don't blindly slap whatever the client sends into a no-SQL database, then vomit it back out for queries.
- ksk 11y agoWith caveats. What you're also implying is that clients should do no processing - because clients can't be trusted to do anything. If you apply this logic to web-browsing, you're asking the server to send the client a bitmap image of what the rendered page should look like.
- JoshTriplett 11y agoNot at all. It's fine for the client to handle processing when the only thing they could hurt is the user of the client. If the client renders a web page incorrectly, only the user of the client gets hurt by that. But the server API must not allow a malicious client to do damage that affects other clients.
- abraae 11y agoYour example is about the client misreporting server state to the end user. The big deal is instead about a badly behaved client being able to make "illegal" changes to the server state.
- cortesoft 11y agoI think that is misinterpreting what the person you are replying to is saying. They aren't saying "don't let the clients do anything", they are saying "don't trust the values the clients send back" If the client messes up the rendering, the only person affected is the client. There is no 'trust' required, because you are not relying on anything the client has done. The idea of trust only comes into play if there is a consequence to that trust being broken.
- ksk 11y agoWell, a bank website would want to use this to make sure nobody MITMs them, or that the client does not have malware, etc - which would affect the user.
- Pitarou 11y agoMITM isn't really relevant for the purposes of this discussion. We're talking about a different application with different threat models.
- stefs 11y agonah, a better example involving a bank would be: you have two accounts. the client can do transactions. the server sends to the client: account A has $100, account B has $200, make your transaction. 1. trusted client client says: i've done my transaction, now account A has $50 and account B has $250. the server updates the database accordingly. 2. never trust the client client says: i want to do a transaction from account A to account B with 50$. the server decreases account A by 50$ and increases account B by $50 and updates the database accordingly. 3. the difference is, with the trusted client model, the client could be hacked and respond with: client says: i've done my transaction, now account A has $52 and account B has $252. the server updates the database accordingly. congratulations, you - as the bank operator - have now lost $4 to the hacker and this is practically what happens with in the division (except that the other players have to pay for it instead of the bank/ubi soft). they try to do server checks to prevent this, but due to network timing problems they can't check the exact values, only calculate if this is maybe approximately right. so a players maximum running speed is, say, 6m/s. they could do periodical checks (every second) if the player moved more than 6m since the last second. but what if the player falls down a building or is thrown by an explosion further than that? it'd register as cheating, even though it's completely legal to jump off a building. so they have to increase the checks for distance/s by 3 to allow those situation (i.e. 18m/s). a cheater with a modified client can now continually run three times as fast as any other player without getting flagged as a cheater. why do they do this? because it's a) easier to implement (the client has to do all the computations anyway - doing them a second time on the server and then sending back to the client isn't an easy problem - you have to interpolate) and b) cheaper (less work = less man hours, less complicated work = cheaper programmers* and less server power needed) * i'm completely sure the devs would have been 100% able to do it right, but it would have taken them longer, thus costing more. so, how to fix it? there's only one way: rewrite the model. but this is expensive and the titles have already been sold, so why bother investing another couple hundred thousand bucks? even the disgruntled gamers will buy the next ubi soft title if it's shiny enough. i mean, few people will buy the game now that multiplayer is infected with cheaters but they already exploited enough of the market and long time players are probably less likely to buy the next title if they're still playing an old one. maybe.
- ageektrapped 11y ago> The server should always be the source of truth. It should always enforce all the consistency rules. Database schemas can be a critical tool here as well. Amen. And I'm a client developer. Clients aren't for data validation, etc. That's the server's job because the server has to store it, use it, ship it off to other things. Clients are for displaying all that data in a way a human can understand. It has people skills, damn it!
- taneq 11y agoThe server is the model and the controller. The client is the view, and marshals input to the controller. Doing it any other way is bananas.
- djsumdog 11y agoI saw a talk where a guy was showing how to cheat at some games. A lot of games will detect and crash you out if they detect a debugger attached to them. Things like Punk Buster, et. al. are more like anti-virus software: they try to find the signatures of known chat clients. So it's best to write you own...and rename your debugging process to "Google Chrome." He got pretty far with his auto-walker in some MMOs. He had limiters so his runs wouldn't be too fast and would go up/downhill correctly...or so he though. He forgot to multiple by -1 somewhere and the server banned him for attempting to fly of into space.
- Cyph0n 11y agoI'm really interested in game hacking. Do you have a link for the video/talk?
- kaoD 11y agoI used to visit Game Deception, the best game hacking technical forum. Unfortunately it closed. I lost interest in game RE a long time ago, but http://www.unknowncheats.me/ http://www.unknowncheats.me/ seems to be its successor, though from a cursory glance I see there are a lot more cheats and less technical information. GD we miss you.
- blahkins 11y agoI used to frequent http://aimbots.net/ http://aimbots.net/ when I was younger. Its a forum dedicated to mostly open source cheats so there is a whole discussion thread with sources and RE strategies.
- grimmfang 11y agoDon't forget the incident where Punk Buster banned anyone with a certain string in memory...
- sdwisely 11y agoI remember it unfortunately being timed around the same time an exploit string would cause one of the AV packages to drop connections. Made gaming IRC channels utter chaos for weeks.
- golergka 11y agoNot every. Right now I'm working on an app where we trust the client. We know that a hacker can compromise a client and send any kind of bogus data, we're just completely OK with it from business perspective.
- andyburke 11y agoCan you give any more insight into this product? Curious what kind of product would have that be ok from a business perspective...
- cmdrfred 11y agoClosed network with locked down terminals?
- bluejekyll 11y agoWhat I'm trying to figure out isn't the business option where it's ok, but the business where you actively are avoiding doing it. I mean why not just do it the right way?
- Ogre 11y agoYou can handle orders of magnitude more users with the same hardware if you don't have to run the game simulation on the server.
- golergka 11y agoEye training app with server creating parameters of the next training session (based on the whole training history and some data analysis magic). If you want to get a training seasion that doesn't fir your real results — go ahead, we don't care.
- kybernetikos 11y ago> "Never trust the client" is good advice for every kind of application. Clients are filthy liars. It's true that you can't trust clients not to lie. However, in some situations, it's the correct decision to accept a constrained number of lies if that brings you benefits. Like so many other absolute statements in software, in reality it's a trade off, and you need to consider the business context to make the right decision.