Putting the entries inside Code tags should help with the spam filter.
However, there is a
known cross-site scripting vulnerability in Yahoo e-mail. Yahoo claims to have fixed it, but
security researchers beg to differ.
I don't get this XSS message, because I tighten Yahoo permissions versus the default whitelist.
The default whitelist includes:
yahoo.com
yimg.com
yahooapis.com
I delete
yahoo.com and
yahooapis.com, and add this tighter whitelist entry:
mail.yahoo.com
-- allowing only the mail sub-domain versus the entire Yahoo universe.
and add
ymail.com
which at some time was needed for handling attachments. It may or may not be now -- they keep changing how they handle attachments.
Since I don't wish to show the "userstatus", messenger, etc.,
yahooapis seems to be needed only to edit account settings, address book, etc. So I Temp-Allow it for those rare occasions, then
Revoke temporary permissions afterward.
This worked fine up until a week or two ago, when it became impossible to sign in to Yahoo mail without also temp-allowing
yahoo.com
So I T-A it, log in, then revoke it. Once logged in, the revoking of
yahoo.com does not seem to affect anything.
A bit of a PITA, but it seems to prevent not only the exploit, but also the NoScript message about blocking it. Let's all be thankful to NS's excellent XSS protection for (apparently) preventing us from becoming victims of this widespread attack. Too bad that Yahoo can't seem to secure their site.
Changed the topic title to reflect that this is a known vulnerability.
Putting the entries inside Code tags should help with the spam filter.
However, there is a [url=http://krebsonsecurity.com/2013/01/facebook-yahoo-fix-valuable-ecurity-hole/]known cross-site scripting vulnerability in Yahoo e-mail[/url]. Yahoo claims to have fixed it, but [url=http://thenextweb.com/insider/2013/01/07/yahoo-mail-users-hit-by-widespread-hacking-xss-exploit-seemingly-to-blame/]security researchers beg to differ[/url].
I don't get this XSS message, because I tighten Yahoo permissions versus the default whitelist.
The default whitelist includes:
[b]yahoo.com
yimg.com
yahooapis.com[/b]
I delete [b]yahoo.com[/b] and [b]yahooapis.com[/b], and add this tighter whitelist entry:
[b]mail.yahoo.com[/b]
-- allowing only the mail sub-domain versus the entire Yahoo universe.
and add
[b]ymail.com[/b]
which at some time was needed for handling attachments. It may or may not be now -- they keep changing how they handle attachments. :roll:
Since I don't wish to show the "userstatus", messenger, etc., [b]yahooapis [/b]seems to be needed only to edit account settings, address book, etc. So I Temp-Allow it for those rare occasions, then [i]Revoke temporary permissions[/i] afterward.
This worked fine up until a week or two ago, when it became impossible to sign in to Yahoo mail without also temp-allowing
[b]yahoo.com[/b]
So I T-A it, log in, then revoke it. Once logged in, the revoking of [b]yahoo.com [/b]does not seem to affect anything.
A bit of a PITA, but it seems to prevent not only the exploit, but also the NoScript message about blocking it. Let's all be thankful to NS's excellent XSS protection for (apparently) preventing us from becoming victims of this widespread attack. Too bad that Yahoo can't seem to secure their site.
Changed the topic title to reflect that this is a known vulnerability.