Post Reply 
Bypass For Mozilla's New Plug-In Check Site
Oct. 07, 2009, 01:39 AM
Post: #1
Bypass For Mozilla's New Plug-In Check Site
The new 'beta' site:

https://www-trunk.stage.mozilla.com/en-US/plugincheck/

has critical functionality blocked by Web filter:

Code:
[Patterns]
Name = "Block/Modify: Sel. JS Properties     07.04.02 [sd] (d.2)"
Active = TRUE
URL = "($TST(hCT=*html)|$TYPE(js)|$TYPE(vbs))(^$TST(keyword=*.(a_js|a_jsprop).*))"
Limit = 128
Match = ".$TST(script=[1s]*)($LST(JSProperties))\3((^[a-z.])|.(^php|asp|cgi|htm)[a-z])\2"
        "&"
        "$SET(eHits=$TST(\5=$TST(hCT=*html)*)$GET(eHits)"
        "%3Cspan class=%22Pr0xFly-Span%22%3E$GET(mHead) JS Property:%3C/span%3E"
        "    $ESC(\3)%3Cbr class=%22Pr0xFly-Br%22 /%3E"
        ")"
        "($TST(volat=*.log:2*)$ADDLST(Log-Main,[$DTM(d T)]\tWEB JS_Prop\t.\3 \t\u)|)"
Replace = "\@\2\0"

