by Tom T. » Fri May 25, 2012 9:30 am
Thrawn wrote:Tom T. wrote:...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.)
Tom T. wrote:.... 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.
Thrawn wrote:Tom T. wrote: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.
Thrawn wrote:Tom T. wrote: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.
[quote="Thrawn"][quote="Tom T."]...The idea was to have no contact with, or content imported from, any http page at that domain. [/quote]
I see...that would require quite a different rule, I think. Something like:
[code]
Site ^http://.*
Deny from https://wellsfargo.com
[/code][/quote]
Interesting idea! (except for forgetting to include or wildcard "online", lol.) And easily expanded:
[code]Site ^http://.*
Deny from https://online.wellsfargo.com https://onlinebanking.otherbank.com https://creditcard.com https://stockbroker.com (etc.)[/code]
[quote="Tom T."].... I don't care to go through the general site at all, but rather start at the https login page....[/quote]
[quote]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 [b]understand[/b] 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.[/quote]
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 [i]securely[/i]-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. 8-)
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. ...
[quote] So, if best practices like Password Safe are followed, we're in agreement that evading the suggested rule is not practical?[/quote]
I'd have to re-read the whole thread and the final "suggested rule" :D , 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. :)
[quote="Thrawn"][quote="Tom T."]Akamai has a much better reputation that either Google or MS. :mrgreen: [/quote]
I know. Most of the trouble with them has been misconfigured [b]users[/b] of their service, misusing their https features. I was largely just ribbing you. But they have had issues before that would allow [b]anyone[/b] to wrap their content in an apparently-valid security certificate :shock:.[/quote]
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.
[quote="Thrawn"][quote="Tom T."]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. :ugeek: ;)[/quote]
Cool idea :). How does this look?
[code]
# Block annoying Yahoo home page
Site ^http://(www|au).yahoo.com/?$
Deny
[/code][/quote]
Looks fine! ... but regardless of whether one uses a Hosts service, even the default hosts file can have an entry or two added:
[code]0 www.yahoo.com
0 au.yahoo.com[/code]
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. :lol:
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. :)
