Hopefully this is a simple question for someone out there.
Basically upon receiving a request to my MVC controller, I want to:
Add an "Authorization" header to the response
Redirect to another application sitting on another domain
Read the "Authorization" header at this external site.
It appears the act of redirecting, strips out all my custom headers and redirects.
My question, how can I add a new header, AND perform a redirect, AND have that header show up in the headers for the receiving host [at the end of the redirect] to read?
You can't. That's not how HTTP works. First, a "redirect" is just a 301, 302, or (since HTTP 1.1) 307 status code with the Location header set to the URL the client should go to. It's the client that initiates the request to that URL, so you have no control over what headers they send.
Second, HTTP is stateless, so the fact that an Authorization header was sent in some response at some point has zero bearing on anything that happens in any future requests. Web browsers and other HTTP clients skirt around the stateless nature of HTTP by using sessions on the server-side and cookies on the client side. The client sends the cookie to the server with the request. The cookie matches an item in the session store on the server, and the server loads up the data from that session to give the appearance as though state was maintained.
Third, cookies don't work in this situation, because they are domain bound and are not sent along with requests to domains they did not originate from. So, even if you were to create session to maintain the authorization, the other site would never see it.
FWIW, the basic premise here, sharing authentication state with a different domain, is exactly what technologies like OAuth were developed for. So direct future research in that direction.
No - 302 redirect are handled by browser and it will not re-attach headers.
Options:
server side proxy
use cookies instead of other headers (if it is the same domain, not your case per 2)
manual redirect client side (may be ok since you are making AJAX call anyway).
Related
My question is, can someone see your full URL web API, that you developed when a user makes a request with that URL get/post/delete/put ? Can they see in network traffic your Web APIs URL that are being called?
Example of URL: https://webapiserver.azure.com/something/something/Username/password
Can you actually see these content when the request is being made from a user, lets say i am developing an Android application, and inside that application, i make these kind of API request, and i worrying about the security, if an 'attacker' can see the content..
You can focus on these to secure your server connection.
All request URLs are visible to outside.
Never ever send passwords or any sensitive information through URLs.
URL can have insensitive parameters like pageno, sort-order etc..
If you want to authenticate a user, Go for a POST request where
username and password are inside the POST body. This alone won't
secure you however.
Use
POST: http://yourapp.com/api/authenticate
BODY:
{
"username": "admin",
"password": "some_hashed_password"
}
Instead of
GET: http://yourapp.com/api/authenticate?username=admin&password=some_hashed_password
Always use SSL to connect to API
You should always use SSL to secure your API.
SSL encrypts your request and response. Your URL will be still visible but payloads will be encrypted.
This question already has answers here:
Will CORS policy prevent resource access from non-browser requests?
(4 answers)
CORS allowed-origin restrictions aren’t causing the server to reject requests
(3 answers)
Closed 3 years ago.
Background:
My server domain is www.good.com, and CORS is not enabled
There is an API under 'test' controller, action name 'hello' (GET method), so the endpoint is www.good.com/api/test/hello
There's a mock malicious web call www.bad.com
Scenario:
www.bad.com sends a request to www.good.com/api/test/hello
Although bad website couldn't see the response on browser, yet the
'hello' action had been executed, and returned a full response.
My questions are:
If the CORS is not allowed, why does the .NET Core framework still let the request enters my action and produce a result? If the purpose of not allowing CORS is to prevent from cross site requests, why don't it just block the request before entering controller/action, so that we save the resource/performance on the server? (since it's not the request we need to handle)
If the response comes with the actual data in the body, it doesn't matter if the browser doesn't let you see the content or not, just use some tool like WireShark, you can still parse the content which might be the sensitive data that been returned by my action. Then CORS is protecting nothing, which is weird to me.
As I understand it, CORS isnt really protecting you from malicious calls. Its protecting the user from malicious sites.
Users use browsers. And the browser is preventing the actual call here.
Browsers are able to cope with cross site referencing and respect CORS headers. By issueing an pre flight optikns request, the actual call will be blocked. My guess is, this preflight options request is missing from you mocked request.
Note: you can always make a mallicious post with any kind of software and execute the request. The thing is: users tend to use browsers. Therefor one could make a site, which maliciously post data to your site, without the user knowing about it.
Or as wikipedia states it:
Although some validation and authorization can be performed by the server, it is generally the browser's responsibility to support these headers and honor the restrictions they impose.
So concluding: I think it doesnt check the origin by itself out of the box, and; I dont know the details of you mock setup, but it seems its not an actual browser call. .... if it is... than thats very interresting; please show the mocked call 🙂
I have 3 different Servers.
On Server A I have a webpage pageA.aspx
On Server B I have a webpage pageFrame.aspx
On Server C I have a Web API controller controllerC.cs
On Server A I have another page pageB.aspx
pageA.aspx and pageB.aspx are different pages on the same website.
pageFrame.aspx is embedded in pageA.aspx as an IFRAME.
pageA.aspx has both the standard ASP.NET authentication and Session cookies, along with other cookies.
pageFrame.aspx picks up these cookies and makes an ajax call to ControllerC.cs and is able to pass these cookies along in the POST Request.
ControllerC.cs now needs to make a POST Request back to Server A by calling pageB.aspx but it needs to pass along the cookies it received in the ajax call from pageFrame.aspx. By doing this it can reach the same session that pageA.aspx was in.
Now pageB.aspx does some processing and replies to the POST request with a ticket(guid). This ticket is then sent back from ControllerC.cs as part of the response to the ajax call to pageFrame.aspx. pageFrame.aspx then submits this ticket to pageA.aspx as a response to the originally request.
PageA.aspx now simply submits back to its web server and can pick up from the session whatever pageB.aspx has placed in the session during its processing.
Now my question is how do i transfer the cookies from pageFrame.aspx's ajax post request in ControllerC.cs to the request it is making to pageB.aspx?
I have been trying to use HttpClient and trying to add the cookies from one request to another but they seem to be in two different namespaces and when i do make a post the cookies aren't picked up and sent. Does anyone know how I can write the code in ControllerC.cs to pick up the cookies in the request made to it from pageFrame.aspx and pass it to the new request it is making to pageB.aspx?
I look forward to and appreciate your help.
Thank you,
Gmat
I need to sign in to a site, I can do this via an url such as url.com/ssorequest?parameters=123. If this is typed in the address im signed in in and gets redirected to the portal.
Now Im supposed to do this through a http post request programmatically but I cant get it to work, I get redirected to a sign in form instead of the portal, ie I dont get signed in.
I used Fiddler to find out what the difference between the two methods was. I found that a couple of behind-the-scenes get-requests were different. The browsers get-requests sends cookie data to the server and fiddlers post-request does not.
When I use fiddler to repeat the browsers first call it doesnt send the cookie data either. So it only works when I do it via the browser window. Unless I use breakpoints in fiddler and tamper with the requests to include the cookie data.
Q: Why does it behave differently from the browser with both http post and when the request is done from Fiddler?
Q: Is there any way to tamper with the requests going out programmatically in my C# app without writing my own Fiddler application?
Most probably you have encountered an anti-forgery cookie. It works in a way to ensure that you are signing in using the page that was first requested and loaded in the browser and the cookie is valid for one request only and hence the fiddler will not be able to log in if you run the same request again.
Using C#, you first have to request the sign-in page and get the cookies provided with this page in a cookie container. Next time, when you post the page along with data, you have to make sure that the cookie is attached with the request.
Edit:
Step1: Browse any page on the site. This will initiate the session. It will also give you the session cookie.
Step2: Request the sign in page. send the cookie obtained in step one along with sign in page so that it can recognize the session. This step is critical. At this stage, there can be either of two things depending on the security system site is using. Either it will send a security cookie along with session cookie or it will add a hidden variable in the form along with a value which serves as security token. Make sure that you get this token/cookie.
Step2: Post the login information on the sign in page (or whatever page the form action leads to) along with the cookie/token obtained in step 1. If it is a token, include it in your post data along with login information or if a cookie, add it to request.
Using Web Browser control or http request in C#, when a website creates a cookie (or tries to), is there a way to capture and display that cookie?
Yes, cookies are returned in the Set-Cookie header. You can use the HttpWebResponse.Headers collection to look through all of the headers and read out the cookies, or there's also the Cookies collection which wraps it for you.
Sure, you can use a tool like Fiddler or FireBug to capture and inspect the requests and responses sent during your session. I'm more familiar with Fiddler, so I'm basing my answer and example on it.
For example, if I log in to my company's Outlook Web Access portal, I enter my user name and password, and the OWA client writes a session cookie to my machine. If I have Fiddler running while I log in, I can see this cookie being written as part of the response from the server due to a successful log in:
**Cookies / Login**
Set-Cookie: sessionid=d8ff0256-7339-4049-81c2-fae98f7c3ed5:0x409; path=/
If there are more cookies being sent down, you'll see them listed under the Cookies group.
I can see these cookies if I click on the resource that was requested (the page that I'm taken to after successful login), and then click on the Headers tab in the Response section of Fiddler.
Hope this helps!