Cloudflare Worker redirect stripping auth headers - cloudflare

I set up a Cloudflare worker to redirect to our API gateway since we don't have control of the DNS and can't just set up a CNAME. The redirect works and it passes along the body and all the headers except Authorization. It receives it, and when I look at the worker console it lists it as redacted. It also redacts the user_key param I'm passing but it passes that through.
const base = 'https://myurl.com'
const statusCode = 308;
addEventListener("fetch", event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
const url = new URL(request.url);
const { pathname, search } = url;
const destinationURL = base + pathname + search;
return Response.redirect(destinationURL, statusCode);
}

First, note that the redactions you are seeing are purely for display in the workers console. This is a feature to protect sensitive secrets from being logged, but it doesn't affect the content of any live request.
Now, with regard to what your Worker is actually doing:
This worker returns a 308 redirect response back to the client. It is then up to the client to follow the redirect, sending the same request to the new URL.
It is the client, then, that decides whether to send the Authorization header to the new location -- the behavior is NOT controlled by Cloudflare Workers. As it turns out, many clients intentionally drop the Authorization header when following redirects to a different domain name. For example, the Go HTTP client library does this, and node-fetch recently started doing this as well. (I happen to disagree with this change, for reasons I explained in a comment.)
If the client is a web browser, then the behavior is complicated. If the Authorization header was added to the request as part of HTTP basic auth (i.e. the user was prompted by the browser for a username and password), then the header will be removed when following the redirect. However, if the Authorization header was provided by client-side JavaScript code when it called fetch(), then the header will be kept through the redirect.
Probably the best way to solve this is: Don't use a 3xx redirect. Instead, have the Worker directly forward the request to the new URL. That is, instead of this:
return Response.redirect(destinationURL, statusCode);
Try this:
return fetch(destinationURL, request);
With this code, the client will not receive a redirect. Instead, the Worker will directly forward the request to the new URL, and then forward the response back to the client. The Worker acts as a middleman proxy in this case. From the client's point of view, no forwarding took place, the original URL simply handled the request.

Related

Why do we need to use the front-channel for an OAuth authorization request?

I've been struggling with this and would love to see if any OAuth experts here have an answer.
For context, I'm trying to integrate OAuth into an existing first-party (internal) front-end client that lives on a subdomain. It's a single-page application. I have an authorization server that has an /oauth2/authorize and oauth2/token endpoint and I'm working with the OAuth 2 with PKCE authorization flow.
In all the examples I've seen externally, it seems like the recommendation is to make a top-level redirect to the authorization URL initial login . And for silently re-authenticating a user (if they were already logged in), using an invisible iFrame set to the authorization URL (and postMessaging the code back to the parent window).
I'm trying to understand what prevents me from making a front-channel request to my /authorize endpoint via Javascript. Something simple like...
const { state, code } = await fetch(authorizationUrl)
For the login case, I can handle a 403 error back from the AS and then redirect them to login from the client-side. For the re-authenticating case (i.e. client has an expired refresh token but is still logged in), this is great because I just get a 200 response and the code back directly in the JSON body and I can use it immediately. There is no top-level redirect, no hassle of saving app state, etc.
It seems like as long as the AS is willing to return the { state, code } via JSON, this should work. This means that
The AS authorize endpoint must be configured to allow CORS on select origins. This seems okay in a first-party context since I know which origins I should allow.
The AS must be sent client credentials (session cookies) with the request (otherwise the AS would have no idea how to determine if the user is logged in). In JS, this would be as simple as adding credentials: true. As long as the cookie credentials have Same-Site: None and the cookie is part of the same domain (cross-domain would not work since some browsers disable cross-site cookie sharing nowadays!)
I feel like I'm missing something crucial here. But at the same time, my prototype is working, so I'd love to get some input from experienced folks here.

Can Cypress intercept requests being made directly to a server?

