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.
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..
Scenario goes like this:
Main parts of web site is on one server. All traffic goes over https. I have no control ovet this server.
Themes use css files and images from another server. Also over https. I have full control over this server.
How vulnerable is the main site (how and why) if css files and images would go over http? I am asking only about css and images.
I don't know how relevant is, but server is Apache and language is PHP.
---------------- edit ------------
So far, there is 'a man in the middle' attack who can change css and thus hide my content, introduce new images and add more text.
But can not create live links, or add js...
Here is a good discussion about this topic started by symcbean.
Any unencrypted HTTP connection can potentially be intercepted and modified by men-in-the-middle. That means, any resource you're retrieving via an HTTP connection is untrustworthy; it cannot be confirmed whether it's the original resource as intended. That means an attacker may be able to include resources in your page which you did not intend to include.
In the case of CSS files content can be altered on your site (display: none, content: "Please go to example.com and enter your password"), in the case of images exploits may be introduced (through buggy image decoding client-side), in the case of Javascript entirely arbitrary behaviour may be injected (e.g. sending all key-strokes to a 3rd party server).
A third party may modify those CSS or images to convey different things, either by tampering that data on the fly, or by spoofing the target. The browser would not know if is getting those from a reliable source, and probably would complain about mixed content issues. CSS3 has many features that may bring pictures from another domain or include unintended content.
I often have to go into other people's work to make modifications for short-term contracts and a lot of times I have to deal with security warnings throwing in IE because something is including HTTP content from maybe an image, or css or whatever, onto a HTTPS secure page.
I was just curious if there is a well known program or service that will scan a URL and come back with exactly what is coming from HTTP instead of HTTPS on a page?
I use fiddler, but for reasons having to do with my own inadequacies, I find the program difficult at times, and am un-able to zero in on the offending content in a timely manner.
Any advice from the true pros?
Using Fiddler:
In main menu > Tools > Fiddler options, tab HTTPS, uncheck Capture HTTPS CONNECTs. Then, in main menu > Rules, check Hide HTTPS CONNECTs.
This way, the only thing you'll see in your Fiddler capture will be the HTTP requests and responses (without the HTTPS requests or CONNECTs getting in the way).
I would load up the page in Firefox and use Firebug's Net panel to examine all the resources that the page loads.
There's no 'set in stone' way as far as I know, but the easiest way I know of is to either use a tool such as Opera Dragonfly or Chrome's Web Inspector, view the 'Network' tab and see where the resources are being loaded from. You can sometimes (depending on what you use) order this alphabetically and you will clearly see between http:// and https://.
Also as already mentioned, you could just search the source for http://.
I have a stylesheet that loads images from an external domain and I need it to load from https:// from secure order pages and http:// from other pages, based on the current URL. I found that starting the URL with a double slash inherits the current protocol. Do all browsers support this technique?
HTML ex:
<img src="//cdn.domain.example/logo.png" />
CSS ex:
.class { background: url(//cdn.domain.example/logo.png); }
If the browser supports RFC 1808 Section 4, RFC 2396 Section 5.2, or RFC 3986 Section 5.2, then it will indeed use the page URL's scheme for references that begin with "//".
When used on a link or #import, IE7/IE8 will download the file twice per http://paulirish.com/2010/the-protocol-relative-url/
Update from 2014:
Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
One downside occurs if your URLs are viewed outside the context of a web page. For example, an email message sitting in an email client (say, Outlook) effectively has no URL, and when you're viewing a message containing a protocol-relative URL, there is no obvious protocol context at all (the message itself is independent of the protocol used to fetch it, whether it's POP3, IMAP, Exchange, uucp or whatever) so the URL has no protocol to be relative to. I've not investigated compatibility with email clients to see what they do when presented with a missing protocol handler - I'm guessing that most will take a guess at http. Apple Mail refuses to let you enter a URL without a protocol. It's analogous to the way that relative URLs do not work in email because of a similarly missing context.
Similar problems could occur in other non-HTTP contexts such as in tweets, SMS messages, Word documents etc.
The more general explanation is that anonymous protocol URLs cannot work in isolation; there must be a relevant context. In a typical web page it's thus fine to pull in a script library that way, but any external links should always specify a protocol. I did try one simple test: //stackoverflow.com maps to file:///stackoverflow.com in all browsers I tried it in, so they really don't work by themselves.
The reason could be to provide portable web pages. If the outer page is not transported encrypted (http), why should the linked scripts be encrypted? This seems to be an unnecessary performance loss. In case, the outer page is securely transported encrypted (https), then the linked content should be encrypted, too. If the page is encrypted, the linked content not, IE seems to issue a Mixed Content warning. The reason is that an attacker can manipulate the scripts on the way. See http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 for a longer discussion.
The HTTPS Everywhere campaign from the EFF suggests to use https whenever possible. We have the server capacity these days to serve web pages always encrypted.
Just for completeness. This was mentioned in another thread:
The "two forward slashes" are a common shorthand for "whatever protocol is being used right now"
if (plain http environment) {
use 'http://example.com/my-resource.js'
} else {
use 'https://example.com/my-resource.js'
}
Please check the full thread.
It seems to be a pretty common technique now. There is no downside, it only helps to unify the protocol for all assets on the page so should be used wherever possible.
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")