当前位置：文档之家 › 防御XSS的七条原则

防御XSS的七条原则

  • 格式：ppt
  • 大小：72.00 KB
  • 文档页数：10

下载文档原格式

  / 10

合集下载

2021年软件评测师真题(含答案)

2021年软件评测师真题(含答案)

2021年软件评测师真题（含答案）（共20分）阅读下列C程序，回答问题1至问题3，将解答填入答题纸的对应栏内。

【C程序】int GetMaxDay( int year, int month){ int maxday=0；//1if( month=1month=12){ //2,3 if（month==2）{ //4 if( year%4==0){ //5 if（year?0==0){ //6 if( year@0==0) //7 maxday= 29; //8 else //9 maxday= 28; }else //10 maxday= 29; } elsemaxday = 28; //11 }else{ //12if (month=4||month=6||month=9||month=11) //13, 14,15,16 maxday = 30; //17 else //18 maxday = 31; } }return maxday; //19 }【问题1】（6分）请针对上述C程序给出满足100ü（判定覆盖）所需的逻辑条件。

【问题2】（9分）请画出上述程序的控制流图，并计算其环路复杂度V(G)。

【问题3】(5分)请给出问题2中控制流图的线性无关路径。

参考答案：【问题1】：Month=1month=12 Month==2 Year%4==0 Year?0==0 Year@0==0 Month==2 Month==4 Month==6 Month==9 Month==11 【问题2】：V（G）=11 【问题3】：1、2 1、2、31、2、3、4、12、13、17、19 1、2、3、4、12、13、14、17、19 1、2、3、4、12、13、14、15、17、19 1、2、3、4、12、13、14、15、16、17、19 1、2、3、4、12、13、14、15、16、18、19 1、2、3、4、5、11、191、2、3、4、5、6、10、19 1、2、3、4、5、6、7、9、19 1、2、3、4、5、6、7、8、19试题分析：判断覆盖：设计足够的测试用例，使得程序中的每个判定至少都获得一次“真值”或“假值”，或者说使得程序中的每一个取“真”分支和取“假”分支至少经历一次，因此判定覆盖又称分支覆盖对于本题中判定的条件有：Month=1month=12 Month==2 Year%4==0 Year?0==0 Year@0==0 Month==2 Month==4 Month==6 Month==9 Month==11 【问题2】控制流图是描述程序控制流的一种图示方法。

软件安全设计与开发测试题

软件安全设计与开发测试题

软件安全设计与开发测试题一、单选题1.对称密钥加密比非对称密钥加密（）。

A 速度慢B 速度相同C 速度快(正确答案)D 通常较慢2.下面关于验证码的使用错误的是（）。

A 必须使用带干扰的验证码B 使用多张图片的验证码，可以增加破解的难度(正确答案)C 用户信息与验证码验证必须在同一个请求提交给服务器D 验证码验证错误后应更新验证码3.关于XSS的说法错误的是（）。

A 全称为跨站脚本攻击B 通过HTML注入篡改网页，插入恶意脚本，控制用户浏览器的一种攻击行为C 分为反射型XSS和存储型XSSD 是一种基于服务器端的攻击脚本(正确答案)4.网站的安全协议是https时，该网站浏览时会进行（）处理。

A 增加访问标记B 加密(正确答案)C 身份验证D 口令验证5.防范XSS攻击的措施是（）。

A 应尽量手工输入URL地址(正确答案)B网站管理员应注重过滤特殊字符，限制输入长度，在代码层面上杜绝XSS漏洞出现的可能性C 不要随意点击别人留在论坛留言板里的链接D 不要打开来历不明的邮件、邮件附件、帖子等6.攻击者通过端口扫描，可以直接获得（）。

A 目标主机的口令B 给目标主机种植木马C 目标主机使用了什么配置的主机D 目标主机开放了哪些端口服务(正确答案)7.下列不属于Web应用带来的风险的是（）。

A SQL注入B XSS攻击C 上传漏洞D DOS攻击(正确答案)8.下列不属于OWASP top 10的是（）。

A 注入B 不安全的直接对象引用C 内存溢出(正确答案)D 敏感信息泄露9.下列不属于安全设计原则的是（）。

A 最小特权B 保护隐私C 不要相信外部输入D 默认信任(正确答案)10.应用开发过程中的安全不包括（）。

A 安全培训B 收集安全需求C 源代码审查D 安全发布(正确答案)11.下列哪个不是浏览器的安全特性（）。

A 同源策略B 浏览器沙箱C 恶意网址拦截D Cookie(正确答案)12.下列关于XSS说法错误的是（）。

前端开发中的网络安全防护措施

前端开发中的网络安全防护措施

前端开发中的网络安全防护措施在当今数字化时代，网络安全问题备受关注，各行各业都面临着来自网络的安全威胁。

对于前端开发人员来说，网络安全也是一个极其重要的问题。

在设计和开发应用程序时，我们需要采取一些关键的网络安全防护措施，以确保我们的应用程序及其用户数据的安全性。

本文将介绍一些前端开发中常用的网络安全防护措施。

1. 输入验证和过滤输入验证和过滤是前端开发中最基本的网络安全防护措施之一。

通过对用户输入的数据进行验证和过滤，我们能够防止一些常见的攻击，如跨站脚本（XSS）和SQL注入。

前端开发人员应该始终对用户输入的数据进行验证，确保其符合预期的格式和内容，并对可能的恶意输入进行过滤，确保应用程序不会受到攻击。

2. 安全的数据传输在网络应用程序中，安全的数据传输是非常重要的。

HTTPS协议通过使用加密技术来保护数据在传输过程中的安全性。

前端开发人员应该使用HTTPS协议来保护敏感信息的传输，如用户登录凭据和支付信息。

此外，还可以使用其他的加密技术，如SSL证书和双因素身份验证，以进一步提高数据的安全性。

3. 跨站脚本（XSS）攻击防范跨站脚本（XSS）攻击是前端开发中常见的安全威胁之一。

开发人员可以采取一些措施来防范XSS攻击，如对输入数据进行过滤和转义，使用CSP（内容安全策略）来限制页面加载的外部资源，以及对敏感信息使用安全的Cookie设置。

4. 防止跨站请求伪造（CSRF）攻击跨站请求伪造（CSRF）攻击是指攻击者利用用户的登录状态发送恶意请求，达到在用户不知情的情况下执行对应用程序的操作。

前端开发人员可以通过实施一些防范措施来抵御CSRF攻击，如使用token验证、添加验证码和设置同源策略。

5. 安全的密码存储与验证对于用户密码的存储与验证，前端开发人员应该采取一些安全措施。

应该使用散列哈希函数来存储密码，以确保即使数据库泄漏，攻击者也无法直接获得用户的密码。

另外，还可以使用密码复杂性检查和限制登录尝试次数等措施来提高密码的安全性。

web安全基础试题及答案

web安全基础试题及答案

web安全基础试题及答案一、选择题1. Web安全的主要目标是：a) 保护用户的个人隐私b) 防止恶意攻击者入侵系统c) 提高网站的性能和可用性d) 阻止未经授权的访问和数据泄露答案：d) 阻止未经授权的访问和数据泄露2. SQL注入攻击是通过在用户输入数据中插入恶意的SQL语句来实现的。