That filter triggers code in 'JSProperties.ptxt (line 16):
Code:
userAgent(^_|.(^((last|)indexOf|match|replace|search|slice|split|substr(ing|)
  |to(Lower|String|Upper)[a-z]+) \(|length)|=([^a-z_$=]|function)| \()&&
                (^$TST(keyword=*.i_ua:*))$SET(#=.PRX)\#

To return functionality to the page, this script must be able to execute:

Code:
ajax.googleapis.com/ajax/libs/jquery/1/jquery.js

so, you can add the following to 'Exceptions-U.ptxt' for that purpose (or something similar modifying it to be either more restrictive or less restrictive):

Code:
ajax.googleapis.com/ajax/libs/jquery/* $SET(0=i_ua:0.$TST(uDom=mozilla.com))

Hopefully, an expert will be along shortly to correct any erroneous statements I have made.

Notes - Plug-in Check Page
- The page currently has SSL certificate issues. For info, see comments on this page:
http://blog.mozilla.com/webdev/2009/10/0...your-help/

Notes - Filter(s):
- Sidki may find that a better fix is available via modification(s) to
the filter or to 'JSPoperties.ptxt' rather than using exceptions.

-Though I do not normally run with Proxo-SSL enabled, I do test with it occasionally, and I noticed that the 'plug-in check' site works with SSL enabled even without adding the above exception (is this the desired behavior?). Additionally, if Header-filter, 'Block All Third Party Scripts', is enabled (sans any specific exceptions for that), the site functionality is blocked, so it seems some specific filters get bypassed automatically with SSL enabled, and others do not?

-In contrast to the note immediately above, when Proxo-SSL is disabled, I noticed that the 'plug-in check' site's functionality is never impacted by enabling Header-filter, 'Block All Third Party Scripts'. Is this because no reference to the 'first-party' exists (i.e., uDom does not get set), thus a 'third-party' cannot be defined and thus, cannot be blocked with that particular filter?
Add Thank You Quote this message in a reply
Oct. 07, 2009, 06:13 PM
Post: #2
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 07, 2009 01:39 AM)ProxoDent Wrote:  The new 'beta' site:

https://www-trunk.stage.mozilla.com/en-US/plugincheck/

has critical functionality blocked by Web filter:

So... what critical functionality gets blocked exactly?
Add Thank You Quote this message in a reply
Oct. 07, 2009, 07:37 PM (This post was last modified: Oct. 07, 2009 07:42 PM by ProxoDent.)
Post: #3
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 07, 2009 06:13 PM)sidki3003 Wrote:  So... what critical functionality gets blocked exactly?

Here, the 'critical' functionality is that the 'plug-in check' does not run. To me that is critical. Smile! See attached images below (one where plug-in check is not working, the other working after applying the exception I posted).

Based on your comment, I must assume that it works for you. Did you see my note that it works if you are running with Proxo SSL enabled:

ProxoDent Wrote:Though I do not normally run with Proxo-SSL enabled, I do test with it occasionally, and I noticed that the 'plug-in check' site works with SSL enabled even without adding the above exception (is this the desired behavior?). Additionally, if Header-filter, 'Block All Third Party Scripts', is enabled (sans any specific exceptions for that), the site functionality is blocked, so it seems some specific filters get bypassed automatically with SSL enabled, and others do not?


Attached File(s)
.png  PlugInCheck-NotWorking.png (Size: 115.25 KB / Downloads: 675)
.png  PlugInCheck-Working.png (Size: 117.31 KB / Downloads: 690)
Add Thank You Quote this message in a reply
Oct. 10, 2009, 09:08 AM
Post: #4
RE: Bypass For Mozilla's New Plug-In Check Site
The mozilla 'plugin-check' page has changed significantly since my first posts (bug fixes and feature modifications / additions). Seems to be picking up a lot more plug-ins, though it still lacks the ability to identify version numbers for quite a few.

Most significantly in regard to Proxomitron, functional scripts are now coming from 'stage.mozilla.com', so the exception:

Code:
ajax.googleapis.com/ajax/libs/jquery/*  $SET(0=i_ua:0.)

isn't required as of this writing (though it was valid when I made my previous posts).

Anyway, I probably jumped the gun posting an exception for a beta site that is going to be in continual development for the time being. I'll refrain from posting any additional requirements if they arise just to cut down on posts that will likely become obsolete in short order.
Add Thank You Quote this message in a reply
Oct. 10, 2009, 02:51 PM
Post: #5
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 10, 2009 09:08 AM)ProxoDent Wrote:  Anyway, I probably jumped the gun posting an exception for a beta site that is going to be in continual development for the time being.

I wouldn't know the site existed without this post.

(Oct. 10, 2009 09:08 AM)ProxoDent Wrote:  functional scripts are now coming from 'stage.mozilla.com'

Could it be that everybody doesn't get the same code?

sidki Wrote:So... what critical functionality gets blocked exactly?

(Oct. 10, 2009 09:08 AM)ProxoDent Wrote:  I'll refrain from posting any additional requirements if they arise just to cut down on posts that will likely become obsolete in short order.

I don't see the harm, if you are doing the work regardless.

Have fun
Add Thank You Quote this message in a reply
Oct. 10, 2009, 10:31 PM
Post: #6
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 10, 2009 02:51 PM)JJoe Wrote:  
(Oct. 10, 2009 09:08 AM)ProxoDent Wrote:  functional scripts are now coming from 'stage.mozilla.com'

Could it be that everybody doesn't get the same code?

sidki Wrote:So... what critical functionality gets blocked exactly?

Yes, it is very possible that people aren't getting the same code.

But regarding Sidke's experience at that point in time, it was also possible that he tested with Proxo SSL enabled, which I pointed out allowed the site to function without the exception. I was hoping he could respond to that point because I found it interesting.

Thanks for the encouragement (seems you're all about that with your latest posts Smile! ).
Add Thank You Quote this message in a reply
Oct. 16, 2009, 01:26 PM
Post: #7
RE: Bypass For Mozilla's New Plug-In Check Site
FYI - The site has moved out of beta:

http://www.mozilla.com/en-US/plugincheck/
Add Thank You Quote this message in a reply
Oct. 18, 2009, 07:32 AM
Post: #8
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 16, 2009 01:26 PM)ProxoDent Wrote:  FYI - The site has moved out of beta:

http://www.mozilla.com/en-US/plugincheck/

Worked well without the need to add additional Exception entry.
Add Thank You Quote this message in a reply
Oct. 18, 2009, 07:37 AM (This post was last modified: Oct. 18, 2009 07:39 AM by Kye-U.)
Post: #9
RE: Bypass For Mozilla's New Plug-In Check Site
It seems to work fine for me without making any changes (both 2009-02-13 (Update 06-06) and 2009-05-24 Alpha 2) Smile!
Visit this user's website
Add Thank You Quote this message in a reply
Oct. 28, 2009, 05:45 PM
Post: #10
RE: Bypass For Mozilla's New Plug-In Check Site
(Oct. 10, 2009 10:31 PM)ProxoDent Wrote:  But regarding Sidke's experience at that point in time, it was also possible that he tested with Proxo SSL enabled, which I pointed out allowed the site to function without the exception. I was hoping he could respond to that point because I found it interesting.

I think i know what was happening. It's a little hard to explain, but i try:

The config is "taming" page scripts.
If at all possible, it does so by not touching external scripts, but redefining potentially dangerous/annoying functions via the Proxomitron script, integrating an observer that can block the function after further inspection.

However, this isn't always possible. Actually, maybe it is possible, but i don't know how, hence my request here: http://prxbx.com/forums/showthread.php?tid=1204

If redefining isn't possible, Plan B is to rename the function/property/method in the *external* script.
The Proxomitron script, which is injected into the main document, will pick up those renamed functions.

If the main document - but not the external scripts - gets bypassed (or isn't filtered due to content-type), there's a good chance that things break.

A notorious example (wonder why i never got any complaints) are those various WoW sites, like wow-europe.com, which comes as application/xml. Same thing happens if you don't filter HTTPS, and a HTTPS page calls external HTTP scripts.



Regarding "responding to that point", i simply don't have the time for wading through asides to collect/guess all required information.

What is very helpful is the Bugzilla way of problem reports:
- User-Agent (Always! Sometimes OS is needed too)
- How to reproduce (SLL filtering is turned on by default)
- Expected result
- Actual result
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: