IBM Security AppScan 在应用程序开发的生命周期过程中提供安全测试， AppScan 扫描很多常规的漏洞，比如跨站脚本攻击（cross site cripting)，HTTP 响应分割（HTTP response splitting），参数篡改(Parameter Tampering)等等。目的是测试网络应用程序在开发过程中的安全漏洞，及时发现并且尽早修复，从而降低应用程序的修复成本。
跨站点请求伪造
可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务
将 HTTP 头设置为“http://bogus.referer.ibm.com” （变体标识：4）
解决办法：
验证HTTP Referer字段
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某官网是通过用户访问http://www.test/test页面完成，用户必须先登录www.test，然后通过点击页面上的按钮来触发某某事件。当用户提交请求时，该请求的Referer值就会是按钮所在页面的URL(本例中，通常是以www. test域名开头的地址)。而如果攻击者要对网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到网站时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，网站只需要对于每一个页面请求验证其Referer值，如果是以www. test开头的域名，则说明该请求是来自网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
代码示例：
在服务器端的拦截器必不可少，它将负责检查到来的请求是否符合要求，然后视结果而决定是否继续请求或者丢弃。在 Java 中，拦截器是由 Filter 来实现的。我们可以编写一个 Filter，并在 web.xml 中对其进行配置，使其对于访问所有需要 CSRF 保护的资源的请求进行拦截。
在 Filter 中验证 Referer
以下代码先取得 Referer 值，然后进行判断，当其非空并以 www.test 开头时，则继续请求，否则的话可能是 CSRF 攻击，转到 error.jsp 页面。
String referer = request.getHeader("Referer");
// 判断 Referer 是否以 www.test 开头
if ((referer != null) && (referer.trim().startsWith("http://www.test"))) {} else {
throw new CustomException("请勿跨站点请求伪造，谢谢合作");
}
存储的跨站点脚本编制
可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务
可能原因
未对用户输入正确执行危险字符清理
技术描述
AppScan 检测到应用程序未对用户可控制的输入正确进行无害化处理，就将其放置到充当 Web 页面的输出中。这可被跨站点脚本编制攻击利用。
在以下情况下会发生跨站点脚本编制 (XSS) 脆弱性：
[1] 不可信数据进入 Web 应用程序，通常来自 Web 请求。
[2] Web 应用程序动态生成了包含此不可信数据的 Web 页面。
[3] 页面生成期间，应用程序不会禁止数据包含可由 Web 浏览器执行的内容，例如 JavaScript、HTML 标记、HTML 属性、鼠标事件、Flash 和 ActiveX。
[4] 受害者通过 Web 浏览器访问生成的 Web 页面，该页面包含已使用不可信数据注入的恶意脚本。
[5] 由于脚本来自 Web 服务器发送的 Web 页面，因此受害者的 Web 浏览器在 Web 服务器的域的上下文中执行恶意脚本。
[6] 这实际违反了 Web 浏览器的同源策略的意图，该策略声明一个域中的脚本不应该能够访问其他域中的资源或运行其他域中的代码。
一旦注入恶意脚本后，攻击者就能够执行各种恶意活动。攻击者可能将私有信息（例如可能包含会话信息的 cookie）从受害者的机器传输给攻击者。攻击者可能以受害者的身份将恶意请求发送到 Web 站点，如果受害者具有管理该站点的管理员特权，这可能对站点尤其危险。
网络钓鱼攻击可用于模仿可信站点，并诱导受害者输入密码，从而使攻击者能够危及受害者在该 Web 站点上的帐户。最后，脚本可利用 Web 浏览器本身中的脆弱性，可能是接管受害者的机器（有时称为“路过式入侵”）。
主要有三种类型的 XSS：
类型 1：反射的 XSS（也称为“非持久性”）
服务器直接从 HTTP 请求中读取数据，并将其反射回 HTTP 响应。在发生反射的 XSS 利用情况时，攻击者会导致受害者向易受攻击的 Web 应用程序提供危险内容，然后该内容会反射回受害者并由 Web 浏览器执行。传递恶意内容的最常用机制是将其作为参数包含在公共发布或通过电子邮件直接发送给受害者的 URL 中。以此方式构造的 URL 构成了许多网络钓鱼方案的核心，攻击者借此骗取受害者的信任，使其访问指向易受攻击的站点的 URL。在站点将攻击者的内容反射回受害者之后，受害者的浏览器将执行该内容。
类型 2：存储的 XSS（也称为“持久性”）
应用程序在数据库、消息论坛、访问者日志或其他可信数据存储器中存储危险数据。在以后某个时间，危险数据会读回到应用程序并包含在动态内容中。从攻击者的角度来看，注入恶意内容的最佳位置是向许多用户或特别感兴趣的用户显示的区域。感兴趣的用户通常在应用程序中具有较高的特权，或者他们会与对攻击者有价值的敏感数据进行交互。如果其中某个用户执行恶意内容，那么攻击者就有可能能够以该用户的身份执行特权操作，或者获取对属于该用户的敏感数据的访问权。例如，攻击者可能在日志消息中注入 XSS，而管理员查看日志时可能不会正确处理该消息。
类型 3：基于 DOM 的 XSS
在基于 DOM 的 XSS 中，客户机执行将 XSS 注入页面的操作；在其他类型中，注入操作由服务器执行。基于 DOM 的 XSS 中通常涉及发送到客户机的由服务器控制的可信脚本，例如，在用户提交表单之前对表单执行健全性检查的 Javascript。如果服务器提供的脚本处理用户提供的数据，然后将数据注入回 Web 页面（例如通过动态 HTML），那么基于 DOM 的 XSS 就有可能发生。以下示例显示了在响应中返回参数值的脚本。
参数值通过使用 GET 请求发送到脚本，然后在 HTML 中嵌入的响应中返回。
攻击者可能会利用类似以下情况的攻击：
[ATTACK REQUEST]
GET /index.aspx?name=>"'><script>alert('PWND')</script> HTTP/1.1
[ATTACK RESPONSE]
HTTP/1.1 200 OK
Server: SomeServer
Date: Sun, 01 Jan 2002 00:31:19 GMT
Content-Type: text/html
Accept-Ranges: bytes
Content-Length: 83
<HTML>
Hello >"'><script>alert('PWND')</script>
</HTML>
在这种情况下，JavaScript 代码将由浏览器执行（>”’> 部分在此处并不相关）。
解决办法：
对特殊字符进行处理，从前台-》后台-》前台，对数据进行处理。
链接注入（便于跨站请求伪造）
·可能会劝说初级用户提供诸如用户名、密码、信用卡号、社会保险号等敏感信息
·可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务
·可能会在 Web 服务器上上载、修改或删除 Web 页面、脚本和文件
可能原因
未对用户输入正确执行危险字符清理
技术描述
该软件使用受外部影响的输入来构造命令、数据结构或记录的全部或一部分，但未能对可能修改其解析或解释方式的元素进行无害化处理。
“链接注入”是通过在某个站点中嵌入外部站点的 URL，或者在易受攻击的站点中嵌入脚本的 URL，从而修改该站点的内容。在易受攻击的站点中嵌入 URL 后，攻击者能够将其作为发起针对其他站点（以及针对这个易受攻击的站点本身）的攻击的平台。
其中一些可能的攻击需要用户在攻击期间登录站点。通过从易受攻击的站点本身发起这些攻击，攻击者成功的可能性更高，因为用户更倾向于登录。
“链接注入”脆弱性是未对用户输入进行充分清理所导致的结果，该输入以后会在站点响应中返回给用户。这样一来，攻击者能够将危险字符注入响应中，从而有可能嵌入 URL，以及做出其他可能的内容修改。
以下是“链接注入”的示例（我们假设站点“www.vulnerable.com”有一个名为“name”的参数，用于问候用户）。
下列请求：HTTP://www.vulnerable.com/greet.asp?name=John Smith
会生成下列响应：
<HTML>
<BODY>
Hello, John Smith.
</BODY>
</HTML>
