Ajax Security之WebGoat实验 - 2016.01.07

         Ajax是一种提供后台默默地与服务器进行交互的技术，它不需要每一次与服务器的访问都刷新页面，只是将数据提交给服务器然后获取服务器的响应，再根据要求进行动态的修改罢了。这就很好地避免了每一次都刷新页面带来的开销。但是有利必有弊。它的弊端同样就在于它的动态修改。由于html的js都是解释执行的，这就意味着对那些没有经过特殊处理的站点，我们可以通过注入我们的html和js代码执行我们想要的结果。这也就引发了XSS（跨站点脚本攻击）和钓鱼攻击等一系列攻击手段的出现。这类攻击的原因归根结底是我们队用户的输入没有做好控制和检测。我们可以通过黑白名单的手法限制用户的输入，这类手段如果做得好是很安全的，只不过灵活性差一点罢了；当然我们还可以通过其他折中的办法，即通过对用户的输入进行编码，进而防止其解释执行。废话不多说了，下面让我们一起进入实验。

1.1 Same Origin Policy Protection（同源策略的保护）

       这个实验非常简单，说白了就是为了让我们虽同源策略有一个感性的认识。同源策略的大概意思就是说，当打开一个页面的时候会有脚本的执行，这个脚本会检查是否属于自己的域下，也只有属于同一个域下的脚本才能正常执行。在这个实验中我们分别给出了两个URL，一个是本服务器下的，另一个是指向外部的请求，我们会发现只有向本站进行请求才能得到返回的数据，而向外部服务器（即，不同源）进行请求则得不到想要的数据。这是为了安全进行考虑的，试着想一想如果你在在的域下可以访问其他域下的数据，那么你就可以得到其他域下的cookie值和数据这是多么的不安全啊。我们分别点击图 1 中的 1 和 2 就可以通过实验。

图 1

1.2 DOM-Based Cross-Site Scripting（基于DOM的跨站点访问） 

文档对象模型DOM（Document Object Mudle），允许动态修改网页。这个实验会把我们的输入显示在页面上，而且没有对用户的输入做任何处理，这就存在很大的危险。

1.2.1 第一步，我们需要在实验提供的图片上右键复制其 src 地址，第二步利用 <img> 标签，创建一个 img 元素，如图 2 所示，则提交后便可完成实验 1 。

 

图 2

1.2.2 第二步，我们需要如图 3 所示，利用 img 标签创建一个 js 的 alert 语句，当然这里让创建的只是一个 alert 语句，你要知道如果存在这样的漏洞我们所要执行的可不仅仅是这么一条语句，我们往往会通过 js 语句将本网站的数据作为参数传给我们的黑客网页（注意这里并不违反同源策略，我们是作为参数去传，但是我们得不到我目标网页的返回值，故不违反同源策略）。注意：由于 src 指定为空，则页面解释执行的时候会出发 onerroer，而 onerror 指向的是我们指定的函数。

图 3

1.2.3 第三步，我们如图 4 所示，利用 <iframe>标签创建一个 js 的 alert 语句。原理同上，只不过 iframe 是为了方便一个页面可以引用多个页面的内容二引入的框架，在这里我们通过 src 引入我们的页面地址，但是当对这个标签进行解释执行的时候遇到“javascript ： alert()”，则会直接调用这一个 js 的 alert 命令。

图 4

1.2.4 第四步，这个实验可以看做是一个钓鱼攻击，至于什么是钓鱼攻击，后面的实验有提到，稍后我再讲，大家只要知道凡是这种用户提交完数据不经处理便显示在页面上或者根据用户提交数据动态执行的都存在这样的风险。这个实验很简单，我们只需复制系统提供给我们的代码到输入框，然互提交就可以了。如图 5 所示。

图 5

