InformAction Forums

I see. So I guess you'd have to exempt ".twitter.com"?

ssj100 wrote:I see. So I guess you'd have to exempt ".twitter.com"?

Nope, in this case it would be better inserting a rule before the general http: -> https: one, in order to allow twimg.com only to be included by twitter, like This way you won't allow arbitrary mixed content to be included by twitter, but only twimg.com icons, which is less dangerous as long as they're only images (not active content).

Gosh, that's a bit complicated - too much for me I think.

But thanks for the tutorial. I haven't come across a site that's broken on me yet (I never use twitter) anyway, so I'll just be using that http to https rule by itself.

Firefox (and even IE 6) would tell you of potential mixed content issues anyway:
http://ssj100.fullsubject.com/security- ... 7.htm#2271

I would say that 95%-100% of the time when people use a "from" clause they are thinking of sub-requests (INC) and consequently find the blockage of top level navigations a surprising and unwelcome side-effect. Shouldn't perhaps INC behavior be the default for from clauses?

One thing I note is that with the rule enforced, this "Security Warning" doesn't come up in Firefox:
http://ssj100.fullsubject.com/security- ... 7.htm#2271

My thinking is that perhaps it's best to disable this rule by default, and when Firefox pops up the "Security Warning", you could enable the rule in order to "safely" log in. What do you guys think? Or is there a way to configure Firefox/NoScript so that the "Security Warning" will come up regardless? Is it intentional that the "Security Warning" is disabled with this rule enabled?

I noticed something interesting on sourceforge:

1. forbid web bugs, disable abe mixed rules, if any
2. log in to sourceforge.net
3. load https://sourceforge.net/directory/
4. Fx does not flag the page as mixed
5. but if you sniff, you'll see that https://static.sourceforge.net/css/ghost/style.php redirects first to http and again back to https
6. this strikes me as a Fx bug, since the redirection can leak cookies. Unfortunately you need NS + web bug blocking to repro it on SF. Giorgio, if you think it's worth reporting, perhaps you can set up a public demo page for bugzilla, to take NS out the equation.
7. abe mixed rule will block this redirection, breaking the site (on other pages, if not this one), so that's not quite what you want in cases like this.
8. A general point to be extracted from this: it's a good idea to, if not block, then anonymize same domain mixed http sub-requests. I think many sites still don't do ssl right and request some resources over http from their own (sub)domains, potentially leaking cookies.
9. automatic https cookie management may help here, but since it doesn't secure cookies if at least one is secured by the site itself, something could still leak
10. abe, it seems can't quite express what's needed:

    Code: Select all

    Site http:
    Anon INC from SECURE_SELF++
    

    there is currently no way to refer to the secure version of SELF++. What do you think about adding that?
11. in addition to abe, perhaps such an option deserves to be in the ui and maybe even on by default (at least for typically static resources: css, images, scripts, ...)?

ssj100 wrote:One thing I note is that with the rule enforced, this "Security Warning" doesn't come up in Firefox:
http://ssj100.fullsubject.com/security- ... 7.htm#2271

That makes sense, with http blocked the page is no longer mixed.

al_9x wrote:

ssj100 wrote:One thing I note is that with the rule enforced, this "Security Warning" doesn't come up in Firefox:
http://ssj100.fullsubject.com/security- ... 7.htm#2271

That makes sense, with http blocked the page is no longer mixed.

Yes, I guess that does make sense. However, it'd be nice to see a notice that http has been blocked on a https page (just like you can see a notice that Scripts have been blocked). Regardless, as I said, one method would be to simply disable the rule and only enable it when you come across such a warning in order to safely log in. I think that's a much more practical way of browsing. What do you think?

al_9x wrote: abe, it seems can't quite express what's needed:

Code: Select all

Site http:
Anon INC from SECURE_SELF++

there is currently no way to refer to the secure version of SELF++. What do you think about adding that?

but this should be ok, no harm in anoning third party requests too:

al_9x wrote:I would say that 95%-100% of the time when people use a "from" clause they are thinking of sub-requests (INC) and consequently find the blockage of top level navigations a surprising and unwelcome side-effect. Shouldn't perhaps INC behavior be the default for from clauses?

Nope. It would introduce ambiguous semantic, and we would need some new keyword to express Deny EVERYTHING from...

al_9x wrote: [*] but if you sniff, you'll see that https://static.sourceforge.net/css/ghost/style.php redirects first to http and again back to https
[*] this strikes me as a Fx bug, since the redirection can leak cookies. Unfortunately you need NS + web bug blocking to repro it on SF. Giorgio, if you think it's worth reporting, perhaps you can set up a public demo page for bugzilla, to take NS out the equation.

While I can see the value of stricter checks, this is not technically a bug in the mixed content UI, because all it is meant to warn you about is that the page contains unencrypted content, which may be used to grab your credentials using a JavaScript DOM spy or keylogger. Network sniffing or MITM, done in during a page-less redirection, is out of the scope of the "Mixed content warning" feature.

al_9x wrote: there is currently no way to refer to the secure version of SELF++. What do you think about adding that?

It might be nice to have, yes.

I have implemented the suggestions made earlier:

