我希望你已经看过这篇文章的第一部分了，其内容为web应用程序是怎样不同于传统的CS结构。如果你还没看过，你会发现看一下会比较有帮助。

在这一部分我们将探讨哪部分信息对客户端来说是有用的。哪些信息可以从客户端所访问的网页收集到？确保web应用程序有合适的安全性是如何的重要？cookies是什么且如何为web应用程序所用？

对web应用程序来说收集尽可能多关于程序信息的安全性测试是非常重要的。你需要找出在你们组织之外连接你们的应用程序的用户有多少，他们寻找什么样的信息。对组织之外的人有用的典型的信息可以归类为以下方面：

ü  嵌入在html源码里的注释和敏感信息

ü  服务器和http响应而产生的错误信息

ü  应用程序错误信息

在web应用程序的开发过程中，考虑这些方面是非常重要的。注释和敏感信息对开发维护代码是非常有帮助的。但如果被恶意用户截获对程序同样很危险。同样，用来改善可用性的详细的错误信息，也可能会产生安全漏洞。

客户端显示的html源码对攻击者来说可能是非常有用的信息来源。所有人都很容易看到html源码因为它是未编译的而且没有隐藏注释。对测试web应用程序安全性的你来说，你应该注意敏感信息比如密码、用户名、数据库名，连接字符串等等。作为一个为安全性负责的人来说，你需要确保在html源码中不存在敏感信息。

为了开始攻击web应用程序，重要的是，知道页面如何被访问及从一个页面到另一个页面需要什么样的数据和参数。为这一目的你需要留意网站及寻找关键值对。你应该创建网站地图。可以用工具或者手动打开所有页面来创建合适的地图。创建页面地图后，通过在html源码中用特定字符串搜索，与html注释、程序注释、ip地址、邮件地址、sql查询、数据库连接字符串、隐性的输入文件等相关的字符串。

如果在此过程中尝试改变参数，你将会在返回的错误信息中发现有趣的信息。有时服务器或应用程序返回了过于有用的信息，这给予攻击者微妙的暗示。比如在登录过程中提供了无效的密码，如果服务器返回的错误信息类似于“无效的秘密”，它基本上指出了用户名是正确的。

之前制作的地图还可以帮助你猜测在服务器上的文件名和目录结构。利用这一技术你可以访问没有呈现在网页链接或者用户不可见的文件。那些不能被客户端浏览的文件一定要放在客户端不容易接近的地方。利用这些有根据的猜测，恶意用户甚至可以获得网站的管理员和控制面板，这些通常是运行在独立的分站点或不同端口的。利用一些端口扫描和其它强制工具，这些类型的漏洞很容易被发现。

web应用程序的脆弱也会暴露在熟悉的用户界面操作。例如，网站中用了一些列表框来获取用户输入。这是为了确保客户端用户不会输入列表框之外的选项。开发团队做这样的假设很简单，不需要做其他额外的确认。他们没有认识到的是，很容易在页面的源码中改变这些数据，甚至可以利用一些工具篡改传输中的请求。而且，如果认证是在客户端，还有可能绕过认证。不仅可以通过禁用java脚本而且可以通过保存文件的本地副本来消除这些验证。为了增加安全性，确保这些验证同样存在服务器端是非常必要的。

另外需要在客户端检查的是cookies。人们不熟悉cookies，cookies是web应用程序存储在客户端硬盘上的文本类型的小文件。web应用程序在并发访问中重用这些数据。web应用程序可以永久的\非永久的或安全的\非安全形式的产生cookies。cookies是个性化的，而且用完后的信息是过期的。cookies可以被用在很多途径。cookies以特定的格式保存在特定的地址。如果你的应用程序的所有功能都依赖于cookies，必须测试cookies是不是能跟你的程序一起运行。

希望理解威胁安全的不同途径后，能提高你对web应用程序安全性测试重要性的认识。在下一节里，我们将探讨客户端提供的数据是怎样被测量的，而服务器是怎样被攻击的。

 

 

原文：

 Web Application Security Testing - Part 2

        

I hope that you have already read first part of this article and familiar with the concept of how web applications are different from traditional client-server applications. If you have not, you might find it useful to read Part-1 as well.

 

In this part we will explore what kind of information is available to the client? What kind of information can be gathered from the pages which client can access? How validation is important to ensure proper security for the web application? What are cookies and how web applications use them?

It is very important in web application security testing to gather as much information about your application as you can. You need to find out how people outside your organization will access your web application and what kind of information they can access. Typical information that will be available to any person outside your organization could be categorized as

 

    * Comments & Sensitive information embedded in the HTML source code

    * Error messages generated at the server and HTTP response returned.

    * Application error message

 

During web application development, it is very important to think about these aspects. Comments or sensitive information can be very useful for you while developing and maintaining the code, but if it is accessed by malicious user it can be dangerous. Similarly, detailed error messages given to improve usability can results in the security loophole.

 

