Issue Url Encrypted

[whitesnake82]

Hello Guys,

I have this problem , I want to encrypt the url mantis issue for security reason for example:

http://localhost/mantis/view.php?id=100

to

http://localhost/mantis/view.php?id=ee4 ... f880169bd9

and when one user click on the url http://localhost/mantis/view.php?id=ee4 ... f880169bd9 show the issue view

[atrol]

A clean solution for it would require a major redesign at some places.

[whitesnake82]

well that it's I'm doing ... but I don't find the way to change the id that do the query for another variable

If somebody can help me Thanks

[whitesnake82]

If someone could help me ... well what I'm doing is convert the id number to base64_encode and save to new field in mantis_bug_table (database), so if I have id = 1234 and the field "code" save = MTIzNA ... what i want to do is search the url by view.php?code=MTIzNA instead of view.php?id=1234, or what is the function to modify

[paul]

Ok, I'm interested, out of interest, whats the requirement/reason for doing this?

Whilst I think I know what you are going to say, and I can see some cases where it might be desirable, i'm just wondering what the rationale you have here is

For instance, anything that refers to a bug by ID - i.e. update/export/etc would need to be changed to display the long ID, otherwise you potentially negate the purpose of hiding it in the first place - or at least, you could give someone a set of userid<>encrypted id's to try to decode. (you mention you are base64_encoding the number - I *assume* you are doing more then that, otherwise it would be fairly easy to reverse)


Paul

[whitesnake82]

Ok, I'm interested, out of interest, whats the requirement/reason for doing this?

Whilst I think I know what you are going to say, and I can see some cases where it might be desirable, i'm just wondering what the rationale you have here is

For instance, anything that refers to a bug by ID - i.e. update/export/etc would need to be changed to display the long ID, otherwise you potentially negate the purpose of hiding it in the first place - or at least, you could give someone a set of userid<>encrypted id's to try to decode. (you mention you are base64_encoding the number - I *assume* you are doing more then that, otherwise it would be fairly easy to reverse)


Paul

first, thank you for your interest

well the reason is I'm using mantis for our company, so any user can "play" with the number of id and see the issue information that they should must not see ... and i believe that i use the id encrypted by any method of encriptation, the user will not interest to see another issue that have confidential information

thanks and sorry for my bad english

[paul]

hang on - this sounds more like a configuration issue - i.e.

do you actually want to:

a) 'encrypt' the urls

b) ensure that permissions are set up correctly such that users can only see what they should be able to

If B - who are your "users"? - internal / external? etc

[whitesnake82]

hang on - this sounds more like a configuration issue - i.e.

do you actually want to:

a) 'encrypt' the urls

b) ensure that permissions are set up correctly such that users can only see what they should be able to

If B - who are your "users"? - internal / external? etc

well a kind of configuration ... and my answer is a) 'encrypt' the urls , first the permission are already configurated in my mantis , and if you're not a user registered then you can see the issue like user guest without links to another zone in mantis only see that issue

now my idea is for example you have http://www.mantisbt.org/bugs/view.php?id=17344 , anyone that have access to internet in any place of the world can see that page and see the information, and go to the links inside the issue like bugnote /wiki/history/etc and if you're more curious if you change /view.php?id=17344 to /view.php?id=17343 you'll know have access to see another issue and their information ... so if I have my mantis publicated in a public server and someone person meet my mantisbt and start up to look inside then he know about confidencial information inside my company considering we already set the permissions for a guest user to see the basic information of the issue

I think if you have something like id=RGFVFREFGHJUIOOJM o whatever the method to encrypted, that number or code will be more security for the company

[paul]

But would the guest user not be able to access the view_all_bug_page.php and search for an issue - thereby finding the URL in this context anyway? Or more, what are you doing at the moment to stop that?

To implement this I could basically see two approaches:

i) something that encrypts/decrypts the query string values
ii) store a GUID/UUID value in the database table for any user/bug object i.e. sprintf('%04X%04X-%04X-%04X-%04X-%04X%04X%04X', mt_rand(0, 65535), mt_rand(0, 65535), mt_rand(0, 65535), mt_rand(16384, 20479), mt_rand(32768, 49151), mt_rand(0, 65535), mt_rand(0, 65535), mt_rand(0, 65535));

Whilst I can see some merit behind not use ?id=X, I'm just wondering what stops a user from getting the list of id's from the view all bug page anyway?

Paul

[whitesnake82]

Yes, the user guest can't be able to access the view_all_bug_page.php because I modified the permissions

