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.
Related
I have a curious problem with a legacy ASP.NET web application using Windows Authentication. A particular page is crashing, and an inspection of the page and the site logs indicates the page is crashing because the request is not properly authenticated - no Windows identity is being requested by IIS or supplied by IE 11.
The page has a curious path; it took a few minutes to decode how it was originally assembled. The initial request is not for a specific page, but is merely a folder-only URL that is routed to Default.aspx. The handler checks the query string and redirects to specific pages accordingly.
The initial request to the site is authenticated, as evidenced by the IIS site logs. The page to which the request is redirected (Response.Redirect) does not authenticate. The absence of the Windows authentication challenge leaves the site with no automatic identity to the targeted page, leading to the page crash (code depending on the identity fails). The sequence goes this way:
Original URL: /sitename/folder/?parameter1=value¶meter2=value
IIS issues the authentication challenge, and the authenticated user is shown in the logs - eg, domain\user
The request is then handled by folder/Default.aspx (default page as defined in IIS)
Default.aspx.cs inspects the query string, and routes the request to (eg) OtherPage.aspx via Response.Redirect.
OtherPage.aspx is requested, and the request is logged - with no authentication, and no challenge
OtherPage.aspx.cs crashes (no user credential)
I am trying to theorize how or why ASP.NET is even permitting the unauthenticated file request. I have tried to reproduce the behavior in a test environment, and have been unable to do so. I have suspected that "Automatic logon in Intranet zone" might have been disabled, or that stored local credentials may be present but somehow causing a conflict, but neither of those scenarios panned out. The former did result in a failed authentication attempt and a proper 401 response from the server (the target page was not fired in a test environment).
Further research into this question has led to a solution if not a 100% dissection of the cause.
The users experiencing the problem were accessing the target site via a link in an email message. The link, for some unknown reason, inhibited the credential exchange between IE and IIS until the site URL was placed in the "Local Intranet" sites list of IE. This allowed the "Automatic logon in Intranet sites only" option to apply which, in turn, allowed the authentication to work.
The reason this is not a "100% dissection" is because these users were accessing the site previously, wherein authentication worked when the site was accessed conventionally. Exactly how the email message link inhibited the authentication exchange is not known. At the moment, I theorize that some security setting inhibits authentication when originating from an email link unless the specific site URL is explicitly qualified as a trusted or Intranet site.
Thanks for your consideration.
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
I already have a working CAS and other sites has the capability to for single sign on. But there is this one site, that does not login automatically. It redirects me to the sites login page though I have successfully signed on in CAS.
Is it possible that SSO do not work on other sites? And why is that? What are the requirements so that SSO will work on that site?
SSO works for all other service site. The above scenario. that you described is only happen if you passed renew=true parameter with you serviceUrl.
For example: your request url to CAS server look like this
https://www.yourcasserver.com/cas/login?service=http://youwebapp.com&renew=true
In this case, parameter renew=true, It allows a client to advise the CAS server login to always authenticate a user regardless of whether a single sign on session already exists.
And this is the useful feature of CAS server, because certain services that would like to use CAS as the authentication mechanism but allow access to sensitive material. They can force CAS to reauthenticate a user to ensure that they are signing in the correct user (and its not a pre-existing SSO session that wasn't terminated.
To use CAS SSO service for all client application, you have to set "renew=false" parameter or you have not pass any renew parameter to CAS login page URL.
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.
how can I synchronize sessionID over multiple second-domain servers? For example, I've got servers(you can log-in into server swarm at any of these), www.service1.com, www.service2.com, www.service3.com, and if you log in at one of them, the login information (+anything else) should persist along them. How can I provide SessionID to other domains? (session itself is stored on sql server shared across the services).
Cross domain logins are possible, but very tricky, and prone to issues.
Generally a scheme to do this will involve a third server that acts a centralized auth server. Login requests on individual sites will route through the auth server and the auth server will pass back a secure token to use as a session id.
I've seen this session id passed back to the server via url redirects, and also through back end server communication.
My personal advice would be to use the auth server as a webservice of some sort, and maintain individual sites logins separately. The workflow would be roughly:
Sign in on a given site
The site would send a behind the scenes request to the auth server asking for authentication and information
The auth server would respond appropriately
The site would login on success, and show error message on failure.
It is possible to use some fancy redirects and some forms of trust to implement a auto login system, but honestly such things are rarely if ever worth it. The above suggestion would end up with them having to login on each individual site, but they'd share the same credentials and profile on every site.
Don't you mean across domains?
This is not possible due to security features in browsers. Browsers do not allow cookies to be accessed across domains.