We Keep Coding

Preventing Cross-Site Request Forgery Attacks With a Windows Client Application

I develop an web application by web api2.
My client application is a windows application that developed by C# , .net 4.0.
The client application sends some Json data to the web api application and the application stores data in database.
Now the issue is sending the request with another method except my application and sending dump data to the server.I have authentication on the server but it isn't enough,I need some tokens for handling this issue.
After some searches i find this article and read it, but the client is a web application.
Could i use this method in my windows client app?how?

Bottom line: You shouldn't need to.
By definition, CSRF attacks can only affect client applications that share cookies across domains. e.g. if you visit www.bank.com with your browser and then open another tab to www.evil.com, if www.bank.com does not protect against CSRF then www.evil.com may be able to POST a form submission to www.bank.com while you are logged in and then transfer money by forging the request to the form's action URL on the transfer money page.
If your client is a Windows application, the HTTP client should not have cookies stored for any other service other than your web API.
Note that the above only applies to when cookies are used as the session management mechanism (i.e. not Kerberos, NTLM, Basic Auth, etc).
.I have authentication on the server but it isn't enough
This should be enough as an attacker cannot forge a HTTP request to your API that will be sent along with the victim's cookies as the cookies are separated due to there being different instances of web clients. Much like being logged into Google on Chrome, but then accessing Google on Firefox - you will not share the same logged in session.
Of course, protect your API with HTTPS so the information is encrypted whilst in transit. Note that this does not protect against decompilation of your source code, which is something that is not easy to prevent. At the end of the day you cannot trust clients that are not under your control. You can make it difficult, but not impossible to prevent someone working out or changing what is being sent to your API.

Cross site anti-forgery tokens are a form of authentication. It authenticates the client who's sending the request: the client has to visit a certain page to get the token from the server, so it cannot be any client who has not visited that page and some how just send random data to that server.
The purpose of authentication is for the server to authenticate the client (other way around is also possible, but let's forget that for the moment). You setup the system such that it is very difficult for others to pretend to be your Windows Form app. Note it can be very difficult, but theoretically it's always possible to fake. So the aim is to setup an auth such that an attacker considers it impractical to launch an attack.
This auth should not be mixed up with the authentication to verify the human user. They are different. An app can provide a UI for human users to login, but the app is not written by you. So you need to authenticate 2 things:
the request actually comes from your app, if that succeeds, then
the human user is who he claims he is, otherwise
reject the request

MVC Redirect with custom headers

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).

URL rewrite in ASP.NET application

How do I redirect url based on register client in c# .net or asp.net 4.0. For example if client registers as "client1" and our website is www.mycompany.com for every page client proceeds should get www.client1.mycompany.com.
More detailed example:
For example another client created is Client2. The pages i have created in general is like
"www.mycompany.com/product.aspx"
"www.mycompany.com/categories.aspx" should be shown as
"www.client2.mycompany.com/product.aspx" and
"www.client2.mycompany.com/categories.aspx" respectively
I have searched on web and found for static pages or using Gloabal.asax during startup of application but haven't found any thing after user logged in.

I have done something similar before in a few sites and there are a couple methods you could use. Assuming that you have a url setup so that all subdomains ( *.url.com) will send any user to your server and you have IIS setup to handle them all (i.e. no host header required, just IP) in the same site you can use one of the following methods:
After login simply send the user to that url. Since .Net won’t care the url the server knows how to render it, then it should be that simple. This assumes all your navigation uses relative paths and you must enable cookie sharing for that domain. This is required if the cookie for login was give on 1.url.com and you send them to 2.url.com You can share cookies in the same domain, requires a little work, but can be done.
Create a generic login page that does a web service request back to the server to see if the user can login. If he or she can have it send back to the browser a command, along with the correct url, that tell the clients browser to post directly to that sites login page (send username, password). This will login them into their site and assign the cookies correctly all from one simple login page. You could even make an external login page that only exists for this purpose. In the end all the generic page did was see if they could login and the sent their credentials to the correct page that did the login. I recommend this be done in a post with ssl for security reasons.
I hope that makes since.

There's a project called UrlRewritingNet which I use - it's pretty old but the source is available so you could recompile it for 4.0.
Link is at http://urlrewriting.net/149/en/home.html

How to secure login and member area with SSL certificate?

