I am developing an iframe for use on a number of our partners websites.
Is there any way I can make sure it can only be used on those websites and not by anyone else
I was intending to add a compulsory querystring to the URL for the website.
Each partner would have a different value in the quesrystring dnd use that to look up an allowed domain
However, is there anyway to know the top level domain of the site hosting the iframe?
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
Or do you need to send the domain from javascript?
Any advice?
However, is there anyway to know the top level domain of the site hosting the iframe?
Nothing reliable.
Presumably this is not sent in the http request for the iFrame? Or is it, I couldn’t see it?
It might be sent in the referer
Or do you need to send the domain from javascript?
If you want to fetch it from the framed page, you will be blocked by the same origin policy.
If you want to sent it from the framing page, you will be putting it in the query string and you can't trust it because it can be set to whatever the person writing the framing page likes.
There is also the X-Frame-Options header (but that has limited browser support).
The most reliable solution I can think of is:
Require the origin to be specified in the query string used to load the frame
Check the referer. If it doesn't match your white-list and is not blank, redirect to a page that is blank except for a link to your site with target="_top" and some JavaScript that top.location = "your site"
Check that the origin specified in the query string is on your whitelist, if it isn't act in the same way as a rejected step 2
Output an X-Frame-Options header that limits the framing to the specified origin
That is likely to catch enough browsers to discourage the framing site from framing your site.
You can try to check referrer which normal browser will send for IFrame requests on the page.
You also can use "x-frame-options" header covered in (How to Block Iframe call and MDN ) but not every browser will respect that (on other hand it is more reliable if browser supports it).
iframe's sanbox attribute might be helpful in controlling the various security aspects in an iframe including origins
http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
The Architecture Journal of 2007 has a nice article about this: Secure Cross-Domain Communication in the Browser
Basically what the article suggests is:
If you have page A on domain 1 with an iframe with page B on domain 2 as its source , then having an iframe on page B to page C on domain 1, would allow you to pass information across domains
I haven't tested it, but this sounds like it could work.
Another possibility is create a file with a special filename (for instance a hash of the URL of page B on domain 2) and basic extension (like .htm) and place it in the root of domain 1. Checking whether the file exists on domain 1 cannot be done by javascript however, so it should be done with server side code.
Related
We have a homebrewed advertising system on our website. Part of this includes code that when an ad is clicked, we first go to a intermediary page that records the click data, which then redirects them along to the desired advertiser's website.
Unfortunately, our current solution requires that a URL parameter be passed to the intermediary page that is the destination URL. Some savvy advertisers have discovered that they can use this for their own nefarious purposes and "launder" their traffic through our site. In other words, on their site, they have a link along the lines of www.oursite.com/redirect?URL=www.theirtargetsite.com, making it seem like that traffic is coming from our site.
I'm working on a solution that will only redirect to a whitelist of URLs, but my first problem is more just knowing what this is called. Finding alternative and probably better solutions is difficult when I don't even know what to call it. With so much spoofing, laundering, and hijacking going on, it's hard to find help for the right topic.
What is it called when website A redirects to website C through website B without the permission of B?
The word you're looking for is open redirect. The MITRE article on this class of vulnerability has some examples of ways that this can be mitigated, e.g:
Whitelist the URLs that you will redirect to
Displaying a warning page before redirecting (probably not viable in your situation)
Use numbers to identify the URLs to redirect to (i.e, look them up in a table) instead of putting the target in a query parameter
Use a HMAC construction to "sign" URLs to redirect to, and reject redirects that don't have a valid signature
If I have a domain which is:
(1) http://www.myownsite.com
And I have another domain that has a link to it:
(2) http://www.pointingtomyownsite.com
Is there a way to find out whether (1) is opened through a redirect from (2) in ASP.NET MVC?
It depends on what you mean by "redirect". If you mean a CNAME DNS entry (where one hostname appears in the browser even though the page is served from another host, and which many people incorrectly call a DNS redirect), then Senad's answer is correct, Request.Url.Host will work. (This is not a redirect BTW).
A real redirect will change the hostname shown in the browser window, and you can get the URL of the previous page using HttpRequest.UrlReferrer. This works for both redirects and links. Although the Referer HTTP header this property exposes is not technically required and may be NULL, in practice it will be sent by all the browsers you should care about except for possibly if the URL was entered directly on a new tab.
Yes,
var hostname = requestContext.HttpContext.Request.Url.Host
I'm designing a site using ASPx and IIS, where clients can sign up and then offer services to their clients. For example:
if you go to http://www.mywebsite.com you can sign up for your mywebsite.com account as a business owner. When you sign up, you are given a Site ID (Example: AA1234).
http://www.mywebsite.com/AA1234
What I want to do is always include the Site ID in every url (Inbound and Outbound). The Site ID is stored in a session variable based on the initial incoming request.
Does anyone know of a good way to do this - or a different design that works better than this?
Thanks
Your question is nebulous at best. However...
Wouldn't this be what cookies are used for?
In particular, if your user is authenticated (this is generally achieved in asp.net with an auth cookie), then at the server, you would have tools at your disposal that allow you to recognize the user and provide a different experience according to whatever criteria you choose. Most likely, these details might be stored in a database.
Found the answer in this topic: http://www.tek-tips.com/viewthread.cfm?qid=1149673
The last response from BoulderBum is exactly what I needed.
Using the HTTP module I will take the /AA1234/ URL and point it to /Company/.
On the way out, I replace all instances of /Company/ with the site id again
I'm using a C# WebClient to post login details to a page and read the all the results.
The page I am trying to load includes flash (which, in the browser, translates into HTML). I'm guessing it's flash to avoid being picked up by search engines???
The flash I am interested in is just text (not an image/video) etc and when I "View Selection Source" in firefox I do actually see the text, within HTML, that I want to see.
(Interestingly when I view the source for the whole page I do not see the text, within HTML, that I want to see. Could this be related?)
Currently after I have posted my login details, and loaded the HTML back, I see the page which does NOT show the flash HTML (as if I had viewed source for the whole page).
Thanks in advance,
Jim
PS: I should point out that the POST is actually working, my log in is successful.
Fiddler (or similar tool) is invaluable to track down screen-scraping problems like this. Using a normal browser and with fiddler active, look at all the requests being made as you go through the login and navigation process to get to the data you want. In between, you will likely see one or more things that your code is doing differently which the server is responding to and hence showing you different HTML than a real client.
The list of stuff below (think of it as "scraping 101") is what you want to look for. Most of the stuff below is probably stuff you're already doing, but I included everything for completeness.
In order to scrape effectively, you may need to deal with one or more of the following:
cookies and/or hidden fields. when you show up at any page on a site, you'll typically get a session cookie and/or hidden form field which (in a normal browser) would be propagated back to the server on all subsequent requests. You will likely also get a persistent cookie. On many sites, if a requests shows up without a proper cookie (or form field for sites using "cookieless sessions"), the site will redirect the user to a "no cookies" UI, a login page, or another undesirable location (from the scraper app's perspective). always make sure you capture the cookies set on the initial request and faithfully send them back to the server on subsequent requests, except if one of those subsequent requests changes a cookie (in which case propagate that new cookie instead).
authentication tokens a special case of above is forms-authentication cookies or hidden fields. make sure you're capturing the login token (usually a cookie) and sending it back.
POST vs. GET this is obvious, but make sure you're using the same HTTP method that a real browser does.
form fields (esp. hidden ones!) I'm sure you're doing this already, but make sure to send all form fields that a real browser does, not just the visible fields. make sure fields are HTML-encoded properly.
HTTP headers. you already checked this, but it may make sense to check again just to make sure the (non-cookie) headers are identical. I always start with the exact same headers and then start pulling out headers one by one, and only keep the ones that cause the request to fail or return bogus data. this approach simplifies your scraping code.
redirects. These can either come from the server, or from client script (e.g. "if user doesn't have flash plug-in loaded, redirect to a non-flash page"). See WebRequest: How to find a postal code using a WebRequest against this ContentType="application/xhtml+xml, text/xml, text/html; charset=utf-8"? for a crazy example of how redirection can trip up a screen-scraper. Note that if you're using .NET for scraping, you'll need to use HttpWebRequest (not WebClient) for redirect-dependent scraping, because by default WebClient doesn't provide a way for your code to attach cookies and headers to the second (post-redirect) request. See the thread above for more details.
sub-requests (frames, ajax, flash, etc.) - often, page elements (not the main HTTP requests) will end up fetching the data you want to scrape. you'll be able to figure this out by looking which HTTP response contains the text you want, and then working backwards until you find what on the page is actually making the request for that content. A few sites do really crazy things in sub-requests, like requesting compressed or encrypted text via ajax, and then using client-side script to decrypt it. if this is the case, you'll need to do a bit more work like reverse-engineering what the client script is doing.
ordering - this one is obvious: make HTTP requests in the same order that a browser client does. that doesn't mean you need to make every request (e.g. images). Typically you only need to make the requests which return text/html content type, unless the data you want is not in the HTML and is in an ajax/flash/etc. request.
(Interestingly when I view the source for the whole page I do not see the text, within HTML, that I want to see. Could this be related?)
This usually means that the discrepancy is caused by some DOM manipulations via javascript after the page has loaded. Try turning off javascript and see what it looks like.
In an aspx C#.NET page (I am running framework v3.5), I need to know where the user came from since they cannot view pages without logging in. If I have page A (the page the user wants to view) redirect to page B (the login page), the Request.UrlReferrer object is null.
Background: If a user isn't logged in, I redirect to the Login page (B in this scenario). After login, I would like to return them to the page they were requesting before they were forced to log in.
UPDATE:
A nice quick solution seems to be:
//if user not logged in
Response.Redirect("..MyLoginPage.aspx?returnUrl=" + Request.ServerVariables["SCRIPT_NAME"]);
Then, just look at QueryString on login page you forced them to and put the user where they were after successful login.
UrlReferrer is based off the HTTP_REFERER header that a browser should send. But, as with all things left up to the client, it's variable.
I know some "security" suites (like Norton's Internet Security) will strip that header, in the belief that it aids tracking user behavior. Also, I'm sure there's some Firefox extensions to do the same thing.
Bottom line is that you shouldn't trust it. Just append the url to the GET string and redirect based off that.
UPDATE: As mentioned in the comments, it is probably a good idea to restrict the redirect from the GET parameter to only work for domain-less relative links, refuse directory patterns (../), etc. So still sanity check the redirect; if you follow the standard "don't use any user-supplied input blindly" rule you should be safe.
If you use the standard Membership provider, and set the Authorization for the directory/page, the code will automatically set a query parameter of ReturnUrl and redirect after a successfull login.If you don't want to use the Membership provider pattern, I would suggest manually doing the query string parameter thing as well. HTTP referrers are not very reliable.
The problem could be related on how you redirect the user to some other page. Anyways, the referer url is nothing you should take as absolute rule - a client can fake it easily.
What you're looking for is best done with a query string variable (e.g. returnURL or originURL). Referrer is best used for data mining operations as it's very unreliable.
See the way ASP.Net does redirection with logins for an example.