以下哪个选项可以有效防止SQL注入攻击？a) 输入验证和过滤b) 使用加密技术c) 实施访问控制d) 配置防火墙答案：a) 输入验证和过滤3. 跨站脚本攻击（XSS）是一种利用网站漏洞进行恶意代码注入的攻击方式。

以下哪个选项可以有效防止XSS攻击？a) 使用加密技术b) 对用户输入进行验证和过滤c) 使用防火墙d) 实施访问控制答案：b) 对用户输入进行验证和过滤4. 常见的密码攻击方式包括以下哪些？a) 字典攻击b) SQL注入攻击c) 重放攻击d) 跨站脚本攻击答案：a) 字典攻击5. 以下哪项措施可以帮助保护Web应用程序免受跨站点请求伪造（CSRF）攻击？a) 使用加密技术b) 实施访问控制c) 应用程序补丁更新d) 验证和过滤用户输入答案：b) 实施访问控制二、简答题1. 什么是会话劫持（Session Hijacking）？如何防止会话劫持？答：会话劫持是指攻击者通过获取合法用户的会话凭证（如Cookie）来冒充合法用户进行恶意操作的行为。

要防止会话劫持，可以使用以下措施：- 使用加密技术对会话数据进行保护，如使用HTTPS协议传输数据。