Background: I have a asp.net webapplication project that should contain a public and a member area. Now I want to implement a SSL decription to secure communication between the client and the server. (In the university we have an unsecured wireless network and you can use a wlan sniffer to read username/password. I do not want to have this security problem for my application, so I thought of a ssl decription)
The application is running on a IIS 7.5. Is it possible to have one webapp that has unsecured pages (like the public area) and a secured area (like the member area, which requires a login)? If yes, how can I relealise the communication between these too areas?
Example:
My webapp is hosted on http://foo.abc.
I have pages like http://foo.abc/default.aspx and http://foo.abc/foo.aspx.
In the same project there is a page like /member/default.aspx which is protected by a login on the page http://foo.abc/login.aspx.
So I would need to implement SSL for the page /login.aspx and all pages in /member/
How can I do that? I just found out how to create SSL certificates in IIS 7.5 and how to add such a binding to a webapp. How how can I tell my webapp which page should be called with https and not with http. What is the best practise there?

From here How to use HTTPS in an ASP.Net Application
After you get SSL setup/installed, you
want to do some sort of redirect on
the login page to https://. Then
whatever page the user is sent to
after validation, it can just be
http://.
Protected Sub Page_PreRender(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.PreRender
If Request.IsSecureConnection = False And _
Not Request.Url.Host.Contains("localhost") Then
Response.Redirect(Request.Url.AbsoluteUri.Replace("http://", "https://"))
End If End Sub
This may be easier to implement on a
master page or just all the pages you
require https. By checking for
"localhost" you will avoid getting an
error in your testing environment
(Unless your test server has another
name than check for that:
"mytestservername").

I don't work with .net, but we do have websites that have similar setup, where some pages are unencrypted and served using http, and a bunch of pages are served with https instead. Here are some stuff we've done... hope they are helpful.
You need to have someway pass the configuration to your code, so it knows the base URI of both the http or https portion. E.g. if your server is foo.bar, you need your code to know that the secure pages are at https://foo.bar:xxx/..., and unsecure pages at http://foo.bar/...
You can configure your server with some redirects to make your life easier. E.g. if in your server configs, in the port 80 area, you redirect /xxx to the port 443 /xxx, then in your http pages, you can just use releative URL like /xxx, and not have to include the base URI. Vice versa, you can setup in port 443 config redirecting /yyy to port 80 /yyy, then in your https pages, you can just use relative URL like /yyy
Posting between http and https pages: you can't redirect post, so you have to use the base URI for the http or https pages in your form element. I.e. in your http pages, if you post to https, you have to specify the https base URI in the action attribute of the form element -- this is the reason for point 1 above.
Obviously both your http and https code should check cookies to determine if a user's logged in, but you want to, in the https pages, check for secure cookies -- those cookies that browser will only send in a https connection. Your plain-text cookies can get sniffed.
AJAX --- this is tricky. You cannot do cross-domain AJAX due to Javascript's security model. So, this means if you are in http, you cannot do AJAX to https, or vice versa; port changes are considered different domains by the browser. There are work-arounds, like using hidden iframes, etc, but those solutions are fairly complex and often have security holes.

Just a word of caution, you shouldn't really use a Self-Signed certificate on a production site. You ideally should get one from a trusted CA (certificate authority). The big names are Verisign and Thwate, but there are other, cheaper CA's out there.
If you use a self-signed certificate on a live site, your users will get an ugly warning message asking if they wish to proceed.
In terms of redirecting users to https areas, I usually just forward the pages I want secured (for example, if a user navigates to http://domain.com/login.aspx, I'll immediately redirect the request to https://domain.com/login.aspx (Response.Redirect(...)), then take them out of the SSL secured area once they are successfully authenticated.

Unsecured & secured HTTP

I have an application which uses 2 web sites (so I guess that is 2 applications...). The user logs on via a https website and is then diverted to a unsecure http website application on successful logon (using forms authentication). I (and others) have started getting the message
"The current web page is trying to open a site in your Trusted sites list. Do you want to allow this?"
when the user is redirected.
Is there a way to stop this in the server configuration or in the code ?
Thanks

If the user is accountable for any actions performed on the "unsecured site", it should not be unsecured. It's not safe to authenticate a user on HTTPS, then let them perform actions using that authentication over HTTP.
If someone is not worried about a man-in-the-middle, it doesn't make sense for them to use HTTPS at all. On the other hand, if a man-in-the-middle attack is a possibility (and in general I assume it is) then sending the session identifier cookie (or other credential) obtained via secure login over an insecure channel allows an attacker to steal it and forge requests to the service.

I think what you are doing at login is to post the login information from the secured page to the non-secured page, which in turn pops up that message.
What you could have done is for the secured login to post to a secured page, then redirect from there to the non-secured page. That should remove the message.

That message appears to be IE's trusted sites warning. There is no way to control it from a remote server, nor should there be as it would be a security risk.