I have a microservice in a non-prod environment which another team is using in another non-prod app that's handed off to 3rd party integrations for testing. That other team unfortunately presents users with the entire failed response of any API calls rather than logging it and returning something generic. Unfortunately, that means that they can see the Authorization header which includes "Bearer {tokenHere}".. This wouldn't normally be an issue in a development environment, but my hands are tied right now and I don't want to completely disable the exception page just because someone else is improperly leveraging that information.
I've looked at the options we have for configuring the developer exception page, but it's very limited. Is there anything I can do to remove the authorization header or all request headers if that's not possible?
note:
In an api call that returns json, this info. is displayed after the stack trace in a new section starting with "HEADERS"
Related
In our project we have an ASP.Net Core Web API backend and an Angular 5 frontend. In development mode, the Angular Page will run on its own server (using node, e.g. localhost:8000). Therefore, accessing a local instance of the API (e.g. localhost:57612) will be a cross-origin request.
CORS is correctly set up for the API, and in the successful case there are no issues. Also, I have enabled app.UseDeveloperExceptionPage() in the API to get nice stack traces in case something goes wrong.
However, Asp.Net only returns the error details/stack trace (as HTML in the error response body) when the request was sent from the same origin (i.e. localhost:57612 in the example above). So in our development setup, we don't get this error response body, we get nothing.
I have not found a way to send the developer error page as response to an errored cross-orign request. In Asp.Net 4.5 + IIS, there was a setting in IIS where one could control this behavior specifically. Does anybody know how to control this behavior in Asp.Net core?
(I think I could implement a workaround in form of a custom ASP.Net error handler that will return all the details of the exception like the Developer Exception Page. But that's a bit silly, reimplementing this functionality.)
I'm currently creating an MVC 6 project (beta 8) which includes some APIs. Along with this is an accompanying Word App which talks to these APIs (just GET methods at present), however all my ajax get JSON requests from the Word app result in an 'Error: Access is denied.' message.
After much searching I believe this may be a CORS issue, so I have enabled this in my startup.cs by adding the following into ConfigureServices:
services.AddCors(options =>
{
options.AddPolicy("AllowAllOrigins", builder => builder.AllowAnyOrigin());
});
and then
app.UseCors("AllowAllOrigins");
into Configure, but this makes no difference, I still just receive the access denied message. I've attempted adjusting my CORS options to allow all methods and tried various other options, including adding
[EnableCors("AllowAllOrigins")]
on the actions, but again it makes no difference.
I am running both projects locally and manually navigating to the api via a browser returns the results without a problem, as does my swashbuckler setup.
Am I missing something obvious here?
In my experience, some browsers don't allow the wildcard response for allow origin when over an SSL connection (which is what you get when you use AllowAllOrigins). If you need your traffic to go over SSL, you need to respond with a list of allowed origins instead of the wildcard.
This answer has a good approach.
I have a WCF REST service hosted in SharePoint that uses SSOM. The client web application sends AJAX requests containing the REQUESTDIGEST in a X-RequestDigest header. I am using the typical SPWeb.ValidateFormDigest() for my POST requests to prevent CSRF vulnerabilities. Works great.
Here's the weird part. Our client uses HP Fortify, and it is reporting that our GET requests are vulnerable to CSRF attacks. My GET requests are indempotent so this seems silly, but I must be compliant.
To get around it, I want to use ValidateFormDigest() in my WCF method for the GET request the same way I do for POST, but it throws this exception:
"Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."
I tried setting AllowUnsafeUpdates, but that just makes the request succeed without validating the digest!
Is there a way to have SPWeb validate the digest within a GET request?
HP Fortify gives recommendations, not edicts. If you think - and can prove - that the warning is spurious, then justifying the pattern should be treated as being compliant. Code analysis tools are not perfect.
I'm using Google Apis, instead of Google Sign In, to connect to Google on my app because I'm developping with Xamarin.
This is the library I'm using : https://github.com/xamarin/google-apis
When I'm logging in, i get this error :
Authentication Error
Unexpected character '<'. At line 1, column 0.
Maybe it's because my AccessTokenUrl is not good, but I've tried many things. I know for a fact that my ClientId, my RedirectUrl and my Secret are okay.
When logging in, Google asks correctly for the good permissions that I want, but after I accept, this is when I receive the error.
I've tried finding the request to see if there was the '<' in it but had no luck accessing it.
Is there a good way to connect to Google with Xamarin using this library or I'm just doing something bad?
Should I just do it nativaly on iOS and Android?
Thanks
I just encountered a similar problem using Xamarin.Auth to hit a custom OAuth service (i.e. not Google). In my case, the accessTokenUrl pointed to an action on a controller that was entirely protected by the [Authorize] attribute. Naturally, the user was required to login before hitting the /oauth/authorize endpoint using a web browser, but the request to /oauth/token to exchange the resulting authorization code for an access token was not inside the same web browser/session. It was trying to get back token data in JSON format but was being redirected to an HTML login screen. Once I changed the token endpoint for anonymous access, things started working (Note: A valid authorization code cannot be obtained without authenticating).
General Recommendations
The error message strongly suggests that the response coming back is HTML (or at least some form of XML). This could be an authentication redirect as it was in my scenario, or possibly some sort of error page. I would first start by setting up a proxy. I used Charles Proxy to uncover some interesting information. You will need to configure SSL on the proxy to see anything except high level information. This will show the exact requests coming out of your app to the OAuth application.
Another technique I used was simulating the requests that the OAuth2Authenticator would be making in a web browser and/or Postman. The first request would be to authorize:
https://your.domain.here/oauth/authorize?client_id=<some_client_id>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F&response_type=code&scope=<some_scope>&state=<some_state>
That endpoint should be protected, so you will likely be redirected to something like this:
https://your.domain.here/Account/Login?returnurl=%2Foauth%2Fauthorize%3Fclient_id%3D<some_client_id>%26redirect_uri%3Dhttp%253A%252F%252Fyour.domain.here%252F%26response_type%3Dcode%26scope%3D<some_scope>%26state%3D<some_state>
After authenticating, the authorize endpoint should redirect to your redirect URI with the authorization code and state included as query string parameters. You will use the code in the next step.
Lastly, using a fresh web browser (i.e. new session), you should hit the token endpoint with your new authorization code and other client information.
https://your.domain.here/oauth/token?client_id=<some_client_id>&client_secret=<some_secret>&grant_type=<your_grant_type>&code=<your_authorization_code>&redirect_uri=https%3A%2F%2Fyour.domain.here%2F
If the response is not JSON data, it should give you an indication about what is failing with Xamarin.
Got the same error.
Solved by using https://accounts.google.com/o/oauth2/token as AccessTokenUrl
I'm using CouchDB as a data source for a C# web service.
Being RESTful, CouchDB passes back a status code of 404 when asked for a document that does not exist. The standard .NET web request wants to throw an exception at this but (to me, at least) communicating that a data source has returned "no results" via an exception is utterly horrible; and it's a stink I really don't want wafting around in my code...
Is there any replacement for WebRequest I can use that will allow me to deal with status codes as I see fit?
EDIT: Just to clarify, due to the responses I've had so far: I do not want to hide the exception that WebRequest throws. I am looking for an alternative to the standard WebRequest that does not throw exceptions based on status codes as .NET's interpretation of what constitutes an error doesn't seem in-line with REST principles.
EDIT #2 I really need a 3.5 compatible way of doing this; sorry for not being specific about that at the start.
The HttpClient library does not throw exceptions after the request. See this for usage examples.
I have not used them but there are several dedicated C# CouchDB client libraries.
There is CouchOne's list of CouchDB drivers.
Also there is the CouchDB wiki list of C# clients.
My personal preference is to stick as closely to the HTTP layer as possible. HTTTP is very simple and the CouchDB API is very simple. There is no need for middleware to access it. (It is unfortunate that your WebRequest class apparently has this bug.)
I'm not sure what's your problem. If you don't want to get 404 when asking doesn't exist documents, I think you just need to add a wildcard application maps in your IIS settings and uncheck the "Verify that file exists" box.