- 使用长而随机的会话标识符，并在会话中使用验证码等安全机制进行验证用户身份。

- 定期更新会话凭证，使攻击者难以获取有效的会话信息。

- 在服务器端实施严格的访问控制，限制每个会话的操作范围。

2. 什么是跨站点脚本攻击（Cross-Site Scripting，XSS）？如何防止XSS攻击？答：跨站点脚本攻击是指攻击者通过在目标网站上注入恶意代码，使其在用户浏览器上执行的安全漏洞。

waf url过滤规则表

waf url过滤规则表

waf url过滤规则表全文共四篇示例，供读者参考第一篇示例：WAF URL过滤规则表是Web应用防火墙（Web Application Firewall）中的一种规则表，用于过滤和阻止恶意URL请求。

它是网络安全的重要组成部分，旨在保护网站和Web应用免受各种网络攻击，如SQL注入、跨站脚本（XSS）、文件包含等。

WAF URL过滤规则表通常包含了一系列规则，用于识别和拦截恶意URL请求。

这些规则可以根据特定的攻击模式和行为特征来设定，帮助防火墙及时发现和阻止恶意请求，保护Web应用的安全。

下面是一份简单的WAF URL过滤规则表示例：1. SQL注入规则：检测URL中是否含有SQL注入关键词，如SELECT、INSERT、UPDATE、DELETE等，如果发现则拦截该请求。

2. XSS规则：检测URL中是否含有跨站脚本（XSS）攻击的脚本代码，如<script>、%3Cscript%3E等，如果发现则阻止该请求。

3. 文件包含规则：检测URL中是否含有文件包含漏洞的特征，如../、%2E%2E%2F等，如果发现则拦截请求。

4. CSRF规则：检测URL中是否含有跨站请求伪造（CSRF）攻击的特征，如csrf_token=、csrf=等，及时拦截恶意请求。

5. 目录遍历规则：检测URL中是否存在目录遍历攻击的迹象，如../、%2E%2E%2F等，及时进行阻止。

6. 恶意文件下载规则：检测URL中是否含有恶意文件下载的特征，如.down、file=等，拦截可能的恶意下载请求。

7. 攻击脚本规则：检测URL中是否含有常见的攻击脚本名称或后缀，如.php、.asp、.cgi等，对可能的攻击行为进行拦截。

以上是一些常见的WAF URL过滤规则示例，实际的规则表还可以根据具体的需求和Web应用的特点进行定制设置。

通过合理设置WAF URL过滤规则表，可以有效防范和抵御各种网络攻击，确保Web应用的安全性和稳定性。

XSS跨站脚本攻击技术原理及防护措施

XSS跨站脚本攻击技术原理及防护措施

XSS跨站脚本攻击技术原理及防护措施2010年07月12日星期一 1:08 P.M.发表：红科网安作者：Amxking发布时间：2010-06-23摘要：本文作者Amxking通过对xss跨站脚本攻击漏洞的历史、攻击特点、攻击原理描述及案例代码实战举例详细解析XSS漏洞攻击技术，并提出防御XSS跨站漏洞的思路方法。

及WEB开发者开发网站过程中防范编码中产生xss跨站脚本攻击漏洞需要注意的事项。

