Is RequestPolicy of any value if using NoScript?

[welly]

Hi

I was wondering whether RequestPolicy addon would be of any value to me if I'm already using NoScript. Is it that the ABE function of NoScript does all (or more) than the RequestPolicy does?

[Giorgio Maone]

Is it that the ABE function of NoScript does all (or more) than the RequestPolicy does?

ABE can be configured to behave like RequestPolicy (i.e. block all the cross-site request by default, except a whitelist).
In its default configuration, though, ABE blocks only cross-zone requests (i.e. attacks on your LAN and your router).
Furthermore, if your aim is really blocking every cross-site request (which would mean that sites cannot link each other anymore), a NoScript-like UI like RequestPolicy's is surely more manageable than editing ABE's rules.

[Thrawn]

I'm using RequestPolicy, and it doesn't appear to block cross-site hyperlinks, presumably because it knows that the action was user-triggered? Yes, it can break sites, but actually, in its default configuration of allowing all subdomains, I've found it to have less impact than NoScript. That's certainly not a dig at NoScript, but the point is, most sites don't rely on cross-site requests in order to function (much less than the number relying on active content from their own domain).

I also agree that the interface is friendlier (and faster to use) than ABE for this job. I've heard that AdblockPlus can give similar behavior, too, but I think that it would again involve writing rules, not just clicking, which will slow things down. Actually, I've done the reverse; with RequestPolicy on, I've unsubscribed from EasyList, because 99% of advertising is cross-site, and if someone chooses to serve ads from their own domain, and I've chosen for NoScript to trust that domain, then hey, why not support the webmaster .

Since NoScript already does so much cross-site work, is there any chance of combining the two addons?

[Thrawn]

Hadn't seen any replies to this, but I've been seriously thinking about it lately: Surely it would be feasible to take RequestPolicy's interface and turn it into a front-end for ABE?

Two advantages over writing ABE rules by hand:
- You get feedback about what requests are being blocked/allowed on the page.
- Create rules just by clicking on the context menu, saving time and avoiding typing errors.

The advantage over just using RequestPolicy would be the access to ABE's finer-grained filtering, like distinguishing GET from POST, filtering per-page, and most importantly, being able to anonymize and/or sandbox requests instead of blocking them.

Anyone think this is a good/bad idea? I'm willing to put some time into it.

[Tom T.]

@ Thrawn:

