12 Replies Latest reply on Jul 24, 2016 10:26 AM by kerrishotts

    How to show userspecific options in interface securely using phonegap

    piyushg90212744 Level 1

      Simply i want to ask if i have a admin user and a employee user.

       

      In this employee can only see the data while admin can also edit and delete the data so how can I securely code this functionality.

       

      I thought of using hide feature if the option doesnt belong to user but even then on decompilation of apk the code will be available. So, how can I secure this?

        • 1. Re: How to show userspecific options in interface securely using phonegap
          VectorP Level 4

          Yes, the code will be available, but is that really the point?

          - What is it exactly that you want to hide? Code? Data? Functionality?

          - Where does that functionality really take place? In the client? On the server?

          - What distinguishes an admin from an employee? A database attribute for his userID on the central db server? Something else?

          • 2. Re: How to show userspecific options in interface securely using phonegap
            kerrishotts Adobe Community Professional

            So, you should never ever rely on secrets in your code for security. This is true of native code as well, so this isn't a limitation of PhoneGap -- native code just takes a little more work to decompile/understand/etc. In short, never put anything you aren't comfortable with the world knowing in code that is distributed to an end-user. Ever. Even with native code.

             

            Your particular question isn't really PhoneGap-specific -- it's an architectural and security question. Step away from the PG side for the moment and think about how your entire system is supposed to work, and how authorization to the various resources is going to be managed. Keep in mind that anything on the client can be subverted -- it's in your user's hands, after all.

             

            That last is why you must validate at every tier -- your backend should not assume that an edit coming from the client is safe to perform. The backend should double check that the user sending the edits has the right to make those changes, and if they don't, the server should return an error. This secures against the user changing your app's code to always allow edits. Even if their app looks like it allows edits, your backend will prevent those changes from being saved.

             

            (Furthermore, although surely your client is validating the data being sent to the server in this example, your server should also perform the same validations. Don't assume that the client is actually doing data validation.)

             

            You're getting into complicated territory here regarding security concerns as well, unfortunately, and so may I suggest OWASP  -- they have a lot of fantastic information regarding security and preventing or mitigating malicious attacks and the like.

            • 3. Re: How to show userspecific options in interface securely using phonegap
              piyushg90212744 Level 1

              actually just as i told..

              lets take an example admin will be able to see 2 more options in navigation than employee. so should i implement something like jquery hide on client side or load the UI elements from server which would be more efficient?

              • 4. Re: How to show userspecific options in interface securely using phonegap
                VectorP Level 4

                So, you decide whether or not the user is an admin, and depending on the result you display the options or not.

                Are these options UI widgets (like buttons or form fields) or are they data that should only be visible to the admin? In the latter case, these data should only be sent by the server if it's an admin. In the former case, they are just UI elements. If operating these elements invokes admin functionality towards the server, you check again server-side.

                 

                If these are navigation elements, you should check the user's status before displaying the next page. That would, of course, only make sense if the data of that new page are not already present in the app package, anyway.

                 

                As Kerri said, this has nothing to do with Phonegap, but rather with application architecture and security.

                • 5. Re: How to show userspecific options in interface securely using phonegap
                  piyushg90212744 Level 1

                  so i should send the ui code from the server in form of AJAX response

                   

                  or should i use simple Jquery show n hide what u suggest.. basically i want to know user interface options for all users (employees+admin) should be inculcated within the app or should be loaded remotely everytym app is used or any other way?

                  • 6. Re: How to show userspecific options in interface securely using phonegap
                    VectorP Level 4

                    Have you considered answering the questions posted by Kerri and me?

                     

                    - should these interface options be unknown by employees all the time, or just hidden? (In other words: would it be any problem if the employees knew that there are also persons, called 'admins', who have additional functionality like 'Go to admin page'?)

                    - do these navigation elements contain secret data (in the query string), that only admins are allowed to know?

                    - what distinguishes an admin from an employee? A database attribute for his userID on the central db server? Something else?

                    • 7. Re: How to show userspecific options in interface securely using phonegap
                      piyushg90212744 Level 1

                      employee should never know about admin rights

                       

                      navigation probably links to functionalities which are to be accessed by admin only

                       

                      there is a particular level range set for admin

                      • 8. Re: How to show userspecific options in interface securely using phonegap
                        VectorP Level 4

                        employee should never know about admin rights

                        OK, so you can't have all navigation elements (links) in your code. Instead, use a web service script to receive a json object with a set of navigation elements for the current user (navigation title and url). Then generate these navigation elements from the data as delivered.

                         

                        navigation probably links to functionalities which are to be accessed by admin only

                        See above. Of course, the server needs to know what role the user has. This can be done by generating a token for the user at login, and passing this token between server and client. This way, the client (=app) doesn't even have to know wat the role of the user is.

                         

                        there is a particular level range set for admin

                        ...which is hopefully known and checked server side, only. In that case, the above suggestion would be pretty secure.

                         

                        But...what about the html pages for the admin role themselves? Aren't they included in your package?

                        It seems a bit useless to hide the navigation options from the app's source if the functionality (whichever that is, you refuse to tell) is still included.

                        • 9. Re: How to show userspecific options in interface securely using phonegap
                          piyushg90212744 Level 1

                          yes the page would have to be included else if everything is being loaded from internet then whats the advantage of an app

                          • 10. Re: How to show userspecific options in interface securely using phonegap
                            kerrishotts Adobe Community Professional

                            Perhaps it would help to hear more about your specific admin needs? What are you intending to display to an admin vs a regular user? Examples would help.

                             

                            My generic perspective:

                             

                            Keep your user interface and data separate. UI should be on the client; data should be sent to and from the server. The server is what verifies that the actions & data are acceptable, so even if the client somehow manages to override the UI and get a page they shouldn't see, there will be no data and no acceptance of data sent by the client.

                             

                            For example, let's assume that you have a simple data entry app. Different rights are assigned to users, and these include read-only, create, edit, and delete. These rights are managed at the server level, and the server will always be checking incoming actions to see if the user has the right to perform these actions. The server will also communicate these rights to the client so that it can present the appropriate UI elements.

                             

                            The UI elements themselves, however, are on the client. So it would be technically possible for a malicious user to ignore the rights sent from the server and to present the ability to perform actions the user isn't authorized to perform. And here's why the server-side check is so important: no matter how many times or how many ways the user tries to get the server to accept changes, if the user isn't authorized to make them, the server will reject the attempt. The malicious user would have to either circumvent your authorization system somehow or get into your backend to make arbitrary changes.

                             

                            Now let's go one step further: let's say that there's a user management component to this app as well. This piece allows an administrator to assign these read,create,edit,delete rights to an end-user. Again, the UI will be present on the client, but the /data/ it would provide (list of users, what rights they have) would come from the server. The UI would only be an option to those users the server has identified as administratory, but because the UI is on the client, it's possible for a malicious user to display that UI whenever they wish. Again, this is why you have server-side checks: if the user is not an administrator, any attempts at changing rights for a user would be rejected.

                             

                            So, in short:

                             

                            - User Interface is on the client

                                - Sometimes this might be the UI as a whole, but other times it might be the UI in part. As an example, an app I wrote for a client needed to have customizable data elements. So the client contained the code to generate all sorts of fields: text fields, drop downs, date time, etc. The server would send the data types it needed, and the client would then render the appropriate UI from client-side elements. Beause the server validated both the data and the authorization, a form that was different (say from a malicious user changing the form layout) would generate an error (from the server) rather than corrupt the server's data.

                            - Data displayed by the UI is from the server

                                - Data can include rights, visibility, etc. So if a user shouldn't see an admin page because they aren't an administrator, that's data. But you always maintain server-side checks because the user could have modified your app in such a way that it ignores those rights.

                                - Sometimes UI layout is data as well

                                - Usually though this is the content of fields and whether an item is checked, etc.

                            - Actions and associated data (sending a new record, updating an existing one, assigning new rights to a user) are always vérified by the server In two ways:

                                - the data matches the required data format (validation)

                                - the user has the authorization to perform the action

                             

                            NOTE: By UI I mean elements, otherwise known as chrome. This often includes layout as well, though not always. I DO NOT MEAN FIELD CONTENTS, VISIBILITY, RIGHTS, AND THE LIKE. That's data.

                             

                            Even shorter:

                             

                            - The server never, ever, ever trusts the client. :-)

                             

                            Again, this is an architecture and security problem, faced by all apps, native or hybrid. You'd have the same problem with a native app -- I could patch the executable to get it to display any UI I want. So no matter what, validation must be done on the server.

                            • 11. Re: How to show userspecific options in interface securely using phonegap
                              VectorP Level 4

                              But Kerri...

                              the OP said he didn't want an employee to know what admin functionality exists at all. He wants the admin UI and even the navigation elements to those functions to be hidden.

                              Hidden, not only from the display, but also from the source code.

                               

                              Are you telling him that he should not want that? :-)

                              • 12. Re: How to show userspecific options in interface securely using phonegap
                                kerrishotts Adobe Community Professional

                                Yeah, pretty much. I had a much longer post that got lost because Safari decided to crash. Grr.

                                 

                                Basically there are four options:

                                 

                                1. Don't deliver administrative functionality in the app at all. Easiest, and most certain not to be thwarted.

                                2. Deliver a version of the app with the administrative functionality. More complex and requires enterprise control over distribution.

                                3. Have a composable UI in the app, and deliver layout and such via JSON. Most complex, but great if the underlying structures change frequently on the server (and one doesn't want to have to release new versions of the app)

                                4. Let the UI exist in the code, even if the employee can see it (in the code bundle). Again, UI doesn't imply data, such as the values of settings or passwords and such.

                                 

                                Here's the thing: if security is threatened merely by the employee's knowledge of what administrative functionality exists (or what the UI looks like), there's a much deeper problem already.

                                 

                                As long as the server is the one vetting whether information is sent to the user and whether that information is accepted back for update, then it doesn't really matter that the UI is present in the code on the user's device. They can force it to show all they want (or even change it), but the server will continue to reject those changes.

                                 

                                Side note: Native apps have the same problem; PG's code just happens to be more accessible.

                                 

                                So, my thought is that there's no reason to preclude navigation links or editing functionality from the client's code. Hide them visually, yes, because you don't want to present an interface that's confusing to the end-user, but don't rely on that for security. Instead, ensure that the server sends the appropriate data and verifies that the received changes are allowed and acceptable.

                                 

                                My two cents, anyway. ;-)

                                2 people found this helpful