I have a client who is deploying a simple affiliate program. Currently, if a visitor comes through the affiliate link, a cookie is set on a third party domain that does the affiliate tracking.
If the person purchases something, a tracking pixel is fired that sends the record to the 3rd party domain.
Obviously this is completely insecure. If someone gets the img or js code, they can just launch a bunch of sessions on different ips and make those requests and the affiliate software will record them as conversions.
The client has no ability to add any server side code, so I can't do a simple server to server call.
Is there any way to create a secure solution using just an IMG or Javascript? I think it's not possible, but maybe I'm not thinking of something.
If there is any user-specific or sale-specific information on the sales page, you could use JavaScript to grab it and send it along inside the query string of the IMG request.
For example, if you have a invoice number, sale ID, or username on the page, and JavaScript can navigate the DOM to retrieve it, you could append that information. Even if a malicious person forges it (creates fake usernames or forges invoice numbers), you're much more likely to catch a bunch of invalid usernames or invoices that don't match sales records.
It's not 100% secure, but it gives you a little extra information that's harder to spoof.
Related
Lets say we have the following url:
https://www.sale.com/?utm_source=CDTest3Newsletter&utm_medium=CDTest3Email&utm_campaign=CDTest3FallSale&utm_id=CDT3ID
A user clicks on the link and surf through it and then close the session.
An hour later he/she navigates to www.purchase.com and a conversion occurs, is there a way to track and relate the conversion to the utm_id=cdt3id?
In Summary the conversion happens in the second domain and we want to relate that to the first domain marketing campaign!
Please note i know hot to enable linker while redirecting from origin domain to target domain!
You have to realize that this kind of behavior is not standard. Therefore, it will require non-standard solutions.
Having said that, your real problem is not the attribution. In the described scenario, you are likely to lose the user completely. Purchase.com will have no idea that this client is supposed to have the same id as on the previous site. The linker adds an explicit _ga query param to the url for the ga library on the purchase.com to know to use that as a user id and not to generate a new one.
If you're not able to reliably pass the client id to the checkout TLD through front-end, you have to use your backend to match the user by the BE auth/session token. Same exact logic applies if you want to pass the attribution data. You just keep it on the backend, bound to the user session token and throw it to the user's cookie on checkout, then grab it with GTM and populate it however you like. Or you can as well just conduct a BE redirect, appending both the _ga and the UTM query params to the url.
There are a bit more options if you're not using GA for your actual analysis. If you're able to match users and calculate attributions on your own either through ETL or persistent derived tables/SQL. So, basically, if you download your GA data to a third party storage like snowflake, asure or BQ and then use a BI tool on top of that. But at this point those options should be pretty apparent from the issue and possible solution described above.
I am building an application in NodeJS + Express where teams can share information with one and other and chat (kind of like an internal messaging forum).
Sometimes there is a need for the team's clients to view and edit some of this stored information on a case by case basis (e.g. a client asks a question and wants to message back and forth with the team, using my app). I don't want the client to have to sign up for an account in this case.
I am thus wondering what is the most secure strategy for generating a URL where anyone with the URL can view and edit a document/POST data to my app within the confines of a single document, without signing in?
(I've seen a couple of posts on this topic but they're quite old and don't focus on this specific case.)
First of all, I can absolutely understand the benefits, but still it is not an optimal idea. However, I would like to summarize some thoughts and recommendations that will help you with the development:
A link like this should not be able to perform critical actions or read highly sensitive data.
Access should be unique and short-lived. For example, the customer could enter his e-mail address or mobile phone number and receive an access code.
If you generate random URLs, they should be generated in a secure random manner (e.g. uuid provides a way to create cryptographically-strong random values).
If I had to design this I would provide as little functionality as possible. Also, the administrator would have to enter a trusted email address and/or mobile phone number when releasing the document. The URL with a UUIDv4 is then sent to this channel and when the customer clicks on the link, he gets a short-lived access code on a separate channel if possible (on the same channel if only one was configured). This way you prevent the danger of an unauthorized person accessing the document in case a customer forwards the original URL out of stupidity.
I've been developing and maintaining a Chrome extension for my company where each customer would be assigned a unique ID in the code. We've been using the ID to determine license status and login to our services (paid extension with monthly subscription fee).
So far we've hosted the extension files ourselves and had unique update URLs for each customer extension. This has been nice and simple; go to our website, click install and you're done. With the latest Chrome release, however, that installation procedure has been thwarted by Google since they now require users to install extensions by dragging and dropping the CRX files into the chrome://chrome/extensions/ tab. Unless of course your extension is available through Chrome Web Store - which leads me to the problem:
We don't want the drag and drop CRX installation - requires Web Store.
We don't want multiple versions of the extension (one for each customer) on the Web Store since that's a maintenance hell every time we update the extension.
We don't want to use Web Store licensing because:
It requires OpenID login.
We sell the extension to schools with many students where the school pays the bill - not the student.
We don't want to lock our payment method to one browser, i.e. we want to be able to maintain licensing and payment through our or servers.
We don't want to have users input a license key since that's too much of a risk with several thousand students having to input the key - also it requires some kind of storage (cookies/localStorage) which would eventually get cleared requiring the license key to be input again.
I'm not 100% certain that my statements are completely correct, so feel free to enlighten me if I missed something.
If they are, the question is whether or not we can somehow tailor the extension for each customer through the Web Store (using the unique ID) without needing to publish one extension per ID?
As a side question any answers that might solve the problem with another method will also be accepted.
For the answer below, I assume your app is a packaged app, not a hosted app.
I have a solution that's fairly similar to your current implementation, but adds one extra step for users. For the student user, the process will work like this:
Download the app from the Web Store. The app does not function yet, and launching it just displays a "Please click the activation link provided by your school/institution" message.
Click a link hosted on your server (i.e., the server where you used to host the update URL) that looks like https://myserver.com/activateapp.php?custid=123456789. You host one such link for each institution you support, and it is the institution's job to provide its link to its students. This link activates the app.
From an implementation point of view, here's how it works:
Host a page, https://myserver.com/activateapp.php, on your server. Server-side, check that the custid parameter is valid. If it is not, send a 404 error.
Your app has a content script that is injected into https://myserver.com/activateapp.php that scans the URL and picks out the customer ID. Once the app finds the ID, it stores it in localStorage. Since invalid customer IDs produce a 404 error, you know that when the content script runs, the page is not a 404 error; therefore, it is reading a valid customer ID.
Any time the app wants to query your services, it checks if it has a customer ID in localStorage. If it does, it uses that ID; if it does not, it displays a message that the app has not been activated yet. Packaged apps will never have their localStorage erased unless your app is programmed to wipe its own storage, or the user does it from the console. Storage erasure will never "accidentally" happen. Even the strongest browser-wide data/cache purge will only clear localStorage from Web pages, not from apps and extensions.
For extra security -- if you don't want people randomly guessing customer IDs -- you can add an extra signature parameter, like https://myserver.com/activateapp.php?custid=123456789&sig=2464509243. This extra parameter is some server-verified transformation of the customer ID (ideally a cryptographic signature or a purely random value associated with the ID in a database) that is impossible for anyone to guess. When the request for activateapp.php hits the server, it checks for a valid customer ID and a valid corresponding signature. Of course, this doesn't stop people who have legitimate access to a valid link from sharing the link to unauthorized people, but I expect that was a vulnerability that existed in your old system anyway.
My boss recently came to me with a security concern.
My company does research and then sends a report to the client (this report is unique for each client and contains identifying information about their business).
We email the report to the client, but we also upload it to our server and provide the client a url containing a hash that he can use to access the report online at any time. (in other words, anyone with the link can access the report)
The link looks something like:
http://www.our_website.com/report_page.php?33355-fn347rhwfh83j3f (just putting random string here is place of the hash)
The code behind the page does the following:
explodes the hash and uses it to look up the report info in the database
verifies that this hash is indeed valid according to report id and email
retrieves the report pdf from the server and displays it.
If the hash in the url does not exist or is not valid, the user get an "invalid" message.
His question is:
Clicking on the link opens the report, does this mean that Google can index these pages and they may appear in Google's search results for the whole world to see?
My gut feeling is that no, if a crawler would get to report_page.php, all it would see if the invalid message, unless it somehow had a valid hash, but I don't know this for sure, and after searching around, I didn't come up with anything to prove me right (or wrong).
Any thoughts? Thanks!
If the URL is posted on a publically accessible page, then the Google crawlers will find it and the page will be indexed. From what you say, this sounds unlikely to be the case so you should be safe. If your client happens to make the URL public though, then Google will crawl and index it. It's similar to a password: keep it private and you're safe.
It is certainly possible for a web crawler to index such pages -- lots of websites use long opaque hashes to identify pages, that alone makes no difference with regards to search engines.
You need to have a robots.txt file disallowing access to those URLs, and add the appropriate headers and meta tags making it clear that crawlers should not index them. Also, if it is really private data, the transaction should be encrypted with SSL. You might also consider having the hashes be usable once only, i.e. require that a new hash be sent by email each time the customer wants to download it. That would effectively prevent random drive-by crawlers (or people) from reading them. (although there is still a race condition between the time the email is sent and when the customer uses the enclosed hash)
in robots.txt you can disallow google and other search engine index your url
by default search engine indexed your url if you link it any where
HTTP Referer is the way I'm doing it at the moment. As everyone who's used this method knows it is not 100% accurate as the Referer header is optional and maybe fiddled with.
Looking at how-to-ensure-access-to-my-web-service-from-my-code-only I'm still unsure of how to go about this in a minimal way.
The situation:
Advertising on someone else's site. Using an iFrame so I can change content/function at will. I pay $x.xx for every time an action is completed. Therefore I need to ensure that the action is being completed from where I said it is allowed to be completed from.
What I'm trying to prevent:
some other webmaster coming along going - "hey that's a nice tool, let me put that on my site"
So as i said at the top, what i do atm is if the referer doesn't match I redirect to a page that has the same tool however whatever actions are preformed on that page they don't cost me any money.
While trying to prevent the above, allow the following:
I don't mind if the webmaster/site owner I'm paying cash to for "actions complete" puts the code on other sites - obviously this is a good thing. Lots more coverage, the site owner gets more cash & i get more actions completed, which generates me more cash.
Question
What can I get the other party to do so I know all the requests coming into my web page are from the other party I have an agreement with and not some random.
Thanks :)
info re app
other parties website has an iFrame. iFrame displays a html/js/php page of mine that sits on one of my domains. This page uses ajax requests to interact with the actual webservice that is a ruby/sinatra app. I have lots of different pages that fit into the look and feel of the other parties website.
So I'm thinking some sort of chatter between the other parties server and my server would be a good idea. Then the result of this chatter would be somehow present during the iFrame request.
However I'm not sure if the other party would be able to set a cookie for the domain being served in the iFrame - in fact I'm pretty sure it can't.
Now to get around that limitation I could have a script included as part of the iFrame on the page that could set a cookie.
Ok the above ideas summarised:
OtherParty server sends a request to my server gets a response.
renders the page with that response as a param to a <script src="...?param"></script>
my script sets a cookie
as script is before iFrame, script is loaded first
iFrame loads with page as a cookie has been set on that domain cookie set before is sent as well
bingo, request verified legit
Does this sound ok?
btw my tool that I want action completed on only works if JS is enabled so...
If you really want to secure who can load your iframe, then one way to do this is via 2-legged OAuth (i.e. have your trusted partner "sign" the iframe GET request). Then your server can grant access based on a cryptographically valid signature and a known signing party. You'll want to enforce relatively short valid lifetimes for the signed requests to prevent someone else from just copying them and embedding them in their own site.
This also gives you the advantage of just having to do an initial, offline key exchange without having your partner making extra server requests of you ahead of the iframe insertion.