服务器端JavaScript注入
布赖恩·沙利文，高级安全研究员，Adobe公司安全软件工程团队，2011年七月
概要
本白皮书乃是为支持黑帽子USA2011的议题，“服务器端JavaScript注入：攻击的NoSQL和Node.js的”而写。本文及附带的会谈将讨论可能出现在软件开发人员创建基于JavaScript的服务器应用程序的安全漏洞，如NoSQL的数据库引擎和Node.js的Web服务器。在最坏的情况下，攻击者可以利用这些漏洞上传并执行服务器上任意的二进制文件，完全控制服务器。（好吃力啊，接下来我可不管排版和颜色了–俺留）
JavaScript的Web应用程序的客户端层被广泛使用（如浏览器）多年，以提供更丰富，更像桌面 的用户体验。但近年来，对JavaScript的兴趣不只是客户端代码了，大家对码个服务器端兴趣激增。现在有服务器端JavaScript（或叫SSJS）的数据库服务器功能（如CouchDB），文件服务器（Opera Unite）和Web服务器（Node.js）。当然，许多新的兴趣可以归功为是JavaScript引擎开发商近期取得的巨大的性能提升。微软，Mozilla的，苹果，谷歌和Opera之间的竞争，为了打造速度最快的浏览器，导致搞出了运行远快于前几个版本的过的JavaScript引擎。虽然它可能不可行的，从性能的角度来构建基于JScript的一个全功能的Web服务器，像iE6（例如），是个全不同的问题， 火狐4以此为目标。另一种可能推动这种转变的是熟悉：很多Web开发人员已经拥有了大量的经验，在构建客户端JavaScript的功能，而在历史上，这些人已经退居编写的Web应用程序前端。但移动到SSJS后端有可能允许组织采取的更好人才储备–利用内部的老人。背景：客户端JavaScript注入（又名跨站脚本）虽然SSJS有实实在在的好处，但因为它们是客户端代码一是存在严重的缺点，可以被利用来在服务器上执行该脚本注入漏洞也同样容易不小心引入服务器端的应用程序代码;进而，服务器端JavaScript注入的影响更为关键和有破坏性。客户端JavaScript注入漏洞是更好地称为他们更常见的名称为“跨站点脚本”（或XSS）。 XSS漏洞的影响可能是非常有害：XSS一直负责会话劫持/身份盗窃（盗窃会话和/或从DOM cookie）;钓鱼式攻击（注射用伪造的登录对话框插入主机应用程序合法页）;击键记录;和螟（MySpace的/萨米等等）。
开放Web应用安全项目（OWASP）目前XSS排名第二危险的威胁，Web应用程序（SQL注入后），以及2011年CWE/ SANS排名前25位最危险的软件错误XSS排名为第4的威胁（从下降在2010年的名单＃1）。
XSS漏洞不仅是极其危险的，在Extreme Tweaker都极为普遍。由Web应用安全联盟（WASC）2008年发布的Web应用程序安全统计报告1估计，全球网站39％至少包含一个XSS漏洞。双方的WhiteHat的Security2和Cenzic3最近的独立研究表明有更大的百分比：WhiteHat估计，64％的网站很容易受到XSS， Cenzic估计68％的漏洞率。
其中一个原因是XSS如此普遍的是，它是那么容易就会一不小心引入应用程序代码。考虑客户端的JavaScript代码，用来处理股票报价请求。 （该代码使用JSON作为消息格式和XMLHttpRequest的作为请求对象。）
（谷歌把这都翻译了）–改不动了， 以下为原生谷歌翻译内容<HTML> …<SCRIPT>VAR XHR=新的XMLHttpRequest（）; xhr.onreadystatechange=功能（）{如果（（xhr.readyState==4）&&（xhr.status==200））{VAR stockInfo=的eval（“（”+ xhr.responseText+’）’）;警报（“当前价格”+ stockInfo.symbol+“是$’+ stockInfo.price）;}}函数makeRequest（tickerSymbol）{xhr.open（“POST”，“stock_service”，真正的）; xhr.send（“{\”符号\“：\”“+ tickerSymbol+”\“}”）;}</ SCRIPT>…<HTML>
此代码看起来简单，但eval可能引入一个严重的漏洞。如果攻击者能够影响从股市的服务来注入脚本代码的响应，调用EVAL将执行在victim’s浏览器上下文的脚本代码。在这一点上attacker’s最可能的举措是将提取的页面的DOM任何认证或会话cookie，并将它们发送回自己，这样他就可以承担受害人的身份，并接替他的会话。
1 2 https://www.whitehatsec.com/home/assets/WPstats_winter11_11th.pdf?doc=WPstats_winter11_11th3 一个新的向量：服务器端JavaScript注入现在考虑旨在JSON解析请求，但该代码执行在服务器层实现一个Node.js的web服务器的JavaScript代码非常相似块。VAR HTTP=要求（“HTTP”）; http.createServer（功能（请求，响应）{如果（request.method===’POST’）{VAR数据=”;request.addListener（’数据’，函数（块）{数据+=块;}）;request.addListener（’端’，函数（）{变种stockQuery=的eval（“（”+数据+“）”）; getStockPrice（stockQuery.symbol）;…}）;
在同一行的代码（传入JSON数据的EVAL）是负责作为在先前的客户端实例的注入漏洞在这个段中。然而，在这种情况下，该漏洞的影响比的victim’s饼干泄漏严重得多。例如，假设在这种情况下，一个合法的，非恶意的JSON消息，股票报价服务看起来是这样的：{“符号”：“AMZN”}对eval则呼叫评估字符串：（{“符号”：“AMZN”}）然而，在这种情况下，没有什么可以阻止攻击者简单地发送其自己的JavaScript代码来代替正常的JSON消息。例如，他可以派：到Response.End（“成功”）服务器代码会执行此命令注入，并返回文本“成功”作为HTTP响应的主体。如果攻击者发送这种探测请求，并收到“成功”作为回应，他知道，服务器将执行他随意提供的JavaScript，而且他可以继续发送一些更具破坏性的攻击。
拒绝服务
拒绝服务的有效的攻击可以简单地通过发送命令执行：而（1）这种攻击将会使目标服务器使用其处理器100％的时间来处理无限循环。服务器将挂起并且无法处理任何其他的传入请求，直到管理员手动重新启动该过程。It’s值得一提的这个DoS攻击是如何不对称的。攻击者doesn’t需要淹没目标数以百万计的请求;相反，仅使用一个八字节净荷单个HTTP请求足以禁用目标。另一种DoS攻击是简单地退出或终止正在运行的进程：process.exit（）process.kill（process.pid）
文件系统访问
最困难之时，就是我们离成功不远之日。
