Security modifing app state from javascript

问题:

I have a question about how to develop my web application security. Assuming that all the javascript code is public and that anyone can make any AJAX call directly, with parameters that seem convenient, then any call that directly modify the status of the database is highly dangerous.

That is, calls as "changePoints" or "updateUserState" allow a malicious user to break the logic of, for example, a game and obtain unlimited money or points.

My intuitive solution to this problem is to desing calls that communicate client with server so through its parameters could not be possible breaking the app logic. In the example of a game, a call like "buySomething" would be safe because the server would be responsible for adding that "something" and subtract the money it costs. Two calls "addSomething" "changeMoney" could accomplish the same task but would be unsafe, for obvious reasons.

My doubts arise from the conclusions that this reasoning leads me: The model part of MVC pattern in client side seems so dangerous, especially if we apply "active record" because AJAX calls have a direct correlation to the database server. Also, my intuitive solution generates a tendency for much of the application logic to be developed on the server side, which can become tedious.

Is there something I'm missing? Are there smarter solutions? Does using models and active record in client side is just insecure?

Thank you for your attention and help.

回答1:

The server is always the ultimate authority. You need all of your app logic server-side and the server needs to validate all actions a user takes. Think of the server as a black box, which represents all of your application logic. Anything outside of that black box is not trustable, not part of "the app". Anything that can be done "from outside" with that black box is by definition untrusted. The black box must only expose valid APIs to the outside and react to any invalid input by rejecting it. An HTML/Javascript interface is merely a convenient way to use those APIs that a normal user can interact with, it is not part of the core application and must not contain critical business logic. It merely represents what goes on inside the black box.

If your application is highly dynamic and often changes state which needs to be reflected in the interface, like in a game, then yes, keeping that in sync with the server-side state can be quite a challange. It's nevertheless necessary.