jQuery ajax security

后端 未结 3 1372
星月不相逢
星月不相逢 2021-01-21 17:49

I have the following ajax call which checks to see if the user is a paid member, if yes it runs certain functions accordingly. This works but i\'m concerned about security. What

相关标签:
3条回答
  • 2021-01-21 18:16

    If you're performing security checks like this client-side then there's nothing to stop the clients either modifying the Ajax URL (to return 'paid'), or just bypassing your JavaScript with their debugger to do what they want by jumping to your '//grant access and run some functions' section.

    Let them perform those actions client-side if they wish, but always have a check in place server-side when the data is sent back before it is processed and stored to the database, or attempts to empty someone's bank account or such; the server-side validation checks are the only validation checks you can trust.

    Never trust clients.

    edit: jfriend00's answer is better :).

    0 讨论(0)
  • 2021-01-21 18:20

    Pinkie what you should do rather than make this check on the client-side is never render code that is meant only for paid users on the client-side, like others mention, this imposes severe security holes since it's very simple to forge ajax requests with merely a firebug console.

    Likewise, just "hiding" markup isn't going to cut it for you, so display:none; won't really accomplish anything in securing your website.

    What I'd recommend is two-fold: firstly, don't even render javascript on the client that isn't meant for the user who is visiting. In this case you might even want to consider invoking a partial action method that decides whether or not to render what js code to the client, depending on the user credentials.

    Secondly, there is only so much that can be done on the client-side, this means: every single method on the server side that is sensitive to the user's credentials should verify that the user is indeed allowed to access this functionality, and not just guess that if he's accessed that method, he must be.

    Update

    In the case you mention where you render a jquery UI dialog, as long as the buttons point to functionality thata verifies on the server-side that the user is who he claims to be, then you are "safe" (even though it's not the cleanliest code on the earth); what you should really be doing is render those buttons based on whether the user has the credentials you require.

    Instead of checking if they have the required credentials in your ajax call, you should be making a query to fetch the portion of HTML / JS you were going to be rendering.

    0 讨论(0)
  • 2021-01-21 18:29

    Ultimately your server needs to always enforce proper authentication. You cannot rely on the client to enforce anything because it can always be compromised (if not in your web page, in a custom-built web page). So, when you get logged in, your server needs to return some sort of token or set a cookie that contains some sort of token and only future requests of the server that have that token or cookie should be honored.

    You can use logic in the client to present a nicer interface to the user (showing them logged in operations only after they've been authenticated, showing appropriate log in or log out options, etc...), but you can't use the client to actually provide security.

    Many REST APIs have a login method that returns a sessionID and all other API requests require that sessionID. The server then checks that sessionID on every request to see if it's for a valid logged in user and to see if it's still valid (sessionIDs are usually only good for some time period if not used regularly).

    Many web apps use a cookie to that all future page views and form submissions will be able to present to the server that they are logged in and authenticated properly because of the presence of the appropriate sessionID in the cookie.

    0 讨论(0)
提交回复
热议问题