I ask your help to better understand if my cross-domain tracking (Adobe Analytics via Experience Cloud ID) is working properly. To me it seems not.
As you see in screenshot 1, my visits might come from Domain A and go, within the same session, to Domain B. We're collecting data, from both domains, to the same AA Report Suite.
The Experience Cloud ID Service is active, in the same way, to both configurations (same mc org id, as you see).
Into Analytics Workspace (screenshot 2) I created a fallout analysis to show how visits move from Domain A to B. The Analysis is based on two segments including visits that in turn include hits for domain A or B.
I expected to see Domain A visits to be distributed also to the Domain B, but it seems not. No visits are going there...how could it be?
Am I missing something with the Experience Cloud ID configuration ?
Thanks so much
The out of box setup for Adobe Experience Cloud Visitor ID Service requires the browser to be able to access a third party call to a subdomain under demdex.net, and then stores a cookie containing the user's identifier under demdex.net domain. See Adobe's KB for more detailed description of the process.
If the browser for whatsoever reasons cannot save or read the cookie, then as the visitor goes from site A to site B, the JavaScript JS library (i.e. Visitor.js) will keep requesting on a set of identifiers from demdex.net or failing contacting demdex.net generate a set of identifiers locally.
Related
So I have a website that send phishing emails for employers and I get the results for this campaign (for example how many employees click on the link, etc)
While testing my website on my personal emails the website became dangerous.
What should I do ?
Disclaimer - I run a phishing simulation service called CanIPhish and I came across this exact same issue when building my phishing websites.
What's happening here, is google is discovering and analysing your website through both it's normal indexing capability but also by scanning emails and detonating links.
When Google or it's threat intelligence partners discover your website it's analysing the content and accordingly flagging it as malicious.
To get around this issue, you need to hide the website behind a load-balancer or CDN which can perform conditional routing based on querystring parameters. Within the querystring you need to create a single-use GUID tied to the campaign and target. When the target detonates the link, they're forwarded to the phishing website and the GUID becomes inoperable. This way, when google or a threat intelligence partner index the site or detonate links in an email, they see something completely different to what your actual targets see.
I'm operating my myriad of phishing websites by hosting them on Amazon S3, I'm using Cloudfront as the CDN, Lambda#Edge on Cloudfront to inspect QueryString parameters and a mixture of DynamoDB with S3 for storing target user details and details on whether a GUID has already been detonated.
To see an example of this - try browsing here and all you'll see is a "Oops you clicked a phishing link" instead of the actual page which is a Google phishing site.
I have been publishing my site to Azure and I've been restricting IP addresses so only people on my list can access the url ex. mysite.azuretestsite.com. But now I want to show people but I don't want to have to ask everyone for their IP address just to give them permission to view it.
The one thing I'm worried about is bots/web scrappers like Google who will pick up my site and then it might end up in their search results or for other purposes, which I don't want to happen before I go live.
Should I be worried about having the site live even though I have't registered the domain name yet? What are the pros and cons here and does it really matter if nobody know the site url? I'm more worried about bots/etc
Normally, crawlers won't know your site mysite.azurewebsites.net exists, unless you have outbound link, and the landing website happens to turn on analytics.
For that case, there is nothing you can do about it. Otherwise, you have to ask user to sign-up before viewing your site.
I would love to get advice on my current project structure idea. I have been searching regarding node.js multi domain packages but i am not sure if they will suit. I also would like to have a easy to manage apps eg. if i want to modify specific app, i have a feeling a single app will get really full and confusing to manage code wise? Basically i am building a website that will have:
Landing Page - www.maindomain.com
User Dashboard - members.maindomain.com
Admin Dashboard - admin.maindomain.com
Now each subdomain app can communicate to each other if they have the credidentials etc.
Would it be correct to create separate 3 Apps to handle each of the sites?
Is there any security concerns having this kind of 3 app setup?
Can account creation occur upon paypal payment?
Ideal flow would be User visits website on landing page and selects a paid package which in turn would direct to paypal. Upon payment user would be returned to website with account creation form, and said Package(order) would become an option on user dashboard.
Admin can pretty much view everything via admin dashboard pretty standard, setup promos etc.
Thanks for your help and advice.
I'm designing an online store with Wix.
They have a great graphic interface which allows non-developers like me to build a professional-looking online store.
However, since I'm a noob in online security, I have this concern - the Wix webpage doesn't support SSL within their pages. But as soons as the customer clicks check out to begin the paying process, he is redirected away from the Wix site to the merchant account page (like paypal etc). The merchant do support SSL.
I'm assuming that although the Wix webpage doesn't support SSL, there is no risk envolved for the customer since he'll be entering his credid card info etc in the merchant account page. Is this correct? If I'm not clear, here is the Wix explanation for the matter:
Is Wix eCommerce secure?
When a customer makes a purchase on a Wix eCommerce site or a site with a PayPal or the Add to Cart button, the only information added by the customer on the Wix site is the product and any product options. Once a customer clicks Checkout, the customer is redirected away from the Wix site and to your merchant account page. Any personal or payment details that the customer has to enter are therefore not entered on the Wix site but rather on the merchant account site which is secured by the merchant account. For more information about exactly how they encrypt and secure payment information, please contact the relevant merchant account.
I'm also assuming only this risk (from the customer's perspective). Are there more risks involved in the Wix website by not supporting SSL? Maybe hacking the website or something? (from the seller's perspective)
This question might be suitable for serverfault.com instead.
But as it's related to development I'll try to answer it to the best of my ability:
When the connection is not carried over SSL (or any other security measure), the traffic is interceptable and malleable. This means that you can not trust that the data you are getting is actually from the user, unaltered. Additionaly, the user cannot trust that he is in fact talking to your server directly without someone in the middle snooping or altering the data.
Seeing as the payment system is a separate system that does allow for SSL, then you have the most obvious security issue covered. It is then up to you to evaluate whether anything up to that point can be considered sensitive. (for example username and password, if the store requires a login).
A good rule of thumb is that "Anything not encrypted is potentially known by anyone. In addition it is also alterable." Say a user wants to place an order, and clicks the appropriate buttons and links to get to the payment system. Now, if a MITM attacker wants to snoop the credit card details, he can intercept the traffic and substitute the buttons and link to trick the user to his own system, made to look like yours, with the only purpose of gathering credit card details. Attacks like this are possible because the average user doesn't know or care about the danger of accepting certificates from untrusted sources, and it is hard to combat unless awareness is raised around the issue. I have seen online shops display a warning before accessing the payment system that the user needs to verify that the certificate actually stems from their server, and that the URL is still refers to their webshop.
...But i digress. To sum up: You've got the important part secure. As for the rest, there are some pitfalls, but manageable if handled properly.
I have a client that has chosen to use Business Catalyst for their public facing services, and they want to access roughly four different servers for various activities. The design team has put forth a requirement to be able to log into these various servers using unique login forms on Business Catalyst for each destination.
The first issue is in having a login form within an https page. Business Catalyst has "secure zones" which can be exposed to users that have already logged into Business Catalyst, and I believe there is a way to do so without login by opening up the secure zone to a range of IP addresses. That doesn't feel like a good faith move by any developer (the secure zone is an oxymoron if it has to be exposed to everybody), so let me know if that passes the insanity check. Having the user login to Business Catalyst just so they can login to one of the secure servers is not going to work from a UX perspective.
The second issue is that Business Catalyst states that it must be within a secure zone before it can do any work with the external tools I need it to work with. This might be solved by resolving the first issue, but this has more to do with form queries in general. I have content modules that need to query these servers, without login, to pull non-critical information down as a response.
I have performed a non-exhaustive search over this weekend to try and find a graceful solution to this challenge, but it doesn't appear to be something that Business Catalyst was designed to handle.
For those of you who TLDR;
I need a secure way to login to 1 of 4 servers from Business Catalyst without login to Business Catalyst (Current implementation theory noted above).
I need a way to query non-critical information responses from 1 of 4 servers, again without login to Business Catalyst (Such as returning cost estimate results).
It is not acceptable to have the user login to Business Catalyst, just to pull queries or login to 1 of 4 servers.
It may not be possible to allow a user to access the other servers using their Business Catalyst session handles.
When user logs in to BC, he will get cookie in form VSVxxxxx, where xxxxxx is BC site ID. Content of cookie is hashed active session ID. Then BC exports two web service API - CRM and eCommerce. In CRM web service there's method Contact_IsLoggedIn, which take two parameters - user ID and session ID. Session ID is one from user VSVxxxxx cookie. It returns true/false, whether user is really logged in BC.
Note that BC have bit strange session handling... it lasts for 30min. no matter whether user clicks on site, or no.