HTML source present on the client side can be an excellent source of information for the attacker. It is very easy for everyone to view HTML source code and since it is not compiled, there is no way to hide HTML comments. For testing web applications for security, you should look for the sensitive information like passwords, usernames, database names, connection strings etc. As a person responsible for security testing you need to make sure that sensitive information is not present in the HTML source code.

 

In order to start attack on any web application, it is important to know how its pages can be accessed, what kind of data and parameters are passed from one page to another. You can keep an eye on the URL for this purpose and look for key-value pairs.  You should always consider creating page map of your site containing this information. You can use tool or can create it manually by navigating to all the pages and making appropriate maps. After you have created this page map, you can search HTML source for specific strings containing information related to HTML comments, Application Comments, IP Address, E-Mail Address, SQL Queries, Database Connection Strings, Hidden input fields etc.

 

If you try to change parameters selected during this process and resubmit the request, you can find interesting information in error messages. Sometimes server or application throws overly helpful error messages which can give subtle hints to the attackers.  For example on supplying invalid password during login process if system throws error like 'invalid password' , it essentially means that username is proper.

 

Page map created earlier can also help you in guessing file names and directory structure present on the web server. Using this technique you can access files for which there is no link present on the pages, or which is not intended to be visible to the user. You must always check for the presence of any pattern in file names and location. Files which should not be viewed by clients should be located in places not accessible to the clients. Using this technique of educated guessing, malicious users can even access admin or control panel of the website, which usually runs as a separate sub-site or run on a different port. These type of loopholes can be identified easily by tools like port scanners and other brute-force tools.

 

Vulnerability of the web application can also be exposed by manipulating UI controls. For example, you might have used websites containing list boxes to take user input. Reason for providing list box is to make sure that client do not choose any other option apart from whatever is supplied in the list. It is very easy for development team to make this assumption and not do any other form of validation. What they fail to realize is that, these values can be changed by making changes in the page source even request can be tampered on transit using appropriate tools. Also if validations are present at the client-side, it is still possible to bypass those validations. This could be achieved either by disabling the java scrīpts or saving a local copy of the file and removing those validations. To safeguard from these vulnerabilities, it is essential to make sure that validations are present on the server side as well.

 

Another thing that should be checked at the client side is cookies. For people not familiar with cookies, cookies are small files of textual data that a web application writes on a client's hard drive. Web application can reuse this data on subsequent visits. Cookies can be delivered by web application using either persistent/non-persistent and secure/non-secure mode.  Cookies can be used for personalization or making sure that information is not accessed after it is expired. There are many ways in which cookies can be used. Cookies are normally stored at predefined location with predefined formats. If your application relies on cookies for any functionality, it is essential for you to make sure that tempered cookies can not be used with your application.

 

Hope after understanding the different ways in which security can be compromised, you will appreciate  the importance of security testing of web applications. In the next article, we will explore how data supplied by client can be tempered and servers can be attacked.

 

You can read more articles on software testing in our article section. You can suggest topics of your interest here , we will try to provide information on those topics as well.

web应用程序和C-S是一样的吗？这个问题在软件测试研究中很常见，如果你是一个与测试相关的web团队的一员，你可能从不同的人那里听到很多次了。

在CS和web应用程序体系之间有很多的不同之处。作为一个测试web应用程序的测试人员，明白cs体系是什么并且web是怎么样不同于传统cs体系的这一点非常重要。

web是cs网络的一种特殊的版本，但有明显的不同。在cs网络，复杂的耗时的数据任务被委派给强大而昂贵的名叫服务器的机器。它们通过网络处理并传输给名为客户端的机器。因此cs体系包含服务器客户端和链接它们的网络。

如果你了解底层的标准，cs体系不是这么简单。为了链接两个机器，你需要网络标准协议，需要合适的软件在客户端和服务器端的网络上发送和接受数据。需要处理好在传输过程中丢失的数据的问题，带宽问题，断网的问题等等。所有这些问题已经被一些协议如tcp/ip,udp,arp等等处理了。开发者使用它们面对的问题就很少了。这些协议是cs体系的支柱。

www是在现有的cs体系的高层开发的。它是ftp和email进行共享文件和数据的替代机制。新的在服务器端处理请求的发展，新的客户端链接和浏览服务器资源的软件，新的发展比如http，html等等加速了web的发展。web体系的主要组件是web服务器，它可以接收从任何客户端发来的请求，web开始时处理静态连接，但很快开始探索比静态连接跟多的可能性。

虽然web是建立在cs纸上的，但还是有明显的区别。比如

web是cs体系的一个特例，臃肿的客户端可以通过各种协议和标准与服务器进行通话，如http，html，xml，soap等等。

在cs体系，客户端和服务器在一个公司的一墙之内，因此在一个受保护的环境中。在这个情况下客户是受信的用户。web是不同的，因为任何一个客户端都可以连接服务器所以不能被可信的对待。

