I have a couple of questions about the OneSignal notification service. I have been reading the documentation and there are couple of things that bother me security-wise or I'm missing something.
As I understand the process Javascript client uses the Web Push SDK to communicate with the OneSignal API. To instantiate the communication it needs appId parameter, which is available to client.
After that the client can call getExternalId, getEmail, getTags methods to potentially gather user sensitive data. Once in possession of that data on some other device methods setExternalId and setTags can be called with gathered data to impersonate other user and receive notifications directed to them (at least those that get routed using the set parameters).
Does OneSignal presume that device (endpoint) is not compromised?
OneSignal doesnt see setExternalId misuse as a security concern, as notifications shouldn't include sensitive information, as stated in their webpush SDK github.
Only recommendations they do about external_id are its uniqueness, and complexity.
Clients can only call getTags, getEmail, getExternalId, and other methods if they know the subscriber's OneSignal player_id. Since the player_id is only known by the client, it is not possible to impersonate the user or to get this data.
Even so, OneSignal recommends against storing sensitive data in tags or other fields.
Related
I building chat application with pubnub,
I have setup everything both backend and frontend,
but in front-end, it requires another argument for UUID. Can anyone tell me where can i get the UUID? how to generate it with pubnub? Do i need to store the UUID in my datbase?
const pubnub = new PubNub({
publishKey: 'myPublishKey',
subscribeKey: 'mySubscribeKey',
uuid: 'myUniqueUUID'
});
Pubnub docs it seems worst, i have not found any information regarding generating UUID, Can anyone tell me how can i resolve it?
PubNub UUID Management Best Practices
The UUID should be something that, as the acronym implies, uniquely identifies the user (or device, server instance, etc.). The UUID can be whatever you see fit to accomplish this in your applications but there are some guidelines you should follow with respect to PubNub.
This is well-documented in the PubNub Platform Documentation, so I am not going to repeat all of that here. Please review Users & Devices: Identity Management docs, under the Connections section, for the full story.
TL;DR
Generate a UUID for the user when they register as a new user and store it in their user profile record in your system (or use PubNub Objects: UUIDMetadata).
Upon successful registration/login of a user, pass the following back to the user (the client PubNub application):
subscribe key
publish key (only need if client can send messages)
uuid (there are UUID generator APIs in PN SDKs - you can make your own but you should avoid using any PII as the UUID).
auth key (this has to do with PubNub Access Manager and not related to this post, but should be implemented for production applications)
use the above to init your PubNub object
each user/client/device should use the same UUID everytime the PubNub object is created
each server instance should have its own UUID. This can simply be a server instance name or identifier
Why are UUIDs Important in PubNub?
Again, it's all detailed in the same docs page under the UUID Impact section, but here's the highlights:
For billing purposes - it is used to calculate MAUs (Monthly Active Users)
For Presence service to work properly - uuid value is used to generate join event when a user subscribes to a channel and for all presence events and APIs.
For easy troubleshooting - if you ever have to contact PN Support, it makes it a lot easier to identify a user across multiple subscribes and other API calls if we can single out a UUID.
Have a Realtime Day!!! ;)
This is in ruby:
Pubnub::UUID.generate
I am developing a chat app and in frontend i am using reactjs
for reactjs, i am using this library: https://www.npmjs.com/package/pubnub-react
I see here, the subcribe and publish key is exposed in frontend, My question is, it it secure to add such key in frontend?
here you go for sample code:
const pubnub = new PubNub({
publishKey: 'myPublishKey',
subscribeKey: 'mySubscribeKey',
uuid: 'myUniqueUUID'
});
PubNub Access Manager
Quote from Stephen Blum (founder and CTO of Pubnub) from an answer to a duplicate question:
This is the same problem with Facebook. I can open your FB page and copy your auth_key from the network tab and gain access to your Facebook page. You must treat your PubNub auth_key the same as you would a secret intended only for the user. This is like a Session Key/ID that allows access to a data stream, similar to the way Netflix, Spotify, Facebook and Gmail provide a secure access layer.
To summarize, you cannot hide the PN keys but you can secure them by enabling and implementing PubNub Access Manager.
Read the docs from the link above, but this question has also been answered a couple of times before on Stack Overflow. The code samples there are older but the concept is the same:
Secure Pubnub subscriber key and channel name
how to hide pubnub keys when using JS
Also, always pass the pub/sub keys back to the client app from your server (along with the auth-key and the UUID) rather than hardcoding them into the client code. This allows you to swap the keys if you ever need to do so. It's rare but can be super-useful if you ever need to.
I have a Cloudflare Worker that presents a registration form, accepts input from the user that is posted back to the Worker which then sends that on to an Node HTTP API elsewhere (DigitalOcean if that matters) that inserts the data into a MongoDB (though it could be any database). I control the code in both the CF-Worker and the API.
I am looking for the best way to secure this. I am currently figuring to include a pre-shared secret key in the API call request headers and I have locked down what this particular API can do with database access control. Is there an additional way for me to confirm that only the CF Webworker can call the API?
If this is obvious to some I apologize. I have always been of the mind that unless you are REALY good at security it is best to consult those who are.
You can research OAuth2.0 standard. That is authorization standard for third party clients. Here is link: https://oauth.net/2/
This solution is the most professional.There are other less secure ways to do it, but easier to implement. Password and username, x-api-key, etc..
It sounds to me that you can also block all IPs and allow only requests from that specific domain name (CF Worker)
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.
SagePay's form callback can be hacked by re-using the success URL that the user is directed to upon a successful transaction. This can create all sorts of problems with duplicate transactions, fake transactions etc.
You can check for a duplicate VPSTxId, but these can be generated anew by hacking around the crypt parameter of the callback URL.
The crypt parameter can also be manipulated to generate a different "Amount" field.
I have not tested what other field values can be changed by hacking the callback URL crypt parameter.
Is there any way (as per PayPal's IPN validation) of doing a double-check callback to SagePay to ensure that the transaction is new and unique?
Thanks for your post. In general we encourage clients to use Server integration where they can. We also constantly monitor transactions for suspicious behaviour and proactively contact our customers if we suspect any malicious activity.
We recommend customers make sure that they’re using the latest version of our integration protocol which is currently v3. Get the latest integration documents.
As Dan suggests you could use the Reporting and Admin API to validate that a transaction does indeed exist on the Sage Pay side but having an additional validation mechanism (like PayPal's IPN) is something we will actively explore.
If you'd like us to update you on this, then please get in contact with our customer services team at support#sagepay.com or 0845 111 44 55.
Sage Pay Support
You should always redirect a user from a success URL.
I personally use a fulfil page (success url), and a thank you page. On the fulfil page, you should obviously only ever process a transaction once (based on the transaction id), and you can store crypt sent with a transaction. The crypt will have to be valid and is only possible to encrypt if you have the encryption key.
So hacking would be extremely difficult unless you are being very security lax, and the hacker would have to know your encryption key to even begin trying to hack it.
Alternatively, you should use the server integration, so that the communications are server-server, not client-server. There is little difference between form and server.
10 immutable laws of security
http://technet.microsoft.com/library/cc722487.aspx