Shortly before I left Yahoo we implemented clickjacking protection on
del.icio.us, in response to the attack on Twitter, documented here:
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=213000919
... and PoC'd here:
http://qd9.co.uk/temp/ClickJackEg.html
While I
Yahoo only prompts for the password (the username is prefilled) if the
user already is signed into Yahoo when doing the OAuth dance.
Allen
Stephane Daury wrote:
> Unless I missed something, Yahoo (and I think Google) only prompts for
> the password when a session is already active, displaying
Unless I missed something, Yahoo (and I think Google) only prompts for
the password when a session is already active, displaying the username
instead of giving the user a form field to fill.
A phisher would have the hardest time doing that (if at all).
But I do see your point.
Stephane
I thought about this solution some more and one issue that came to
mind, which is actually noted in the OAuth spec, is that by
conditioning users to enter their credentials each time they are
redirected from a Consumer site you run the risk of increasing the
potential of phishing attacks. Somethin
Yahoo always requires the user to enter their password (even if the user
is already signed into Yahoo) before issuing persistent credentials. The
intent is to verify that the user is actually sitting in front of the
computer before issuing a persistent credential, to protect against the
case wh
On May 4, 9:14 pm, Josh Roesslein wrote:
> A simple way to block this attack would be to force the user to login each
> time before displaying the approval page (even if there is a SP session
> cookie). This way the attacker
> can not load the approval page in a frame. They would need the passwor
A simple way to block this attack would be to force the user to login each
time before displaying the approval page (even if there is a SP session
cookie). This way the attacker
can not load the approval page in a frame. They would need the password to
do so. This does impact the user experience a
Allen,
You are correct about the security attribute being able to disable
frame busting scripts in IE. IE8 supports a X-Frame-Options HTTP
response header which can be used by a developer to deny their
approval page from rendering in a frame. However IE8 is not currently
widely used. Even requiri
Hi Stephen,
Thanks for pointing this out. It might not be sufficient to deploy only
Framebusting JS on the approval screens, as the attacker can disable JS
for the iframe in IE by setting the security attribute to "restricted"
http://msdn.microsoft.com/en-us/library/ms534622(VS.85).aspx
SPs m
