6 ms·

Can anyone explain to me how authentication works with JS-based storage client like this? It scares me to think a user might have the ability to store anything

Can anyone explain to me how authentication works with JS-based storage client like this? It scares me to think a user might have the ability to store anything via the web on my dime. I feel like I'm missing something.

princeverma 14y ago
I am wondering same thing, can somebody explain this please.
- jnbiche 14y ago
  It's relatively easy to do basic HTTP authentication using Javascript. If you're on SSL, that's reasonably secure. Once you're authenticated the server can issue a nonce that identifies you and gives you authorization (role-based access) to various pages/objects/apps based on that nonce.
lacker 14y ago
There are two main types of security. Object-level, and app-level. Each object gets access controls that are similar to ACLs in Unix systems. That provides for the sort of security that separates different users' data from each other. On an app-level, you can also control per-class which operations are usable. For more detail, see: https://parse.com/docs/data#security https://parse.com/docs/data#security You should be able use these in combination to secure your app. If you have more specific questions about how to secure a particular use case, drop us an email at feedback@parse.com and we can help figure something out.
- peripitea 14y ago
  I still don't get how I, as a malicious (or curious) user with some form of write permission, would be prevented from doing the equivalent of opening up Firebug console and typing while(true){var p = new Post(); p.save();}
  - equark 14y ago
    What prevents you from doing this with ajax post on every existing website?
    - jgannonjr 14y ago
      This is true, but at least if you control your own backend you can do some sort of rate limiting on the server side
    - peripitea 14y ago
      Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max posts per user = 10), but that doesn't really solve the problem. Edit: And I should add that the problem isn't just a user creating new many objects. The problem is that without code controlled exclusively by me somewhere in the middle, business logic (i.e. anything not codified in your database schema) becomes unenforceable. E.g. pull up firebug and type player.levelUp(); player.save();. Now there may be some subset of applications where business logic like this is completely unnecessary, but I can't think of many.
      - fooandbarify 14y ago
        I can't see it working well in a game scenario, but the vast majority of CRUD apps out there could be safely implemented using Parse's security model (as described in lacker's link).
        bonaldi 14y ago
        They use a game in their JS documentation! And as they wrote it it's totally vulnerable to the user incrementing their own score. It's not just games, either. As soon as a client-server solution gets beyond utterly trivial it becomes hard to see how you'd do it without server logic. Take another example described in lacker's link -- a messageboard post: the ACL defines whether or not a user can make a new post, but what controls the content of that post? What forces HTML tags to be dropped, or limits the number of images in a post, or the size of the post, or checks the domains of links, or prevents xss, or rate-limits a user? Some of this you can do by treating your entire database as "dirty" and sanitising things on the way out, too, but that doesn't come close to squaring the circle.

princeverma 14y ago

I am wondering same thing, can somebody explain this please.

jnbiche 14y ago
It's relatively easy to do basic HTTP authentication using Javascript. If you're on SSL, that's reasonably secure. Once you're authenticated the server can issue a nonce that identifies you and gives you authorization (role-based access) to various pages/objects/apps based on that nonce.

lacker 14y ago

There are two main types of security. Object-level, and app-level. Each object gets access controls that are similar to ACLs in Unix systems. That provides for the sort of security that separates different users' data from each other. On an app-level, you can also control per-class which operations are usable. For more detail, see: https://parse.com/docs/data#security https://parse.com/docs/data#security You should be able use these in combination to secure your app. If you have more specific questions about how to secure a particular use case, drop us an email at feedback@parse.com and we can help figure something out.

peripitea 14y ago
I still don't get how I, as a malicious (or curious) user with some form of write permission, would be prevented from doing the equivalent of opening up Firebug console and typing while(true){var p = new Post(); p.save();}
- equark 14y ago
  What prevents you from doing this with ajax post on every existing website?
  - jgannonjr 14y ago
    This is true, but at least if you control your own backend you can do some sort of rate limiting on the server side
  - peripitea 14y ago
    Server-side logic. The difference is that traditional data flow is UserControlledCode (i.e. client-side JS) --> MyServer --> DataStore, whereas this is UserControlledCode --> DataStore. In practice you may often choose not to have the code in MyServer do anything beyond act as a pass-through, but not having that option at all seems scary. The only recourse I see is things like database schema constraints (e.g. max posts per user = 10), but that doesn't really solve the problem. Edit: And I should add that the problem isn't just a user creating new many objects. The problem is that without code controlled exclusively by me somewhere in the middle, business logic (i.e. anything not codified in your database schema) becomes unenforceable. E.g. pull up firebug and type player.levelUp(); player.save();. Now there may be some subset of applications where business logic like this is completely unnecessary, but I can't think of many.
    - fooandbarify 14y ago
      I can't see it working well in a game scenario, but the vast majority of CRUD apps out there could be safely implemented using Parse's security model (as described in lacker's link).
      - bonaldi 14y ago
        They use a game in their JS documentation! And as they wrote it it's totally vulnerable to the user incrementing their own score. It's not just games, either. As soon as a client-server solution gets beyond utterly trivial it becomes hard to see how you'd do it without server logic. Take another example described in lacker's link -- a messageboard post: the ACL defines whether or not a user can make a new post, but what controls the content of that post? What forces HTML tags to be dropped, or limits the number of images in a post, or the size of the post, or checks the domains of links, or prevents xss, or rate-limits a user? Some of this you can do by treating your entire database as "dirty" and sanitising things on the way out, too, but that doesn't come close to squaring the circle.