保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
单击提交则表示您同意developerWorks
的条款和条件。 .
所有提交的信息确保安全。
developerWorks 社区:
我的概要信息
选择语言：
IBM®Security
的®是一款领先的应用安全性测试套件，旨在整个软件开发生命周期中管理漏洞测试。 IBM Security AppScan
自动进行漏洞评估、扫描和检测所有常见的 Web 应用程序漏洞，包括 SQL 注入，跨站脚本，缓冲区溢出和 Flash/ Flex 应用程序和 Web2.0 的漏洞扫描。 AppScan 的的特点和优点包括以下内容：1）扫描和测试，适用范围广的应用安全漏洞 2）能够扫描复杂的 Web 应用 3）高精度，先进的检测功能，包括动态和创新的混合动力分析玻璃盒测试（运行时分析），静态污点分析 4）快速修复，可优先成果，修复成建议 5）增强您的见解组织遵守政府和行业任务，促进了 40 项合规报告。Web 应用程序的支持，包括：Adobe 的 Flash，JavaScript，Ajax 和简单对象访问协议（SOAP）的 Web 服务。此试用版提供了
IBM 的 Security AppScan 标准版的全部功能，没有任何功能上的限制。唯一限制是，扫描被限制到一个站点，Altoro Mutual：http://demo.testfire.net。
使用注意：使用评估许可证，您可以扫描测试网站，Altoro Mutual：http://demo.testfire.net。使用预定义的模板，demo.testfire.net，它显示在新的扫描对话框。当提示输入用户名和密码,
使用：用户名
jsmith密码 Demo1234 您如何需要评估和测试您组织自己的网站，需要申请试用许可证：.该下载选项包括用于 Web 服务的扫描组件。当您下载并使用此试用版后，您可以在 Appscan 用户社区
提交技术问题和疑问，请访问：。产品信息
选择您的首选平台IBM Security AppScan: Windows (HTTP or Download Director)
参考资源获得帮助关于&会话标识未更新&，其实我觉得应该是颇有争议的，为何登录后不更新会话标识就会存在危险，是不是担心读取到旧会话中存在Session的取值呢？这个恕我不懂。
关于漏洞的产生
&会话标识未更新&是中危漏洞，AppScan会扫描&登录行为&前后的Cookie，其中会对其中的JSESSIONOID（JSP）或者 ASP.NET_SessionId（ASP）进行记录。在登录行为发生后，如果cookie中这个值没有发生变化，则判定为&会话标识未更新&漏洞。
JSP的修复方法可参考这位大侠的文章，我个人没有确认过：
ASP的修复方法可以参考以下代码，在登录按钮点击后，确认登录前，加入3行代码对Cookie进行清空已达到重置SessionId的效果。
protected void btnLogin_Click(object sender, EventArgs e)
//重置SessionId
Session.Clear();
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
//登录判断
if (check(txtName.Text,txtPassword.Text))
FormsAuthentication.SetAuthCookie("admin", false);
Response.Redirect("Default.aspx");
AppScan中，对&会话标识未更新&也提供了修改建议：
一般修订建议 始终生成新的会话，供用户成功认证时登录。防止用户操纵会话标识。请勿接受用户浏览器登录时所提供的会话标识
使用代码前
使用代码后
为何会产生漏洞
有人会问这个漏洞为何会产生? 为什么有的站点会出现,有的站点没有使用代码却又不会出现。写在最后，我提供一个思路，这样才是深入浅出的研究问题：
有时候网站登录页面，并不会立刻产生SessionId，例如我写的登录页面，页面中是不会出现ASP.NET_SessionId：（使用Chrome+Edit This Cookie插件）
登录后才会出现ASP.NET_SessionId，另一个是登录代码中增加的验证Cookie。
但是当我在登录页加载之前，添加了信息在用户Session中（例如为了添加图形验证码的需要），这时候登录页加载的时候就会产生SessionId
protected void Page_Load(object sender, EventArgs e)
//产生会话标识未更新漏洞
Session["useless"] = 1;
一旦登录前就有SessionId，那么AppScan就有了可以比较的SessionId，在登录后比较SessionId的变化，那么也就会产生&会话标识未更新&漏洞。
写在最后的最后，&会话标识未更新&的危害，在于攻击者通过某种方式（如XSS）将自己的Id置入了被攻击者的浏览器，将会话标识改为某个攻击者预设的值，被攻击者正常登陆，若服务器接收了这个预设值，那么相当于攻击者获得了被攻击者登录后的权限，因此才要求在登录时更新会话标识。
阅读(...) 评论()Appscan安全漏洞修复
&&1.会话标识未更新：登录页面加入以下代码
request.getSession(true).invalidate();//清空session
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
request.getSession(true).invalidate();//清空session
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
不是很明白session的机制，高手路过可以指教一下。
&2.跨站点请求伪造：
在出错的url加参数sessionid。
response.getWriter().write( &&script&parent.location.href='dbase/admin/loginJsp.action?sessionId=&+sessionId+&'&/script&&);
response.getWriter().write( &&script&parent.location.href='dbase/admin/loginJsp.action?sessionId=&+sessionId+&'&/script&&);
如果带参数报ssl错误，使用下面的post方式传值：
response.getWriter().write(
&&script language=\&javascript\&& & +
&document.write(\&&form action=dbase/admin/loginJsp.action method=post name=formx1 style='display:none'&\&);& +
&document.write(\&&input type=hidden name=name value='&+sessionId+&'\&);& +
&document.write(\&&/form&\&);& +
&document.formx1.submit();& +
&&/script&&
response.getWriter().write(
&&script language=\&javascript\&& & +
&document.write(\&&form action=dbase/admin/loginJsp.action
method=post name=formx1 style='display:none'&\&);& +
&document.write(\&&input type=hidden name=name value='&+sessionId+&'\&);& +
&document.write(\&&/form&\&);& +
&document.formx1.submit();& +
&&/script&&
&3.启用不安全HTTP方法
修改&web&工程中或者服务器web.xml,增加安全配置信息，禁用不必要HTTP方法
&security-constraint&
&web-resource-collection&
&url-pattern&/*&/url-pattern&
&http-method&PUT&/http-method&
&http-method&DELETE&/http-method&
&http-method&HEAD&/http-method&
&http-method&OPTIONS&/http-method&
&http-method&TRACE&/http-method&
&/web-resource-collection&
&auth-constraint&
&/auth-constraint&
&/security-constraint&
&login-config&
&auth-method&BASIC&/auth-method&
&/login-config&
修改web工程中或者服务器web.xml,增加安全配置信息，禁用不必要HTTP方法
&security-constraint&
&web-resource-collection&
&url-pattern&/*&/url-pattern&
&http-method&PUT&/http-method&
&http-method&DELETE&/http-method&
&http-method&HEAD&/http-method&
&http-method&OPTIONS&/http-method&
&http-method&TRACE&/http-method&
&/web-resource-collection&
&auth-constraint&
&/auth-constraint&
&/security-constraint&
&login-config&
&auth-method&BASIC&/auth-method&
&/login-config&
4.已解密登录请求
配置SSL，具体见/admin/blogs/1320231
在web.xml加入如下配置。
&security-constraint&
&web-resource-collection &
&web-resource-name &SSL&/web-resource-name&
&url-pattern&/*&/url-pattern&
&/web-resource-collection&
&user-data-constraint&
&transport-guarantee&CONFIDENTIAL&/transportguarantee&
&/user-data-constraint&
&/security-constraint&
&security-constraint&
&web-resource-collection &
&web-resource-name &SSL&/web-resource-name&
&url-pattern&/*&/url-pattern&
&/web-resource-collection&
&user-data-constraint&
&transport-guarantee&CONFIDENTIAL&/transportguarantee&
&/user-data-constraint&
&/security-constraint&
5.高速缓存的ssl页面
&meta http-equiv=&Pragma& contect=&no-cache&&
&meta http-equiv=&Pragma& contect=&no-cache&&
response.setHeader(&Pragma&, &No-cache&);
response.setHeader(&Pragma&, &No-cache&);
6.目录列表
配置文件目标拒绝访问。
在conf/web.xml下:
&servlet-name& default &/servlet-name&
&servlet-class& org.apache.catalina.servlets.DefaultServlet &/servlet-class&
&init-param&
&param-name& debug &/param-name&
&param-value& 0 &/param-value&
&/init-param&
&init-param&
&param-name& listings &/param-name&
&param-value& false &/param-value&
&/init-param&
&load-on-startup& 1 &/load-on-startup&
&/servlet&
&servlet-name& default &/servlet-name&
&servlet-class& org.apache.catalina.servlets.DefaultServlet &/servlet-class&
&init-param&
&param-name& debug &/param-name&
&param-value& 0 &/param-value&
&/init-param&
&init-param&
&param-name& listings &/param-name&
&param-value& false &/param-value&
&/init-param&
&load-on-startup& 1 &/load-on-startup&
&/servlet&
把listings对应的value设置为fasle.
或者把上面的这个servlet加到你的虚拟路径下的web-inf/web.xml中,把servlet-name改为其它的,再加一下servlet-mapping
&servlet-name& default1 &/servlet-name&
&servlet-class& org.apache.catalina.servlets.DefaultServlet &/servlet-class&
&init-param&
&param-name& debug &/param-name&
&param-value& 0 &/param-value&
&/init-param&
&init-param&
&param-name& listings &/param-name&
&param-value& false &/param-value&
&/init-param&
&load-on-startup& 1 &/load-on-startup&
&/servlet&
&servlet-mapping&
&servlet-name& default1 &/servlet-name&
&url-pattern& / &/url-pattern&
&servlet-mapping&
&servlet-name& default1 &/servlet-name&
&servlet-class& org.apache.catalina.servlets.DefaultServlet &/servlet-class&
&init-param&
&param-name& debug &/param-name&
&param-value& 0 &/param-value&
&/init-param&
&init-param&
&param-name& listings &/param-name&
&param-value& false &/param-value&
&/init-param&
&load-on-startup& 1 &/load-on-startup&
&/servlet&
&servlet-mapping&
&servlet-name& default1 &/servlet-name&
&url-pattern& / &/url-pattern&
&servlet-mapping&
您对本文章有什么意见或着疑问吗？请到您的关注和建议是我们前行的参考和动力&&
您的浏览器不支持嵌入式框架，或者当前配置为不显示嵌入式框架。您现在的位置： &
JavaScript常见安全漏洞及自动检测技术(1)
JavaScript常见安全漏洞及自动检测技术(1)
　　随着Web2.0的发展以及Ajax框架的普及，富客户端Web应用(Rich Internet Applications，RIA)日益增多，越来越多的逻辑已经开始从服务器端转移至客户端，这些逻辑通常都是使用JavaScript语言所编写。但遗憾的是，目前开发人员普遍不太关注JavaScript代码的安全性。据IBMX-Force2011年中期趋势报告揭示，世界五百强的网站及常见知名网站中有40%存在JavaScript安全漏洞。本文将结合代码向读者展示常见Java Script安全漏洞，旨在帮助读者能够在日常编码工作中规避这些安全漏洞。此外，客户端Java Script安全漏洞与服务器端安全漏洞原理略为不同，自动化检测JavsScript安全漏洞目前存在较大的技术难题，本文将结合案例跟读者分享如何利用IBM Rational AppScan Standard Edition V8.0新特性(JavaScript Security Analyzer，JSA)技术自动化检测JavaScript安全漏洞。
　　JavaScript常见安全漏洞
　　2010年12月份，IBM发布了关于Web应用中客户端JavaScript安全漏洞的白皮书，其中介绍了IBM安全研究机构曾做过的JavaScript安全状况调查。样本数据包括了675家网站，其中有财富500强公司的网站和另外175家著名网站，包括IT公司、Web应用安全服务公司、社交网站等。为了不影响这些网站的正常运行，研究人员使用了非侵入式爬虫，仅扫描了无需登录即可访问的部分页面，每个站点不超过200个页面。这些页面都被保存下来，研究人员采用IBM的JavaScript安全分析技术离线分析了这些页面，集中分析了基于DOM的跨站点脚本编制及重定向两种漏洞。
　　测试结果令人惊叹，这些知名网站中有14%存在严峻的JavaScript安全问题，黑客可以利用这些漏洞进行植入流氓软件，植入钓鱼站点，以及劫持用户会话等。更令人惊叹不已的是，随着IBM的JavaScript安全分析技术的成熟发展，2011年中期X-Force报告显示，IBM重新测试了上述这些知名网站并发现了更多的安全漏洞，大约有40%的网站存在JavaScript安全漏洞。
　　下文本文将结合代码向读者展示常见这些JavaScript安全漏洞，以便读者在实际编码过程中注意到这些安全问题，及早规避这些风险。
　　1、基于DOM的跨站点脚本编制
　　我们都听说过XSS(Cross Site Script，跨站点脚本编制，也称为跨站脚本攻击)，指的是攻击者向合法的Web页面中插入恶意脚本代码(通常是HTML代码和JavaScript代码)然后提交请求给服务器，随即服务器响应页面即被植入了攻击者的恶意脚本代码，攻击者可以利用这些恶意脚本代码进行会话劫持等攻击。跨站点脚本编制通常分为反射型和持久型：当请求数据在服务器响应页面中呈现为未编码和未过滤时，即为反射型跨站点脚本编制;持久型指的是包含恶意代码的请求数据被保存在Web应用的服务器上，每次用户访问某个页面的时候，恶意代码都会被自动执行，这种攻击对于Web2.0类型的社交网站来说尤为常见，威胁也更大。应对跨站点脚本编制的主要方法有两点：一是不要信任用户的任何输入，尽量采用白名单技术来验证输入参数;二是输出的时候对用户提供的内容进行转义处理。
　　但鲜为人知的是还有第三种跨站点脚本编制漏洞。2005年AmitKlein发表了白皮书《基于DOM的跨站点脚本编制&第三类跨站点脚本编制形式》(&DOM Based Cross Site Scripting or XSS of theThird Kind&)，它揭示了基于DOM的跨站点脚本编制不需要依赖于服务器端响应的内容，如果某些HTML页面使用了document.location、document.URL或者document.referer等DOM元素的属性，攻击者可以利用这些属性植入恶意脚本实施基于DOM的跨站点脚本编制攻击。
　　下面我们将通过一个很简单的HTML页面来演示基于DOM的跨站点脚本编制原理。假设有这么一个静态HTML页面(如清单1所示)，用来展示欢迎用户成功登录的信息。
　　清单1.存在DOM based XSS的HTML代码
　　按照该页面JavaScript代码逻辑，它会接受URL中传入的name参数并展示欢迎信息，如清单2所示：
　　清单2.正常情况下的访问URL
　　但如果恶意攻击者输入类似如下的脚本，见清单3，该页面则会执行被注入的JavaScript脚本。
　　清单3.访问URL中注入脚本
　　很明显，受害者的浏览器访问以上URL的时候，服务器端会跟正常情况下一样返回清单1中所示HTML页面，然后浏览器会继续将这个HTML解析成DOM，DOM中包含的document对象的URL属性将包含清单3中注入的脚本内容，当浏览器解析到JavaScript的时候会执行这段被注入的脚本，跨站点脚本编制攻击即成功实现。
　　值得关注的是，通过以上示例可以看出，恶意代码不需要嵌入服务器的响应中，基于DOM的跨站点脚本编制攻击也能成功。可能某些读者会认为：目前主流浏览器会自动转义URL中的'&'和'&'符号，转义后的注入脚本就不会被执行了，基于DOM的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的，但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对URL的转义，譬如攻击者可以利用锚点'#'来欺骗浏览器，如清单4所示。浏览器会认为'#'后面的都是片段信息，将不会做任何处理。
　　清单4.访问URL中结合锚点注入脚本
　　2、通过URL重定向钓鱼
　　网络钓鱼是一个通称，代表试图欺骗用户交出私人信息，以便电子欺骗身份。通过URL重定向钓鱼指的是Web页面会采用HTTP参数来保存URL值，且Web页面的脚本会将请求重定向到该保存的URL上，攻击者可以将HTTP参数里的URL值改为指向恶意站点，从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单5给出了较为常见的含有通过URL重定向钓鱼漏洞的代码片段。
　　清单5.执行重定向的JavaScript代码片段
　　可以看出，这些JavaScript脚本负责执行重定向，新地址是从document.location、document.URL或者document.referer等DOM元素的属性值中截取出来的，譬如用户输入清单6所示。
　　清单6.执行重定向的URL
　　显然用户一旦执行了清单6所示URL，将被重定向到钓鱼网站。这个漏洞的原理很简单，比服务器端的重定向漏洞更好理解。但通过URL重定向钓鱼的情况下，钓鱼站点的网址并不会被服务端拦截和过滤，因此，这个漏洞往往比服务器端重定向漏洞更具有隐蔽性。
　　3、客户端JavaScript Cookie引用
　　Cookie通常由Web服务器创建并存储在客户端浏览器中，用来在客户端保存用户的身份标识、Session信息，甚至授权信息等。客户端JavaScript代码可以操作Cookie数据。如果在客户端使用JavaScript创建或修改站点的cookie，那么攻击者就可以查看到这些代码，通过阅读代码了解其逻辑，甚至根据自己所了解的知识将其用来修改cookie。一旦cookie包含了很重要的信息，譬如包含了权限信息等，攻击者很容易利用这些漏洞进行特权升级等攻击。
　　4、JavaScript劫持
　　许多Web应用程序都利用JSON作为Ajax的数据传输机制，这通常都容易受到JavaScript劫持攻击，传统的Web应用程序反而不易受攻击。JSON实际上就是一段JavaScript，通常是数组格式。攻击者在其恶意站点的页面中通过&SCRIPT&标签调用被攻击站点的一个JSON动态数据接口，并通过JavaScript Function Hook等技术取得这些JSON数据。如果用户登录被攻击网站后（假定其身份认证信息是基于Session Cookie来保存的），又被攻击者诱引访问了恶意站点页面，那么，由于&SCRIPTsrc=&&这种标签的请求会带上Cookie信息，恶意站点会发送JSON数据获取请求至被攻击站点，被攻击站点服务器会认为当前请求是合法的，并返回给恶意站点当前用户的相关JSON数据，从而导致用户数据泄密。整个过程相当于一个站外类型的跨站点请求伪造CSRF攻击。
　　随着Ajax的进一步推广，以及HTML5的逐步应用，还有更多的客户端安全漏洞出现。目前对于JavaScript的安全研究尚不多，新推出的HTML5客户端存储、跨域通信等新特型也都跟安全紧密相关，有兴趣的读者可以作进一步阅读。鉴于笔者知识有限，JavaScript相关安全漏洞暂且分享这么多，下面将谈谈JavaScript安全漏洞的检测技术。
　　自动化检测JavaScript安全漏洞
　　正如我们所熟知，检测代码安全漏洞一般有白盒检查和黑盒检查。白盒检查侧重于对代码的分析，可以通过手工代码审查，或者自动代码分析工具。黑盒检查主要是模拟黑客攻击的方式进行渗透测试。通常而言，黑盒检查的准确度高一些，但代码覆盖面比较小，而白盒检查的代码覆盖率较高，但误报率比较高。两种方式相结合能够互相弥补不足，混合检查方式将会是未来的趋势。
　　结合JavaScript代码而言，出于跨浏览器兼容、更好的Ajax特性需求等原因，越来越多的Web应用依赖于第三方的JavaScript代码库，譬如Dojo、JQuery等。这些代码库为了降低文件大小，往往都进行了代码压缩，导致其可读性极差，因此手工代码审查几乎不具备可行性。此外，页面JavaScript调用入口很多，手工对其进行渗透测试的工作量和难度都非常大。因此，我们需要推荐使用自动化测试工具来检测JavaScript安全漏洞。
　　Rational AppScan JSA原理简述
　　JSA是RationalAppScanStandardV8.0新推出的一项AppScan扩展，用来进行执行静态JavaScript分析，以检测常见客户端安全漏洞。JSA融合了JavaScript静态污点分析技术和网站动态爬虫技术。简而言之，AppScan会保存爬虫所探索到的所有URL的完整的HTTP响应，然后JSA对这些响应页面逐个进行JavaScript代码分析。JSA在分析每个页面时应用两个阶段：数据流分析和字符串分析。首先，JSA查找从源(Source)到接收器(Sink)中未经过清除工具(Sanitizer)的轨迹。如果可找到此轨迹(Trace)，那么JSA将在第二步中使用字符串分析的变体&&字符串前缀分析(SPA)进行验证。相比于单纯的JavaScript代码静态分析技术而言，JSA技术更为先进和准确，因为它是在完全解析好的HTML页面及DOM环境中进行安全漏洞分析。
　　如今Web2.0网站及Ajax应用中，HTML页面往往都需要浏览器基于服务器响应里的HTML和JavaScript代码进行动态解析后才形成完整的HTML和DOM，单纯基于服务器响应中的JavaScript代码进行静态污点分析存在一个明显缺陷--其所测JavaScript代码及执行环境不一定完整，因此它无法保证测试的准确度和全面性。JSA正是克服了以上缺点，融合了白盒检测和黑盒检测两种测试方法的优点，并引入IBM的字符串分析技术，所以JSA有着更好的准确性和全面性。　　利用AppScan检测JavaScript安全漏洞
　　AltoroMutual是IBM所提供的Web安全漏洞演示网站，下文笔者将向读者展示如何利用AppScan JSA来检测该网站所存在的JavaScript安全漏洞。
　　启动AppScan，点击菜单&扫描&扫描配置&打开扫描配置对话框，设置起始URL为&;。
　　▲图1.设置起始URL
　　在扫描配置对话框左侧，点击&登录管理&，然后点击右侧的&记录...&按钮录制登录过程，确保会话中检测处于活动状态。
　　▲图2.设置登录方法
　　在扫描配置对话框左侧，点击&测试策略&，检查测试策略设置。默认测试策略应该是&缺省&，其已经包含了常见JavaScript测试，可以点击&已启用/已禁止&查看当前默认启用的测试策略。
　　▲图3.检查测试策略
　　关闭扫描配置对话框，点击菜单&扫描--仅探索&或单击快捷按钮(如图4所示)启动探索。本文仅示例如何检测JavaScript安全漏洞，所以选择&仅探索&+客户端JavaScript分析的测试方式。
　　▲图4.启动探索
　　点击菜单&工具&扩展名&JavaScript Security Analyzer&或者快捷按钮(如图5所示)打开&分析JavaScript&。在弹出的JavaScript Security Analyzer对话框中，单击&立即分析&。
　　▲图5.分析JavaScript
　　JavaScriptSecurityAnalyzer扫描完成后，即在结果列表中列出所发现的客户端JavaScript安全漏洞。如下图所示，AltoroMutual站点存在&基于DOM的跨站点脚本编制&及&开放式重定向&漏洞，下文将展示这些漏洞的详细信息。
　　▲图6.查看扫描结果
　　展开结果列表中的&基于DOM的跨站点脚本编制&，单击第一个&JavaScript&问题，在下方的问题信息中将会展示其详细信息。我们可以看出，AppScan保存了对JavaScript问题代码的分析结果，并用黄色标识定位了源(Source)和接收器(Sink)，利于开发人员快速修复该漏洞。
　　▲图7.基于DOM的跨站点脚本编制问题信息
　　同样，展开并查看&开放式重定向&问题，在问题信息栏中展示了该漏洞的代码分析结果。
　　▲图8.开放式重定向问题信息
　　注意：
　　本文为了快速展示如何检测JavaScript安全漏洞，所以选择&仅探索&+客户端JavaScript分析的测试方式。实际工作中，建议您只需要跟通常一样进行扫描(即手工探索结合自动探索站点，然后执行测试)，AppScan默认会在测试过程中自动执行JavaScript Security Analyzer。
　　Rational AppScan Standard能检测已知常见JavaScript安全漏洞，但AltoroMutual仅展示了基于DOM的跨站脚本编制和重定向漏洞，故本案例的结果列表中仅包含上述两项安全漏洞。
&&&主编推荐
&&&热门试卷
&&&最新视频
&&&热门阅读
&&&最新问答
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&&&湘教QS2-164&&增值电信业务经营许可证湘B2-