+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived Development & Programming (https://forum.codeigniter.com/forumdisplay.php?fid=23)
+--- Thread: Encrypting URI Segments (/showthread.php?tid=50140)
Encrypting URI Segments - El Forum - 03-15-2012
[eluser]dblackherod[/eluser]
Greetings...
How do I get to encrypt CodeIgniter URI segments such that it is not human readable via the address bar of the browser but then it is decrypted internally before any classes and helpers using uri segments data can use them and encrypted back before displaying in the address bar of the browser?
What I intend to achieve:
--- http://example.com/Controller/function/param/value
BECOMES
--- http://example.com/Zfg0sOl43mnQZf3N
I've been peeping inot the core of the framework and discovered that;
1. Any well written Encryption Library will do.
2. Router class (_set_request method) MUST decode the encrypted url segments
3. URL helper (site_uri function) MUST be over-ridden to encrypt uri segments
4. URI class ( ? method(s) ) MUST also decode (..and also encode?!) the encrypted uri segments.
What I do not know is what URI functions to override.
Infact, when I override uri_string method of URI class to decode the encrypted uri_string, i get an error_404 (Missing Resource). All i'm doing is trying to set the uri_string variable of the parent class (URI) to the decrypted format.
Code:
class MY_URI extends CI_URI {
var $uri_string;
function __construct() {
parent::__construct();
}
function uri_string() {
return MYENCRYPTIONCLASS::mydecryptionmethod($this->uri_string);
}
}I expect that the uri_string variable is set, then all methods requesting it should get this updated value
Please help!
By The way, it would be excellent if this was a uri_protocol option in APPPATH.config/config.php just like AUTO, REQUEST_URI, etc.
Encrypting URI Segments - El Forum - 03-17-2012
[eluser]fuchong[/eluser]
I guess my first thought is why do you have to encrypt the controller and method you're calling? It would seem like you would be doing a lot of extra work to make these obscure. You might be able to write a hook for what you're doing, but why not just encrypt the parameters that are being passed around using the CI encryption library?
I think that the idea of what you're doing is interesting, but I'm assuming that the problem you're trying to solve can be done in an easier way. If there a chance you tell us what you are attempting to accomplish by hiding all this information?
Encrypting URI Segments - El Forum - 03-17-2012
[eluser]dblackherod[/eluser]
i just realized that:
controller/users which lists all users for admin group can be accessed by a less privileged user who should only be able to edit his/her profile via controller/users/id/7 by simply traversing the url to read controller/users.
one might argue that this is a design approach error and a simple method call in the controller's constructor to check whether the logged in user is a member of an authorized group should sort this out but NO!
what happens when the same controller needs to be accessed by both groups but the functionalities for both groups should be isolated? i.e. controller/settings/others can be sccessed by every group but controller/settings should not.
besides the controllers to be edited are so many all that refactoring is too much work compared to fixing up a brilliantly simple library and helpers to obfuscate the uri segments
Encrypting URI Segments - El Forum - 03-17-2012
[eluser]CroNiX[/eluser]
Good luck with that approach. It would be better to fix the flawed design plan (it sounds like it wasn't planned out to begin with). Obfuscation is not security and it will probably come back to bite you. All you are doing is providing a url that doesn't look as good, but if discovered, can be very destructive. Someone will figure it out, they always do.
Encrypting URI Segments - El Forum - 03-17-2012
[eluser]Mauricio de Abreu Antunes[/eluser]
Tell us: why are you doing it? I really wanna know.
Encrypting URI Segments - El Forum - 03-19-2012
[eluser]dblackherod[/eluser]
@CroNiX
I did not say it was a design approach flaw... I said it could be argued that way but that argument would be wrong.
@mauricio
I already explained why earlier in the thread.
One thing worthy of note here is that...
The design approach is not flawed as one might be easily led to think. Unfortunately, CI does not provide any form of AOP functionality that would allow me to secure my controller methods and it would take a while to provide such functionality via 3rd party libraries.
Having said that, it'll suffice to know that my design approach goes thus...
1. Every Controller after successful login extends an Admin Controller that loads the necessary helpers and libraries. The controller handling session management extends the CI Controller class directly.
2. Every functionality that a controller provides is available within that controller; there are no 2 or 3 or X controllers providing the same or different functionality for different user groups.
So, there isn't A controller for A group and B controller with a subset of functionalities for B group and C controller for C group... like that. Also, considering that the system is modular in nature, it does not make much sense to have module developers writing controllers for different user groups in the system - what happens when the application's admin creates new user groups which module developers have no way of knowing?
I do not know if any other approach exists cleaner than this and if there is, i would love to learn that as well.
So, in effort to avoid code refactoring that spans an entire application, i think it only makes sense that the URI segments which are on display should be encoded/obfuscated/encrypted such that only the application developers know what is going on internally. The users simply enjoy the application and are not tempted to start messing around with the URI segments just to see which ones shoot money out the screen... :lol:
Encrypting URI Segments - El Forum - 03-19-2012
[eluser]aquary[/eluser]
Still cannot understand why would controller A have to be made for user group A, and controller B, which is similar to group A with some exceptions, for group B and so on.... The way you speak would happen only by the flaw in your system analysis and design.
Sure it's waste of time to copy&paste; codes to create one controller for each group. That's why nobody do it. Take a look anywhere and you'll see that no one ever do things in that approach.
Normally I love to do "reinventing a wheel" by myself, as a practive to improve my logic and coding ability. But yours is to "Create something to replace a wheel"
What people do about this stuff, at least for me, is to check if the user is in a group could use the current section or not. However, the checking is not on the controller itself, but rather directly on the method. So, by your example, the URI controller/users/id/7 would be accessible for each user to edit their profile. But, it doesn't mean he could simply traversing back to controller/users and access it since the authentication is also in controller/user, which prevent them from accessing if they are not in a right group.
That's why ppl said it's a flaw in the design if a user could access the prohibited area. They could do it because the developer either "allow" them to do, or "forgot" to close the hole.
Encrypting URI Segments - El Forum - 03-19-2012
[eluser]WanWizard[/eluser]
The point is that security, authorisation and access control management should be part of the design of every application from day one. And it seems to be this is not the case here.
I don't think anyone is arguing different controllers should be written for different user groups, the point is that your controllers should perform their actions based on the access rights of the current user.
The fact that you mention refactoring to build ACL's in means CroNiX is right, and the design of the application is fundamentially flawed. A problem you don't fix by encoding URI segments.
One possible solution is to do your ACL checking centrally by extending the Router class. Have it check if the current user has access to the combination of URI segments, and only route to the controller if it passes the test. This will work as long as you don't have code in your controller that has to behave differently based on the ACL while having the same URI segments.
Encrypting URI Segments - El Forum - 03-19-2012
[eluser]Mauricio de Abreu Antunes[/eluser]
"I don’t think anyone is arguing different controllers should be written for different user groups, the point is that your controllers should perform their actions based on the access rights of the current user."
I agree!
Encrypting URI Segments - El Forum - 03-19-2012
[eluser]John Murowaniecki[/eluser]
[quote author="WanWizard" date="1332151291"]The point is that security, authorisation and access control management should be part of the design of every application from day one. And it seems to be this is not the case here.
I don't think anyone is arguing different controllers should be written for different user groups, the point is that your controllers should perform their actions based on the access rights of the current user.
The fact that you mention refactoring to build ACL's in means CroNiX is right, and the design of the application is fundamentially flawed. A problem you don't fix by encoding URI segments.
One possible solution is to do your ACL checking centrally by extending the Router class. Have it check if the current user has access to the combination of URI segments, and only route to the controller if it passes the test. This will work as long as you don't have code in your controller that has to behave differently based on the ACL while having the same URI segments.[/quote]
[quote author="Mauricio de Abreu Antunes" date="1332156646"]"I don’t think anyone is arguing different controllers should be written for different user groups, the point is that your controllers should perform their actions based on the access rights of the current user."
I agree![/quote]
dblackherod there are many ways to do what you really need, but encrypt urls isn't the best choice.. In truth this form is one of the worst, not to say palliative and unsafe.
WanWizard for security reasons and authorization we have session identifiers, temporary and unique tokens, etc.. For me, extending the Router class is another way to improve the initial XGH way - so this doesn't solve the problem.
Mauricio é, né?!