Steve M wrote: [...] > 1. Based on your description, don't trust the client. Therefore, > "security", whatever that amounts to, basically has to happen on the > server. That's the right answer. Trying to enforce security within your software running the client machine does not work. Forget the advice about shipping .py's or packaging the client in some way. > The server should be designed with the expectation that any > input is possible, from slightly tweaked variants of the normal > messages to a robotic client that spews the most horrible ill-formed > junk frequently and in large volumes. It is the server's job to decide > what it should do. For example, consider a website that has a form for > users to fill out. The form has javascript, which executes on the > client, that helps to validate the data by refusing to submit the form > unless the user has filled in required fields, etc. This is client-side > validation (analagous to authentication). It is trivial for an attacker > to force the form to submit without filling in required fields. Now if > the server didn't bother to do its own validation but just inserted a > new record into the database with whatever came in from the form > submission, on the assumption that the client-side validation was > sufficient, this would constitute a serious flaw. (If you wonder then > why bother putting in client-side validation at all - two reasons are > that it enhances the user experience and that it reduces the average > load on the server.) Good advice. -- --Bryan
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4