4 ms·

To walk a little further down that path, if there is database access how is validation done since none of the client code can be trusted to have been executed a

by ktsmith 16y ago

To walk a little further down that path, if there is database access how is validation done since none of the client code can be trusted to have been executed and all input from the client should be considered suspect?

mckoss 16y ago
User authentication is handled by the server, and then a session cookie is created on your application sub-domain. App writers don't have to worry about authentication - just redirect the user to the www.pageforest.com/sign-in/appid page, and the will redirect back to the app if the user has granted the application permissions to save on their behalf (much like a 3-legged oAuth).
- deleted 16y ago
  [deleted]
- ktsmith 16y ago
  Thanks for the answer, but my question isn't about user authentication/validation but validation of input from the user into my application. A simple example, I set up a survey app. Several of the questions contain user input in the form of dates or numbers such as, date of birth, number of years living in the united states, years employed, etc. To help weed out bogus answers I want the fields to be validated/filtered. Date fields should be dates, numeric fields should only contain digits. In a traditional client server app I can validate this on the client side before submission in javascript, but I would still need to validate it on the server side as the clients input cannot be trusted. There is no guarantee that the validation code was ever run, that the user didn't modify the code as/before it was executed or that the user didn't simply post bogus data via a script. Much more importantly, if I'm taking user input and then pushing that data back into the page for other users to see how do I prevent someone from submitting malicious javascript that is then executed by the next users browser when they view the document? The pitch is that my application is 100% client side javascript so it would seem to preclude the vast majority of apps that I can even think of since the users input would need to be processed/validated server side before I would be willing to store it or make it available for others to consume.
  - drcode 16y ago
    For your survey app example, why can't you just allow the client to submit bogus data if they want, then filter out the junk when you collect the data for reporting at the end? (This is assuming that the pageforest server doesn't implode when someone does this, but I see no reason to assume this would happen from a theoretical standpoint.) For you second example, why the heck would you run javascript eval on the document data? As explained by mckoss, the storage format is JSON, not raw javascript that is executed. This is an important distinction: jQuery and other client libraries contain special commands for handling JSON that exist specifically to resolve the kinds of problems you are describing. EDIT: It looks like the other reply explains that there is no "trusted agent", so this is clearly a limitation of their system (though not a theoretical limitation, as far as I can tell- No reason they couldn't allow the app creator to log in with pseudo-admin privlidges to do reporting.)
    - ktsmith 16y ago
      Why in the world would I want to collect garbage. Sure I can post process all of the survey data but it's trivial to do it on the front end so why not. In a significant number of other cases failing to validate input would simply be a non starter limiting this to toy apps. As to the second point: Who said anything about _me_ running a javascript eval on user supplied data. Go look at their wiki example click edit and in the text box type: <script>alert('boo');</script> then click the hide button. Notice two things. The first is that when you type the last > on the ending script tag the included script executes and you get the alert popup. When you reload the page you'll still see the alert('boo'); in the wiki display (in <code> tags) but the <script> tag is still live in the page as there's either no or very limited output sanitization. In a typical client/server application this is hopefully going to be sanitized or eliminated prior to ever being stored. The storage format is irrelevant if the data being stored is spit right back out into the page as in the wiki example.
      - drcode 16y ago
        You're absolutely right on the alert issue in the wiki: Displaying unsanitized text in this way is a security bug. However, I think the security bug is in the client app, which should sanitize any data it pulls from the server, if the server data may have originated from another user (if this is even possible in the current pageforest API) not in the inherent design of pageforest. But that is indeed a good argument in your favor, ktsmith.

by ktsmith 16y ago

mckoss 16y ago

User authentication is handled by the server, and then a session cookie is created on your application sub-domain. App writers don't have to worry about authentication - just redirect the user to the www.pageforest.com/sign-in/appid page, and the will redirect back to the app if the user has granted the application permissions to save on their behalf (much like a 3-legged oAuth).

deleted 16y ago
[deleted]
ktsmith 16y ago
Thanks for the answer, but my question isn't about user authentication/validation but validation of input from the user into my application. A simple example, I set up a survey app. Several of the questions contain user input in the form of dates or numbers such as, date of birth, number of years living in the united states, years employed, etc. To help weed out bogus answers I want the fields to be validated/filtered. Date fields should be dates, numeric fields should only contain digits. In a traditional client server app I can validate this on the client side before submission in javascript, but I would still need to validate it on the server side as the clients input cannot be trusted. There is no guarantee that the validation code was ever run, that the user didn't modify the code as/before it was executed or that the user didn't simply post bogus data via a script. Much more importantly, if I'm taking user input and then pushing that data back into the page for other users to see how do I prevent someone from submitting malicious javascript that is then executed by the next users browser when they view the document? The pitch is that my application is 100% client side javascript so it would seem to preclude the vast majority of apps that I can even think of since the users input would need to be processed/validated server side before I would be willing to store it or make it available for others to consume.
- drcode 16y ago
  For your survey app example, why can't you just allow the client to submit bogus data if they want, then filter out the junk when you collect the data for reporting at the end? (This is assuming that the pageforest server doesn't implode when someone does this, but I see no reason to assume this would happen from a theoretical standpoint.) For you second example, why the heck would you run javascript eval on the document data? As explained by mckoss, the storage format is JSON, not raw javascript that is executed. This is an important distinction: jQuery and other client libraries contain special commands for handling JSON that exist specifically to resolve the kinds of problems you are describing. EDIT: It looks like the other reply explains that there is no "trusted agent", so this is clearly a limitation of their system (though not a theoretical limitation, as far as I can tell- No reason they couldn't allow the app creator to log in with pseudo-admin privlidges to do reporting.)
  - ktsmith 16y ago
    Why in the world would I want to collect garbage. Sure I can post process all of the survey data but it's trivial to do it on the front end so why not. In a significant number of other cases failing to validate input would simply be a non starter limiting this to toy apps. As to the second point: Who said anything about _me_ running a javascript eval on user supplied data. Go look at their wiki example click edit and in the text box type: <script>alert('boo');</script> then click the hide button. Notice two things. The first is that when you type the last > on the ending script tag the included script executes and you get the alert popup. When you reload the page you'll still see the alert('boo'); in the wiki display (in <code> tags) but the <script> tag is still live in the page as there's either no or very limited output sanitization. In a typical client/server application this is hopefully going to be sanitized or eliminated prior to ever being stored. The storage format is irrelevant if the data being stored is spit right back out into the page as in the wiki example.
    - drcode 16y ago
      You're absolutely right on the alert issue in the wiki: Displaying unsanitized text in this way is a security bug. However, I think the security bug is in the client app, which should sanitize any data it pulls from the server, if the server data may have originated from another user (if this is even possible in the current pageforest API) not in the inherent design of pageforest. But that is indeed a good argument in your favor, ktsmith.