A page we have is visited by users from two domains. lets call them x.com and y.com
I want some of the code to only display when the user visits from y.com- how do i do this in the same vbscript file? Or do i HAVE to have separate files?
i was thinking something like
if request.SOMETHING.contains("x") then etc
Try Request.ServerVariables("HTTP_REFERER").
You'll notice that REFERER is misspelled; that's because HTTP_REFERER was set in stone in RFC 1945 before anyone caught the spelling error.
More info
In addition to checking the referer as others have suggested you could also while calling the page put a value in the url indicating where you have come from (assuming you have access to the pages you are linking from).
This is more easy for a malicious or just curious user to mess with than the http referrer so in some ways it is less reliable. However you should bear in mind that the http referrer isn't a guaranteed solution anyway (a browser might not send it, security programs might strip out the header, etc.) and that any user who manually edits things in the querystring that they shouldn't be playing with has no grounds for complaint if things stop working. As long as it won't be a security hole it should be fine. And if changing the value is a security hole you shouldn't use the referrer either since that can be easily modified by those with a mind to.
request.servervariables("HTTP_REFERER")
Related
Let's say that a page is just printing the value of the HTTP 'referer' header with no escaping. So the page is vulnerable to an XSS attack, i.e. an attacker can craft a GET request with a referer header containing something like <script>alert('xss');</script>.
But how can you actually use this to attack a target? How can the attacker make the target issue that specific request with that specific header?
This sounds like a standard reflected XSS attack.
In reflected XSS attacks, the attacker needs the victim to visit some site which in some way is under the attacker's control. Even if this is just a forum where an attacker can post a link in the hope somebody will follow it.
In the case of a reflected XSS attack with the referer header, then the attacker could redirect the user from the forum to a page on the attacker's domain.
e.g.
http://evil.example.com/?<script>alert(123)>
This page in turn redirects to the following target page in a way that preserves referer.
http://victim.example.org/vulnerable_xss_page.php
Because it is showing the referer header on this page without the proper escaping, http://evil.example.com/?<script>alert(123)> gets output within the HTML source, executing the alert. Note this works in Internet Explorer only.
Other browsers will automatically encode the URL rendering
%3cscript%3ealert%28123%29%3c/script%3e
instead which is safe.
I can think of a few different attacks, maybe there are more which then others will hopefully add. :)
If your XSS is just some header value reflected in the response unencoded, I would say that's less of a risk compared to stored. There may be factors to consider though. For example if it's a header that the browser adds and can be set in the browser (like the user agent), an attacker may get access to a client computer, change the user agent, and then let a normal user use the website, now with the attacker's javascript injected. Another example that comes to mind is a website may display the url that redirected you there (referer) - in this case the attacker only has to link to the vulnerable application from his carefully crafted url. These are kind of edge cases though.
If it's stored, that's more straightforward. Consider an application that logs user access with all request headers, and let's suppose there is an internal application for admins that they use to inspect logs. If this log viewer application is web based and vulnerable, any javascript from any request header could be run in the admin context. Obviously this is just one example, it doesn't need to be blind of course.
Cache poisoning may also help with exploiting a header XSS.
Another thing I can think of is browser plugins. Flash is less prevalent now (thankfully), but with different versions of Flash you could set different request headers on your requests. What exactly you can and cannot set is a mess and very confusing across Flash plugin versions.
So there are several attacks, and it is necessary to treat all headers as user input and encode them accordingly.
Exploitation of xss at referrer header is almost like a traditional reflected xss, Just an additional point to make is "Attacker's website redirects to victim website and hence referrer header with required javascript will be appended to the victim website request".
Here One essential point that needs to be discussed is Why only with IE one can exploit this vulnerability why not with other browsers?
Traditional answer for this question is 'Chrome and firefox automatically encodes URL parameters and hence XSS is not possible..' But interesting thing here is when we have n number of bypasses for traditional xss bypasses. why can't we have bypasses for this scenario.
Yes.. We can bypass with following payload which is same way to bypass HTML validation in traditional payload.
http://evil.example.com/?alert(1)//cctixn1f .
Here the response could be something like this:
The link on the
referring
page seems to be wrong or outdated.
Response End
If victim clicks on referring page, alert will be generated..
Bottomline: Not just only IE, XSS can be possible even in Mozilla and Firefox when referrer is being used as part of href tag..
What is the point of doing this?
I want a reason why it's a good idea to send a person back to where they came from if the referrer is outside of the domain. I want to know why a handful of websites out there insist that this is good practice. It's easily exploitable, easily bypassed by anyone who's logging in with malicious intent, and just glares in my face as a useless "security" measure. I don't like to have my biased opinions on things without other input, so explain this one to me.
The request headers are only as trustworthy as your client, why would you use them as a means of validation?
There are three reasons why someone might want to do this. Checking the referer is a method of CSRF Prevention. A site may not want people to link to sensitive content and thus use this to bounce the browser back. It may also be to prevent spiders from accessing content that the publisher wishes to restrict.
I agree it is easy to bypass this referer restriction on your own browser using something like TamperData. It should also be noted that the browser's http request will not contain a referer if your coming from an https:// page going to an http:// page.
If I disable javascript and cookies, Amazon.com detects that cookies are disabled without a redirect. If you click the cart link, there's only a get on the cart page.
I'm guessing amazon.com is most likely not using ASP.NET, but how would you accomplish detecting disabled cookies using ASP.NET without the use of javascript and redirecting? Is it possible to detect if cookies are disabled in one round trip?
I believe what you're describing is impossible. Amazon doesn't appear to do that. As proof:
Disable JavaScript
Clear your cookies (but leave them enabled)
Go here: http://www.amazon.com/gp/cart/view.html/ref=gno_cart
You'll get the message "Please Enable Cookies in your Web Browser to Continue." But if you reload the page, the message will go away, because cookies got set on the first viewing.
The reason this doesn't work is that when a page response sets cookies, the server can't tell they've been properly set until the next request. You can get around that using JavaScript, of course, but without that there's no way for the server to know in advance whether a request comes from a browser that will accept cookies.
You don't need redirect to get at the cookies. All you need is a delayed load content.
Basically, I believe the following would work:
The 'GET /index.html' response sets the Cookies (they come in the header, and are stored before index.html is received and rendered).
You can than check for cookies while serving say 'GET /TinyImage.gif' if you don't run into caching problems and respond to images dynamically.
So, the final problem, is how do you inform the user about your findings from the TinyImage request? Definitely not easily, but if you use IFrame instead of a simple tag, you can essentially have two GET requests for a single page render.
Or, you can be really, really insane and actually stall the first GET until the second GET confirms the browser settings. This is for some HTTP wizards, but if you can wrap your head around Comet (not AJAX, Comet!), it can come in handy.
It's definitely possible, just tricky. Would I try doing so in ASP.NET? Can't promise anything but it will be a neat thing to share.
I guess it may load the page in the javascript / cookies off configuration and then use javascript to do the check and set functionality to cookies enabled if needed.
Could you set a Cookie in Page_Init for instance, then see if you could read from it in Page_PreRender?
Not sure that's even possible, but that's the only way I could think of.
I do not believe this is possible, but I figure there are people out there way smarter than me, so why not check ..
I would like to have an HTTP image that is viewable from within a page when used w/in an img tag, but NOT visible if the img src link is called directly. Does that make sense? Viewable in page, but not if called directly.
Quick edit .. acceptable alternative is to embed image in page in such a way as url is not human readable / able to be extracted and typed into browser.
Update 2 ... .NET IIS7 env.
Note that "security" products such as Norton Internet Security and Norton Personal Firewall prevent the HTTP Referer: (TBL's spelling mistake, not mine) header being sent by default. As these products are widely used, referrer blocking will break things for an awful lot of people.
FWIW, if I was keen to get your image other than by viewing your page (although I can't imagine why I should be) I would just grab the bits as they came over the network when I viewed your page, using something like Charles or Fiddler. It's completely impossible to make content available over the web but prevent people from making a copy.
I believe that you can achieve something like this by relying on the referrer header supplied by the browser - when the referrer is a web page on your own site, you serve up the image, but not otherwise.
It's not 100% reliable (as passing the referrer isn't mandatory in the HTTP spec) but works well enough for some sites.
This is achieved through configuration of your webserver; you therefore might have more luck asking this on ServerFault.
Yes, there are lots of articles on how to setup mod_rewrite rules in apache to try and prevent direct access to files.
http://www.cyberciti.biz/faq/apache-mod_rewrite-hot-linking-images-leeching-howto/
It depends on how it gets built. You can always make sure your referrer is the page that you expect it to be hosted from and lock down requests there.
If you have some notion of authentication, you could bury the image under some type of php/ruby script or asp.net http handler that requests the image from the server or database (in a place that is not publicly viewable but is reachable by your server-side code) and that handler could check for your authentication status before returning it.
Frankly, I re-worked my solution so I didn't really have to worry bout it ... know that's a cop out, as it doesn't REALLY answer the question, but there it is. My concern that users would be able to defraud the "game" I was creating if they could figure out the sequence that was being used to name the images. Quick and dirty solution .... don't make image file names sequential / predictable.
I need to ensure that my webpage is always within an iframe owned by a 3rd party. This third party refers to our landing page using src="../index.php".
Now my question is, if I make use of referrer to ensure that the page was requested by either myself or from the third party and if not force a reload of the 3rd party site, are there any big gotchas I should be aware of?
For example, are there certain common browsers that don't follow the referrer rules?
Thank you.
Also, it's REFERER because it somehow got misspelled in the spec. That was my very first REFERER gotcha.
You can't use referrer to "ensure" that the webpage is always being called from somewhere else because of referrer spoofing.
Referrers are not required. If a browser doesn't supply it then you'll get yourself into an endless redirect loop. Referrer is effectively "voluntary" just like cookies, java, and javascript.
Although. You could keep a log of IP & time last redirected. Prune the logs for anything over 5 minutes old and never redirect more than once per 5 minutes. You should catch 99.9% of users out there but avoid an infinite redirect loop for the rest. The log cannot rely on anything in the browser (that's the original problem) so no cookie and no session. A simple 2-column database table should suffice.
The only way you could do this is to directly authorize the request because of referrer manipulation..
You could restrict requests to a set of IP addresses, if you want to be lax, or require that the including client/system has an authentication cookie for requests shown in the iframe.
Good Luck
Even well-known formats may change...
Google apparently has changed its referrer URL. April 14, 2009, An upcoming change to Google.com search referrals; Google Analytics unaffected:
Starting this week, you may start seeing a new referring URL format for visitors coming from Google search result pages. Up to now, the usual referrer for clicks on search results for the term "flowers", for example, would be something like this:
http://www.google.com/search?hl=en&q=flowers&btnG=Google+Search
Now you will start seeing some referrer strings that look like this:
http://www.google.com/url?
sa=t&source=web&ct=res&cd=7
&url=http%3A%2F%2Fwww.example.com%2Fmypage.htm
&ei=0SjdSa-1N5O8M_qW8dQN&rct=j
&q=flowers
&usg=AFQjCNHJXSUh7Vw7oubPaO3tZOzz-F-u_w
&sig2=X8uCFh6IoPtnwmvGMULQfw
(See also Google is changing its referrer URLs from /search into /url. Any known issues?)
Be aware that Internet Explorer (all versions) specifically OMITS the HTTP REFERRER whenever a user navigates to a link as a result of JavaScript. (bug report)
e.g.
function doSomething(url){
//save some data to the session
//...
location.href = url;//IE will NOT pass the HTTP REFERRER on this link
}