i) Now I added the codeline in the source of mantis that when you created a new issue automatically add the id encrypted to a new field in the mantis_bug_table (database)

Now when I'm going to the url view.php?newfield=AaBUhGTrFrTfDdvbnjiUHK to find the issue , it show me an error like

Code: Select all

APPLICATION ERROR #200

A required parameter to this page (id) was not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

[paul]

Ok - been thinking about this slightly more.

a) Given we have our SOAP API etc, and that you were concerned about guest users - I'm wondering if it would be easier to create a custom 'guest' page that you publish (that removes the 'confidential' information.

b) I think you'll need to show/leave the existing ID same and visible (and somehow add a second verification parameter for what you are doing. - see below for an idea )

P.S. I can't help but think 'encrypting' the url's in this way is the wrong solution to the problem - or at least i'm not understanding the problem correctly (in terms of the code)

---------------

a) We currently utilise the ID's in various places - removing this is going to be problematic.
b) You probably want to check who/what can access the SOAP API in your configuration (as that could be used to bypass what you are trying to do if not configured properly)
c) You will need to be careful about the information that can be disclosed if for example someone uses the 'search'/'filter' issues feature of mantis or the export features of mantis

In terms of 'view.php', quite frankly, i'd leave the id=5 visible (I suspect something will leak it otherwise anyway) but then add a 2nd parameter &verifyid=foo.

Depending on who you are trying to protect (and whether the people are all valid users), i'd then look at:

string_api.php - string_get_bug_view_url and string_get_bugnote_view_url [P.S. search the source for view.php for other places to consider]
view.php - add a check at top of patch to compare id and verifyid values are valid.

So for example, if your concern is that people could copy view.php URL's around, and they were all valid users accessing the system, you could make string_api generate a url that has ?id=5&verifyid=md5( "secret". $id . auth_get_current_user_id() )

Somewhere near the top of view.php it would then be rather trivial to rebuild this with something like:

if( $_get['verifyid'] !== md5( "secret" . $id . auth_get_current_user_id())) {
echo "sorry no pasting links allowed";
}

Of course, this is the wrong solution if you need to be able to copy/paste links to people, but I'm sure you get the idea I'm thinking of. My wider concern is having done this, how many other ways in Mantis there are to bypass this - soap api, filter/search code etc

[whitesnake82]

Ok - been thinking about this slightly more.

a) Given we have our SOAP API etc, and that you were concerned about guest users - I'm wondering if it would be easier to create a custom 'guest' page that you publish (that removes the 'confidential' information.

b) I think you'll need to show/leave the existing ID same and visible (and somehow add a second verification parameter for what you are doing. - see below for an idea )

P.S. I can't help but think 'encrypting' the url's in this way is the wrong solution to the problem - or at least i'm not understanding the problem correctly (in terms of the code)

---------------

a) We currently utilise the ID's in various places - removing this is going to be problematic.
b) You probably want to check who/what can access the SOAP API in your configuration (as that could be used to bypass what you are trying to do if not configured properly)
c) You will need to be careful about the information that can be disclosed if for example someone uses the 'search'/'filter' issues feature of mantis or the export features of mantis

In terms of 'view.php', quite frankly, i'd leave the id=5 visible (I suspect something will leak it otherwise anyway) but then add a 2nd parameter &verifyid=foo.

Depending on who you are trying to protect (and whether the people are all valid users), i'd then look at:

string_api.php - string_get_bug_view_url and string_get_bugnote_view_url [P.S. search the source for view.php for other places to consider]
view.php - add a check at top of patch to compare id and verifyid values are valid.

So for example, if your concern is that people could copy view.php URL's around, and they were all valid users accessing the system, you could make string_api generate a url that has ?id=5&verifyid=md5( "secret". $id . auth_get_current_user_id() )

Somewhere near the top of view.php it would then be rather trivial to rebuild this with something like:

if( $_get['verifyid'] !== md5( "secret" . $id . auth_get_current_user_id())) {
echo "sorry no pasting links allowed";
}

Of course, this is the wrong solution if you need to be able to copy/paste links to people, but I'm sure you get the idea I'm thinking of. My wider concern is having done this, how many other ways in Mantis there are to bypass this - soap api, filter/search code etc

Yeah , but where I'll find the place to put the code to modified and put the conditional that you wrote ... viewing the example that I expose before

Code: Select all

APPLICATION ERROR #200

A required parameter to this page (id) was not found.

Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section.

The page is requesting a number of id , where is the place of the whole code that I could find that requesting of id and add the new code for request more parameters like " . $id . auth_get_current_user_id()"