XSS漏洞概述：XSS(Cross Site Script)跨站点脚本攻击是一种注射的问题，在这种恶意脚本注入否则良性和信任的网站类型。

跨站点脚本（XSS）攻击，攻击者使用时，会出现一个网络应用程序发送恶意代码，一般是在浏览器端脚本的形式，向不同的最终用户。

这些缺陷，使攻击成功是相当普遍，发生在任何地方从一个Web应用程序使用在输出它没有验证或编码了用户输入。

攻击者可以使用XSS的恶意脚本发送到一个毫无戒心的用户。

最终用户的浏览有没有办法知道该脚本不应该信任，将执行该脚本。

因为它认为该脚本来从一个受信任的源，恶意脚本可以访问任何Cookie，会话令牌，或其他敏感信息的浏览器保留，并与该网站使用。

甚至可以重写这些脚本的HTML网页的内容。

XSS漏洞历史：XSS(Cross-site scripting)漏洞最早可以追溯到1996年，那时电子商务才刚刚起步，估计那时候国内很少人会想象到今天出现的几个国内电子商务巨头淘宝、当当、亚马逊（卓越）。

XSS的出现“得益”于JavaScript的出现，JavaScript的出现给网页的设计带来了无限惊喜，包括今天风行的AJAX(Asynschronous JavaScript and XML)。

同时，这些元素又无限的扩充了今天的网络安全领域。

XSS 漏洞攻击特点：（1）XSS跨站漏洞种类多样人：XSS攻击语句可插入到、URL地址参数后面、输入框内、img标签及DIV标签等HTML函数的属人里、Flash的getURL()动作等地方都会触发XSS漏洞。

网络安全面试题及答案

网络安全面试题及答案1. 简述密码破解的常见方法。

密码破解的常见方法包括暴力破解、字典攻击和社交工程等。

- 暴力破解：通过尝试所有可能的密码组合来破解密码，属于最原始的手段。

暴力破解方法的成功与否取决于所破解密码的长度和复杂程度。

- 字典攻击：使用预先准备好的密码字典，包含常见密码、常用词语和常见组合，尝试这些字典中的每一个密码来破解密码。

字典攻击方法可以节省暴力破解所需的时间。

- 社交工程：通过欺骗、操纵或诱导目标用户透露密码信息。

攻击者可能通过冒充他人身份、发送诈骗邮件或制造紧急情况等手段进行攻击。

2. 什么是XSS攻击？如何防范XSS攻击？XSS（Cross-Site Scripting）攻击是指攻击者通过在网页中嵌入恶意脚本，然后将脚本传输给受害者，当受害者访问该页面时，恶意脚本将在受害者浏览器中执行，使攻击者能够窃取受害者的敏感信息或进行其他恶意行为。

防范XSS攻击的方法包括：- 输入验证和过滤：对用户输入的数据进行严格验证和过滤，确保输入的内容符合预期格式，避免执行恶意脚本；- 输出编码：在输出用户数据到页面之前，对数据进行适当的编码，将特殊字符转换为对应的HTML实体，以防止恶意脚本执行；- 使用CSP（Content Security Policy）：CSP是一种安全策略，通过限制网页中可以加载和执行的内容来源，来减少XSS攻击的风险；- 设置HttpOnly标志：将Cookie标记为HttpOnly，这样浏览器将禁止通过脚本访问这些Cookie，减少XSS攻击的影响。

3. 什么是DDoS攻击？如何应对DDoS攻击？DDoS（Distributed Denial of Service）攻击是一种通过将大量的请求发送到目标服务器，以消耗其网络带宽、服务器资源或其它资源的攻击行为，目的是使目标系统无法正常提供服务。

应对DDoS攻击的方法包括：- 流量清洗：将流量引导到专门的DDoS防护设备来过滤和分析流量，识别出恶意流量并将其清洗掉，确保正常流量可以到达目标服务器。

XSS防御方法总结

