I want to load an external website in an iframe. But faced issues due to Same-Origin-Same-domain policy. So for solving this I used the proxy solution in which we send our request to a proxy file (I wrote in java) and then it requests the server and return back the response. This is working perfectly fine.
But using this method all the pages are not correctly loaded into my iframe.
Currently I am working on localhost. The problem i am facing is there are some errors in fetching the page like:-
On fetching www.google.com i got these errors:-
GET http://localhost:8080/images/srpr/logo1w.png 404 (Not Found)
a.html:101 GET http://localhost:8080/extern_js/f/CgJlbhICaW4gACswRTgALCswWjgALCswDjgALCswFzgALCswPDgALCswUTgALCswCjgAmgICaGUsKzCYATgALCswFjgALCswGTgBLCswQTgALCswTTgALCswTjgALCswVDgALCswaTgALCswkAE4ACwrMJIBOAAsKzDVATgALCsw2AE4ACwrMBg4ACwrMCY4ACyAAlCQAnA/Q4V9Cbp7fuo.js 404 (Not Found)
These errors are coming because relative path has been specified in the webpage i am fetching (I guess). Am I right? If I am then how to correct these things so that such errors can be corrected.
After searching on net, I got a site which does this perfectly. Please checkout http://optimizely.com
The issue appears to be that if a site uses relative HREFs (relative to the domain/path that the site was loaded from), then your solution will cause problems because you've changed the apparent load domain/path to something else.
One possibility is for you to inject a tag into the right place in the page (in the <head> section) like this to properly set the base href:
<base href="http://www.google.com">
See this article for more info: http://www.drostdesigns.com/base-href-tag/
This solution is not foolproof though because if the site is already using a <base href="xxx"> tag, your may cause problems and if javascript code is doing manipulations based on the loaded domain/path, the base href won't fix that. Whether those issues matter or not will depend upon the particular page.
If the base href solution doesn't work, you might have to proxy all the other requests for resources too (images, ajax calls, etc...) so that everything destined for the other host, but requested from you is proxied appropriately. This would be more foolproof.
There is no way we can tell just by the description you've posted so far of the problem.. but if the answer is indeed as you have alluded to, then simply correct it -- whenever you get a relative link, make it a fully qualified one by prepending the domain from within your proxying script.
Related
Sometimes websites won't let you load images without a valid referrer. Take this as an example, it returns a forbidden error. In a similar question I have found this answer, that suggests doing something like this:
<img src onerror="fetch('https://i.pximg.net/img-original/img/2020/11/28/06/04/23/85949640_p0.png', {headers: {Referer: 'https://www.pixiv.net/en/'}}).then(r=>r.blob()).then(d=> this.src=window.URL.createObjectURL(d));" />
This however, still fails to load the image. Checking the code of some extensions that promise to fix this error by installing scripts shows that they're just changing the referral, and that this should get things working.
Sometimes websites won't let you load images without proper a referrer.
Yes. Plenty of websites do not want to pay to store images and transfer them over the network so that freeloaders can display them on their websites without shouldering the cost.
In a similar question I have found this answer, that suggests doing something like this
That fails for two reasons.
It is a forbidden header. Browsers are designed to prevent your JavaScript from lying about where requests are being triggered from.
Most sites hosting images don't grant permission, via CORS, to third-parties to read them with JS. They are even more unlikely to if they do referer checking to stop freeloading!
If a website doesn't want you displaying images they host, you need to respect that.
Pay for your own image hosting instead.
Don't copy the images from the third-party to your own site unless you are sure they aren't protected by copyright (or you have permission).
Apologies if this is a roundabout way of asking this question, but I am a little confused about how the web and javascript work.
What I want to do: execute javascript on all pages of a list of urls I have found. (Specifically use jquery to pull info from them)
Problem I can't execute Javascript on these pages because they aren't mine and don't have the Access-Control-Allow-Origin header. So I can't load them (with AJAX) in order to use JQuery on them.
BUT Google Chrome can both load pages and execute javascript on them (with their developer's console). So if I wanted too, I could go to each page, open the developers console, and pull the information from there. If there's nothing stopping Chrome from accessing these, then why am I stopped? And, is there a way around this?
Thank you, and I hope my description makes sense. I've been researching this for a while but have found nothing that explains how seemingly inconsistent CORS is.
I could go to each page, open the developers console, and pull the information from there. If there's nothing stopping Chrome from accessing these, then why am I stopped?
You're not stopped. You, the human at the keyboard, can do exactly as you say, by visiting each page as a top-level page.
What is stopped -- happily -- is any and all scripts on the Web you happen to run having the same level of visibility that you do. Based on your cookies and your network topology, you have a unique view into the Web. You can see your home router's control interface (on 192.168.1.1 or similar). You can see any local web server you're running on 127.0.0.1. No one else can see these. If the same-origin policy were not in place, then any script that you loaded on the Web could inspect these.
And, is there a way around this?
If you have some scripts that you trust absolutely (hopefully a significant subset of "all scripts that exist on the Web") that you want to be able to bypass the same-origin policy and see your full, cross-domain view of the Web, you could load them as an extension, which can act with elevated permissions beyond the abilities of normal web pages. (See How does Same Origin Policy apply to browser extensions?)
I'm going to assume that you are looking to grab data from these pages that aren't yours and store it somewhere. I have done this before with curl using php. If you are looking to display these sites for users to interact in a different way, but starting from a page that is yours, you may be able to render these pages by grabbing the source html using curl and rendering it as a sort of proxy.
I've used this tutorial for something similar https://www.youtube.com/watch?v=_kQN-3aNCeI . Hopefully this gives you a start. I think you should be a little more detailed in your question though to get more help.
I am testing for XSS, I add some JavaScript code in the URL and suddenly all the pictures and style of the page disappear, displaying just the text content, and the injected JavaScript command even doesn't get executed, does what happens mean my code is vulnerable to this type of XSS?
The URL is:
http://localhost/index.php/<script>alert('hacked');</script>
No. This has nothing to do with XSS (that the script is not being executed is a good clue to that!).
What is means is that http://localhost/index.php/<script>alert('hacked');</ is a different "directory" to http://localhost/index.php/ or http://localhost/.
You have relative URLs in your document and they don't start with a / so they are relative to the URL of the page.
Since you are accessing the page from a URL that points to a different directory, the links have broken.
For a better understanding about CrossSite Scripting and how to replicate and prevent it, I recommend you the OWASP site, which also includes documentation about other common web vulnerabilities.
The URL is: http://localhost/index.php/script alert('hacked');script
Also, is not helpful to post an URL pointing to your localhost, since that site is in your machine and not on the internet, so we cannot access it and test it. If that same site is also published on the internet, post it with its public IP or its domain.
I dropped the <> of the script tag here as it is filtered
To post source code of any language in a question, format it with the Code format (the brackets button, in the format toolbar).
<script>Example of source code with script tag</script>
It looks like AJAX is indeed unable (at least for all practical purposes) to write foreign HTML to the current page. But what if your CDN website had, say, a JS that would simply document.write() everything? Then your HTML document would have nothing but a remote script.
<html>
<script src="https://pastebin.com/raw.php?i=0wm5v7i6">
</script>
</html>
I tried this. Funny thing is, sometimes it works and other times it does a kind of security error:
Why doesn't this work? What if, on your own website, you simply put everything on an easy host like Google Drive?
What if, on your own website, you simply put everything on an easy host like Google Drive?
That is possible, unless
You want control over your website and don't want to depend on the security and availibility of another site, or that somebody reports your pastebin as abuse and it gets deleted.
You want to make proper use of security features like content security policy and don't want to allow everything from pastebin.com.
You want search engines to find you. Although at least google does limited interpretation of JavaScript I doubt that they will handle this content the way you like.
From the looks of it, PasteBin doesn't supply content over SSL (https). You've put https in the URL to your script, but PasteBin just redirects this request to http, and the net effect is that you are trying to access a script over http when the page is accessed over https, and Chrome prevents that.
Just try going to https://pastebin.com/raw.php?i=0wm5v7i6: your browser will be redirected to http://pastebin.com/raw.php?i=0wm5v7i6.
we have a site with Iframes pointing to dynamic Urls (by user input).
In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Is there any solution for this?
Any other suggestions?
Thanks,
Tal
we have a site with Iframes pointing to dynamic Urls (by user input). In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
So it sounds like you are making a sort of "browser in a web page."
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
Yes, except not many things have onerror events. I assume you are aware of this from your comments on other answers. If I understand you right, you're talking about using a dummy script element to load the URL first (as a script, even though it's not really a script), and determine whether the URL is valid using the using onload/onerror handlers for the script element (onerror will not fire on a script error, only a network error).
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Your assumption is correct. If the URL actually does contain a script, it will execute in the user's browser in the same domain as your site.
Is there any solution for this?
A simple workaround might be to do something like what jsfiddle.net does... have a separate subdomain act as a "firewall" between the third-party content and your real domain.
Any other suggestions?
The script preload hack is really just that, a hack. It misappropriates the script tag and makes needless requests. I would probably look into using XHR to fire off a HEAD request instead, or doing some light server-side proxying.
Yes, if you use a <script> tag to embed a remote JS file, you have a security problem as the code is going to be executed in the context of your page.
The only workaround idea that comes to mind is making a server-side request to the resource and parse the response headers. This however may behave differently from a client-side request, as the call will be coming from the server, so it'll have a different IP, different cookies, etc.
If the user can only specify the frame’s URL, then any scripting in the frame’s document would be run in the context of the frame’s document and not in the context of the parent document the frame is embedded.
The question whether a script running inside the frame can access the parent’s document (i. e. your document) depends on the origin of both documents: only if they are equal both document’s are said to be same origin. And only in that case one document can access the other document.