Develop Reference

Get original origin of request with .NET Core API

I know that Request.Headers["Origin"] gets the origin header of a request, but this is changeable on the client-side by setting the header manually. Thus not that safe.
Is there such a value that contains the original, readonly/unchangeable origin of a request? Like the one CORS is using?
I need this value to check if the request is officially coming from the site it's supposed to come from. The trick is that I need it in the controller method to search an object in the database based on this value and a key only used for that site.
The problem with CORS is that it can whitelist a list of URLs but not check if the site and the key belong to each other, thus can whitelisted site 1 access the data of whitelisted site 2 if it mimics the Request.Headers["Origin"] and the key of site 2

Unfortunately (or perhaps fortunately?) there is no reliable way to check this from the data that the browser sends to your server. The user is able to forge any and all information that you receive from the browser.
This is why mechanisms that need to reliably determine the origin of a user use some sort of token mechanism, public/private signatures, certificates and the sort to determine it. Unfortunately this is never as simple as looking up some information that the browser provides you with, so it seems like you might need to redesign your whitelisting mechanism by relying on something else than origin, possibly implicating single-sign-on measures (like SAML). It's hard to provide further suggestions without more information on the underlying problem that the origin-check is intended to solve.

How to identify Post Data is hacked using anti-forgery token

I know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.
submit a post request with below information
cookie token(antiforgerytoken)
form data(first name & last name)
form input hidden token(antiforgerytoken)
Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.
In this scenario, how we can make sure the data submitted securely reached server without any modification
Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.
I am not sure if this is a valid question.If yes,any help would be appreciated

Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.
CSRF, and antiforgerytoken
The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.
This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.
Note that this has nothing to do with legitimate request content.
Integrity of requests
A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.
Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.
Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)

HTTP Error 414. The request URL is too long. asp.net

I'm getting the error "HTTP Error 414. The request URL is too long." From the following article, I understand that this is due to a very long query string:
http://www.mytecbits.com/microsoft/iis/query-string-too-long
In web.config, I have maxQueryStringLength="2097151". Is this the maximum value?
In order to solve this problem, should I set maxUrl in web.config? If so, what's the maximum value supported?
What should I do to fix this error?

This error is actually thrown from http.sys, not from IIS. The error gets thrown before the request is passed along to IIS in the request-handling pipeline.
To verify this, you can check the Server header value in the HTTP response headers, as per https://stackoverflow.com/a/32022511/12484.
To get https.sys to accept longer request URLs without throwing the HTTP 414 error, in the Windows Registry on the server PC, at Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters, create a DWORD-type value with name MaxFieldLength and value sufficiently large, e.g. 65535.
Reference: Http.sys registry settings for Windows
If you decide to make this change, then obviously it’ll need to be made in all environments (including all production server(s)) -- not just on your local dev PC.
Also, whatever script and/or documentation your team uses to set up new server instances will need to be updated to include this registry setting, so that your team doesn’t forget to apply this setting 18 months from now when setting up a new production server.
Finally, be aware making this change could have adverse security consequences for all applications running on your server, as a large HTTP request submitted by an attacker won’t be rejected early in the pipeline as it would normally.
As an alternative to making this change to bypass the http.sys security, consider changing the request to accept HTTP POST instead of HTTP GET, and put the parameters into the POST request body instead of into a long URL. For more discussion on this, see question Design RESTful GET API with a long list of query parameters.

As described in this answer -> What is the maximum length of a URL in different browsers?
The allowed length of a url depends on a combination of browser and server. Hence it's hard to say exactly how long the url can be. The answer recommends to stay below 2000 char in the url. I do not know why your querystring is so long. Can you shorten it? It's hard to give you any recommendations without knowing more about the solution and your query string.

Generally, Url has its own limits in length and if you set this value you may solve the problem for a while, but bear in mind that for a long url situations, best practice is working with forms. To be specific, it is better to use POST actions instead of Get.

just to complement, if you try with massive parameters, using Request ajax and receive de 414 ERROR. change the dataType property to JSON then submit as POST type.
this resolved my problem.

Add session variable to inbound and outbound URLs

I'm designing a site using ASPx and IIS, where clients can sign up and then offer services to their clients. For example:
if you go to http://www.mywebsite.com you can sign up for your mywebsite.com account as a business owner. When you sign up, you are given a Site ID (Example: AA1234).
http://www.mywebsite.com/AA1234
What I want to do is always include the Site ID in every url (Inbound and Outbound). The Site ID is stored in a session variable based on the initial incoming request.
Does anyone know of a good way to do this - or a different design that works better than this?
Thanks

Your question is nebulous at best. However...
Wouldn't this be what cookies are used for?
In particular, if your user is authenticated (this is generally achieved in asp.net with an auth cookie), then at the server, you would have tools at your disposal that allow you to recognize the user and provide a different experience according to whatever criteria you choose. Most likely, these details might be stored in a database.

Found the answer in this topic: http://www.tek-tips.com/viewthread.cfm?qid=1149673
The last response from BoulderBum is exactly what I needed.
Using the HTTP module I will take the /AA1234/ URL and point it to /Company/.
On the way out, I replace all instances of /Company/ with the site id again

Append an HTTP header to all IE requests

I have a scenario which requires me to append an HTTP header to all outgoing IE-based HTTP communications on a machine. This doesn't need to work outside of IE.
I first attempted to create a simple HTTP proxy in C#, but the performance of this proxy wasn't very good, and there were issues with HTTPS communications.
My second attempt was to use FiddlerCore, which I hoped would have better performance, but was only marginally faster than what I had created myself.
Aside from writing a TCP filter driver to do this (not in my skillset), is there another option? Strictly speaking, this doesn't have to be an HTTP header. It could even be something I tack on to the user agent string.
I was thinking perhaps about creating a simple BHO, but I'm hoping there is an easier solution... one that I can write in C# perhaps.

How about just reading the user-agent string in your code and if it's IE then append the HTTP header?

Just use user agent string. It is documented here http://msdn.microsoft.com/en-us/library/ms537503(VS.85).aspx .
Per article following registry key can be used to add to the user agent string: SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Pre Platform\Token = Value.