I am sending HTTP requests from GAE to MongoLab in the form of:
https://api.mongolab.com/api/1/databases/rival_testdb/collections/testCollection?apiKey=someKey
If this request was coming directly from client side, I would be very concerned. But since this request is coming from inside a servlet in GAE, is this a security concern? How could I make this more secure if possible?
I would like to use MongoLab if possible, but their API only allows for putting the API key directly in the requesting URL. So I am stuck using a URL like the one above for all API requests.
As long as you can secure the API key on the server you should be good. You do not have to worry about it being sniffed on the network as all the communications are over HTTPS thus encrypting the request string and the apiKey along with it.
-will
This is a valid concern for most public services.
Specifically for MongoLab, this discussion is present over here: https://support.mongolab.com/entries/20269612-REST-api-permissions-and-security-best-practice and it does not look like the security additions that they are talking about has been released in public.
Do check out to the link.
Having said, I am assuming that the only way that you are accessing the Mongolab API is from within your GAE Application? That at least makes it more difficult for anyone to sniff out the url from your application.
A good solution would be for MongoLab to allow a HTTP Header to be inserted before your make the REST call. Here you would some ID that identifies that it is your GAE App. And then MongoLab should be doing a check for that before permitting the call to do its work.
Related
I have taken a look around the internet and all the solutions emphasize using Express and Node Js API in place to able to send an email. I would love to see any suggestions on how to best go about it because I don't have a backend in place. Thank you.
You're going to need some sort of backend otherwise the API-Key will be exposed.
From the SendGrid documentation:
When you have a browser-only application that reaches out to APIs, the API key has to be embedded in the application. Anyone with access to a browser-only application can access all of the Javascript source code, including your API keys.
Making your API key publicly accessible could result in anyone authenticating API calls with your API key — this is a significant security concern both for you and SendGrid.
You could use a serverless AWS lambda function or google function which would be a "backend" but without having to support the infrastructure / use a big framework.
The following is the architecture of my Web application.
Web UI(Angular JS) running on nginx
Back-end data access layer (Java App) running on glassfish app server
My question is, how can I prevent a valid user from tampering or manipulating the REST service JSON request using some proxy tool.
One thing that I thought of was to encrypt the JSON but this will still expose the public key and the source code of how to encrypt it since its done on client side scripting. Is there a better way of doing secured JSON request?
P.S: I'm not talking about "Man in the middle Attack". This is not related to session hijacking. This is about a valid session user tampering the POST request using tampering tools.
You can't.
Anything that runs on client-side is exposed. Almost everything there can be tampered.
So your best bet is that you have a strong server-side validation before you process the data from the client.
I'd like to send requests against the Google Directions API. Google provides a Node.JS client library for the API. However, this AP is server-side only. Attempting to use it from a browser script results in a CORS failure. Multiple past answers (such as this one) indicate that this library simply can't be used in this way.
The alternative is to use the client-side JavaScript API. However, this requires adding a <script> tag to the document root. That's the wrong level of abstraction for my needs. I'd like to use a method from a library or dot-js file instead.
Following the advice given here, I'd like to ask: is there a module available through npm I can use to query the Google Directions API client-side?
It's not naively possible to access the Google Maps Directions API from the client side. Web browsers implement the Single-Origin Policy, which requires that any requests to a domain come from the same domain. Requires between domains are disallowed by default. Cross-domain requests can be enabled at the server lever by setting the right CORS headers on the endpoint, but the Google Maps servers choose not to do this.
There are two ways of working around this. One is to wrap the request using the Google API Auth library. However, I could not get this to work.
What did work was using a reverse proxy. This workaround is actually mentioned in the Google Directions API intro page (albeit obliquely). You will need to set up a server which forwards any requests to an API request, then returns that API request to the original requester. Since this is now a server-side request, SOP will not apply, and you will be good to go.
For an example implementation check out this repository on GitHub.
https://developers.google.com/maps/documentation/directions
This is the Directions API web service. It does not require adding a <script> tag.
You can make direct requests to the service as per the example:
https://maps.googleapis.com/maps/api/directions/json?origin=75+9th+Ave+New+York,+NY&destination=MetLife+Stadium+1+MetLife+Stadium+Dr+East+Rutherford,+NJ+07073&key=YOUR_API_KEY
once you have generated an API key and replaced YOUR_API_KEY in the request with your own key.
I have an app engine service deployed in GAE (written in Node) to accept a series of click stream events from my website. The data is pushed as an CORS ajax call. I think, since the POST request can be seen in browser through the developer tools, somebody can use the app engine URL to post similar data from the browser console.( like in firefox, we can resend the URL. Chrome also has this features i guess)
A few options I see here is,
Use the firewall setting to allow only my domain to send data to the GAE.
This can still fail me since the requests can be made from the browser console repetitively)
Use a WAF ( Web Application Firewall) as a proxy to create some custom rule.
What should be my approach to secure my GAE service?
I don't think the #1 approach would actually work for you: if the post requests are visible in the browser's development tools it means they're actually made by the client, not by your website, so you can't actually use firewall rules to secure them.
Since requests are coming into the service after fundamentally originating on your own website/app (where I imagine the clicks in the mentioned sequences happen) I'd place the sanity check inside that website/app (where you already have a lot more context info available to make decisions) rather than in the service itself (where, at best, you'd have to go through loops to discover/restore the original context required to make intelligent decisions). Of course, this assumes that the website/app is not a static/dumb site and has some level of intelligence.
For example, for the case using browser development tools for replaying post requests you described - the website app could have some 'executed' flag attached to the respective request, set on the first invocation (when the external service is also triggered) and could thus simply reject any subsequent cloned/copy of the request.
With the above in place I'd then replace sending the service request from the client. Instead I'd use your website/app to create and make the service request instead, after passing through the above-mentioned sanity checks. This is almost trivial to secure with simple firewall rules - valid requests can only come in from your website/app, not from the clients. I suspect this is closer to what you had in mind when you listed the #1 approach.
I'm in the process of creating a Laravel API/AngularJS Monster. The idea of completely separating them out (Frontend, DB, API) was mainly because I wanted to get into app development and keep all things separate so the API could do all the grunt work. So in the future I intend on making interfaces of which I'll be the only one using including OS X/iOS/Native apps.
However I'm looking on stuff online and following some setups and tutorials and I'm seeing that CSRF is a good thing to implement, seems secure and the right thing to do...
But is it necessarily right for an API?
What security measures would be good for using an API?
The only thing I really know anything about implementing right now is Session cookies and using HTTPS throughout my application(s).
If the API is accessed client-side, then yes, you need CSRF protection.
This assumes that cookies (or another authentication mechanism) is used from the front-end, is passed to your API from JavaScript and then actions are initiated, or content returned.
For the items that initiate action (i.e. non safe methods - RFC 7231) you will need to send some sort of CSRF token (e.g. Synchronizer Token Pattern which is recommended, or Double Submit Cookies), although there are other valid methods for preventing CSRF such as checking for X-Requested-With or Origin headers.
Whichever method you choose, you would be able to also implement this authentication in your apps. From a custom application retrieving the token or cookie value is trivial, or passing an extra header is easy too. What makes this CSRF protection work for your website is that the browser will restrict which other domains can read tokens or send headers because of the Same Origin Policy. If your API is on a different domain, CORS can be used to allow access from your website domain only, although it sounds like you're already past this stage. Remember to protect your API with HTTPS also, and set the Secure flag on any cookies, and you should also think about using HSTS to further secure your API and website.