My setup currently looks like:
API Gateway --- ALB --- ECS Cluster --- NodeJS Applications
|
-- Lambda
I also have a custom domain name set on API Gateway (UPDATE: I used the default API gateway link and got the same problem, I don't think this is a custom domain issue)
When 1 service in ECS cluster calls another service via API gateway, I get
Hostname/IP doesn't match certificate's altnames: "Host: someid.ap-southeast-1.elb.amazonaws.com. is not in the cert's altnames: DNS:*.execute-api.ap-southeast-1.amazonaws.com"
Why is this?
UPDATE
I notice when I start a local server that calls the API gateway I get a similar error:
{
"error": "Hostname/IP doesn't match certificate's altnames: \"Host: localhost. is not in the cert's altnames: DNS:*.execute-api.ap-southeast-1.amazonaws.com\""
}
And if I try to disable the HTTPS check:
const response = await axios({
method: req.method,
url,
baseURL,
params: req.params,
query: req.query,
data: body || req.body,
headers: req.headers,
httpsAgent: new https.Agent({
: false // <<=== HERE!
})
})
I get this instead ...
{
"message": "Forbidden"
}
When I call the underlying API gateway URL directly on Postman it works ... somehow it reminds me of CORS, where the server seems to be blocking my server either localhost or ECS/ELB from accessing my API gateway?
It maybe quite confusing so a summary of what I tried:
In the existing setup, services inside ECS may call another via API gateway. When that happens it fails because of the HTTPS error
To resolve it, I set rejectUnauthorized: false, but API gateway returns HTTP 403
When running on localhost, the error is similar
I tried calling ELB instead of API gateway, it works ...
There are various workarounds, which introduce security implications, instead of providing a proper solution. in order to fix it, you need to add a CNAME entry for someid.ap-southeast-1.elb.amazonaws.com. to the DNS (this entry might already exists) and also to one SSL certificate, alike it is being described in the AWS documentation for Adding an Alternate Domain Name. this can be done with the CloudFront console & ACM. the point is, that with the current certificate, that alternate (internal !!) host-name will never match the certificate, which only can cover a single IP - therefore it's much more of an infrastructural problem, than it would be a code problem.
When reviewing it once again... instead of extending the SSL certificate of the public-facing interface - a better solution might be to use a separate SSL certificate, for the communication in between the API Gateway and the ALB, according to this guide; even self-signed is possible in this case, because the certificate would never been accessed by any external client.
Concerning that HTTP403 the docs read:
You configured an AWS WAF web access control list (web ACL) to monitor requests to your Application Load Balancer and it blocked a request.
I hope this helps setting up end-to-end encryption, while only the one public-facing interface of the API gateway needs a CA certificate, for whatever internal communication, self-signed should suffice.
This article is about the difference in between ELB and ALB - while it might be worth a consideration, if indeed the most suitable load-balancer for the given scenario had been chosen. in case no content-based routing is required, cutting down on useless complexity might be helpful. this would eliminate the need to define the routing rules ...which you should also review once, in case sticking to ALB. I mean, the questions only shows the basic scenario and some code which fails, but not the routing rules.
Related
I'm trying to set up an API Management Gateway using a custom domain. However, when I go to test it out, I get an SSL error. I am not sure if I've missed any steps or I've misconfigured my custom domain. The API returns a 200 response when I use the default Gateway URL but returns a 400 when I use my custom domain.
Any help in this domain is appreciated. Thanks
I've described the steps I've followed below:
Steps followed to create a custom domain:
Setup a CNAME for my custom domain api.something.com in Route 53 with Value as .azure-api.net
When creating a custom domain, I added my PFX certificate to the custom domain. When creating my certificate, I set CN="*.something.com. Additional settings such as Negotiate Client Certificate: false and Default SSL binding: true
Created an API with the suffix app1 so that my API is reachable at api.something.com/app1
Now, when I try to test it out through the portal, I get the error
HTTP/1.1 400 Bad Request
content-length: 123
content-type: application/json
vary: Origin
{
"error": "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."
}
This is the request header. ALs I've turned off Require Subscription Key but I'm not sure why the subscription key is still included in the header
GET https://api.something.com/app1/api/heartbeat HTTP/1.1
Host: api.something.com
Ocp-Apim-Subscription-Key: xxxxxxxxx
Ocp-Apim-Trace: true
A couple of days ago I asked AWS lambda basic-authentication without custom authorizer. I got the answer which was enough for me, I implemented the custom authorizer which works properly.
I have a very similar problem right now because we decided to change API Gateway to Application Load Balancer which will trigger the lambda function on an appropriate path.
I would like to prepare the basic authentication for this endpoint also (exact the same as before).
So, the same problem:
AWS lambda function which is a proxy for an additional service. This function only forwards the whole request and give the user the whole response. That's why I need to force the usage of the Authentication header and I would like to have the prompt window for passing the credentials: Authentication.
The response which should be sent from the lambda function is a little bit different than for the API Gateway: Using AWS Lambda with an Application Load Balancer - AWS Lambda
About the authentication with the usage of ALB, I found only Authenticate Users Using an Application Load Balancer - Elastic Load Balancing.
I can't find anything connected with Basic Authentication and the prompt window.
Has anyone ever tried to setup basic auth with ALB for the lambda function? Where to look for the information?
To answer my own question:
I started my search for an answer in the wrong places. I thought that it should be connected with the ALB but in the end, it was not that hard as I thought at the beginning. It can work as a simple Basic Authentication.
So, it is enough to return that response from the asynchronous function/handler to do that in the simplest way:
{
statusCode: 401,
statusDescription: "401 Unauthorized",
isBase64Encoded: false,
headers: { "content-type": "application/json", "WWW-Authenticate": "Basic" },
body: "",
};
Of course, there is a possibility to return anything that you want in the body of this response.
I've recently deployed my website and my back-end on the same vps, using nginx, but now when I do a request with PostMan to http://IP:port/route - I get the response from the server from any PC.
I think this not how its suppose to work. I set the CORS options to origin : vps-IP (so only my domain), but my server still accepts the requests from PostMan. Is there any way to prevent my back-end from accepting these requests limiting the domain to only my domain AKA my vps ip? And must the requests bypass nginx first?
Another question is to protect my website; important request and response headers are showing in the browser network tab - like Authorization JWT token, is this normal or is this some security risk?
I think there's a bit of confusion here regarding CORS.
Cross Origin Resource Sharing is not used for desktop client to server / or server to server calls. From the link:
Cross-Origin Resource Sharing (CORS) is a mechanism that uses
additional HTTP headers to tell a browser to let a web application
running at one origin (domain) have permission to access selected
resources from a server at a different origin. A web application makes
a cross-origin HTTP request when it requests a resource that has a
different origin (domain, protocol, and port) than its own origin.
So it's a web application to another server thing and it's actual functionality is implemented by browsers.
Is this normal?
Yes it is. This means that people who are using Postman can make requests to your server and it's your responsibility to ensure that you're protected against stuff like that. What browsers would do is they would take a look at what domains you allow your server to be called from and if it is a different domain trying to access the resource they will block it. Setting the list of domains that can access to your resources is your / your server's responsibility, but enforcing that policy is the browser's responsibility. Postman is not a browser, so it doesn't necessarily implement this feature (and it doesn't have to).
If you are showing/leaking the tokens in the headers (in a different device than what you have authenticated with or before signing in) - that's a serious security problem. If it's happening on the device that you've signed-in and only after you signing in, then it's expected. This is assuming that you don't leak the information in any other way and designed / implemented it correctly.
There are prevention mechanisms to what you're worried about. And you might be on a service like that without even noticing it, your hosting / cloud deployment provider might have either an implementation or an agreement with another company / tool so you might be already protected. Best to check!
These
Cloudflare DDOS Protection
Amazon Shield
are the first paid services to appear on a quick search, I'm sure there are more. There are also simple implementations which will offer some protection:
Ruby Rack
npm ddos
Another node solution with Redis
Nodejs - Express CORS:
npm i --save cors and then require or import according to your use case.
To enable server-to-server and REST tools like Postman to access our API -
var whitelist = ['http://example.com']
var corsOptions = {
origin: function (origin, callback) {
if (whitelist.indexOf(origin) !== -1 || !origin) {
callback(null, true)
} else {
callback(new Error('Not allowed by CORS'))
}
}
}
app.use(cors(corsOptions));
To disable server-to-server and REST tools like Postman to access our API - Remove !origin from your if statement.
var whitelist = ['http://example.com']
var corsOptions = {
origin: function (origin, callback) {
if (whitelist.indexOf(origin) !== -1) {
callback(null, true)
} else {
callback(new Error('Not allowed by CORS'))
}
}
}
app.use(cors(corsOptions));
It's really easy to implement and there are many options available with express cors module. Check full documentation here https://expressjs.com/en/resources/middleware/cors.html
I have an Azure Active Directory tenant that I wish to authenticate with from my Node.js application running on an Azure App Service instance. I'm using passportjs and passport-azure-ad to do this.
Locally everything works fine. I can authenticate with the Azure AD tenant and it returns back to my page correctly. However on Azure it fails with the error:
authentication failed due to: In collectInfoFromReq: invalid state received in the request
My configuration is exactly the same (apart from redirectUrl) as I'm using the same tenant for local testing as well as in Azure yet it still fails. I've set up the proper reply urls and the authentication returns back to my application.
Here is my config:
{
identityMetadata: `https://login.microsoftonline.com/${tenantId}/.well-known/openid-configuration`,
clientID: `${clientId}`,
responseType: 'id_token',
responseMode: 'form_post',
redirectUrl: 'https://localhost:3000/auth/oidc/return',
allowHttpForRedirectUrl: false,
scope: [ 'openid' ],
isB2C: false,
passReqToCallback: true,
loggingLevel: 'info'
}
I'm using the OIDCStrategy.
My authentication middleware:
passport.authenticate('azuread-openidconnect', {
response: res,
failureRedirect: '/auth/error',
customState: '/'
});
I've compared the encoded state on the authorizerequest vs the returned response and they differ in the same way locally as well as on Azure, yet Azure is the only one complaining. Examples of how the states differ:
Azure:
Request state: CUSTOMEwAuZcY7VypgbKQlwlUHwyO18lnzaYGt%20
Response state: CUSTOMEwAuZcY7VypgbKQlwlUHwyO18lnzaYGt
localhost:
Request state: CUSTOMTAYOz2pBQt332oKkJDGqRKs_wAo90Pny%2F
Response state: CUSTOMTAYOz2pBQt332oKkJDGqRKs_wAo90Pny/
I've also tried removing customState completely yet it still fails.
Anyone know what's going on here? Am I configuring it incorrectly?
Edit: It appears that this may not be an issue with passport-azure-ad. I'm not sure yet, but some debugging revealed that there is no set-cookie header on the login request to my app. The session is created, but no cookie is set thus the returning response is unable to look up the session info including the state and compare them. The result is that it reports invalid state since it's unable to retrieve data from the session.
Turns out the problem was that the session was never properly created thus there was no state for process-azure-ad to compare. The reason for this was that I had configured express-session to use secure session cookies under the assumption that since I was connecting through the https://...azurewebsites.net address the connection was secure. This is not technically the case though.
Azure runs a load balancer in front of the Web Application effectively proxying connections from the outside to my app. This proxy is where the secure connection is terminated and then traffic is routed unencrypted to my application.
Browser -(HTTPS)> Load balancer -(HTTP)> Application
The result is that node did not report the connection as secure unless a set the configuration option trust proxy:
app.set('trust proxy', true);
When this option is set express will check the X-Forwarded-Proto header for which protocol was used to connect to the proxy server (in this case the load balancer). This header contains either http or https depending on the connection protocol.
For Azure though this is still not sufficient. The Azure load balancer does not set the X-Forwarded-Proto header either. Instead it uses x-arr-ssl. This is not a big problem though as iisnode (the runtime I'm using to run node on IIS in Azure) has an option called enableXFF that will update the X-Forwarded-Proto header based on the external protocol of the connection. Setting both these options enables express-session to set the secure cookie keeping the session stored and allowing passport-azure-ad to store and compare state information on authentication.
PS: Big thanks to Scott Smiths blog + comments for providing the answer:
http://scottksmith.com/blog/2014/08/22/using-secure-cookies-in-node-on-azure/
This is a known encode issue with module passport-azure-ad. See:
"State" gets encoded and causes "collectInfoFromReq: invalid state received" #309
"invalid state received in the request" causing infinite loop on Login #247
You could upgrade the module version to v3.0.7 or a newer one to fix it.
I have NodeJS service which is protected and exposed using a load balancer. Need to call the drill Query.JSON API which is projected using j_secuirty_check.
Existing logic:
First hit the j_security_check URL with the credentials and receive the cookie.
Hit the query.JSON URL with the received cookie in the above step.
Code Snippet:
var options1 = {
url: 'http://<HOSTNAME>:8047/query.json',
method: 'POST',
json: JSON.parse('{ "queryType":"SQL", "query": "show schemas"}'),
headers : {
cookie : setcookie
}
};
The above method is working without the load balancer.
Example:
backend service running on http://localhost:3000
Drill URL: http://<SOMEIP:PORT>/query.JSON
Issue:
The second request is redirecting to login page thought we set cookie received in the previous step.
Example:
backend service running on https://<LOADBALANCER_URL>
Drill URL: http://<SOMEIP:PORT>/query.JSON
Is this because of https & http protocols or diff domain?
Please share your suggestion.
In case of load balancer the request might be going to another Drillbit WebServer which doesn't issued the cookie in first step. In which case it will not work, your load balancer should have some concept of sticky session or send the request from a client to same WebServer every time.