December 03, 2012, 7:51 PM — Attackers can read emails, contacts and other private data from the accounts of Yahoo users who visit a malicious page by abusing a feature present on Yahoo's Developer Network website, according to an independent security researcher.
A limited version of the attack was presented on Sunday at the DefCamp security conference in Bucharest, Romania, by a Romanian Web application bug hunter named Sergiu Dragos Bogdan.
In his presentation, the researcher showed how the Web-based YQL (Yahoo Query Language) console, available on the developer.yahoo.com website, can be abused by attackers to execute YQL commands on behalf of authenticated Yahoo users who visit malicious websites.
YQL is a programming language similar to SQL (Structured Query Language) that was created by Yahoo. It can be used to query, filter and combine data stored in databases.
The Yahoo developer website provides access to a Web-based console that developers can use to learn and test YQL by running YQL queries against Yahoo's own databases.
Non-authenticated users can only run YQL queries against tables containing publicly visible Yahoo information, such as information from Yahoo Answers, Yahoo Weather and other services. However, when they are authenticated, users also gain access to tables containing their own Yahoo account data, including emails, contacts and private profile information.
When a query is entered in the console's "YQL statement" field and the "TEST" button is pressed, a user-session-specific authorization code called the "crumb" is also submitted along with the request. The crumb is generated when the user visits the YQL console page and is inserted into the form requests automatically.
During his presentation, Bogdan presented a proof-of-concept (PoC) attack page that loaded a specific developer.yahoo.com URL inside an iframe. When the attack page was visited by an authenticated Yahoo user -- a test account was used -- the iframe returned the visitor's crumb code.
However, security mechanisms built into browsers don't allow code running in the context of one domain name to read content from a page hosted on a different domain that was loaded inside an iframe. This means that while the visitor himself can see the crumb code on the attack page, thanks to the iframe being loaded in his browser, the attack page itself can't read the code or automatically use it to make authenticated YQL queries using the victim's Yahoo session.