E-mail security

  

Hi all,

Currently working on an internal app to be used within a company. The system is a basic form that collects details about a employees request.

The system then creates an email using this information and sends it to management and HR to be approved or declined.

The email has a button on the that connects back to the systems to update the request with managements review. The button changes the request status from pending to either approved or declined within the system.

My issue is that I am concerned about the security of the email, as it connects from and back to a direct record within the system.

So far I can validate the form to only allow emails to be send to internal email addresses and only to include the sender, management and HR. Also the the information is not strictly confidential but more private to the employee (the most confidential information being email addresses). 

Is there any security measures I should be taking to reduce the chance of security being comprised? Or is this an secure as I can expect?

Thanks

Peter

Hi Peter,

How exactly are you "connecting back to the system" from your email? Does it have a link to one of your app's screens? If that is the case, then you need to secure your app against unauthorized access, in case an unauthorized user somehow ends up having access to one of the emails. The first step to do this is to create a specific role for the users that will be allowed to update the request status and select that role for your screen. You should end up with something similar to this:

As an additional layer of security, also check for that Role in the action that updates the status of your record using the built-in "Check<YourRole>Role" actions that are automatically created when you add a new role to your app.

With this you will have a very reasonable level of security for this specific scenario.

Hi Peter Travers,

Another advice is to be careful when sending emails, containing the database identifier of that record.

Aurelio Junior wrote:

Hi Peter,

How exactly are you "connecting back to the system" from your email? Does it have a link to one of your app's screens? If that is the case, then you need to secure your app against unauthorized access, in case an unauthorized user somehow ends up having access to one of the emails. The first step to do this is to create a specific role for the users that will be allowed to update the request status and select that role for your screen. You should end up with something similar to this:

As an additional layer of security, also check for that Role in the action that updates the status of your record using the built-in "Check<YourRole>Role" actions that are automatically created when you add a new role to your app.

With this you will have a very reasonable level of security for this specific scenario.

Hi Aurelio Junior,

Thanks for your reply

So the email has two buttons/links, one to approve and to decline, Whenever one is clicked, the logic runs to find the record with the record Id of the email and to update the request status (from Pending to Approved or Declined). To do this I needed to open the system, but I just made a sort of stand alone page of the system that informs the Approver that the request has been updated and that they are free to close the window/tab. From this screen no other screens in the system can be accessed.

As for checking approver roles, each employee approver is their manager, but I can't make all managers approvers, as a managers approver may will also be other manager, which may lead to them being able to approve their own request.

Example: Manager A can make a request to himself and because he is a manager with a approver role, he can approve his own request.

Also due to business logic an employees manager is able to change quite frequently, making it difficult to assign one manager to one employee.

Due to this issue I am trying to make the emails secure as possible so there is a sort of audit trail of the request that can be tracked by HR.

I understand that there many not be much I can do to ensure the security, but I just want to cover as much as possible.

Thanks

Peter


Marco Arede wrote:

Hi Peter Travers,

Another advice is to be careful when sending emails, containing the database identifier of that record.

Hi Marco Arede,

So I am currently sending the Id of the record with the email, so I can use it to link back to the system. What is the best way to handle this?? Is there any encryption methods I can look into?

Thansk

Peter

This might not be the best way, but one thing you can do is add a mandatory attribute to your entity and fill it in with a GUID when you create the record, so that you send that in the e-mail, instead of the ID.

The problem with sending Ids is that they're sequential, so a bad person could access every other record simply by changing the Id value in the URL parameter.

GUIDs don't have this problem, they're not sequential, they have a random component, so you can't easily guess them.


Peter Travers wrote:

Marco Arede wrote:

Hi Peter Travers,

Another advice is to be careful when sending emails, containing the database identifier of that record.

Hi Marco Arede,

So I am currently sending the Id of the record with the email, so I can use it to link back to the system. What is the best way to handle this?? Is there any encryption methods I can look into?

Thansk

Peter



Carlos Ribeiro da Fonseca wrote:

This might not be the best way, but one thing you can do is add a mandatory attribute to your entity and fill it in with a GUID when you create the record, so that you send that in the e-mail, instead of the ID.

The problem with sending Ids is that they're sequential, so a bad person could access every other record simply by changing the Id value in the URL parameter.

GUIDs don't have this problem, they're not sequential, they have a random component, so you can't easily guess them.

Hi Carlos,

Thanks for this. I was worried about sending the identifier, but wasn't sure how to handle it. Will look into adding a GUID attribute.

Thanks

Peter 

Hi Peter,

It seems like there are quite a few business rules/validations that have to be performed when approving/rejecting a record. I strongly advise you to control in your application the employees and their respective managers, so that you can validate that a user trying to modify a record has the required permissions to do that. If you set up your screen to only be accessible to logged in users, than you can easily get the logged in user's Id using the GetUserId() built-in function. You can then use that to get that specific user's details/permissions.

Aurelio Junior wrote:

Hi Peter,

It seems like there are quite a few business rules/validations that have to be performed when approving/rejecting a record. I strongly advise you to control in your application the employees and their respective managers, so that you can validate that a user trying to modify a record has the required permissions to do that. If you set up your screen to only be accessible to logged in users, than you can easily get the logged in user's Id using the GetUserId() built-in function. You can then use that to get that specific user's details/permissions.

Hi Aurelio Junior,

Thanks, will have a look into doing the way you described.

Peter


Peter Travers wrote:

Marco Arede wrote:

Hi Peter Travers,

Another advice is to be careful when sending emails, containing the database identifier of that record.

Hi Marco Arede,

So I am currently sending the Id of the record with the email, so I can use it to link back to the system. What is the best way to handle this?? Is there any encryption methods I can look into?

Thansk

Peter

Something like Carlos Ribeiro da Fonseca refered can be made. But many other options are possible, to solve this case, and also with interesting user friendly scenarios. 

Another thing you want to think about, for your app logic validation, is what happens when you have more than one email with same subject (when is sent more than once).

Marco Arede wrote:

Peter Travers wrote:

Marco Arede wrote:

Hi Peter Travers,

Another advice is to be careful when sending emails, containing the database identifier of that record.

Hi Marco Arede,

So I am currently sending the Id of the record with the email, so I can use it to link back to the system. What is the best way to handle this?? Is there any encryption methods I can look into?

Thansk

Peter

Something like Carlos Ribeiro da Fonseca refered can be made. But many other options are possible, to solve this case, and also with interesting user friendly scenarios. 

Another thing you want to think about, for your app logic validation, is what happens when you have more than one email with same subject (when is sent more than once).

Hi, 

Can you provide some details on the other options I may look into??

I am not sure what you mean by the last comment, about having more that one email with the same subject.

Thanks 

Peter


Peter Travers

Your email becomes more secured if has less relevant information, this leads to think on a link to your application without any database contextual reference (just a link to the app). Inside the application make the necessary logic to cope with this. And think this way on business process technology. This is maybe something you can also think on!

Cheers!