梳理： （1）移除用户上传的DOM属性，如onerror等
（2）移除用户上传的style节点，script节点，iframe节点等 （3）对用户输入的代码标签进行转换（html encode、回显decode） （4）对url中的参数进行过滤 （5）对动态输出到页面的内容进行HTML编码 （6）服务端对敏感的Cookie设置 httpOnly属性，使js脚本不能读取到cookie （7）CSP 即是 Content Security Policy
（8）nginx naxsi换页符等等使用s表示
XSS防御方法总结
转自：
关闭浏览器xss拦截：
正则：匹配任何不可见字符，包括空格、制表符、换页符等等 使用\s表示。
（1）转字符转义在客户端或者服务端做都行。 （2）反转义 （3）domparse 去掉一些标签以及属性，以及完成dom配对和校验

SQL注入及XSS攻击防御

SQL注入及XSS （跨站脚本）攻击防御技术SQL注入一、什么是SQL注入SQL注入：利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，这是SQL注入的标准释义。

SQL注入利用的是正常的HTTP服务端口，表面上看来和正常的web访问没有区别，隐蔽性极强，不易被发现。

二、SQL注入的危害SQL注入的主要危害包括：1、未经授权状况下操作数据中的数据2、恶意篡改网页内容3、私自添加系统账号或是数据库使用者账号4、网页挂木马。

三、SQL注入的方法1. 没有正确过滤转义字符在用户的输入没有为转义字符过滤时，就会发生这种形式的注入式攻击，它会被传递给一个SQL 语句。

这样就会导致应用程序的终端用户对数据库上的语句实施操纵比方说，下面的这行代码就会演示这种漏洞：statement := "SELECT * FROM users WHERE name = '" + userName + "';"这种代码的设计目的是将一个特定的用户从其用户表中取出，但是，如果用户名被一个恶意的用户用一种特定的方式伪造，这个语句所执行的操作可能就不仅仅是代码的作者所期望的那样了。

例如，将用户名变量（即username）设置为：a' or 't'='t ,此时原始语句发生了变化：SELECT * FROM users WHERE name = 'a' OR 't'='t';如果这种代码被用于一个认证过程，那么这个例子就能够强迫选择一个合法的用户名，因为赋值't'='t 永远是正确的。

在一些SQL服务器上，如在SQL Server中，任何一个SQL命令都可以通过这种方法被注入，包括执行多个语句。

下面语句中的username的值将会导致删除"users "表，又可以从“ data ”表中选择所有的数据（实际上就是透露了每一个用户的信息）。

确保代码安全的基本原则

确保代码安全的基本原则随着信息技术的快速发展，代码安全已经成为一个非常重要的话题。

无论是个人开发者还是大型企业，都需要意识到代码安全的重要性，并采取适当的措施来保护代码的安全性。

本文将介绍一些基本的原则，以确保代码的安全。

1. 避免输出http地址在代码中，尽量避免直接输出http地址。

这样做可能会导致敏感信息泄露，例如数据库连接字符串、API密钥等。

应该使用配置文件或环境变量等安全的方式来存储和获取这些敏感信息。

2. 不要输出公式在部分应用场景中，可能会涉及到公式的计算和输出。

然而，直接将公式输出到前端可能会导致安全问题，例如XSS攻击。

为了确保代码的安全，应该对公式进行适当的处理和过滤，确保输出的内容安全可靠。

3. 避免内容重复在代码中，避免出现重复的内容是一个重要的原则。

重复的代码可能会导致维护困难、增加漏洞的风险，并且浪费了代码资源。

应该通过抽取公共函数、使用循环等方式来避免代码的重复。

4. 规范整洁的格式为了提高代码的可读性和可维护性，应该保持整洁的代码格式。

可以使用缩进、空行、注释等方式来使代码结构清晰、易于阅读。

此外，还应该遵循编码规范，统一命名规则、函数调用方式等，以减少潜在的安全隐患。

