Security problem in notification links

Home Forum Managing Stage / Role Field Access Security problem in notification links

This topic contains 5 replies, has 0 voices, and was last updated by  MABrown 12 years, 1 month ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #275


    My testing of our on-premise PerfectForms installation (with SSO Gateway) has revealed a security problem related to links in notifications.

    Unlike opening an instance from the dashboard (where the role is set when opened based on the user), the URL in notifications generated by the system include the intended user and role.

    In the event that a notification link is accessed by an unlicensed user other than the intended, that user can follow the link and it will open the form instance with all of the rights and abilities granted to the intended user, even if they are authenticated (through SSO) as not the intended user. I have noticed that this is not an issue with licensed users, since the form prevents licensed users from following links in others’ notifications.

    Is seems like this is a large oversight. I have attempted to add a security scheme to the form using the “Form is opened” behavior, but I can’t get it to a point where authorized users can see the form and unauthorized users can’t.

    Am I missing something?



    Have to wonder how these notifications are available to these unauthorised users? its similar in some respects to if you tell someone your username and password to any other application, they can then ‘be you’.

    having said that, you could perhaps look at covering this by using the special field properties (/Documentation/manual/html/special_fields__properties.htm) and on the ‘form is opened’ write to a (hidden) field the special “user-domainusername’.

    if the forms are accessed via the SSO gateway, then this field will only populate if a Perfectforms user is accessing the form, and as you’ve seen already these users will not be able to be masquerading as the actual user. Where the field is not populated (ie you can then add in a validation control to check if this field is ’empty’) then you can look at either setting all the fields to readonly or disabled, or present a message to the user that they are not authorised



    You said, “If the forms are accessed via the SSO gateway, then this (User – domain username) field will only populate if a Perfectforms user is accessing the form…”

    However, this does not match my test results. If an unlicensed user is accessing a form instance (from a notification) via the SSO gateway, it is possible for a field set at form-open by the “User – Domain username” property to be populated, as could any field populated by one of the “User” properties, with the information of the intended recipient of the notification.

    Furthermore, when following such a link the form role is always determined by the intended recipient of the notification, thusly granting any user following that link the rights of that role. I know this because I am using the special-fields properties you describe in my added security.

    Here is how it works so far; in the “Form is opened” behavior, the form attempts to set three fields:

    Current Role – populated by “Form – Role” property

    Licensed Username – populated by “User – Domain username” property

    Unlicensed Username – populated by “Gateway – HTTP USER” property

    When a form instance is opened through a normal link or the dashboard, it behaves as you described. The role is determined by the user. If the user does not have permission, the role is “Unspecified”. Also, only one of the username fields is populated, depending on whether or not the user has a PerfectForms account. If a user attempts to bypass SSO, neither field is populated. This makes for an easy check.

    When a form instance is opened through a notification link, the “Current Role” field matches the role set when setting up the notification, regardless of who clicks the link – even if the instance is opened bypassing SSO. In the event the intended recipient of the notification is a licensed user, then the Licensed Username field is populated with their username, and can be opened by any unlicensed user (or anonymously).

    As a result, my security behavior cannot reliably check against the Current Role or Licensed Username fields, in the event the form is opened from a notification link. Also, I cannot setup the behavior to determine if the form was opened from a notification, so I am at an impasse. No matter how I configure my security, there is always a way around it.

    With respect to the comparison to username/passwords, most people keep that information in their memory, as opposed an email generated by a system that is not under their control, so I do not believe the comparison is fair. With respect to how a notification could become available to the wrong user, it could be as easy as forwarding a message to another user, but regardless of how it could be done, I would feel much more comfortable with the system if I didn’t need to worry about it at all.



    Would need to see your actual form you are ‘testing’ with to see why you are not seeing the expected result when the SSO gateway is enabled. the ‘user-domain username’ only populates when a known perfectforms user accesses the form, otherwise the Gateway – http user’ populates. please send that over to us at and we can have a look to see what is going on to see if it is your form, or tif it is how your SSO is implemented

    have to say though, that if you are looking to cover a possible scenarion where an email notification is forwarded to an unauthorised user, you also have to consider that this PF user could just as easily tell an unauthorised user their log in credentials to the perfectforms application as well. Even if you were to restrict your forms so that only perfectforms users could access it (ie removing the WORLD permission) which is what a number of other users do where they have a requirement for higher levels of security) then someone could still do that.

    perhaps a different way to approach this is to simply identify WHO (not role, but person) is accessing the form from the above properties and store this in hidden fields that the users can’t see, and then either refer to the ‘data history’ aspect where all this information is stored for audit purposes, or set up a report where you are able to see who accessed the form and then you/your managers can discuss any such breaches with the appropriate staff



    I believe I now understand why the system sets roles based on notification URLs. Since unlicensed users can only be assigned a role based on an email address, and given that when a user opens the form the SSO module only returns the domain name, there is no way to correlate an unlicensed user to the email address assigned to the role. Instead, the role is tied to the URL in the notification.

    That is fine for unlicensed users; my behavior will send that username to LDAP and return the user’s email address, which I can then compare to the email address of the current role. The problem is when the notification is intended for a licensed user, where the URL is linked to the user information as well as the role.

    In our particular case, removing the World permissions is not a possibility. We need to allow both licensed and unlicensed users to access the form. We also cannot limit the system to “Domain Authentication Only” because we intend to deploy forms to users outside of the domain eventually as well.

    The idea of removing the role association from the notification and adjusting permissions based solely on the domain username is a possibility, but it will take a lot of work and is impractical, given the number of permissions in this particular form.

    Is there any way to disassociate the licensed user information from the link? I could also solve this problem if I can somehow determine if the SSO gateway was used. I tried to populate a field with the form URL to search against, but it always comes back as the non-SSO URL. (Perhaps you can also lend some insight as to why that is happening.)

    Finally, is there anyway to change the role after the instance has been opened? (Something like: If {condition is met}, role = {new Role}, else, role = “Unspecified”)

    I am currently looking into the possibility of sending a test form over.



    I think you may be missing what ROLE actually is and how it can help

    Roles are defined for users as you send them a notification. it doesn’t matter if that user holds a perfectforms account or not, when you set up the notification to them, you can define the role that they are to be assigned.

    You can then control the rights to the form objects based on that role for each stage of the form.

    If some other person is then accessing the form they will not have a role (where you see it as ‘unspecified’) and you can then control their rights to the form by using the ALL role. Look at the ALL role as being ‘anyone else that may get to the form that we have not notified specifically’.

    Whether you use the SSO gateway or not, you can control what a person can see and do on the form based on the ROLE assigned with the ALL role being the ‘anyone else’. You don’t even need to do anything on the form to present the ‘role’ to a field (although you may do that initially in testing).

    if you do then want to change a users role, when the next submit is actioned, set up another notification to them (doesn’t need to send them an email or present to the dashboard) defining that new Role and as that user then accesses the form in the future they will be prompted to select which role they wish to log into the form with. Personally I would see that being used very sparingly and only to users that are fully aware of what this means as it will be very easy for someone to not understand what they are being asked and then log in as the wrong role and be onto you when they then can’t get to do the work they expect

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.