Encrypting URI Segments

[eluser]dblackherod[/eluser]
People... I am glad that this agenda has attracted this much attention and that @wanwizard is in on the conversation as well.

My point is not that controllers should be written for different user groups, neither is it that the system's design is flawed from day one... NO!

it seems only @mauricio understands what i'm getting at.

All i'm saying is... how can URI segments be safe from unnecessary traversal to access unauthorized resources by unauthorized users without refactoring a sea of code.?

The quickest way that comes to thought is URI segments encryption. Another good idea just mentioned is defining what URI segments are allowed for different user groups.

I hope this explanation gives us a clear understanding of the agenda.

The system design is not flawed because URI segments can be traversed manually, neither is it necessary to write controllers for each user group's functionality; its just so that the CI framework does not handle such for us and as good developers capable of building complex systems, we should be able to figure effective implementation approaches to problems such as this.

I still insist that encrypting URI segments is the safest approach to achieving this cause and all that are needed include;

1. A Simple Encryption class Library with encryption and decryption methods
2. A MY_Router class extension overriding the _set_request method
3. A MY_URI class extension overriding the site_url method.

A brilliant alternative would be to define which URI segment combinations are allowed for various user groups. But, on second thought, how would module developers know what groups have been created for an instance of the application such that they are able to define URI segments authorizations accordingly?

This still leaves the encryption option an undisputed approach.

Baseline remains that all I need to know is which Router and URI functions to override because I was able to encrypt and decrypt the URI segments but i became unsure which Router and URI methods to override when i realized the need for uri_to_assoc helper method uses URI segments.

I'm also willing to pay someone to make this feature a reality 'cos I was so close to achieving it...

[eluser]WanWizard[/eluser]
[quote author="John Murowaniecki" date="1332166103"]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.[/quote]

XGH :question:

I agree it's absolutely not the way to go, but I understand that if it's an existing application and you have this issue, it might be a more cost-efficient way to introduce a central 'shield' in front of your controllers instead of modifying each and every controller.

Sometimes you have to look at this from a business perspective and not from a technical/architectural perspective (even though I would hate to be forced to do that ).

[eluser]dblackherod[/eluser]
@wanwizard...

when you determine what user group accesses a URI segment in every controller method, you will agree with me that it does not solve the problem speedily.

Infact, the possibility of all user groups accessing the same URI segment but with different parameters has not been considered.

Apart from this approach being a smart and speedy one for a really huge codebase, one cannot help but agree that it is a really cool one.

All i need to knoe as a module developer are the routes that my module builds while executing as part of the entire system. To the application's user, the segments are unreadable (depending on the strength of my encryption approach).

The only observation i made in my implementation was that pagination values were not encrypted as well, which makes so much sense. Like so...

http://example.com/controller/method/par...../page/33

BECOMES

http://example.com/vN5fbHj49DcH70oKwp3VM/33

Note: the encryption method simply uses base64 encoding algorithm strictly for proof-of-concept only

[eluser]WanWizard[/eluser]
@dblackherod:

I still think encrypting the URL is a stupid idea, so don't quote me as a supporter of it. It does not provide any security whatsoever. It makes it just a little bit harder (about 2 seconds) to get in. The fact that you call it smart worries me a lot, I sure hope this is not a project for a client.

Best option is: integrate authentication and authorisation in your code. Make sure nothing is executed without.

Second best: authenticate and authorize on a URI segment level before the controller is called.

And yes, it might be complex for a large application, but that is the price you pay for poor application design. And it will provide you with real security, albeit perhaps not as granular as you would like.

[eluser]John Murowaniecki[/eluser]
[quote author="dblackherod" date="1332174574"]@wanwizard...

...
http://example.com/controller/method/par...../page/33

BECOMES

http://example.com/vN5fbHj49DcH70oKwp3VM/33
..[/quote]


[quote author="WanWizard" date="1332179993"]@dblackherod:

I still think encrypting the URL is a stupid idea..[/quote]

dblackherod: dude, is you REALLY want to proceed this way may some

Code:

$route['(:any)'] = 'your_security_control/method/$1';

So, in your_security_control.php, you'll have one method to redirect the user to the correct controller/method/arguments that you need.. But I prefer to extend some core/controller and change the constructor behavior to check the sessions userdata for what the user can execute or not.