5. 避免使用图片链接在代码中，避免使用图片链接是一个重要的安全原则。

图片链接可能会导致跨站脚本攻击（XSS）或者其他安全漏洞。

为了确保代码的安全，应该使用安全的方式来处理图片，例如将图片转换为base64编码或者使用CDN等。

6. 避免如图所示在代码中，避免使用“如图所示”这样的描述是一个基本原则。

这样的描述通常是不准确的，会给代码的理解和维护带来困难。

应该通过准确的文字描述或者注释来解释代码的逻辑和功能。

7. 避免重复问题在代码中，避免出现重复的问题是一个重要的原则。

重复的问题可能会导致代码的错误或者安全漏洞。

为了确保代码的安全性，应该仔细审查代码，排除重复的问题，并进行相应的修复。

8. 不要自我介绍在代码中，不要出现不必要的自我介绍。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

•
•
原则2：在将不可信数据插入到HTML标签之间时，对这些 数据进行HTML Entity编码
• 在这里相当强调是往HTML标签之间插入不可信数据，以区别于往HTML标签属性部分插入不可信 数据，因为这两者需要进行不同类型的编码。当你确实需要往HTML标签之间插入不可信数据的时 候，首先要做的就是对不可信数据进行HTML Entity编码。比如，我们经常需要往DIV，P，TD这 些标签里放入一些用户提交的数据，这些数据是不可信的，需要对它们进行HTML Entity编码。很 多Web框架都提供了HTML Entity编码的函数，我们只需要调用这些函数就好，而有些Web框架 似乎更“智能”，比如Rails，它能在默认情况下对所有插入到HTML页面的数据进行HTML Entity 编码，尽管不能完全防御XSS，但着实减轻了开发人员的负担。 <body>…插入不可信数据前，对其进行HTML Entity编码…</body><div>…插入不可信数据 前，对其进行HTML Entity编码…</div><p>…插入不可信数据前，对其进行HTML Entity编 码…</p> 以此类推，往其他HTML标签之间插入不可信数据前，对其进行HTML Entity编码[编 码规则] 那么HTML Entity编码具体应该做哪些事情呢？它需要对下面这6个特殊字符进行编码： & –> &amp; < –> &lt; > –> &gt; ” –> &quot; „ –> &#x27; / –> &#x2f;有两点需要特别 说明的是: 不推荐将单引号( „ )编码为 &apos; 因为它并不是标准的HTML标签 需要对斜杠号( / )编码，因为在进行XSS攻击时，斜杠号对于关闭当前HTML标签非常有用 推荐使用OWASP提供的ESAPI函数库，它提供了一系列非常严格的用于进行各种安全编码的函数。 在当前这个例子里，你可以使用: String encodedContent = ESAPI.encoder().encodeForHTML(request.getParameter(“input”));
•
•
原则1：不要在页面中插入任何不可信数据，除非这些数已 经据根据下面几个原则进行了编码
• • 第一条原则其实是“Secure By Default”原则：不要往HTML页面中插入任何不可信 数据，除非这些数据已经根据下面几条原则进行了编码。 之所以有这样一条原则存在，是因为HTML里有太多的地方容易形成XSS漏洞，而且形 成漏洞的原因又有差别，比如有些漏洞发生在HTML标签里，有些发生在HTML标签的 属性里，还有的发生在页面的<Script>里，甚至有些还出现在CSS里，再加上不同的 浏览器对页面的解析或多或少有些不同，使得有些漏洞只在特定浏览器里才会产生。 如果想要通过XSS过滤器（XSS Filter）对不可信数据进行转义或替换，那么XSS过 滤器的过滤规则将会变得异常复杂，难以维护而且会有被绕过的风险。 所以实在想不出有什么理由要直接往HTML页面里插入不可信数据，就算是有XSS过滤 器帮你做过滤，产生XSS漏洞的风险还是很高 <script>…不要在这里直接插入不可信数据…</script>直接插入到SCRIPT标签里 <!– …不要在这里直接插入不可信数据… –> 插入到HTML注释里 <div 不要在这里 直接插入不可信数据=”…”></div> 插入到HTML标签的属性名里 <div name=”… 不要在这里直接插入不可信数据…”></div> 插入到HTML标签的属性值里 <不要在 这里直接插入不可信数据 href=”…”></a> 作为HTML标签的名字 <style>…不要在 这里直接插入不可信数据…</style> 直接插入到CSS里最重要的是，千万不要引入任 何不可信的第三方JavaScript到页面里，一旦引入了，这些脚本就能够操纵你的 HTML页面，窃取敏感信息或者发起钓鱼攻击等等。
防御XSS的七条原则
前言
• • 本文将会着重介绍防御XSS攻击的一些原则，需要读者对于XSS有所了解，至少知道 XSS漏洞的基本原理，如果您对此不是特别清楚，请参考这两篇文章：《Stored and Reflected XSS Attack》《DOM Based XSS》 攻击者可以利用XSS漏洞向用户发送攻击脚本，而用户的浏览器因为没有办法知道这 段脚本是不可信的，所以依然会执行它。对于浏览器而言，它认为这段脚本是来自可 以信任的服务器的，所以脚本可以光明正大地访问Cookie，或者保存在浏览器里被当 前网站所用的敏感信息，甚至可以知道用户电脑安装了哪些软件。这些脚本还可以改 写HTML页面，进行钓鱼攻击。 虽然产生XSS漏洞的原因各种各样，对于漏洞的利用也是花样百出，但是如果我们遵 循本文提到防御原则，我们依然可以做到防止XSS攻击的发生。 有人可能会问，防御XSS的核心不就是在输出不可信数据的时候进行编码，而现如今 流行的Web框架（比如Rails）大多都在默认情况下就对不可信数据进行了HTML编码， 帮我们做了防御，还用得着我们自己再花时间研究如何防御XSS吗？答案是肯定的， 对于将要放置到HTML页面body里的不可信数据，进行HTML编码已经足够防御XSS 攻击了，甚至将HTML编码后的数据放到HTML标签（TAG）的属性（attribute）里 也不会产生XSS漏洞（但前提是这些属性都正确使用了引号），但是，如果你将HTML 编码后的数据放到了<SCRIPT>标签里的任何地方，甚至是HTML标签的事件处理属 性里（如onmouseover），又或者是放到了CSS、URL里，XSS攻击依然会发生， 在这种情况下，HTML编码不起作用了。所以就算你到处使用了HTML编码，XSS漏洞 依然可能存在。下面这几条规则就将告诉你，如何在正确的地方使用正确的编码来消 除XSS漏洞。
原则4：在将不可信数据插入到SCRIPT里时，对这些 数据进行SCRIPT编码 • 这条原则主要针对动态生成的JavaScript代码，这包括脚本部分以及HTML标签的事件处理属性（Event
• • • • •
• •
• • • • •
Handler，如onmouseover, onload等）。在往JavaScript代码里插入数据的时候，只有一种情况是安全 的，那就是对不可信数据进行JavaScript编码，并且只把这些数据放到使用引号包围起来的值部分（data value）之中，例如： <script> var message = “<%= encodeJavaScript(@INPUT) %>”; </script> 除此之外，往JavaScript代码里其他任何地方插入不可信数据都是相当危险的，攻击者可以很容易地插入攻 击代码。 <script>alert(„…插入不可信数据前，进行JavaScript编码…‟)</script>值部分使用了单引号 <script>x = “…插入不可信数据前，进行JavaScript编码…”</script> 值部分使用了双引号 <div onmouseover=”x=‟…插入不可信数据前，进行JavaScript编码…‟ “</div> 值部分使用了引号，且事件 处理属性的值部分也使用了引号 特别需要注意的是，在XSS防御中，有些JavaScript函数是极度危险的， 就算对不可信数据进行JavaScript编码，也依然会产生XSS漏洞，例如： <script> window.setInterval(„…就算对不可信数据进行了JavaScript编码，这里依然会有XSS漏洞…‟); </script>[编码规则] 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式 为 \xHH （以 \x 开头，HH则是指该字符对应的十六进制数字） 在对不可信数据做编码的时候，千万不能图方便使用反斜杠（ \ ）对特殊字符进行简单转义，比如将双引号 ” 转义成 \” ，这样做是不可靠的，因为浏览器在对页面做解析的时候，会先进行HTML解析，然后才是 JavaScript解析，所以双引号很可能会被当做HTML字符进行HTML解析，这时双引号就可以突破代码的值 部分，使得攻击者可以继续进行XSS攻击。例如： 假设代码片段如下： <script> var message = ” $VAR “; </script>攻击者输入的内容为： \”; alert(„xss‟);//如果只是对双引号进行简单转义，将其替换成 \” 的话，攻击者输入的内容在最终的页面 上会变成： <script> var message = ” \\”; alert(„xss‟);// “; </script>浏览器在解析的时候，会认为反斜杠后面的 那个双引号和第一个双引号相匹配，继而认为后续的alert(„xss‟)是正常的JavaScript脚本，因此允许执行。 可以使用ESAPI提供的函数进行JavaScript编码： String encodedContent = ESAPI.encoder().encodeForJavaScript(request.getParameter(“input”));
•
• • • • • •
原则3：在将不可信数据插入到HTML属性里时，对这些数 据进行HTML属性编码
• • • • • • • • • • • • • • • • 这条原则是指，当你要往HTML属性（例如width、name、value属性）的值部分(data value)插入不可信数据的 时候，应该对数据进行HTML属性编码。不过需要注意的是，当要往HTML标签的事件处理属性（例如 onmouseover）里插入数据的时候，本条原则不适用，应该用下面介绍的原则4对其进行JavaScript编码。 <div attr=…插入不可信数据前，进行HTML属性编码…></div>属性值部分没有使用引号，不推荐 <div attr=‟…插入不可信数据前，进行HTML属性编码…‟></div> 属性值部分使用了单引号 <div attr=”…插入不可 信数据前，进行HTML属性编码…”></div> 属性值部分使用了双引号[编码规则] 除了阿拉伯数字和字母，对其他所有的字符进行编码，只要该字符的ASCII码小于256。编码后输出的格式为 &#xHH; （以&#x开头，HH则是指该字符对应的十六进制数字，分号作为结束符） 之所以编码规则如此严格，是因为开发者有时会忘记给属性的值部分加上引号。如果属性值部分没有使用引号的话， 攻击者很容易就能闭合掉当前属性，随后即可插入攻击脚本。例如，如果属性没有使用引号，又没有对数据进行严 格编码，那么一个空格符就可以闭合掉当前属性。请看下面这个攻击： 假设HTML代码是这样的： <div width=$INPUT> …content… </div> 攻击者可以构造这样的输入： x onmouseover=”javascript:alert(/xss/)” 最后，在用户的浏览器里的最终HTML代码会变成这个样子： <div width=x onmouseover=”javascript:alert(/xss/)”> …content… </div> 只要用户的鼠标移动到这个DIV上，就会触发攻击者写好的攻击脚本。在这个例子里，脚本仅仅弹出一个警告框， 除了恶作剧一下也没有太多的危害，但是在真实的攻击中，攻击者会使用更加具有破坏力的脚本，例如下面这个窃 取用户cookie的XSS攻击： x /> <script>var img = document.createElement(“img”);img.src = ”/xss.js?” + escape(document.cookie);document.body.appendChild(img);</script> <div 除了空格符可以闭合当前属性外，这些符号也可以： % * + , – / ; < = > ^ | `(反单引号，IE会认为它是单引号) 可以使用ESAPI提供的函数进行HTML属性编码： String encodedContent = ESAPI.encoder().encodeForHTMLAttribute(request.getParameter(“input”));