Yikes, I should have read this before replying extensively to your PM to me.
(I haven't posted in this thread, and so am not subscribed to it.)

RP is designed for request *by one site* *to another site*. As you said, a hyperlink is (an offer for) a request by a user to visit another site, not a request that the site makes automatically -- else, there'd be no need for the hyperlink.

However, RP can be configured to prevent *prefetching* of links, which is a serious privacy leak even if you never click on them.

in its default configuration of allowing all subdomains, I've found it to have less impact than NoScript.

Meaning all subdomains of sites that you allow or temp-allow in RP? If so, the situation is the same as with NS:
Only base 2nd-level domains are shown by default, because each tool can be intimidating enough to new users already.

Those who get comfortable with them, and start browsing FAQ, preferences/options, etc. can allow full addresses in RP just as in NS. However, NS can show you both at the same time, which RP cannot do. When you click one radio button for domain level, it *replaces* the previous choice, whereas NS lets you check more than one.

most sites don't rely on cross-site requests in order to function

I don't know the statistics, but try visiting YouTube without allowing requests to ytimg.com, regardless of NS permissions.

In fact, more and more sites are storing their "static" content (that doesn't change very often) separately from the stuff that changes frequently, for reasons that should be apparent after a bit of reflection. In doing support, I visit many sites whose pages are all text on white, or don't work at all, until they are allowed to call their static storage (*which is often not executable, and hence, not subject to NS permissions*).

google.com > gstatic.com
maps.google.com (for those who don't wish to blanket-allow the google domain) > maps.gstatic.com

More, or trust me on this?

I've unsubscribed from EasyList, because 99% of advertising is cross-site,

I don't use ABP at all, because between NS and RP, ads never make it through anyway.

is there any chance of combining the two addons?

Not by Giorgio, although since both are FOSS, anyone is free to create their own, subject to whatever restrictions are in the GNU licenses.

Giorgio has stated that in general, "Do one thing, and do it well". Okay, NS does lots of stuff, but it is all for one purpose: Block undesired executable content, even if from the same site.
RP's purpose is to block cross-site requests, regardless of whether they're still images or even harmless plain text (not much of that around, lol).

RP is more for privacy and annoyance-blocking, with some overlap on CSRF and other cross-site attacks, while NS is about security and harmful code, with some overlap into protecting privacy by blocking data-mining scripts and the like.

At one point, NS had a checkbox, "Forbid web bugs", but it was removed, because the New, Greatly Improved Fx 4+ no longer had the infrastructure to let NS do that. RP could do that. Giorgio said he wasn't too unhappy about it, because he didn't want NS focusing on privacy-only issues, which leads to bloat and more problems.

Create rules just by clicking on the context menu, saving time and avoiding typing errors.

The advantage over just using RequestPolicy would be the access to ABE's finer-grained filtering, like distinguishing GET from POST, filtering per-page, and most importantly, being able to anonymize and/or sandbox requests instead of blocking them.

Anyone think this is a good/bad idea?

I do.

But as said in PM, NoScript 3.x for the desktop will have site-specific permission ability built in, without hand-typing rules. Check out the version already available for Mobile (in the link), and see how much of that might be doing what you're considering.

Sorry I didn't see this thread a year ago, but I think I was away from the site a good bit around that time.

[Thrawn]

Thanks for the reply, Tom!

I'm certainly looking forward to NoScript 3, so that I can selectively block plugins . However, I really like the idea of RequestPolicy as a way of blocking as-yet-unknown cross-site exploitation (just as NS blocks as-yet-unknown JavaScript/Java/Flash/PDF exploits). Note that whenever a new XSS vector is discovered, Giorgio has to chase his tail for a week responding to it.

Default-deny for cross-site requests solves the problem, and ABE provides a more powerful engine than RequestPolicy; I particularly like its ability to Anonymize and Sandbox requests, so you don't have to let your defences down entirely. However, RequestPolicy provides an interface that allows you to quickly whitelist what you need to, which I consider necessary in order to make default-deny usable. So I guess this is really more about making RequestPolicy better at what it does, rather than making NoScript better at what it does - but it's relevant to both.

Regarding your PM questions about the level of granularity in an ABE frontend - I was thinking it would start with replacing RequestPolicy functionality - basic site-to-site interactions - and could be taken further in later versions. Some complex rules might still need hand-editing - and the frontend would need to be designed to accommodate that - but if ABE can be made at least as accessible as RequestPolicy, then the frontend will have succeeded.

By the way, yeah, lots of sites lose their stylesheets with RequestPolicy on. I'm not too concerned about that, so long as I can still read them, so I don't normally consider them 'broken'. But yes, there certainly are lots of sites that get ugly with RP on, and some that don't work at all. That's one of the factors that really makes anonymized and sandboxed requests appealing...

[Tom T.]

Not much to say in reply, and by all means, work on your basic concepts, but one clarification:

I'm certainly looking forward to NoScript 3, so that I can selectively block plugins

By "Site-specific permissions", we're talking about selective *script-blocking* as well as plug-ins.

You'll be able to allow, say, Facebook scripts at Facebook only, but nowhere else.
Thus removing the present requirement to use ABE for this.

GL, and feel free to let us know about your product, perhaps in Forum Extras > Web Technology or Security.
Cheers.

[Thrawn]

Moved to Forum Extras > Security: http://forums.informaction.com/viewtopi ... =19&t=8059

[Thrawn]

Just came across another motivation to prefer ABE engine over RequestPolicy, documented here and alluded to already in this conversation:

I'm using RequestPolicy, and it doesn't appear to block cross-site hyperlinks, presumably because it knows that the action was user-triggered?

RP is designed for request *by one site* *to another site*. As you said, a hyperlink is (an offer for) a request by a user to visit another site, not a request that the site makes automatically -- else, there'd be no need for the hyperlink.

RP is more for privacy and annoyance-blocking, with some overlap on CSRF and other cross-site attacks, while NS is about security and harmful code, with some overlap into protecting privacy by blocking data-mining scripts and the like.

RequestPolicy will not block user-triggered actions. ABE will. For blocking web bugs etc, this is no big deal, but for blocking CSRF and XSS, you want ABE.

[Tom T.]

RequestPolicy will not block user-triggered actions. ABE will. For blocking web bugs etc, this is no big deal, but for blocking CSRF and XSS, you want ABE.

... and NS in general. (XSS protection is independent of ABE.)

I wish he'd put up a demo, to see whether his proposed method would trigger an XSS warning/block. It certainly appears as though it would, even if the user were lured into trusting both sites: (FAQ 4.1)

Cross-site requests from a trusted site to a different trusted site are checked through the InjectionChecker engine, which is more accurate and sanitizes only requests which contain conspicuous fragments of HTML or syntactically valid JavaScript.

Lots of conspicuous HTML in the demo code.

Agree overall that a combination of NS with ABE + RP is best -- or just NS + SABER.