Site .twimg.com
Accept INC(IMAGE) from .twitter.com

Site http:
Deny INC from https:

but am now experiencing problems with images not loading up in my gmail messages.

How do I go about resolving this so that, as is the case with the above twitter line, images are rendered within gmail?

Many thanks in advance

Dukeswharf wrote:but am now experiencing problems with images not loading up in my gmail messages.

You should look into Tools|Error Console for messages starting with [NoScript ABE] which refer to GMail, in order to figure out an exception.

Giorgio Maone wrote:

Dukeswharf wrote:but am now experiencing problems with images not loading up in my gmail messages.

You should look into Tools|Error Console for messages starting with [NoScript ABE] which refer to GMail, in order to figure out an exception.

Many thanks for the heads-up, Giorgio.

All works fine now.

Fine-tuning scripting permissions can catch this at a much simpler level than ABE exceptions.

1) First, my results at the test, default (all scripting denied):

Nothing happens at all. No messages. Zip. Zero. Nada. Nein. Zilch.
And the padlock icon shows the red exclamation point, which as Giorgio said, warns me not to enter sensitive data into this site.

2) Temp-allow https.ie.microsoft.com

Dangerous Mixed Content was blocked! See for yourself...enter a fake username and password below and try it in other browsers.
I can't inject malicious code into this site to steal your identity.

Still successful. Still the red ! on the padlock icon.

(Side note: Just checked. To my surprise, "warn when encrypt contains unencrypted" was *not* checked, yet I got the exclamation point anyway. Which should be sufficient warning, although many users might not notice that, and need the text warning.)

3) Revoke that, forced reload (avoiding any possible cache complications) and TA http.ie.microsoft.com
Same result as #1. Nothing at all happens. And the NS logo is *staying solid red*, despite confirming the TA permission.

4) Then TA
http.ie.microsoft.com and
https.ie.microsoft.com

Now the attack succeeds.

So for successful attack, user must allow the script from both secure and insecure site.

The problem is that most users would simply allow or TA microsoft.com, which allows *all* of the above, plus more. Solution below.

ssj100 wrote:By the way, it's not just Hotmail that has a problem when you add that code. Yahoo Mail also has the same problem - you need to exempt ".yahoo.com" to be able to log in.

Not at all. Please keep reading.

ssj100 wrote:From what you're saying, people shouldn't be using Hotmail and Yahoo? Last time I checked, the vast majority of people who have web-mail either use Hotmail or Yahoo? Do you have a Hotmail or Yahoo account? Can you check it out to see why they both require http content to be loaded into their https login process?

Never used Hotmail; been using Yahoo mail for many years.

Yahoo login page,
https://login.yahoo.com/config/login_verify2?&.src=ym
is not mixed, on my machine. Padlock has no exclamation; no warnings of mixed content, The reason: *All scripting is forbidden.* The login page works; the padlock does not have the warning icon, and the URL bar is correctly color-coded. I don't know why you're saying, or experiencing, that yahoo.com must be allowed in order to log in.

ETA: Note the src=ym. (source = Yahoo Mail) Perhaps that parameter eliminates the need for the blanket yahoo.com permission?

After login, it's all in cleartext, but no passwords to steal. Anything sent in clear text email needs to be something you wouldn't mind shouting out your window or posting on the Web. Else, use an SSL e-mail, or for max protection, (encrypt the message before it leaves the machine, not just the connection) Hushmail, with the "Enable Java (local encryption applet)" selected. Or roll your own PGP or GPG.

The only scripting allowed is
mail.yahoo.com
mail.yimg.com

Which is enough for basic email services. Some features may require TA yahooapis.com.

But the point is, do *not* blanket-allow the entire Yahoo domain.
Nor other sub-domains: news.yahoo.com, finance.yahoo.com, etc.

I never could get the "mixed content" warning from Yahoo, and I believe that's because, *as a personal choice only*, my HOSTS file contains which prevents the browser from connecting to that site at all. I did it to stop the annoying redirects to the Y home page every time I log out of e-mail, but apparently, it's also preventing this entire mixed-content isse -- *exactly* as the selective allows at the MS demo site prevented the attack, but blanket-allows of microsoft.com allow the attack to succeed.

You'd be surprised how often this simple idea of restricting permissions to only the needed sub-domains enhances security, reduces annoyance, etc.

I do not have any ABE rules beyond the default system rule, yet all of the above is true. ABE is not required for these cases.

Afterthought: I stayed with Yahoo Classic mail, precisely because the TOS of the New, Deproved mail included reading all contents and profile-building (which Gmail has been doing for a long time already), a nasty step up from the previous practice of displaying targeted ads (which I never see) based on keywords in a particular message or subject line. Perhaps the New Yahoo mail requires this mixed-content login page. Try my suggestions above, and if they don't solve it, I'd say go back to Classic Yahoo mail.

@ Giorgio:
In addition to your rule, Wouldn't it also be good to have this rule?: (I left out the Accept; presumably we'll accept all HTTPS content; else, the rule would need to be changed, or a separate rule, right?)

I just dived into this thread, and if I'm understanding it correctly, my rule would deny all http content at https sites -- which is what we wanted to do in the first place, correct? Or not?