1.2.5第五步，这也是这个小实验的最后一步，即提供了一种对用户提交数据处理的防护措施：特殊字符的替换处理。利用的是 js 的 escapeHTML（） 这个函数，根据系统提示，如图 6 所示，我们按图中所示输入数据，然后修改 escape.js 的代码，源码如图 7 所示，修改之后如图 8 所示，最后执行结果如图 9所示。我们可以看到 escapeHTML 对用户输入的特殊字符进行了过滤，这样 <img> 标签的内部结构被破坏，将不再被解释为 img 标签使用，而把它当做一个字符串输出。进而提高安全。那么这种方式到底能不能防护？

图 6

图 7

图 8

图 9

1.3 Client Side Filtering （客户端过滤）

客户端过滤的意思就是说页面加载的时候服务端将所有的信息都传给客户端，然后存储于客户端，当用户访问数据的时候就不需要再向服务端发送请求而是在本地根据用户的身份对用户可以访问的数据进行限制。这样一来就引发了很大问题，即所有的数据都存储在客户端，只不过没有显示出来罢了，则我们可以通过hidden标签或者display：none进行寻找，或者根据已知的一条信息进行查找，那么我们就可以找到信息的存储位置，进而绕开客户端的访问控制，寻找我们被限制查看的数据。如图 10 所示就是隐藏于客户端的数据。

图 10

则通过隐藏的数据进行查找，然后找到我们要找的数据再提交就可以绕开访问控制。

        另外，客户端存储本身就是不安全的，那么我们如果非要进行客户端存储，就要在客户进行第一次请求数据的时候根据用户的身份返回给用户应有的信息，即不能给出多余的信息，我们可以通过在 clientSideFiltering.jsp 添加如图 11 所示代码，实现上述的安全机制。

图 11

1.4 DOM Injection（文档对象注入模型）

这个实验需要查看页面的源代码，其实就是查看元素的代码罢了。首先当我们向输入框中插入内容时会发现，每输入一个值都会出发一个 up 函数，这个函数的功能就是将我们的输入发送到服务器端，然后判断我们的输入是否是正确的，如果是正确的则会激活激活按钮。而我们的实验则是即使输入错误的也可以使得激活按钮可用。这时我们使用Firebug进行调试，根据激活按钮的值找到这个 button 元素，然后将其 disabled 属性去掉或者修改为 false 都可以，这时我们会发现激活按钮可用了，如图 12 所示，于是我们随便输入一些数据进行提交，发现这个实验通过了。如图 13 所示。

图 12

图 13

1.5 XML Injection（XML注入）

Ajax往往利用XML与服务器端进行信息交互，而XML很容易被恶意者截获攻击。这个实验的原理大概是这样的：客户端查询自己积分的时候，会向服务器发送请求，然后服务器将客户端的积分数目，以及可以购买的商品信息以XML的形式发送给客户端，然后客户端对其进行多选，最后将所选的商品信息发送给服务器，这是服务器并没有对用户提交的商品信息进行检查，也没有对用户的积分是否购买提交的商品进行检查，而是默认为客户端发送的数据是刚刚传送给客户端的数据。但是这个时候的数据已经被我们修改了。我们可以看到没有修改之前服务器返回的数据如图 14 所示，经我们修改之后的数据 如图 15 所示，然后我们选中所有的商品如图 16 所示，提交可以看到实验已经获得成功，如图 17 所示；

    

图 14                                                                                                                              图 15

图 16

 

图 17

1.6 JSON Injection（JSON 注入）

JSON(JavaScript Object Notation)是一种简单地轻量级的数据交换格式，包含很多形式：数组，列表，哈希表和其他数据结构。广泛应用于AJAX和Web2.0，相比XML，JSON得到程序员的青睐，因为它使用简单、方便，速度更快，但是与XML一样都存在注入攻击。

首先这个实验的大概处理过超和上一个实验一样，只不过将 数据的传输格式由 XML 变成了 JSON ，那么我们看一下正常情况下的数据如图 18 所示，然后 我们对其进行修改 如图 19 所示，修改结果如图 20 所示，然后提交数据，结果如图 21 所示。这样我们就获得了既不停站又便宜的飞机票。

