Best way to obfuscate url parameters

[Ruud van Lent]

Hi,

not getting any 'love' on this thread: https://groups.google.com/forum/#!topic/joomla-dev-general/JSlk_xtGB0s
So probably asking the wrong question :)

I have a plugin that shows Social Sharing buttons. I have a blog component that displays an article in a kick-ass ahum nice way :)

What I want to do is the following:
When a user is logged in and shares a blog via the social media buttons, I want to add the user ID to the shared url
The blog component then reads this ID and prompts the blog with a "shared via [name of user]" where name of user is a lookup from the passed ID in the URL.

Now this works perfectly, but because anybody can add the parameter to the url it is also a security risk as you now have a way to lookup the user names...

So I want to obfuscate the ID so that it is impossible or harder to try to get the user names.
I do not have the possibility to add a table or an extra column to hold a separate ID.

So what would be the best way to achieve this?

[Mathew Lenning]

I wouldn't try to hide the user ID in the URL. Because as a general rule of thumb anything in public domain can and will be decoded.

That being said I think you could keep the user ID hidden in the back end and achieve the same outcome with a random hash xref table. 

Then just use the hash assigned to the user in the URL.

Of course this still would let them brute force the user names, but they wouldn't be able to access any IDs and generating a bunch of random hashes looking for hits would be a pain.

You could probably use two hashes to make it twice as hard to get a matching pair.

Fair warning, I'm not a security expert by any means, so this might not be the best approach. 

[Sloan]

You might have two arguments in the url, randomized, but where a certain math calculation yields the user ID. That would at least mask the actual user/user ID relationship. The best way is to use a separate table with a lookup to determine the user ID.

[seraphim]

In the question he stated that he is not able to add a separate table or column. Maybe you can put three hashes in the url. One is fake and with the other two you recalculate the userid. just a thought.

Op 19-10-17 om 13:26 schreef Sloan:

You might have two arguments in the url, randomized, but where a certain math calculation yields the user ID. That would at least mask the actual user/user ID relationship. The best way is to use a separate table with a lookup to determine the user ID.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

[Michael Babker]

Take a read through https://paragonie.com/blog/2015/09/comprehensive-guide-url-parameter-encryption-in-php

Long and short, either just pass the plain unobfuscated ID or add tracking to the database (I'm assuming this functionality is in a plugin or component, you can add your own database table with the tracking information) to have a unique randomly generated identifier.

In general, being able to gain access to the user ID or the username shouldn't be considered an information leak.  https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-disclosures-of-usernames-or-user-ids-not-a-security-issue explains the rationale for this fairly well.  In general the ID is going to be unique to an installation and having access to that information would only be beneficial if you were trying to craft a SQLi attack, which if successful means you have other issues more important to worry about than whether the user ID can be learned by a random third party.  As for the username, just as noted in the linked reference, the username is fairly often an already known public identifier (i.e. my usernames on joomla.org websites are either mbabker (my Twitter handle, already a public name) or michael.babker (my full name, already public info)).  While gaining the username may be helpful in gaining unauthorized access to an account, depending on the user's account and your site's configuration, the password would still have to be gained which would require some kind of targeted attack on that account and if a second authentication factor is configured access to that information is required as well.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send email to joomla-dev-general@googlegroups.com.

[Ruud van Lent]

Thanks all for thinking along.
@michael: your tweet with the link to the blog this week was what set me to take a step back from encryption :)
The issue with passing the ID as-is, is not only for security but also anybody can tweet the blog with somebody else user name popping up above the article: not security, but could as well be quiet annoying :S

Joomla is for me the perfect CMS and I do not want to duplicate functionality (like k2 or easyblog) but stay as close to what Joomla! core has to offer. The plus here is that maintenance of my component (which is actually a wrapper around a system and content plugin, and some authors views / front-end blogmanagent: https://extensions.joomla.org/extensions/extension/authoring-a-content/blog/ochblog/) is low and I can 'harvest' the improvements in core (as that is what I am using), there is also no importing / exporting / migrating of content etc.. Downside is that sometimes you hit a functional limitation where the easy way is to add a table (in this example) or redo part of the functionality. That is the reason that I am reluctant of adding a database and trying to figure out if it is possible in an other way.:)

Still not sure why my initial post (code) didn't work, but for now I think I will stick to obfuscating knowing that it is only working as a 'scarecrow'

If somebody has any after thoughts please share, I know I am not the only one facing this (at least I hope so :))

To post to this group, send email to joomla-de...@googlegroups.com.

[Michael Babker]

Your best option is going to be adding a database table with a mapping of hash IDs to user IDs if you don't want to directly use the user ID as the query parameter value.  And for that you don't even need to worry about using an encryption API, you can basically use bin2hex(random_bytes()) (natively those require PHP 5.6 and 7.0 but I think we've got polyfills for both in the core distro) or Joomla\CMS\User\UserHelper::genRandomPassword() to generate these tokens.  If you're really trying to stick to only using what data and APIs are available in an out-of-the-box core install, then just use unobfuscated values otherwise you end up writing some crazy logic to obfuscate and deobfuscate that value in a way that has to be repeatable (like base64_encode() and base64_decode() do).

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send email to joomla-dev-general@googlegroups.com.

[Russ Winter]

Surely, if you are only allowing this "functionality" to logged-in users, then any perceived risk is dramatically reduced anyway? As the user-account would need to have been compromised first... and as Michaels' information suggested, you have bigger issues.

And, then, seeing as your user is logged-in, to negate the risk of even a logged-in user attempting to post/tweet as another user, you check the parsed value against the users session/logged-in ID, if they don't match, don't add the additional post content, if they do match, then add the additional text.

--
Regards,
Russ Winter

To post to this group, send email to joomla-dev-general@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

[Ruud van Lent]

Hi Russ, just to clearify:

the user (ruud) logs in, presses the tweet share button to share the article. The link to the article is shared with the parameter ?sb=1234 (where 1234 is the code for ruud's account)
Now when somebody follows that link they see the article and the messagebox "This blog is shared by Ruud"

here you can see a working example: https://onlinecommunityhub.nl/community-tools/what-is-the-new-router-in-joomla-3-8-and-what-will-it-do-for-your-site-s-seo-ranking?sb=LmOyAzV0BGuwZQt2MzR1MQxmAGAwMQZ1Z2Lk
(as you can see I have currently obfuscated the user ID)

So this is not about tweeting as a different user: no security issue here :)

What another user CAN do is share any blog on my site and add the parameter ?sb=1234 and when visiting that blog it says that the blog is shared by Ruud... Ruud does not know of this...

This is not a security risk as discussed above and pointed out in the WP link that Michael shared, but it is annoying for Ruud :)

That was the reason why I wanted to obfuscate the 1234 into something that has a high chance of not working when added manually.

I will take Michaels advice and create a table for this that will hold a hash linked to an id.

[Russ Winter]

No problems Rudd, I obviously wasn't really understanding your requirements. Good luck with working it all out.

--
Regards,
Russ Winter

--