I have been trying to intercept a server request using Cypress' intercept method.
I have noticed that Cypress can intercept requests made through the front-end/browser, however, the intercept method doesn't work if I make a request directly to the back-end server.
Let me clarify what I mean:
One thing is intercepting a request that the front-end/browser makes to the back-end server.
Another thing is intercepting a call that doesn't use the browser but calls directly the back-end endpoint.
For example:
I can create a user using the front-end interface
or I can create a user calling the back-end endpoint directly (directly calling the server).
Coming back to my question. Is there a way to intercept a call that was made directly to the back-end endpoint?
This is what I have tried so far:
I wrote a regex to intercept api/v0/customers
I then made a request to http://locahost:5440/api/v0/customers (which is the URL of the server)
Finally, I waited for the request to happen
Timeout request using Cypress intercept method
cy.intercept(/^\/api\/v0\/customers\/$/).as('createCustomer');
cy.request(createCustomer(customerData, headers));
cy.wait('#createCustomer').then(({ status, body }) => {
const customerId = body.customer_id;
console.log(body);
expect(status).equal(201);
});
Here's the problem: There was a timeout error.
As you can see in the image, I'm making a request to http://locahost:5440 which is the server URL. NOTE: I made sure the server was up and running.
The regex is also correct and it will match the endpoint http://locahost:5440/api/v0/customers
I suspect that intercept only works for requests being made through the browser. Is this assertion correct? I couldn't find this answer anywhere in the Cypress docs.
Is there a way for me to intercept a call being made directly to a server (not using the browser)?
You don't have to intercept the requests you explicitly make with cypress, just use .then to get the response, like this:
cy.request(createCustomer(customerData, headers)).then((response) => {
const customerId = response.body.customer_id;
console.log(response.body);
expect(response.status).equal(201);
});
Reference: https://docs.cypress.io/api/commands/request#Yields

Whats the best way to force a browser redirect after logout of ServiceStack

Currently when a user logs out the log out process works correctly but the user stays on the same screen and therefore can still see secure data.
What is the best practice for forcing a browser redirect after logging out of ServiceStack?
It's not possible for the server to enforce a client redirect. It's really up to the client to enforce the security for the data after you logout. If the client has been trusted with the secure data already, during the course of the session, then you need to trust that the client will secure it appropriately when the session ends.
While you can have ServiceStack send redirect headers to the client when logging out, there is nothing requiring the client to actually take that action.
If a JavaScript client makes an AJAX request to ServiceStack to logout, the redirect response doesn't affect the page displaying the secure data, because the AJAX request operates effectively in a separate scope from the page showing the data, and so that page remains unaffected by the redirect. So the redirect is useless, unless the client explicitly provides a mechanism to handle such event.
The client must take responsibility to navigate away from the secure data itself. The best practise would be:
In the success method of your call to the logout action, you should:
Dispose of any sensitive in memory data. i.e. JavaScript Variables / DOM Elements displaying the data.
Delete the session cookie
Redirect to login
If you have secured your service properly, then navigating back through the history should still trigger a session check, for which there will no longer be a valid session, and you should be redirected away.
You previously mentioned using AngularJS. If you were doing this with the $http service, then the success callback can be used, like this:
$http({method: 'POST', url: '/auth/logout', data: { provider: "logout" }}).success(
function(data, status, headers, config) {
$scope.someValue = null; // Remove sensitive values from the scope (though it should be cleared up anyway with the redirect to a different state)
$cookieStore.remove('ss-id'); // Remove the cookie
$state.transitionTo('login'); // Redirect to login state
}
);
This example assumes you have injected the $http, $cookieStore, $state providers
tl;dr
The client must enforce the security. The server redirect should be treated as nothing more than a suggestion to the client.
Use the success callback of the logout request action to delete the session cookie, dispose of any values in memory and redirect away from the data.
Hope this helps.

how do you request a session from servicestack basic authentication, at /auth/basic?

