Yahoo! Mail, Windows Live Hotmail, Gmail by Google

[lost]

Yahoo! Mail, Windows Live Hotmail, Gmail by Google, the largest email services, have a meaningful number of accounts that are getting hacked one way or another.
Please, someone post expertly coded ABE rules for each of these 3 email services.
(Perhaps such rules can reduce the attack surface.)

[therube]

The latest Gmail issue (that I'm aware of) was more a phishing issue & not any breach at Gmail.

Yahoo works without allowing yahoo.com. (I use Yahoo "Classic" version.) yimg.com is allowed. Not sure if it is actually needed or not.

Hotmail/Live, well that's MS, so I'd expect that to be FAIL. (OK, maybe being harsh there?)

[Guest]

( @therube http://en.wikipedia.org/wiki/Cross-site ... cteristics )

Again:
Yahoo! Mail, Windows Live Hotmail, Gmail by Google, the largest email services, have a meaningful number of accounts that are getting hacked one way or another.
Please, someone post expertly coded ABE rules for each of these 3 email services.
(Perhaps such rules can reduce the attack surface.)

[GµårÐïåñ]

Although I understand your concern and ABE can certainly limit if not cripple any malicious code that might get injected or load through the email, the fact is that most of these hacks are either phishing (as therube suggested) which means that the user needs to be intelligent about it, or they are hacked directly off their servers in which case ABE or anything else will not be able to do a damn to stop it. Only those who maintain the security of those servers can do something about it. I added this to give you a bit of perspective on what a client-side tool can/cannot achieve and at what point you are at the mercy of the provider no matter what YOU do.

[Guest]

...ABE can certainly limit if not cripple any malicious code that might get injected. . .

I believe you.

So, again:
Yahoo! Mail, Windows Live Hotmail, Gmail by Google, the largest email services, have a meaningful number of accounts that are getting hacked one way or another.
Please, someone post expertly coded ABE rules for each of these 3 email services.
(Perhaps such rules can reduce the attack surface.)

[GµårÐïåñ]

If Giorgio doesn't get around to doing it, I will take some time, log into each one and make one up for you and post it, but I have alot on my plate so I may not be able to get it that quickly, in the meantime you might want to try and read the ABE documentations and see if you can whip something up yourself.

[Guest2]

Guest,
As you are so keen for this to happen, it would help if you gave an example of an attack vector that you think ABE rules could block and that isn't blocked by a default NoScript installation. Are you sure there is one?

[Giorgio Maone]

Try these:

Code: Select all

Site mail.google.com
Accept from .google.com
Deny

Site .mail.yahoo.com .mail.yimg.com
Accept from .yahoo.com yimg.com yahooapis.com
Deny

Site .live.com .hotmail.com .wlxrs.com
Accept from .live.com .hotmail.com .wlxrs.com
Deny

They should make any CSRF attack against these services virtually impossibe.
However this can be have usability effects, so let us know about breakages.

[Guest]

@Giorgio Maone, Thank you!

By the way, what about CSRF against the "Sign In" and/or "Sign Out" URLs for Yahoo!, Microsoft, and Google?

Consider that "One Windows Live ID gets you into Hotmail, Messenger, Xbox LIVE—and other Microsoft services," for example. If by CSRF a user can be signed out of his/her account and/or signed in to someone else's account, he/she becomes at risk for certain social engineering tricks.

[Giorgio Maone]

By the way, what about CSRF against the "Sign In" and/or "Sign Out" URLs for Yahoo!, Microsoft, and Google?

That's a known risk (e.g. used as a first stage of a session riding attack), and it's covered by the rules above.

[GµårÐïåñ]

Giorgio, thanks for getting that done. I noticed something that would cause an error and tested to confirm that. Just a heads up that the google portion will trigger an ABE error when you type gmail.com into the addressbar claiming that chrome is hijacking the window, just so you know. Here is a sample of that alert, I added gmail to the site list and that fixed it but wanted to give you a heads up if you want to update what you provided to include that as well.

Code: Select all

[ABE] <mail.google.com> Deny on {GET http://mail.google.com/mail/ <<< http://gmail.com/, chrome://browser/content/browser.xul - 6}
USER rule:
Site mail.google.com
Accept from .google.com
Deny

Otherwise it works well, thanks and take care.

[Guest]

. . .and it's covered by the rules above.

For "Windows Live Hotmail" I believe you are correct.
Would adding login.yahoo.com as a "Site" for Yahoo! be protective and wise?
(I have no comments as to Google, because of the potential usability effects issue)

[Guest]

They should make any CSRF attack against these services virtually impossibe.
However this can be have usability effects, so let us know about breakages.

How about "same site request forgeries"? http://ha.ckers.org/blog/20061120/click ... -for-csrf/
Because all users can get to post to various "forums", groups.yahoo.com and autos.yahoo.com, FOR EXAMPLE, and SOME "forums" may not block all types of relevant evil postings, there remains a request forgery potential risk to these email services I suspect.

Would tightening the "Accept from" restrictions solve the "same site request forgeries" risk?

[GµårÐïåñ]

Would adding login.yahoo.com as a "Site" for Yahoo! be protective and wise?
(I have no comments as to Google, because of the potential usability effects issue)

adding login.yahoo.com would not affect the security all that much as it is just a centralized authentication point for yahoo services. what you are worried about would only occur if you were to include a wildcard for yahoo.com which would include all their sub-domains and then yes, you could run into the restriction being ineffective. as long as you keep the restrictions currently placed, adding login.yahoo.com will not affect the security and will improve usability in certain cases actually.

Google Rule:

Code: Select all

Site mail.google.com
Accept from .google.com gmail.com
Deny

tested to be effective and complete as of now, unless you have special cases to share, this will work well with any breakage.

Yahoo Rule:

Code: Select all

Site .mail.yahoo.com .mail.yimg.com
Accept from .yahoo.com yimg.com yahooapis.com login.yahoo.com
Deny

tested to be effective and resolve the breakage when it comes to login verification and time out logins which require the centralized page.

Microsoft Rule:

Code: Select all

Site .live.com .hotmail.com .wlxrs.com
Accept from .live.com .hotmail.com .wlxrs.com
Deny

this is fine as is, I haven't encountered issues and don't see anything else that would be needed. hope that all helps.

[Guest]

adding login.yahoo.com would not affect the security all that much as it is just a centralized authentication point for yahoo services.

Request forgery targeting login.yahoo.com or a "centralized" sign-in/sign-out point for Windows Live or for Google can cause users to be signed out of their own accounts and/or signed-in to someone else's account, either of which can be part of a scheme that tricks users.

In any case, I believe I got the clarity I needed from this thread, so thanks to those who provided information.