Remember that if you use '(:any)' in your routers you'll ovewrite any standart call to your controllers.. So if you proceed this way you'll need to put all your controllers on routing..

..But you can get some http://youtapplication.com/secret:275876...84b799a790 changing the permitted uri chars on your config file and setting a route ['secret\:any)'] to your pog function.

..But I sustain the strong opinion that you need look other ways to solve this problem..






@WanWizard: XGH is a development methodology and planning - eXtreme Go Horse (widely used and disseminated in forums for weekend programmers).. hehehe

[eluser]pbflash[/eluser]
I agree that encrypting the URL is not a good idea. When building any application my first step is to setup security and ACL. I have been using ion_auth and I build my own ACL. Groups and permissions can be changed in the admin area. I then have an admin and frontend controller that extends MY_Contoller and they check the users group to see if they are permitted to access the controller. Then my methods will check to see if the have permission to access the method.

Just because CI doesn't have auth and ACL included does not mean that an application should be built without it. Doing so was a design flaw from the start. Encrypting the URL is just covering up the mistake and it wouldn't be long before someone figures it out and exploits your application.

[eluser]srpurdy[/eluser]
[quote author="dblackherod" date="1332173528"]All i'm saying is... how can URI segments be safe from unnecessary traversal to access unauthorized resources by unauthorized users without refactoring a sea of code.?[/quote]

I don't think people mis-understand what your saying. Sure having an encryption library as an option isn't a bad thing, but still designing your code so this is not possible should be done anyway.

I wrote a multi-site system that has about 20-30 active sites using the system it's 1 giant code base. Those users that have a website under this system all use the same methods for various controls that the system allows them access too. I even give them the ability to give access rights to other users. This required a lot of code logic for each function to work. It makes each function much more complicated but it's how it should be done in a system where you allow that much control. It's a massive system however so I'm sure even with all the extra work I did to make sure things were locked down I probably even missed some. (it's possible) but I wouldn't try to hide that with encryption. I rather fix the problem.

That's not saying an encryption library doesn't have a place. It probably does, but I think your using it or want to use it for the wrong reasons.

If you can explain how someone would get around this. Let me know.

Code:

function your_function()
{
if($this->uri->segment(3) == '')
  {
  echo "Direct access not allowed";
  }
else
  {
  //Check the users ID
  $data['userid'] = $this->user_model->check_id();
  
  //Extract ID
  if(!$data['userid']->result())
   {
   $data['new_id'] = '';
   }
  else
   {
   foreach($data['userid']->result() as $getid)
    {
    $data['new_id'] = $getid->id;
    }
   }
    
  if($data['new_id'] == $this->db_session->userdata('id') OR $this->freakauth_light->isSuperAdmin())
   {
   //Form fields here......
   $this->form_validation->set_error_delimiters('<h5>', '</h5>');
   if($this->form_validation->run() == FALSE)
    {
    //your view file template etc....
    }
   else
    {
    //form validation was sucessful do whatever....
    }
   }
  else
   {
   if(!$data['new_id'])
    {
    $data['new_id'] = '';
    $this->site_error->error_four_zero_four();
    }
   else
    {
    $this->site_error->access_denied();
    }
   }
  }
}

You could also do some things that get repeative and move them into 1 single function and just call the function at the beginning of the function. Depends on what your doing of course.

Shawn

[eluser]aquary[/eluser]
"Unreadable" doesn't mean "Inaccessible"....
The case here sounds like this to me:

A: "Hooray, I got Javascript validation on the form before submitting them. No more server side validation!! LOL
B: "What happen if I disable javascript?"

[eluser]dblackherod[/eluser]
Alrighty people... so you all think this is a stuuuupid idea right?

what happens when i use an encryption mechanism that uses my own secret key?!

Anyways I'm proceeding with my cause and I'll have it up on github for anyone who needs that functionality for their applications.

MAybe then, i'll do a downloads count and gloat when it burns out the rooftop... :lol:

This would be soon enough 'cos people I am really close. I'm just using Base64 for proof-of-concept but believe me... when its done and we use a 128-bit encryption algorithm, then it'll be something worth using.

Thanks people for the thread build... CI sure has appdev rocking steady. ;-)

[eluser]CroNiX[/eluser]
*ambiance of crickets chirping*