I have set up a servicestack service with basic authentication using the first example, here:
https://github.com/ServiceStack/ServiceStack/wiki/Authentication-and-authorization
This automatically sets up a route: /auth/basic
However, I cannot find any information or examples on how to format a request to this URL (Variables/GET/POST/Auth Header, etc.).
I am able to access a simple service using the basic authentication credentials, so they are active and correct.
I have no custom authentication plugged in, just basic authentication.
I have tried:
Using a JsonServiceClient to send UserName and Password variables by GET or Json POST to /auth/basic, with and without an Auth header also containing the user & pass.
Using a browser to send GET requests with URL parameters of the user/pass, or as http://user:pass#localhost:123/auth/basic
I always just get "HTTP/1.1 401 Invalid BasicAuth credentials".
The only examples I can find involve some kind of custom authentication, and then /auth/credentials is accessed, but I want to use /auth/basic
I have looked at the code and it looks like it reads an Auth header, but the service does not accept one.
I am actually trying to get this working so I can then disable it and verify it is disabled (I want to require basic authentication for every request).
Questions are:
What is the correct way to call the /auth/basic service? I will take a servicestack client API example, specifications or even a raw http request!
How do you disable the /auth services altogether?
Many thanks.
What is the correct way to call the /auth/basic service? I will take a servicestack client API example, specifications or even a raw http request!
var client = new JsonServiceClient("http://localhost:56006/api");
var resp = client.Post(new Auth() { UserName = "TestUser", Password = "Password" });
This assumes you have also registered an ICacheClient and IAuthUserRepository (and added a user account)
The JSON format looks like this if you call into /auth/basic?format=json
{
"UserName": "admin",
"Password": "test"
"RememberMe": true
}
How do you disable the /auth services altogether?
Don't add the AuthFeature plugin to configuration.
You can also remove plugins
Plugins.RemoveAll(x => x is AuthFeature);
Putting the following in apphost config seems to do the trick.
//Disable most things, including SOAP support, /auth and /metadata routes
SetConfig(new EndpointHostConfig()
{
EnableFeatures = Feature.Json | Feature.Xml
});
I am a little suspicious about what this does to /auth however, because it returns an empty response, while most routes return 404.
So, would this truly disable the /auth functionality? As in, if someone formed a correct request to /auth/credentials, will it still return an empty response?

JAX-RS, RestEasy: No session cookie

Folks,
Used to be that when you hit a servlet/jsp, the app server would automatically start a session. It would put a session cookie in the first dynamic response that would get tracked throughout.
I have a rest backend and I notice that no session cookies are being traded. So I manually add code to send the JSESSIONID cookie:
#Context
private HttpServletRequest httpRequest;
// ...
#GET
#Path( "/{rcpGuid}" )
public Response myMethod( ... )
{
final HttpSession session = httpRequest.getSession();
final String sSessionId = session.getId();
...
return Response.status( Response.Status.SEE_OTHER ).
location( redirectUrl ).cookie( new NewCookie( "JSESSIONID", sSessionId ) );
}
Now this is causing 2 copies of the JSESSIONID cookie being returned where before there was no Set-Cookie header. This is what I see now in my browser's inspector:
Set-Cookie:JSESSIONID=sdm-Q1P6pRoQbKd4-9cJylGb; Path=/nn, JSESSIONID=sdm-Q1P6pRoQbKd4-9cJylGb; Version=1
I don't care as long as this would work. But unfortunately, when my browser requests the URL being redirected to (notice that the response is "SEE_OTHER"), that request does not bear the session id. This causing my app to not function right.
Any insights?
Used to be that when you hit a servlet/jsp, the app server would automatically start a session. It would put a session cookie in the first dynamic response that would get tracked throughout.
The app server doesn't create a session until httpRequest.getSession() is called.
I have a rest backend and I notice that no session cookies are being traded. So I manually add code to send the JSESSIONID cookie:
In your example, you call getSession() and create a separate jsessionid cookie. That would explain why you have two cookies. If you do neither, you wont have a jessionid at all.
If it is a REST back-end, so you should not have JSESSIONID cookie and keep your back-end endpoints as Stateless.
All informations required to get a result from one of your web service should be contained in the request to the web service. A web service is idempotent.