Testing the Hidden Data

在去年的内部交流中，提及过Hidden data的测试，昨天在和群内朋友聊天，谈及web页面的Hidden Data，觉得可以作为去年总结的补充，拓展Hidden Data的范围，进而持续拓展测试范围。

首先总结下，目前所总结的Hidden Data种类：

l DB中的Hidden Data：这是援引《Testing the Hidden Data》这篇论文的内容，主要涉及的Hidden Data为数据库中的隐含字段；

l System中的Hidden Data：这是去年工作中对Hidden Data的扩展，指的是系统运行状态下部署在crontab(Linux)或者windows(计划任务)中的周期任务诸如此类的执行后台任务的功能点；

l Web页面的Hidden Data：web页面中处于Hidden模式的控件，在get或者post数据时候提交给后台缺不需用户干预；

1. DB中的Hidden Data:

        先看定义吧：Suppose that an application asks a user for two pieces of information – a name and a password –to create an account. The user enters the two fields of data and then saves. Finally, a confirmation window retrieves the new record from the database and displays the name and password. To validate that all the data was saved correctly, a Quality Assurance tester simply needs to check the name and password on the confirmation window. Or do they? Suppose that the database record holds a third piece of information – Creation Date – which doesn’t appear on the confirmation window and is only used for archiving. If Creation Date isn’t saved correctly and the Quality Assurance tester only validated the onscreen data, then this problem might not be discovered. The Creation Date could have a defect that causes a user account to become archived on the wrong date, and yet the problem could go unnoticed

because it is hidden from the user interface. This example is simplistic, but it demonstrates the point: it is important that hidden data fields are tested.

Applications have two types of data: the kind that are made visible to the user, and the kind that are hidden from them. Defects in the visible data are easy for Quality Assurance testers to detect, because the problems can be seen directly through the user interface (UI). Hidden data defects are more difficult to detect because they don’t appear in the UI, only in the database -- where Quality Assurance testers might not be aware of them. The testers would need to check the database directly, without

using the application. If the Quality Assurance team is testing the application as a ‘black box’ – from the user’s point-of-view without knowledge of the programming or components behind it – then hidden data would not be tested at all.

     这是援引的《Testing the Hidden Data》这篇论文中的What is Hidden Data?这段内容，其实也就是通过案例来介绍Hidden Data的定义：加入页面需要输入“姓名”和“密码”两个字段来构造一个用户信息，当在保存数据库时，表中同时记录了第三个字段“生成时间”，此时，这个生成时间就是Hidden Data。在本案例中，如果不对”Creation Date”这个Hidden Data进行测试，可能就会遗留下隐患：比如在后续的审计归并中，想搜索某一时间段内的注册用户，由于Creation Date这个字段记录的是错误的，那么这样的统计必然不准确等等。

      这样的影响往往是比较细小的，可能在前台同步操作过程中没有功能上的影响，但对于后续功能是会造成影响的。

2.System中的Hidden Data：

这是看到Testing the Hidden Data这篇论文后对Hidden Data的补充：我们广义上的Hidden Data可能会并非那么狭义的数据库字段或者文本中的信息，也许可以更宽泛，比如—后台执行某些特定任务的某些脚本。

      介绍一个案例吧：我们的系统会使用Crontab来执行一些周期性的任务，这些任务往往在前台没有控制口提供，比如：定时重启系统，一些临时文件的清理等等，它们都是又运行在Crontab中的shell或者python脚本完成的。在平时的测试中，我们更多集中在前台功能的验证，而由于是测试环境，系统比较干净，运行时间较短(验证无误后就重装出货了)，类似这种定期清理临时文件脚本执行不成功也没有明显的暴露(时间短，体会不出来系统磁盘紧张)。但在客户环境下，可能客户的系统要跑一年甚至数年，很多时候，一些后台功能没有正确执行的缺陷就暴露出来，比如上文说的磁盘临时文件清理功能，由于没有正确执行，客户的磁盘空间使用的非常快。要经过远程调试才能够发现问题。

      所以，后续的解决方案就是：自动写脚本对crontab中的任务做测试，确保这些没有前台接口的功能点也能正确执行。

3.web页面的Hidden Data：

在web页面中，一些控件会处理为Hidden的模式，当提交数据时其中的值也同时会提交到后台。先看一个比较极端也比较古老的例子，是在《黑客攻防技术宝典—Web实战篇》援引的一个常用的例子：

<form. action=”order.asp” method=”post”>

      <p>Product: Sony VAIO A217S</p>

      <p>Quantity: <input size=”2” name=”quantity” >

      <input name=”price” type=”hidden” value=”1224.95”>

      <input type=”submit” value=”Buy”></p>

</form>

在这个例子中，表单字段名为price，被标记为隐藏。当用户提交表单时，这个字段将被提交到服务器：

      POST /order.asp HTTP1.1

      Host : wahh-app.com

      Content-Legth: 23

      Quantity=1&price=1224.95

此时，虽然price字段并未显示在屏幕上，并且用户无法对其进行编辑，但这只是因为应用程序指示浏览器隐藏该字段而已。因为在客户端进行的一切操作最终将用客户控制，用户编辑这个字段时可以接触这个限制。

      我经常使用Firefox下的Tamper Data来进行这样的操作，任意修改提交的数据值，达到自己的测试效果。

      这里面就要提及，在日常的测试中，对于Edit这样的明显从用户获取数据的控件类型，往往研发人员进行了严格的校验，包括前台的JS校验和后台的参数校验，而对于List,checkbox或者是置于Hidden状态下控件，往往校验不严格甚至没有校验。比如：

      <form. name="loginForm" action="/user/login" method="post">

            <img height="0" width="0" class="bg" src="/stylesheet/iceye/images/login_bg.png">

            <div class="body">

           <img class="logo" src="/stylesheet/iceye/images/login_logo_sc_zh_CN.png">

            <fieldset>

                   <legend></legend>

                   <label for="username" class="">用户名</label><input type="text" name="user[account]" id="username" value="">

                    <label for="password">密码</label><input type="password" name="user[password]" autocomplete="off" id="password" value="">

                    <input type="hidden" value="local" name="login_type" id="login_type">

                    <input type="submit" class="submit" value="登录">

             </fieldset>

             <div nmouseout="this.className='language'" nmouseover="this.className='language on'" class="language">

             <b class="cur zh_CN"></b>

             <span class="list">

                    <a class="cn" href="/index/locale/lang/zh_CN"></a>

                    <a class="en" href="/index/locale/lang/en_US"></a>

                    <!-- <a href="/index/locale/lang/zh_TW" class="cn2"></a>-->

             </span>

      </div>

                    <div class="cmn_form_err">

      </div>

</div>

</form>

这段Html是我们自己产品的登录界面，大家可以看到中间有个隐藏字段为：

<input type="hidden" value="local" name="login_type" id="login_type">

我用Tamper Data拦截了Post的数据，默认为local，修改为任意数据后，返回的结果是Fatel Error，也就是说，后台对于提交的这个数据没有做防御性处理。当然，在此处也没有进一步做测试，如果对于”有心”的人，一些隐藏字段的利用将带来较为严重的后果。

其实上述三种所谓的Hidden Data，所具有的的共性就是前台往往没有提供控制接口，所以功能较为隐蔽，在日常的测试中往往不被注意，但如果细心一点，也会发现这些测试点，拓展我们的测试领域，让我们的产品功能更可靠，而产品本身更坚固。