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.
Related
If I set up a simple web server online (eg nginx), and generate a very large random string (such that it is unguessable), and host that endpoint on my domain, eg
example.com/<very-large-random-string>
would I be safe in say, hosting a webapp at that endpoint with no authentication to store my personal information (like a scratch-pad or notes kind of thing)?
I know google docs does this, is there anything special one has to do (again, eg for nginx) to prevent someone from getting a list of all available pages?
I guess I'm asking is there any way for a malicious actor to find out about the existence of such a page, preferably irrespective of what web-server I used.
I'd be pretty alarmed if my online bank started using this system, but it should give you a basic level of security. Bear in mind that this is security through obscurity, which is rather frowned upon and will immediately turn into no security whatsoever the moment someone discovers the hidden URL.
To prevent this from happening, you will need to take a few precautions:
Install an SSL certificate on your server, and always access the url via https, never via http (otherwise the URL path will be sent in plain view and visible to everyone along the way).
Make sure your secure document contains no outgoing links. This includes not only hyperlinks (<a href="...">) but also embedded images, stylesheets, scripts, media files and so on. Otherwise the URL will be leaked to other domains via the Referer request headers.*1
(A bit of a no-brainer, but) make sure there are also no inbound links to this page. Although they aren't so common now, web hosts used to generate automatic "web stats" pages showing the traffic to each web domain. Some content management systems generate a site map automatically. This would be just as bad.
Disable directory browsing on your server. In other words, make sure that someone who visits the directory level above your hidden directory isn't presented with a list of subdirectories.
Bear in mind that the URL will always be visible in your address bar and browser history, and possibly in other places like your browser's cookie jar. Your browser will probably provide the rest of the URL by auto-complete when someone types the domain into your address bar.
*1: Actually, your browser will only send a Referer header when you access other https pages, but still...
I was using Fiddler see on-the-field how web sites use cookies in their login systems. Although I have some HTTP knowledge, I'm just just learning about cookies and how they are used within sites.
Initially I assumed that when submitting the form I'd see no cookies sent, and that the response would contain some cookie info that would then be saved by the browser.
In fact, just the opposite seems to be the case. It is the request that's sending in info, and the server returns nothing.
When fiddling about the issue, I noticed that even with a browser cleaned of cookies, the client seems to always be sending a RequestVerificationToken to the server, even when just looking around withot being signed in.
Why is this so?
Thanks
Cookies are set by the server with the Set-Cookie HTTP response header, and they can also be set through JavaScript.
A cookie has a path. If the path of a cookie matches the path of the document that is being requested, then the browser will include all such cookies in the Cookie HTTP request header.
You must make sure to be careful when setting or modifying cookies in order to avoid XSS attacks against your users. As such, it might be useful to include a hidden and unique secret within your login forms, and use such secret prior to setting any cookies. Alternatively, you can simply check that HTTP Referer header matches your site. Otherwise, a malicious site can copy your form fields, and create a login form to your site on their site, and do form.submit(), effectively logging out your user, or performing a brute-force attack on your site through unsuspecting users that happen to be visiting the malicious web-site.
The RequestVerificationToken that you mention has nothing to do with HTTP Cookies, it sounds like an implementation detail that some sites written in some specific site-scripting language use to protect their cookie-setting-pages against XSS attacks.
When you hit a page on a website, usually the response(the page that you landed on) contains instructions from the server in the http response to set some cookies.
Websites may use these to track information about your behavior or save your preferences for future or short term.
Website may do so on your first visit to any page or on you visit to a particular page.
The browser would then send all cookies that have been set with subsequent request to that domain.
Think about it, HTTP is stateless. You landed on Home Page and clicked set by background to blue. Then you went to a gallery page. The next request goes to your server but the server does not have any idea about your background color preference.
Now if the request contained a cookie telling the server about your preference, the website would serve you your right preference.
Now this is one way. Another way is a session. Think of cookies as information stored on client side. But what if server needs to store some temporary info about you on server side. Info that is maybe too sensitive to be exposed in cookies, which are local and easily intercepted.
Now you would ask, but HTTP is stateless. Correct. But Server could keep info about you in a map, whose is the session id. this session id is set on the client side as a cookie or resent with every request in parameters. Now server is only getting the key but can lookup information about you, like whether you are logged in successfully, what is your role in the system etc.
Wow, that a lot of text, but I hope it helped. If not feel free to ask more.
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.
I'd like to remove the cookies of another site from users on my site. Is there any way to access the cookies from different domains.
No, the same origin policy forbids that. You can only view or set cookies that you set and that are valid for the current URL.
No, of course not. That would be terrible. How would you like it if any site you went to could just read your stored password to any site you have saved?
Try it and Google will block your site from Chrome and your whole site will end up being blacklisted as it appears to contain Malware! While it's not illegal, it's a kind of behaviour that makes you as popular on the Internet as the average spammer...
Furthermore, the storage of cookies depends on the browser that is used by the client. You don't have any control over that.
However, if the other site has an URL that will remove the cookie, you can inline that URL in an IFrame on your site so visitors of your site will call the cookie cleaner from the other site, thus clearing their cookie in a valid way. The Same Origin Policy will apply in this case since it's the original site that clears it. But if the other site offers no such functionality then it won't work...
The only place I can think that this you'd need this would be if you owned many domains, and you log in on one domain, you want to log off in another domain.
In php, the "setcookie" function has a way to specify a domain. You should put in the domain you wish for the cookies to be modified under. Then when you can erase/modify the cookies across all those domain.
Otherwise though, the answer is no, you cannot modify a cookie on another domain unless it gave you permission to modify such cookies.
Wow, I certainly hope there's no way to do this! If there is a way, it's a bug in the browser security.
Obvious follow-up questions: Is there any way I can set something in a user's browser that will prevent him from accessing a competitor's site? Is there any way I can cause other people's web servers to explode and kill everyone in the building?
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.