URL Giving away to much Info

I currently work on a timesheet portal. One of the features is that as employees are submitting requests an email is sent out to the supervisor that lets the supervisor see that they have a request to approve. In this email is a link to the request that the supervisor can click on to take them to the link.
Currently it looks like this.

http://timeportal.fake/viewrequest.aspx?ID=555&RequestType=2&Role=5

The problem with this system the way it was written is that with the information that is given a user could manipulate the system to allow them to approve one of their own requests as their supervisor. While this has yet to happen, I want to prevent this from happening. Is there a way to create the link without giving away all the information? When you login currently the system keeps all the info in a session. But when you try and follow the link the system would take you to the request page as an employee, when it should be supervisor. This confuses the user and they logout and back in going through the menus to get to the requests and in the right state.

At this point I would rather just have them goto the main menu, but that does not seem to be an option that everyone can be happy with. What other options could we try?

Is there not any type of login into the web app?
You could then control who has ability to approve requests based on there permission level.

Yhea there is a login but everyone on the system at some level is an employee. The role only changes when they take an action on the website. Example looking at their employees timesheets would change their access level from "Employee" to "Supervsior". The individual who proccesses all the time sheets when she looks at them would go from "Employee" to "Payroll". The problem is that they want to click the link in the email, login and be taken directly to the request bypassing the permission level. This used to be passed in by the URL, but now it's not.

You can encrypt the parameters, pass them through URL, and decrypt in the site when user clicks through that link in the mail. You can even pass those sensitive values.

Take a look at this sample, it may offer some help.

bhicken,

I am really not sure I follow your authentication scheme. Someone is either a Supervisor, or they are not. They don't suddenly become a Supervisor by looking at a certain screen. This very much sounds like the wrong approach.

Can you show an example of the type of authentication/authorization you are currently doing, by showing us some code?

Gary

Quote:

---

Originally Posted by bhicken

I currently work on a timesheet portal. One of the features is that as employees are submitting requests an email is sent out to the supervisor that lets the supervisor see that they have a request to approve. In this email is a link to the request that the supervisor can click on to take them to the link.
Currently it looks like this.

http://timeportal.fake/viewrequest.a...tType=2&Role=5

The problem with this system the way it was written is that with the information that is given a user could manipulate the system to allow them to approve one of their own requests as their supervisor. While this has yet to happen, I want to prevent this from happening. Is there a way to create the link without giving away all the information? When you login currently the system keeps all the info in a session. But when you try and follow the link the system would take you to the request page as an employee, when it should be supervisor. This confuses the user and they logout and back in going through the menus to get to the requests and in the right state.

At this point I would rather just have them goto the main menu, but that does not seem to be an option that everyone can be happy with. What other options could we try?

---

The better method will be encrypt the values in the URL and create a link and send mail.

When the supervisor clicks the link decode the url and check for the appropriate id and value. If the user Modified id then allow the supervisor to reject the the request.

Or Else send only some id, then store the other information in a table, when the user clicks the link display the information from the table.

I dunno, I am with Gep13!

If you are logging in it shouldn't matter how they manipulate the link. Because when that user logs in you are grabbing their credentials.

Maybe we don't quite understand your problem and situation.

The request information should go into a table in the database.

Then in the link you should only have one number, the "request_id", which should be an auto number ("Identity" in SQL Server).
Something like:
http://timeportal.fake/viewrequest.aspx?ID=1234

So then you get that ID, and load the data from the database.

One problem with that is that if the user manually changes the ID, he/she can view any request they want...

With SQL server there is even a better way.
You add another field, something called "Request_Rnd_ID" have it as type "uniqueidentifier", then in the "Default Value or Binding" set it to "NEWID()"

So then your link will look something like:
http://timeportal.fake/viewrequest.aspx?ID=D9AB3BDB-D4CD-47D8-9A76-522AC5A38513

Since that ID is completely random, the chances that someone would guess another ID that actually exists is astronomical.

The code is really spread out, a problem that I'm working on. I can give you a basic idea of how it works though:

All users login and their default role is Employee. Even a supervisor has to submit a timesheet as an employee. When viewing their own items they view them as an employee.

If you have employee/s under you then you have the option to look at "My Employees". This will show you all the employees you have under you and changes the Role to Supervisor. The way the system sits currently the only way to change this role is to use that menu item. The system before was set up to parse the role out of the URL. which causes this problem:

Employee recives and email:

Your request has been returned by your supervisor:
timeportal.fake/requests/view.aspx?id=555&role=3 <- meaning Employee

with that link you could then change role=3 to role=5 (supervisor) and approve your own request. Not to mention you could change ID to what ever you wanted and view/approve a request that was not yours.

I would list code but I didn't write the system to begin with and the code is all over the place. There isn't just one chunk of code that I could post to explain it. I hope that this helps explain the problem better.

I'm just looking for the best approach at solving the problem. It seems most people lean towards the encryption I'll have to take another look at that.

Besides encryption, I gave you the best way to solve the problem. And that is not to have those values in the link at all. Have your own unique ID.

Quote:

---

Originally Posted by CVMichael

Besides encryption, I gave you the best way to solve the problem. And that is not to have those values in the link at all. Have your own unique ID.

---

This is certainly one route to go.

However, I would still argue that there is an issue with the authentication mechanism that you are using.

Regardless of whether a Supervisor is submitting their own timesheet, they are still a Supervisor, that fact doesn't change.

Gary

After reading your post (#5): Yes you are correct, the user should first be authenticated (logged in), and then to click on that link... and if user clicks on the link and he/she is not authenticated yet, then the application should redirect to logg-in page, then back to that link after successful log-in.

So, both should be implemented correctly; the authentication, and also have just an ID (uniqueidentifier) in the link to hide the other parameters.

While I agree that a supervisor should always be the supervsior, that was not how the system was implemented orginally and I don't see me being allowed to change it anytime soon.

CV- I must have overlooked that post of yours, I went back and do like that Idea. I think I may give that a go.