由于cs是在一个公司的防火墙只能，所以安全性方面的问题就没有web应用程序那样重要。

在cs体系，每个客户端都是明确的；每个被服务器接收到的请求都包含有谁发起这个请求的信息。在web体系，任何一个用户都可能是危险的。

web给那些在网络上怀有恶意的用户篡改数据的机会。与web体系相比传统cs结构中数据被篡改的几率小的多。

在cs体系中客户端的数量是可预期和可控制的。但是在web体系很难。

在cs体系客户受约束很多，装什么系统，在哪个平台运行，用什么浏览器等所有事情都能被限制。相比之下，在web体系没有什么是可以被控制的。

因为如此，在cs体系中的测试和web体系的城市也是不同的。受影响的主要区域可以概括为以下方面：

商业逻辑：在cs体系所有的客户端逻辑都需要测试而在web体系大多数情况是不需要的。

平台和操作系统依赖性：web应用程序是脱离操作系统依赖的，只需要在不同的浏览器测试。cs体系程序依赖于操作系统或平台，所以强调要测试不同的平台和操作系统。

可测量性：web程序必须测试在数千个用户并发情况下的表现。对cs程序来说这个数量相当少。

安全性：这是web程序的重要组成，但对cs程序来说要求很低。原因是cs程序的客户端和服务器之间的交互是发生在信任领域的，而在web程序没有这种情况。

总而言之，web程序是cs体系程序的一个特例，但他们在很多领域不同。在web环境中测试，所有的明确的地方都需要充分的记录，因为每个连接的客户端对系统都存在着潜在的威胁。

希望这篇文章对你在cs和web方面区别认识有所帮助。另外，在这个体系和另一个体系中的测试怎样不同，安全性测试的重要性也是基于这篇文章的内容。

下一篇文章将更深入的讨论这个话题，并且将要讨论针测试web程序安全性的各种技术和工具。

这篇文章也参考了我最近读到的Mike Andrews and James A. Whittaker的《怎样打破web软件》一书。那本书会给你更多关于web程序安全测试方面的知识。

 

   （最近比较闲，就翻译了一下）

   回归测试比较容易理解但如果没有一个好的自动化工具来处理所有的细节恐怕很难执行。testcomplete就是这么一个自动化测试执行工具。

   回归测试意思是“重复一个已经执行成功的测试并将新的结果与之前的测试结果相比较”。当你在一个项目上运行一个测试并修正项目编码的时候，这个过程是有用的。用户从此过程中得到两件事情----一个测试脚本，和一个被认可的标准。回归测试时基于一个观点：重复利用一个测试脚本并接受这个标准，而并不是一旦测试成功就将之遗弃。

    在真正的回归测试中，所有形式的所有测试及其结果都记录在一起，没有一个被扔掉。在每次的重复中，所有存在的经过验证的测试脚本被运行并且将新的结果与已存在的标准相比较。并且，通常会增加一个或多个测试脚本对项目进行测试并调试直到项目成功通过所有的测试脚本。显然，在此观点来看一些自动化测试工具是必须的。检查几百个结果是否正确是人力所不可能达到的。

    测试一开始回归测试就开始了。回归测试脚本随着编码重构及项目的进展越来越壮大 。很快它将包含上千个必须借由自动化软件来顺序执行的小测试脚本。

    测试脚本的开发灵感来源于testcomplete重要功能的设计，测试日志。

    在强大的机器和老练的测试管理工具的帮助下，一天之中我们能运行多次全部的回归测试。不管什么时候一旦程序中加入了一个新的功能，按规定对应的测试脚本将比编码更早一步加入到脚本中来。一旦编码完成，它将被编译，并且整个回归测试集合将在此编译版本上运行。测试集合的结果将自动检查，新测试的结果将手工检查，修改的编码将再次整体测试直到通过相应的测试 。这些测试脚本及其验证结果将像编码被添加进版本一样被添加进测试集合。

    这样的程序的优势是如果这些回归测试脚本中有一个发生故障 ，你知道它是由哪部分编码导致的。

    回归测试的运用是极限编程方法的中心。（参考极限编程，Kent Beck, Addison-Wesley, 或者 http://www.extremeprogramming.org/）。AutomatedQA公司跟极限编程或她的拥护者没有关系，但极限编程是基于对TestComplete来说测试自动化的有效性和软件管理的通用性。TestComplete也显著地影响其他极限编程实践。

    来看看一个回归测试在testcomplete中是怎么执行的？

• 首先，执行测试脚本并进行调试。
• 其次，在测试脚本中添加或修改。
• 然后为新加入版本的特殊性功能设计一个测试脚本。
• 在新版本上运行旧的和新加入的测试脚本。
• 修改并重复执行直到所有脚本都测试通过。
• ……