图 18

图 19

图 20

图 21

1.7 Slient Translations Attacks（静默转移攻击）

对客户端而言，任何一个默默处理的程序，使用单一提交的系统都是危险的。如果一个 Web 应用允许一个简单地 URL 提交，一个预设会话攻击将允许攻击者在没有用户授权的情况下完成交易。在 Ajax 中情况会变得更加糟糕，所有的处理都是不知不觉的，不会再页面上给用户反馈，所以注入的攻击脚本可以在用户未授权的情况下从客户端把钱偷走。

这个实的背景大概是这样的：一个允许使用 URL 提交的 web 页面，隐藏着转账者的账户，只需输入被转账者和转账金额就可以转账，而且还不会给出提示和授权，这样的话我们就可以通过在地址栏中执行 js 代码将预设账户的钱转走。这就要求我们首先要去审查元素，找到利用 Ajax 提交数据的函数（利用firebug），如图 22 所示 ，这个函数是 submitData，有两个参数，分别是被转账者的账号和转账金额，具体的执行过程如图 23 所示，执行结果如图 24 所示。注意：有的浏览器设置在地址栏是不能执行 js 代码的，可以设置允许，然后就可以进行实验了。

图 22

图 23

图 24

1.8 Dangerous Use of Eval（危险指令的使用）

这个实验的主要考察对象是 eval 函数，这个函数可以执行任意的 js 代码，也就是说如果我们用 eval 来处理输入的字符串的话，那么如果我们输入的是一些构造指令，它将会为我们执行，这是很可怕的。这个实验就是利用了 eval 的特性让他帮我们执行了alert(doucument.cookie)代码下面我们看一下实验过程。首先，我们通过实验我们发现这个页面会将我们的 card 和 code alert 出来，于是我们查看源代码如图 25 所示 ，发现他是用的 eval 函数，则我们如图 26 所示构造特殊字符串；然后提交，最后得到结果，如图27所示。

图 25

图  26

图 27

1.9 Insecure Client Storage（不安全的客户端存储）

这个实验的目的有两个，即：（1）在不知道优惠码的情况下，从页面中获取优惠码；（2）修改价格属性可读为可写，然后修改价格，使得自己获取更便宜的商品；这；两个攻击之所以能够成功，就是因为客户端存储且服务端不做检查导致的。服务端的计算是基于客户端传送过来的数据，而不是自身数据库内的数据，然而客户端是不可信的，这就导致服务器端很容易被欺骗。另外客户端本身是不安全的，那么把优惠码存储于客户端就相当于告诉用户优惠码了，这样的话还有什么安全性可言。接下来让我们进入实验。

老样子，先提交几次正常的数据试试，然后再查看 js 的源代码，找到控制函数，如图 28 所示 ，则最终须有将 decrypted 的值（如图 29 所示）赋给coupon，这个过程可以在 js里面实现，也可以在webscarab截获的数据包内修改参数实现，如图 30 所示 ，然后我们就可以完美的获取优惠码，完成第一个实验，如图 31 所示。

              

图 28                                                             图29

图 30

图 31

接下来第二个实验，这个实验的原理呢是这样的，就是服务器端会从客户端获取商品的价格，那么我们就需要修改商品的价格为 0 ，这样呢有多种方法可以实现，第一删掉表格的 readonly 属性，如图 32 所示；第二，直接在代码中修改其 value 值为 0 ； 第三在提交数据的时候，用 webscarab 截获数据，修改参数为 0 ；折几种方法都可以实现，我们采用第一种方法，结果如图 33 所示。

图  32

图  33

 

到此为止，我们关于 WebGoat 上关于 Ajax Security 的实验也就做完了，总结几条编程注意事项吧：

（1）不可再客户端存储重要敏感信息；

（2）要做好服务器端的认证；

（3）要做好一切系统之外的数据的检查过滤；

（4）要充分利用同源策略；

（5）要控制 Web 应用的 url 传输；