CTSESSION cookie is used in WebSSO to identify a user. I wonder what does CT stand for in the name of the cookie?
I've tried to search CTSESSION word in stackoverflow, but it gives only 5 results and abbreviation of CT is not expanded there.
Related
I'm sending a mass email though Emma (3rd party vendor) that will contain a link to a landing page. The landing page will be personalized and display some of the user's identifying info (name, title, email). Additionally, there will be a form collecting a few of the user's preferences that will be saved back to that user's record in Emma's database.
The user ID column in the 3rd party's database is incremental so I obviously can't just append that value through the query string otherwise user 522, for example, would get a link such as www.example.com?landing/?uid=522 allowing him (or anyone with the link)cto take a wild guess at other values for uid (such as 523... or 444) and change other users' preferences as well as view their personal data quite easily.
Bottom line is that I'm trying to find a secure way to pass an ID (or other unique value) that I can look up via API and use to dynamically display and then resubmit personal info/data on this landing page on a user-to-user basis.
I had an idea to add a custom column to my list in Emma for a unique identifier. I would then write a script (accessing Emma's API) to BASE64 Encode the ID (or possibly email address, as that would be unique as well) and add that to the list for each user. In my email, I could then pass that to the landing page in for the form of ?xy=ZGF2ZUBidWRvbmsuY29t, but I know this is encoding and not encrypting so not all that secure... or secure at all for that matter.
To my knowledge, there's no remote risk of anyone receiving the mailing having the ability and/or inclination to know what those extra characters in the link are, BASE64 Decode, BASE64 ENCODE another email address or integer an make a request with the newly BASE64 encoded value in order to manipulate my system in an an unintended way.
BUT for the purpose of this question, I'd like to know the "right" way to do this or what levels of security are currently being taken in similar circumstances. I've read about JWT tokens and some OOth stuff, but I'm not quite sure that's possible given that I've got the Emma API to deal with as well... and/or if that is overkill.
What is appropriate/standard for passing values to a page that are in turn used for a form to be resubmitted along with other user-supplied values when giving the user the ability to submit a "compromised" (intentionally or not) form could, at worst, could cause one of their competitors to have bad preference and opt-in saved data in our Emma mailing list?
Security on the web is all about "acceptable risk". You can reduce risk in various ways, but ultimately there's always some risk exposure you must be willing to accept.
Your very best option would be to force users to be logged-in to view the page, and to avoid using any querystring parameters. That way the backend for the page can pull the ID (or whatever it might need) out of the server's session.
Your next best option still involves forcing the user to be logged in, but leave the uid in the URL -- just be sure to validate that the user has access to the uid (i.e. don't let a user access another user's info).
If you can't do that... then you could create random keys/ids that you store in a database, and use those values (rather than uid or email or real data) in the URL. BUT let's be clear: this isn't secure, as it's technically possible to guess/deduce the scheme.
Absolutely DO NOT try passing the info in the URL as base64 encoded data, that's likely to be the first thing a hacker will figure out.
Keep in mind that any unsecured API that returns PII of any kind will be abused by automated tools... not just a user farting around with your form.
To my knowledge, there's no remote risk of anyone receiving the
mailing having the ability and/or inclination to know
^ That's always always always a bad assumption. Even if the result is at worst something you think is trivial, it opens the door for escalation attacks and literally exposes the company to risks it likely doesn't want to accept.
If you're stuck between bad options, my professional advice is to have a meeting where you record the minutes (either video, or in a document) and have someone with "authority" approve the approach you take.
In case anyone needs a working example, I found this at https://bhoover.com/using-php-openssl_encrypt-openssl_decrypt-encrypt-decrypt-data/. It uses PHP's openssl_encrypt and openssl_decrypt, and it seems to work perfectly for my purposes
<?php
$key = base64_encode(openssl_random_pseudo_bytes(32));
function my_encrypt($data, $key) {
// Remove the base64 encoding from our key
$encryption_key = base64_decode($key);
// Generate an initialization vector
$iv = openssl_random_pseudo_bytes(openssl_cipher_iv_length('aes-256-cbc'));
// Encrypt the data using AES 256 encryption in CBC mode using our encryption key and initialization vector.
$encrypted = openssl_encrypt($data, 'aes-256-cbc', $encryption_key, 0, $iv);
// The $iv is just as important as the key for decrypting, so save it with our encrypted data using a unique separator (::)
return base64_encode($encrypted . '::' . $iv);
}
function my_decrypt($data, $key) {
// Remove the base64 encoding from our key
$encryption_key = base64_decode($key);
// To decrypt, split the encrypted data from our IV - our unique separator used was "::"
list($encrypted_data, $iv) = explode('::', base64_decode($data), 2);
return openssl_decrypt($encrypted_data, 'aes-256-cbc', $encryption_key, 0, $iv);
}
I first ran my_encrypt in a loop to encrypt the uid of each member in the list.
$members[$uid] = array('unique-identifier' => my_encrypt($uid, $key));
Next, through the API, I modified each member's record with the new value.
$ret = update_members_batch($members);
That only had to be done once.
Now in my email, I can pass the uid through the query string like this www.example.com/landing/?UID=<% unique-identifier %>, which will look something like www.example.com/landing/?UID= XXXXX2ovR2xrVmorbjlMMklYd0RNSDNPMUp0dmVLNVBaZmd3TDYyTjBFMjRkejVHRjVkSEhEQmlYaXVIcGxVczo6Dm3HmE3IxGRO1HkLijQTNg==
And in my page, I'll decrypt the query string value and use it via the API to get the email address with something like:
$member_email = get_member(my_decrypt($_GET['UID']))['email'];
and display it in the appropriate location(s) on my page.
I think this covers all my bases, but I am going to have a stakeholder meeting to get sign-off. What potential vulnerabilities does this expose that I should warn them about?
I'm VERY new to Selenium and only came across it when trying to find a way to do the following:
I am a member of website which has forum groups. The website does not have a search function where you can search for all users within a group who are, say, from the UK.
What I want to do is navigate to the user list within a certain group and have a script that looks on the page for the text "United Kingdom" (the country of origin is written next to each username) and then either stores the username or (more preferable) the link which the username points to.
I have managed to write bits that do things like, highlight the term "United Kingdom" etc. But I can't seem to figure out how you search for one piece of text, but store the link which sits in the same element.
Any help would be greatly appreciated!
This should work if you use java bindings, although the basic principle stays the same with other languages
String foo = driver.findElement(By.Id("xxx")).getAttribute("href");
up to a few days ago, when using Graph API search, the results were contextualized to the current user. For example, being logged in with my user so using my access token, calling a search with q=Massimo&type=user returned friends of mine named Massimo, followed by other people called Massimo, but friends of mine were above other results.
Today it just returns random people, the search seems not to be contextualized anymore.
Were there some changes? Are there new search options to get the contextualized results as opposed to generic ones? Was it a policy change for some reason? Or is it simply a side effect or a temporary problem?
TIA
EDIT:
Clarification : the search box inside the Facebook site itself, still returns contextualized content. Previously, a call to the search system via graph api returned more or less the same results, tailored to the user.
Search results are cached by query and not the user searching for something. That means the first time someone searches for something it's cached by facebook. Later, if someone else searches for the same thing, they will get similar results (not always tailored to their account). Privacy settings play a role (e.g. what information is visible and if the user can be searched). but in general, the results will be the same.
You can test this by searching for the same user using two different access tokens. The results will be relatively the same, even if one user is a friend and the other is not.
E.g. Using User A, search for User C (A and C are friends). Check the results.
Then, search for User C, but using User B (B and C are NOT friends). The results should be relatively the same (if not exactly the same.
Basically, I am writing e-mails that are sent when a person registers on my website, and it will have an activation link that needs to have a string assigned to a GET variable.
When the person clicks the link, they will be taken to a page on the site where the string will then be decrypted and matched to something in the database that is unique to them. It will then activate their account.
I'm doing this in CakePHP, so if there's any function built in, that would be preferable.
I've tried lots of options, and most of them either are really short, really strange, or have characters in them that would mess up the GET variable.
I need the output to be preferably around 20 characters, with only letters and numbers.
Simply use a random, unique string. No need for encrypting or decrypting it, it just needs to be unique, long and random. That's simply known as an opaque token. It does not have any meaning, it's just something unique that only one user is supposed to have. UUIDs are a great fit.
do {
$token = str_replace('-', '', String::uuid());
} while (!$this->User->isUnique(array('token' => $token)));
The United States District Court for the Southern District of New York in re Doubleclick Inc. stated:
"GET information is submitted as part of a Web site's address or "URL," in what is known as a "query string." For example, a request for a hypothetical online record store's selection of Bon Jovi albums might read: http://recordstore.hypothetical.com/search?terms=bonjovi. The URL query string begins with the "?" character meaning the cookie would record that the user requested information about Bon Jovi.
Is it true that a URL query string with a "?" would have the cookie record the user requested information? If so, what RFC/standard includes this?
Edit: I understand the United States District Court doesn't define standards, but I would like to have something concrete to note that they were incorrect.
If you read the whole document, you'll note that they say
DoubleClick's cookies only collect
information from one step of the above
process: Step One. The cookies capture
certain parts of the communications
that users send to
DoubleClick-affiliated Web sites. They
collect this information in three
ways: (1) "GET" submissions, (2)
"POST" submissions, and (3) "GIF"
submissions.
They are describing a process used by DoubleClick, not an internet standard.
You (and anyone else, including DoubleClick) can take information that is available to you (including information that might be sent as part of a GET submission) and store it in a cookie.
You should interpret the sentence in question (in context) like this:
DoubleClick stores information from the query string in a cookie.
The URL query string is the portion of a URL that begins with the "?" character.
The query string portion of the hypothetical URL is "Bon Jovi".
DoubleClick's process would use a cookie to record that the user requested information about Bon Jovi
Supported Conclusion:
DoubleClick takes/took information from a URL query string (which is the part of the URL that begins with a "?") and uses a cookie to record information that the user requested.
Unsupported Conclusion:
A URL query string with a "?" would have the cookie record the user requested information. There exists some RFC that describes this behavior.
It's certainly possible to store the query string in a cookie, but there is no technical standard that forces that to occur.
They are likely referencing something specific to the code on that specific website, which is presumably storing the query string in a cookie.
Cookies get set and submitted seperately from the URL, so in the HTTP-header it would look like this:
GET /search?terms=bonjovi
Cookie: $Version=1; UserId=JohnDoe
The only way the query string would be stored in a cookie would be if a cookie path is used in conjunction with rewritten URLS or if the server explicitely sets a cookie with some sort of id or the query string.
Last time I checked, the US District Court for the Southern District of New York didn't define Internet standards.
The query string does not affect the cookies, they are using technical language in a sloppy way.
That text may be just an example and you shouldn't stick to that.
Including any text in the query string does not imply a cookie is created with that information, although some sites may contain additional code to do so.