I have implemented a webhook URL for a Twitter bot application and Twitter sends me the events happing (tweets, mentions, replies, etc).
The webhook URL supports the following endpoints:
Endpoint 1: GET /twitter
Endpoint 2: POST /twitter
Both endpoints use the same URL but the HTTP verb is different.
According to Twitter's documentation I need to implement a CRC check in the GET endpoint before it can send me the events happening in the POST one.
I have already implemented the CRC check in the GET endpoint and my question is if I need to implement the CRC check also in the POST one, for security reasons.
Related
The popular SMS service Twilio allows the application to receive a status callback for downstream message events after sending an SMS message by calling the Twilio API.
Our application utilizes both basic auth and passport.js to manage users, session and protect routes.
What's the correct way to protect the POST route that receives the status callbacks from Twilio, since these callbacks will not be authenticated or signed?
(In other words, trying to protect the route that receives the POST from Twilio on callback currently returns a 401. Removing the authentication obviously allows the request to be received and processed, but leaves the route unprotected.)
This webhook will definitely need to be a public endpoint. Usually for webhooks you will get a signed header that will enable you to verify that the message is legit.
If this is not the case, what you can do is to create a middleware that compares the MessageSid that you receive on the callback with the sid that you got when you made the request to generate the sms.
In case the message doesn't have a MessageSid or the MessageSid does not match any on your database you give an unauthorize response.
You have a couple of options detailed here:
Security
For Express and validating Twilio Webhooks, there is a good blog below.
How to secure Twilio webhook URLs in Node.js
this is regarding incoming sms from a mobile phone via twilio.
when testing with postman (and I append the header with a Bearer JWT token I received from my app), everything works fine and my app can recognise the request.
but sending an sms results in a 401 error as my endpoints are not reachable. any proven ways of doing this or do I have to hack my app to bypass incoming requests from twilio and just every request that comes from that twilio number.
please help!
Twilio developer evangelist here.
Twilio will not send a bearer token JWT in requests because it doesn't know to authenticate with your application like that.
You will need to bypass the JWT check for requests from Twilio. If you're using express that should be straightforward and if you share some code we can look into how to make that happen for your app. On the up side, there are other security methods you can put in place instead.
Twilio supports HTTP authentication via basic or digest auth. If you can set the endpoint in your app to require authentication in this way instead, then it can be secured.
You can also check against the X-Twilio-Signature header that is sent with every request to validate that the request came from Twilio. There is a guide on how to validate Twilio requests in Node.js with Express.
I'm using Dialogflow v2 in my Angular app for the client side and I have a requirement to send a custom http header (token) with the request to get it from the webhook for an intent. How can I send this custom header to the API?
The way I made it work was by sending an HttpClient request to my firebase function to verify the authentication and from there I used the Dialogflow node SDK to do the Dialogflow related tasks, handling the webhooks by myself, instead of attaching a function in the Dialogflow intent.
This gave me the flexibility to use whatever type of authentication, intent and request handling I want, so I don't have to worry about the limited 5 seconds per webhook request as well.
I've successfully completed account linking on api.ai, and now I'm trying to execute a webhook. The problem here is that I need the token that was generated during the linking process to go into the authentication field. Otherwise I will always get a "403" error back. How can you change the auth token in the webhook header field dynamically for each user that issues a Google Home voice command?
For all I know that's not currently possible. I pretty much had the same issue, and I resorted to connecting to an intermediate server that handles the webhook, extracts the access token (available via the actions-on-google node.js API as getUser().access_token), and then forwards the request in the right format to the original host.
I am making a Twilio app. Twilio can send a request to the server after a call is over, but it isn't able to be associated with the logged in user of my website because Twilio is making an independent request. If I were to tell Twilio to post something at
example.com/response.html?token=ba38pgab38g4agdusoehle8qihxs&data=somedata
and then use this token as a way of verifying that this Twilio request is associated with a user, is that secure?
I have seen this technique used before on password reset forms. An email will contain a link, and the user's identity is confirmed only using the token.
Is doing this in my Twilio app secure? Are there any gotchas to note?
It's as secure as any other request to your server from a remote HTTP client (like a browser). If you want to make sure that no one between Twilio's servers and yours can read the request, you should use HTTPS/SSL.
For this use case, it's probably better to associate the CallSid value that's sent with every request to your server with the user in your system. When the StatusCallback for a completed call fires, look up the user associated with that call and act accordingly.
A few of the browser-based single sign on protocols like OpenID and SAML use a similar technique to track state when redirecting between the site you're trying to authenticate to and the site doing the authentication. I think the technique is good enough for what you want to achieve.
I'm not familiar with Twilio, but I'd be careful about using to identify a user though. Generating a unique code (aka nonce) for every request and having Twilio pass that nonce back in the response would be more secure, as it only identifies a particular request. It might be overkill though.