Is there a reliable way to determine where a user is coming from in an ASP.NET application? We have a web application that is linked to from two different locations. The two links are on separate domains, and they need to dictate certain user permissions within this app. Here's what I have tried so far...
Using Request.UrlReferrer (which is the Referer HTTP header). This always returned an empty string. I believe this is because the hyperlinks use Javascript to launch a popup window. Based on my research, the user agent provides this HTTP header on standard hyperlinks. Javascript popups are a different story (evidently).
A simple query string to indicate the referrer. This is not really an option because we need something that is not so easy to bypass (more secure).
Any ideas? I understand that in the grand scheme of things, this could have a better overall design/structure. Please don't post an answer suggesting I re-design everything, because that is not an option.
There's no a reliable way to tell where an user is coming from and this is not only an ASP.NET limitation, but all web applications in general. The url referrer can be easily spoofed so it is not reliable. I think the best option could be some encrypted url parameter, or cookie if you prefer.
So both pages should agree on common private keys.
Page1 will use the key to encrypt its address and pass it to Page2
Page2 will check for the presence of this parameter and try to decrypt it with the same private key used to encrypt
If this succeeds it means that Page2 will be capable to determine who called it, if not, the data has been tampered
Without the browser passing a referrer or using the querystring like you describe, there is no way to know.
Another option is to have two different landing pages on the ASP.NET application. The landing pages can set the security options and then redirect to a common homepage. This is a little more secure than the querystring option.
Or, you could place a 1x1 pixel image on the referring sites that is pulled from your ASP.NET application site. The referrer should be passed to the script and you could then set a cookie on the users machine that you can then reference when they hit the app homepage.
Related
I have written a custom http module which I successfully deployed to sharepoint. The purpose behind this module was to track if the users to the sharepoint site had accepted an EULA (represented as a cookie in the request context) and then simply redirect them to another website (running independantly) to accept our EULA etc. The problem that I am facing at the moment, is that while users with their web-browsers using the site are fine, everything works as it should, but the trouble occurs with things like the SPFarms serch failing etc when trying to index the site. My quesiton is basically, how/what should I be filtering to ensure that my module only executes my logic for a request coming from a webbrowser and how to detect any of sharepoints crawlers etc such as the search service etc? I realize i can hardcode it to check for the username that the service is running on and check the filepath extensions and filter on that, but that seems like horrible design. please advise if you know of a better way to do this please
Try filtering based on the User-Agent string, in Request.UserAgent -- just don't rely on User-Agent for security purposes, since it can be faked.
I have a code which generates iframe which user can embed on his site.
I want to show my iframe only on particular sites.
How can I do this?
For example:
I can give a unique key to user and use this key on server side.
But another user can get this key an use it.
Is there simple solution?
The referrer solution is not robust in any way. Referrer is something "said" by the browser it can be manually overridden as said above, moreover anyone could simply use a proxy and reintegrate the iframe.
So, basically, it depends on how much code can be put on the "Trusted server".
If you can, use one time tokens. Trusted server gets a list of tokens from server having the iframe. The url served by the trusted server contains the token which will be invalidated upon serving the content of the iframe. This does mean that there is a "write" for each read. And tokens will take some space.
You can use the referrer response-header as described in the HTTP standard.
Though expert users (the übergeeks/browsermodders) know how to omit this. You should may not do this for security reasons.
I have an application with different sections. Each section is accessed through a domain. Example: www.section1.com, www.section2.com, www.section3.com. I need to preserve the session when the user navigates from one to another URL. The application is the same in IIS. How to accomplish that?
You will need to pass on the session-cookie, and re-set that cookie on the new domain. That will make the session live over several domains (assuming you use the same app).
Example:
Link from section1.com:
<a href="http://www.section2.com/?s=askdjh3k4jh234kjh">
then, OnSessionStart (or OnRequestStart) check for query-parameter s and attach session to it. Meaning, just manually set cookie ASP.NET_SESSIONID to the value you pass on.
This has severe security-implications, so don't allow this unless you know what you're doing. another solution might be to store something into a common backend (database?) and pass around the user with a token that represents the actual session (and set the cookie based on that token), that you generate on a middle-page when navigating away from section1.com -> transferusertonewdomain.aspx -> section2.com/?token=randomTokenThatMatchSessionInDatabase
That would prevent that anyone could hijack a session by jsut knowing the value of the cookie. However, that is possible never the less if you're somewhat familiar with a computer anyway.
If you have multiple domains (and not just subdomains, which are easier), you're going to have more complications doing this than you'd like, because you can't share cookies across different domains.
The usual workaround is to embed a link an image on the other domains that are served by an asp.net page (or HttpHandler if you like). That page should contain a querystring with a unique token and a hashed version of that data appended with some shared secret. Then, that page will set a cookie on the response appropriate to for that domain to associate itself with appropriate data. It will serve typically a 1x1 transparent image as the response. Usually you only want to do this upon login to one of the sites.
Unless you do some customizations, session is specific to an application regardless of session mode you are using. Here's an article that talks about how to customize SQL session so that you can use session across multiple applications.
You should start by change the sessionState from being "InProc" to either StateServer or SqlServer, ensure that the MachineKeys are identical across all sites (domains and servers), and then set up the relevant backend systems to capture the state information.
More information can be found on:
Session-State Modes
ASP.NET State Management Overview
You could use a cookie to pass it, still researching to find out how. I will repost.
** EDIT
There is another Stack Overflow question, see if it helps, 315132
It basically asks
I need to share SSO information
between two different domains with a
cookie, can this be done in PHP and
how?
the answer given was
On both domains, place an image or
other web element that is pulled from
the other domain. Use the URL to
notify the other domain that user X is
on domain A, and let domain B
associate that user ID with that user
on their system.
It's a little complex to carry out
correctly, but if you think it through
it'll work out very well.
Vinko points out in a comment
(thanks!) that I shouldn't take it for
granted that you understand the
security risks involved. If this
information is of any value to anyone,
then you should make sure you use
proper encryption, authentication, etc
to avoid releasing sensitive
information and to avoid various
attacks (replay, man in the middle,
etc). This shouldn't be too onerous
since you control both websites and
you can select a secure secret key for
both, since the communication is only
going between the two servers via this
special URL. Keep it in mind though.
The user is Adam Davis.
If I am on a website#1, and I enter my username/pwd for website#2 on a login page that is on website#1, and website#1, behind the scenes, makes a httpwebrequest to website#2 and posts to the login page. If I then navigate to website#2, should I be logged in?
website#2 uses formsauthentication and I call a httpHandler that is on website#2 and pass it the username/password via the querystring.
Should this work?
What you're trying to do is called Single Signon. The way you're doing it, posting values from one site to another, probably won't work because you're using the same technique a hacker might use to trick user into sharing their login information. It's called a cross-site request forgery attack. IIS is configured not to allow that.
Generally, you need a central authentication system that both sites use to share login information. This can be done in several ways, including a shared database-based login system. Google "asp.net single sign on" for more ideas.
Do site #1 and #2 want their users to have single sign on?
If so, read up on single sign on. It's a bigger project than can be addressed here. There is a good book on it though from Wrox :
http://www.amazon.com/Professional-ASP-NET-Security-Membership-Management/dp/0764596985/ref=cm_lmf_tit_10
Or are we imagining something sinister?
If we are imagining something sinister, then evil site #1 would collect the credentials, then automate a browser on the server side to start checking to see if site #2 uses the same password and user combination. Then the server would have an authenticated session. This wouldn't give the user who accessed site #1 an auth cookie, the HttpWebRequest object on the server would get the auth cookie. Site #2 couldn't really do anything to prevent this because a browser request from one computer looks much alike a browser request from another. A well crafted attack would spoof all elements of the browser's request so that it looks like it came from a browser instead of a primitative HttpWebRequest object, which may not even set the user-agent.
Site #2 should stop using passwords and user Id or use 2 factor ID if they are concerned abut this, or do something that requires javascript for logon because spoofing a browser that is executing javascript is harder than spoofing a browser that just sends and receives http requests and responses.
There are too many security issues trying to auto-authenticate between sites. There needs to be a central security provider that both sites belong to so that hand off is completed securely.
We use CA's Siteminder for cross site authentication. Effectively, web 1 creates a unique session id on the siteminder server and passes any credentials and info to it. Siteminder invokes web2 and passes the information by means of session variables. Web 2 retrieves the data from the session and uses it. There's much more going on there but that's the just of it.
To do something like this, I would strongly consider using an out of the box solution as generally coding up custom security generally falls short.
While this can be done on some cases, in the form of an HTTP request with POST parameters, you will not be authenticated once you browse to site #2.
This is because, generally, these sites store a cookie on your end and these are domain-based, which means that even if you grabbed that and stored it yourself from site #1, the cookie name would not match site #2.
Additionally, site #2 may not be easy to authenticate against and this is usually a security concern that developers are aware of. This can be considered an attempt of XSS as well.
In case you're simply doing this for yourself, I'd recommend LastPass and save most of your info in it.
Please reconsider your goals and how to achieve them, this is not the way.
Edit: Link text.
This could work, depending on the security measures in place on website #2. For a secure website, this would fail.
I would recommend against this purely on the basis of good security and good coding/design practices.
If you are unclear what security measures stop this, you should probably educate yourself so you can prevent the same issues on your own site. See http://www.owasp.org/index.php/Top_10_2007
Since both your sites are using FormsAuthentication you can easily configure both of them to share FormsAuthentication encryption schemes.
This will allow you to do Cross Application Authentication automatically :)
When do you initially get assigned your unique http cookies when visiting a website?
I'm asking this in the sense of when creating a gui auth login from a website. Do you get your cookies the moment you visit the website? If so, if you don't visit the website by homepage and go straight to the http://website.com/login.php form, do you initially also get your cookies there if you haven't received them yet?
On load of the the first page that sets a cookie.
It will be sent along with the content of that page, in the HTTP header.
In PHP:
You can set a cookie any time before sending output to the browser.
You can read it (via $_COOKIE) any time after setting it, including in the same page load.
Just remember that if you read it in the same page load where you set it, you are reading it from the current process, and not from the client's cookie, which won't have been sent yet.
The server/application can set cookies whenever your browser makes an http request. In other words, the answer is implementation-dependent.
I would suggest that you take a look at Fiddler (or some other http tracing tool) to better understand the interaction.
There is no correct answer to this. It is an implementation detail that no two websites (using different base code) do the same way. Variables include the implementation system/language (ASP, PHP, Python, Ruby, etc), use of standardized (or custom) libraries, how security-minded the website is, how long ago the website was written, etc.
Most websites will set your session cookie no matter what page you first arrive from. There are many ways to do this but all involve every possible entry point calling common routines in the website's source code for handling sessions, permissions, navigation, logins, etc.
Having said that, I'm there a significant number of websites that do not set any cookies until you do something that needs to be remembered (login, adding a product to a shopping cart, setting a preference, etc).
How you should do it depends on what is important to your website. There is no single answer to this.
Here's the official standard for cookies and their behaviors:
http://www.ietf.org/rfc/rfc2965.txt
Most browsers will try to conform to this standard as closely as possible, but note that it is up to the implementer. If there are bugs, then of course the behavior is different.
I think the thing you're looking for is that cookies are passed in with the request as long as the domains or URI are the same.
As someone else alluded to, cookies can be manipulated and are inherently insecure. Don't use them as a way for security. You can keep track that they've been logged in successfully with them, but you should put an expiration date on that fact.