Some Sites you Might Want to Protect

[Tom T.]

Well, if you really want to stop all HTTP traffic to Wells Fargo, then I'd again suggest the Force HTTPS feature, this time with '.wellsfargo.com'q

I can stop all http traffic to ME from insecure WF by not visiting the sites that aren't already HTTPS-secured in and of themselves.

The issue raised -- and as said, I'm not sure about this -- was stopping traffic from http WF to https WF. We can't stop that. But in the RP example, we stopped the secure page from sending us content that they got elsewhere.

My forcing HTTPS on http WF doesn't inherently make the http page any more secure against phishing attacks, MITM, XSS, etc.
(The hacker doesn't force HTTPS, LOL.)
The idea was to have no contact with, or content imported from, any http page at that domain.

OK, I've thought some more and realised that there's a good way to protect the encrypted online banking portion of the site, while allowing the general site to link to the login page.

If that is your wish, fine. I don't care to go through the general site at all, but rather start at the https login page. Not sure why you're so attached to the insecure page, or want to go through there to get to the secure login. (If I sound a little testy, please remember yesterday's PM: It''s been a *very* long day. )

and capable of extracting passwords from the Firefox password manager, if they're stored there and not protected by an addon like Secure Login or similar.

I think you know my feelings about storing passwords in a browser or browser add-on. (Maybe not?)
I would *never* store pws in an Internet-facing app. (Two words: Password Safe)

On an unrelated note, you've mentioned that it's better for people to ditch Google/Microsoft/Yahoo services, but Wells Fargo relies on Akamai?

Akamai has a much better reputation that either Google or MS.
(Both of the latter have been the subject of numerous lawsuits by various governments and other entities.)

There is no Akamai scripting at WF.
RP shows a request. When I blocked it, all that changed was that the WF logo disappeared from the page.

IOW, no *active content* from Akamai.

Even if they tried to plant a web bug, this user's practice of always restarting the browser before and after "sensitive" activities, which was derided by some, would dump the bug before I browsed anywhere else.

I don't have quite so low an opinion of Yahoo, or I wouldn't use their webmail (for non-sensitive messages; all else via Hushmail.)

What I do believe in, as a general rule, is Occam's Razor and the Principle of Least Privilege, both of which were axiomatic decades ago when resources were scarce, but have seemingly been discarded these days:
If you don't need it, don't allow it.

Certainly don't whitelist it. And delete it from Default W/L.

I went so far as to block Yahoo home page in Hosts, not because I distrust them, but it stops the annoying redirect every time I log out of Mail, which would take me to their portal page, full of distracting junk that eats bandwidth. The "Firefox can't connect" message, coming internally from a Hosts lookup, happens instantaneously.

[Thrawn]

Well, if you really want to stop all HTTP traffic to Wells Fargo, then I'd again suggest the Force HTTPS feature, this time with '.wellsfargo.com'q

I can stop all http traffic to ME from insecure WF by not visiting the sites that aren't already HTTPS-secured in and of themselves.

The issue raised -- and as said, I'm not sure about this -- was stopping traffic from http WF to https WF. We can't stop that. But in the RP example, we stopped the secure page from sending us content that they got elsewhere.
<snip>
The idea was to have no contact with, or content imported from, any http page at that domain.

I see...that would require quite a different rule, I think. Something like:

Code: Select all

Site ^http://.*
Deny from https://wellsfargo.com

OK, I've thought some more and realised that there's a good way to protect the encrypted online banking portion of the site, while allowing the general site to link to the login page.

If that is your wish, fine. I don't care to go through the general site at all, but rather start at the https login page. Not sure why you're so attached to the insecure page, or want to go through there to get to the secure login. (If I sound a little testy, please remember yesterday's PM: It''s been a *very* long day. )

Well, I'm trying to assemble rules that work, unmodified, for as many users as possible; copy-and-paste candidates (if only for those who understand what they're copying). So, rules that are a bit safer, but break the normal flow of the site and require things like bookmarks or copying and pasting link addresses, are left as an exercise for the advanced reader.

I think you know my feelings about storing passwords in a browser or browser add-on. (Maybe not?)

Indeed I do . So, if best practices like Password Safe are followed, we're in agreement that evading the suggested rule is not practical?

On an unrelated note, you've mentioned that it's better for people to ditch Google/Microsoft/Yahoo services, but Wells Fargo relies on Akamai?

Akamai has a much better reputation that either Google or MS.

I know. Most of the trouble with them has been misconfigured users of their service, misusing their https features. I was largely just ribbing you. But they have had issues before that would allow anyone to wrap their content in an apparently-valid security certificate .

I went so far as to block Yahoo home page in Hosts, not because I distrust them, but it stops the annoying redirect every time I log out of Mail, which would take me to their portal page, full of distracting junk that eats bandwidth. The "Firefox can't connect" message, coming internally from a Hosts lookup, happens instantaneously.

Cool idea . How does this look?

Code: Select all

# Block annoying Yahoo home page
Site ^http://(www|au).yahoo.com/?$
Deny

[Thrawn]

More (Australian) bank candidates for review:

Code: Select all

# Suncorp Bank
Site .internetbanking.suncorpbank.com.au
Accept from SELF
Anon GET from .suncorp.com.au
Deny

# Heritage Bank
Site .online.hbs.net.au
Accept from SELF
Anon GET from .heritage.com.au
Deny

# BankWest
Site .ibs.bankwest.com.au
Accept from SELF
Anon GET from SELF++
Deny

# St George Bank
Site .ibanking.stgeorge.com.au .webapps.stgeorge.com.au
Accept from SELF
Anon GET from SELF++
Deny

# SA Bank
Site .ibanking.banksa.com.au .webapps.banksa.com.au
Accept from SELF
Anon GET from SELF++
Deny

# HSBC Bank
Site .hsbc.com.au
Accept from SELF
Anon GET
Deny

[Thrawn]

<snip> if you want to use ABE, then you don't need a regex, just use:

Code: Select all

Site .wellsfargo.com:80
Deny

My mistake; this doesn't work. So, there's no easy (non-regex) way to define the equivalent of:

Code: Select all

Site http://*.example.com

I wonder whether that's worth suggesting to Giorgio as an enhancement?

[Tom T.]

...The idea was to have no contact with, or content imported from, any http page at that domain.

I see...that would require quite a different rule, I think. Something like:

Code: Select all

Site ^http://.*
Deny from https://wellsfargo.com

Interesting idea! (except for forgetting to include or wildcard "online", lol.) And easily expanded:

Code: Select all

Site ^http://.*
Deny from https://online.wellsfargo.com https://onlinebanking.otherbank.com https://creditcard.com https://stockbroker.com (etc.)

.... I don't care to go through the general site at all, but rather start at the https login page....

Well, I'm trying to assemble rules that work, unmodified, for as many users as possible; copy-and-paste candidates (if only for those who understand what they're copying). So, rules that are a bit safer, but break the normal flow of the site and require things like bookmarks or copying and pasting link addresses, are left as an exercise for the advanced reader.

Bookmarking is "advanced"?

I'm looking at the Bigger Picture, forgetting about ABE for the moment, and encouraging *all* users to start at the site's HTTPS secure login page, and access all else from there. This takes no more tech skill than to go to the insecure page, enter blank creds, and be taken to the "right" page: the secure login page. Then bookmark that. (and restart the browser *once*, to clear any remnants of the insecure page, such as insecure cookies, etc.)

You may raise the issue of potential corruption of bookmarks. (is it really all that common, esp. if NS is running the show?) But I don't think I've mentioned that there is this amazing freeware tool in which you copy/paste that desired URL, and it is then stored "securely encrypted" in a non-Internet facing app. Click the entry, click "B" for browse, and it will auto-browse to your securely-bookmarked secure login page. Clicking "A" will auto-type user/pass, and even hit the login button for you. Newer versions will do all of that with a click or two on the site name: browse to it, enter the creds, and submit.

You can even configure it to open the browser inside your favorite sandboxing program. At least, it works for Sandboxie. The Browse-To function first launches SB, which then invokes the browser, which then goes to the desired URL. Awesomely cool, really.

IMHO, this is a big gain in security even for the average user who is not quite up to messing with ABE. Combine it with your other lockdowns, and. ...

So, if best practices like Password Safe are followed, we're in agreement that evading the suggested rule is not practical?

I'd have to re-read the whole thread and the final "suggested rule" , but from feeble memory, I think we're getting the maximum security that can be gotten from COTS or OSS products.

Finalization of this research may result in a complete "Best Practices for Sensitive Sites" post.

Akamai has a much better reputation that either Google or MS.

I know. Most of the trouble with them has been misconfigured users of their service, misusing their https features. I was largely just ribbing you. But they have had issues before that would allow anyone to wrap their content in an apparently-valid security certificate .

Yes, that's bad. But at least in this case, it's still not *active content*; hence, far less potential damage that a successful attack like that could do. (Akamai script not allowed there.) I may try blocking Aka in RP for a while, and see just how much, if any, actually-necessary imagery is lost.

I went so far as to block Yahoo home page in Hosts, not because I distrust them, but it stops the annoying redirect every time I log out of Mail, which would take me to their portal page, full of distracting junk that eats bandwidth. The "Firefox can't connect" message, coming internally from a Hosts lookup, happens instantaneously.

Cool idea . How does this look?

Code: Select all

# Block annoying Yahoo home page
Site ^http://(www|au).yahoo.com/?$
Deny

Looks fine! ... but regardless of whether one uses a Hosts service, even the default hosts file can have an entry or two added:

Code: Select all

0  www.yahoo.com
0  au.yahoo.com

No coding knowledge required, no knowledge of regexp required, only editing a text doc, ensuring that the entries are always *below* the default localhost entry.

btw, when I visited au.yahoo.com, they said "Hi Tom!" (reading the cookie, as I'm logged into email also), then gave me the weather for Sydney.
With a link, "Change your location." I guess "Location" is part of Account Settings, and not coded into the cookies, but then why choose Sydney over, say, Canberra, Melbourne, etc.? Funny.

[Thrawn]

Interesting idea! (except for forgetting to include or wildcard "online", lol.) And easily expanded:

Code: Select all

Site ^http://.*
Deny from https://online.wellsfargo.com https://onlinebanking.otherbank.com https://creditcard.com https://stockbroker.com (etc.)

I'm glad you like it .

I'm looking at the Bigger Picture, forgetting about ABE for the moment, and encouraging *all* users to start at the site's HTTPS secure login page, and access all else from there. This takes no more tech skill than to go to the insecure page, enter blank creds, and be taken to the "right" page: the secure login page. Then bookmark that. (and restart the browser *once*, to clear any remnants of the insecure page, such as insecure cookies, etc.)

Well, at the Commonwealth Bank site (for example), you start off at www.commbank.com.au, and you click on a dropdown menu item that opens a new window at www.my.commbank.com.au. If you were to click that without the 'Anon GET' rule, as you suggest, then all you would get is an ABE notification. You'd have to right-click on the link, if possible, or manually type out what you see in the ABE notification, to get the right URL to create your bookmark. So, someone who added the Commbank rule as part of a list, and then later signed up as a Commbank customer, would have a learning curve figuring out how to use the site. Not ideal.

Do you see any particular vulnerability associated with the link-fixing 'Anon GET from http' clause, beyond what I suggested (which I think we agree is not a practical attack)?

You may raise the issue of potential corruption of bookmarks. (is it really all that common, esp. if NS is running the show?) But I don't think I've mentioned that there is this amazing freeware tool in which you copy/paste that desired URL, and it is then stored "securely encrypted" in a non-Internet facing app.
<snip>

OK, OK, so I'll see if I can track down the corresponding KeePass functionality (I'm pretty sure it's there). And if I can find either application in the Ubuntu package repositories, I'll use that one.

Finalization of this research may result in a complete "Best Practices for Sensitive Sites" post.

Up to you, Mr Moderator .

Looks fine! ... but regardless of whether one uses a Hosts service, even the default hosts file can have an entry or two added:

Code: Select all

0  www.yahoo.com
0  au.yahoo.com

No coding knowledge required, no knowledge of regexp required, only editing a text doc, ensuring that the entries are always *below* the default localhost entry.

...but it does need administrative privileges. For those without that, the ABE rule could be handy.

btw, when I visited au.yahoo.com, they said "Hi Tom!" (reading the cookie, as I'm logged into email also), then gave me the weather for Sydney.
With a link, "Change your location." I guess "Location" is part of Account Settings, and not coded into the cookies, but then why choose Sydney over, say, Canberra, Melbourne, etc.? Funny.

Curious indeed. Probably it's because Sydney is the usual international airport?

Any comments on the other bank rules thus far?

[Tom T.]

Well, at the Commonwealth Bank site (for example), you start off at www.commbank.com.au, and you click on a dropdown menu item that opens a new window at www.my.commbank.com.au. If you were to click that without the 'Anon GET' rule, as you suggest, then all you would get is an ABE notification. You'd have to right-click on the link, if possible, or manually type out what you see in the ABE notification, to get the right URL to create your bookmark. So, someone who added the Commbank rule as part of a list, and then later signed up as a Commbank customer, would have a learning curve figuring out how to use the site. Not ideal.

Knowing *nothing* about the site, I went to your suggested home page, www commbank.com.au, and in the upper right was a link-button for "NET Bank". Both the onmouseover destination and the actual destination were

Code: Select all

https://www.my.commbank.com.au/netbank/Logon/Logon.aspx

Any novice can click the "Logon or register for NET Bank", and get the above, which is the ideal place to start. Two steps, as suggested, and then bookmark that (however one chooses to bookmark).

Do you see any particular vulnerability associated with the link-fixing 'Anon GET from http' clause, beyond what I suggested (which I think we agree is not a practical attack)?

Not immediately, but as per above, I think it's moot.

Looks fine! ... but regardless of whether one uses a Hosts service, even the default hosts file can have an entry or two added:

Code: Select all

0  www.yahoo.com
0  au.yahoo.com

No coding knowledge required, no knowledge of regexp required, only editing a text doc, ensuring that the entries are always *below* the default localhost entry.

...but it does need administrative privileges. For those without that, the ABE rule could be handy.

A user without admin privilege can create ABE rules? ... I guess you mean, have the Admin make the rules in advance.

Just have the Admin create, or even e-mail, the proper HTTPS link to the limited user, who has been instructed to consult before creating a new login to sensitive sites.

Any comments on the other bank rules thus far?

TBPH, a bit burned out. Would rather let this sit for a bit, come back fresh, and review the entire thread.
If some are indeed unnecessary, then they don't need to be evaluated.

[Thrawn]

<snip> if you want to use ABE, then you don't need a regex, just use:

Code: Select all

Site .wellsfargo.com:80
Deny

My mistake; this doesn't work. So, there's no easy (non-regex) way to define the equivalent of:

Code: Select all

Site http://*.example.com

I wonder whether that's worth suggesting to Giorgio as an enhancement?

Any comments on this approach?

Code: Select all

Site ^http://[~/]*example\.com/.*