Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • As far as I can say, this approach can’t ever work really right, I’m afraid. Security is a big issue with Javascript, and the origin of code and content (in terms of DNS domain, mostly) plays a big role. There are tight limitations on what is permitted to code when things with different origins mix.

    Now Greasemonkey runs scripts in the context of the page; however, it gives them access to functions that run within the browser’s local security context. That’s what’s special abo

    • Yes, but I have a proxy... That means I can write a GM_xmlhttpRequest with a specially formed URL which appears to fetch from the current domain but which the proxy rewrites to fetch from the intended domain.

      http://this.domain.com/<some long string>/intended.com/something.xml -->

      http://intended.com/something.xml

      That's my theory anyway - I haven't implemented it yet. Can you see any problems with that? Obviously I'm opening up an XSS hole so I'd need to make sure that the GM_ functions weren't accessible to the page's original JavaScript. I think that can be achieved with a nested scope around the injected GM Javascript.

      • Nice lateral thinking there!

        It almost sounds too easy to be right, but at first glance I can’t see anything wrong with that. I’d use HTTP Auth credentials rather than a long string in the URI, but that’s just a quibble.

        • I've just released 0.03 which supports GM_xmlhttpRequest to arbitrary sites. I'm afraid it uses a long arbitrary string in the URL to alert the proxy at the moment. I'll have a think about using auth credentials instead - it certainly sounds cleaner.