I'm currently using SendGrid's Inbound Parse Webhook to feed emails to my application. I've been able to get it working by pointing the URL to an endpoint which my application has exposed. SendGrid just sends the email in the form of a JSON format HTTP POST request to this endpoint and I just process each request internally.
My question is, now that I have it working, how do I ensure that only SendGrid can use this endpoint? At the moment, anyone can utilise this HTTP POST endpoint and pretend that an email has been sent to the application.
Can I get SendGrid to send some sort of unique key to identify themselves? Is there a way I can restrict by ip address?
There are two ways which you may secure your endpoint. SendGrid's webhooks support basic auth (e.g. https://user:pass#example.com/endpoint). You can also implement a unique key, that you check before acting upon the request (e.g. https://example.com/endpoint?key=123).
The simple answer, however, is anything that you add to the URL can act as unique authentication for SendGrid.
Related
I'm currently working on a small project where I need to create login and register functionalities for a web application. A colleague of mine had the opinion, that a login request should be done with a post request where the user credentials are stored in the body of the request. I was used to do login requests with a Get-Request where the login credentials are stored in the authentication header (e.g. with Basic-Authentication). So I've read some threads and most of them say, that a POST-Request is better than a GET-Request for login. But also some threads said, that it is better to store user credentials in a request header instead of the body. In case the credentials are stored in the header I don't understand why a GET-Request should be better than a POST-Request.
So I was wondering what you think. What are the benefits/disadvantages of Login with POST-Request and User Credentials stored in the Request-Body compared to storing them in the header via Base-Authentication (encrypted with Base64).
Thanks for any opinions.
A POST is preferable for login request, because the authentication information will be sent in the HTTP messages body rather than the URL. Although it will still be sent plain text, unless you're encrypting via HTTPS.
GET method data is sent to the server followed by the URL which will be seen to everyone.
Both GET and POST method are used to transfer data from client to server in HTTP protocol but main difference between POST and GET method is that GET carries request parameter appended in URL string, while POST carries request parameter in message body which makes it more secure way of transferring data from client to server in HTTP protocol.
In my application, I am exposing a rest endpoint and configured it in twilio account for the incoming message.
Now since the request is not coming from a logged in user but from an external customer, there is no token sent in the request and so the exposed API is not secure.
Is there a way I can make it secure apart from making it a https call?
That is what x-twilio-signature should be used for. The Webhook requests from Twilio will have this HTTP Request Header. You can read more in implementation, below.
How to secure Twilio webhook URLs in Node.js
Security
Asides for what #Alan mentioned , I would also make your URL hard to guess.
https://softwareengineering.stackexchange.com/questions/325806/are-private-unguessable-urls-equivalent-to-password-based-authentication
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
HTTP GET method will transfer data over the url as in https://www.example.com/users?id=1. If I use HTTPS the connection will be secure but the sensitive data in the link could still be logged on the server uppon processing the link requested by the client, exposing secrets to be acquired by some hacker later.
OWASP recommends not storing anything on the links, as it can be logged on the web server.
But REST uses GET to retrieve data, as a "Read" would in a CRUD operation.
So the question is, How can I make a secure GET call on REST?
EDIT: One example: OWASP says to NOT include an API Key on the URL address, but since all data sent on a GET request is placed on the URL, how would I send the API Key to the server in other to authorize the GET response from that user, since I can't place it on the URL itself?
OWASP doesn't explain how to achieve this.
EDIT: One example: OWASP says to NOT include an API Key on the URL address, but since all data sent on a GET request is placed on the URL, how would I send the API Key to the server in other to authorize the GET response from that user, since I can't place it on the URL itself?
You're wrong that all data must be specified in the URL. There's a lot of stuff that actually goes into HTTP headers! Instead of an API key in a url, you should use an Authorization header.
I have a set of REST services that I ONLY want my web application to consume. I do not want my users to be able to use their credentials and have the services consumed by a third party application (since my data is paid for). I there a way to ensure that only my javascript can make calls to the services from a browser that cannot be spoofed (request headers and user agent detection for instance will not work.)
This is probably more of a creative problem.
I am also providing a REST API. I use a mix of an API Key which is always static an can be spoofed. Next is a signature which will be generatet on clinet side and prooved on server side on each request. The signature is build by a combination of all parameters AND a secret password. this prevent a man in the middle from executing for example the same call with another parameter.
Only bad is that a spoofed request can be sent again. I dont know already how to prevent that.
Signed client certificates and HTTPS.