安全评测解决方案与代码编写规范.docx

安全评测解决方案与代码编写规范.docx

《安全评测解决方案与代码编写规范.docx》由会员分享，可在线阅读，更多相关《安全评测解决方案与代码编写规范.docx（30页珍藏版）》请在冰豆网上搜索。

安全评测解决方案与代码编写规范

WEB安全评测解决方案

与代码编写规范

北京恒华伟业科技股份有限公司

2013年10月

目录

1Xss注入简介2

1.1一个简单的例子2

1.2网上的xss讲解3

2防御xss的七条原则9

2.1前言9

2.2原则1：

不要在页面中插入任何不可信数据，除非这些数已经据根据下面几个原则进行了编码10

2.3原则2：

在将不可信数据插入到HTML标签之间时，对这些数据进行HTMLEntity编码11

2.4原则3：

在将不可信数据插入到HTML属性里时，对这些数据进行HTML属性编码12

2.5原则4：

在将不可信数据插入到SCRIPT里时，对这些数据进行SCRIPT编码14

2.6原则5：

在将不可信数据插入到Style属性里时，对这些数据进行CSS编码16

2.7原则6：

在将不可信数据插入到HTMLURL里时，对这些数据进行URL编码17

2.8原则7：

使用富文本时，使用XSS规则引擎进行编码过滤18

3项目中防御xss的具体措施21

3.1在jsp中的输出防御21

3.1.1stuts标签输出防御21

3.1.2Esapi标签输出防御21

3.1.3Java输出代码防御通过<%=temp%>的方式22

4防御url中的xss代码注入攻击办法23

5控制通过输入非登录页的url进入系统功能24

5.1.1Referer验证过滤器24

5.1.2window.open和window.location.href=特殊处理24

6系统日志组件的调用方法25

6.1.1方法一:

直接调用25

6.1.2方法二通过Annotation25

1Xss注入简介

1.1一个简单的例子

先看下现在frp登录页面的xss注入漏洞

先打开系统登录页

http:

//192.168.2.99:

8080/scmm/

然后在系统用户名中文本框中输入

1,xss:

*/-->'">;

密码为1

点击登录按钮，则出现如下界面

原因是系统验证用户名失败后，重新跳转到login.jsp

而login.jsp中通过${userCode}的方式对userCode变量进行了直接的页面输出，从而执行了不安全的脚本，正确的方式使应当对userCode进行字符编码转换后再进行输出，具体的编码转换输出方式，请参照第三章节

再比如在一个博客添加页面blogAdd.jsp中

有一个form表单

Form表单提交后跳转到blogInfo.jsp

如果在js中使用blog.subject

如果我在from表单中blog.subject文本框中输入

“varmyiframe=document.createElement（“iframe”）;

myiframe.style.height=”100px;”;myiframe.style.width=”100px;”

myiframe.src=””;

document.getElementsByTagName（‘body’）[0].appendChild（myiframe）;

则会成功在你的网站上显示出一个XX的页面，使用类似的代码可以实现网站钓鱼功能

例如创建一个支付页面，引诱你把账号和密码输入到钓鱼网站中

正确的做法是对用户输入blog.subject文本框中的值进行非法字符过滤后再保存到数据库或者在对blog.subject的字段值进行输出的时候进行字符转换

转换方式是将

VarblogSubject=”

propertyvalue=”blog.subject”/>”;

修改为

VarblogSubject=”

propertyvalue=”blog.subject”escapeJavaScript="true"/>”;

因为struts的property标签默认只对输出的值进行html过滤,而不对javaScript进行过滤

1.2网上的xss讲解

XSS漏洞概述：

XSS（CrossSiteScript）跨站点脚本攻击是一种注射的问题，在这种恶意脚本注入否则良性和信任的网站类型。

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

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

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

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

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

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

XSS漏洞历史：

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

XSS的出现“得益”于JavaScript的出现，JavaScript的出现给网页的设计带来了无限惊喜，包括今天风行的AJAX（AsynschronousJavaScriptandXML）。

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

XSS漏洞攻击特点：

（1）XSS跨站漏洞种类多样人：

XSS攻击语句可插入到、URL地址参数后面、输入框内、img标签及DIV标签等HTML函数的属人里、Flash的getURL（）动作等地方都会触发XSS漏洞。

（2）XSS跨站漏洞代码多样人：

为了躲避转义HTML特殊字符函数及过滤函数的过滤，XSS跨站的代码使用“/”来代替安字符“””、使用Tab键代替空格、部分语句转找成16进制、添加特殊字符、改变大小写及使用空格等来绕过过滤函数。

如果在您的新闻系统发现安全漏洞，如果该漏洞是一个SQL注入漏洞，那么该漏洞就会得到您的网站管理员密码、可以在主机系统上执行shell命令、对数据库添加、删除数据。

如果在您的新闻或邮件系统中发现安全漏洞，如果该漏洞是一个XSS跨站漏洞，那么可以构造一些特殊代码，只要你访问的页面包含了构造的特殊代码，您的主机可能就会执行木马程序、执行^***Cookies代码、突然转到一个银行及其它金融类的网站、泄露您的网银及其它账号与密码等。

XSS攻击原理：

XSS属于被动式的攻击。

攻击者先构造一个跨站页面，利用script、、

hellov=newActiveXObject（"MSXML2.XMLHTTP.3.0"）;v.

open（"GET",":

8080/testxss/doadmin.jsp?

v=hacked4"）;v.send（）;alert（v.status

Text）;

以普通用户身份修改uservalue为以上任何一个，当admin浏览index.jsp时，即可悄无声息的修改adminvalue

这里演示了3种跨站手法:

1是利用img、iframe等tag直接发起请求，这适用于无法直接出script的情况，其中是一个redirect，指向

:

8080/testxss/doadmin.jsp?

v=hacked2；

2是用script提交post表单；

3是ajax技术。

以上攻击能够成功有2个原因：

1.应用程序没有对uservalue做足够多的过滤，导致用户有机会构造一个复杂的跨站语句来触发admin的非预期行为；

2.应用程序在响应adminvalue修改请求时没有防范措施来识别这是不是出于用户主动。

漏洞1很容易修复，只要像防止SQLInjection那样对用户输入的所有内容都过滤即可。

漏洞2才是问题的根源，即便我们修补了漏洞1，只要诱使admin用户访问包含的页面，仍然能达到目的，而这是一件极容易

做到的事。

防范措施：

这里给出一些防范XSS攻击的措施。

必须说明的是，对于XSS攻击，并不像SQLInjection那样可以有一劳永逸的解决方案——只需要grep一下所有的sql调用。

这是一

场长期的斗争，而且往往需要我们采取修改业务流程、产品设计等看似削足适履的手段。

先总结一下常见的攻击手法：

1.依赖跨站漏洞，需要在被攻击网站的页面种入脚本的手法

1.1.Cookie盗取，通过javascript获取被攻击网站种下的cookie，并发送给攻击者。

1.1.1.从cookie中提取密码等隐私

1.1.2.利用cookie伪造session，发起重放攻击

1.2.Ajex信息盗取，通过javascript发起ajex请求。

1.2.1.从ajex结果中获取隐私。

1.2.2.模拟用户完成多页表单。

2.不依赖跨站漏洞的手法

2.1.单向HTTP动作，通过img.src等方法发起跨站访问，冒充被攻击者执行特权操作。

但是很难拿到服务器的返回值。

2.2.双向HTTP动作，如果服务器产生一段动态的script，那么可以用script.src的方法发起跨站访问并拿到服务器的返回值。

防范手法如下：

1.防堵跨站漏洞，阻止攻击者利用在被攻击网站上发布跨站攻击语句不可以信任用户提交的任何内容，首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把htmltag弄出来。

这一个层面做好，至少可以堵住超过一半的XSS攻击。

2.Cookie防盗

首先避免直接在cookie中泄露用户隐私，例如email、密码等等。

其次通过使cookie和系统ip绑定来降低cookie泄露后的危险。

这样攻击者得到的cookie没有实际价值，不可能拿来重放。

3.尽量采用POST而非GET提交表单

POST操作不可能绕开javascript的使用，这会给攻击者增加难度，减少可利用的

跨站漏洞。

4.严格检查refer

检查httprefer是否来自预料中的url。

这可以阻止第2类攻击手法发起的http请求，也能防止大部分第1类攻击手法，除非正好在特权操作的引用页上种了跨站访问。

5.将单步流程改为多步，在多步流程中引入效验码

多步流程中每一步都产生一个验证码作为hidden表单元素嵌在中间页面，下一步操作时这个验证码被提交到服务器，服务器检查这个验证码是否匹配。

首先这为第1类攻击者大大增加了麻烦。

其次攻击者必须在多步流程中拿到上一步产生的效验码才有可能发起下一步请求，这在第2类攻击中是几乎无法做到的。

6.引入用户交互

简单的一个看图识数可以堵住几乎所有的非预期特权操作。

7.只在允许anonymous访问的地方使用动态的javascript。

8.对于用户提交信息的中的img等link，检查是否有重定向回本站、不是真的图片等

可疑操作。

9.内部管理网站的问题

很多时候，内部管理网站往往疏于关注安全问题，只是简单的限制访问来源。

这种网站往往对XSS攻击毫无抵抗力，需要多加注意。

安全问题需要长期的关注，从来不是一锤子买卖。

XSS攻击相对其他攻击手段更加隐蔽和多变，和业务流程、代码实现都有关系，不存在什么一劳永逸的解决方案。

此外，面对XSS，往往要牺牲产品的便利性才能保证完全的安全，如何在安全和便利之间平衡也是一件需要考虑的事情。

web应用开发者注意事项：

　　1.对于开发者，首先应该把精力放到对所有用户提交内容进行可靠的输入验证上。

这些提交内容包括URL、查询关键

字、http头、post数据等。

只接受在你所规定长度范围内、采用适当格式、你所希望的字符。

阻塞、过滤或者忽略其它的

任何东西。

　　2.保护所有敏感的功能，以防被bots自动化或者被第三方网站所执行。

实现session标记（sessiontokens）、

CAPTCHA系统或者HTTP引用头检查。

　　3.如果你的web应用必须支持用户提供的HTML，那么应用的安全性将受到灾难性的下滑。

但是你还是可以做一些事来

保护web站点：

确认你接收的HTML内容被妥善地格式化，仅包含最小化的、安全的tag（绝对没有JavaScript），去掉任何

对远程内容的引用（尤其是样式表和JavaScript）。

为了更多的安全，请使用httpOnly的cookie。

2防御xss的七条原则

2.1 前言

本章节将会着重介绍防御XSS攻击的一些原则，需要读者对于XSS有所了解，至少知道XSS漏洞的基本原理，如果您对此不是特别清楚，请参考这两篇文章：

《StoredandReflectedXSSAttack》《DOMBasedXSS》

攻击者可以利用XSS漏洞向用户发送攻击脚本，而用户的浏览器因为没有办法知道这段脚本是不可信的，所以依然会执行它。

对于浏览器而言，它认为这段脚本是来自可以信任的服务器的，所以脚本可以光明正大地访问Cookie，或者保存在浏览器里被当前网站所用的敏感信息，甚至可以知道用户电脑安装了哪些软件。

这些脚本还可以改写HTML页面，进行钓鱼攻击。

虽然产生XSS漏洞的原因各种各样，对于漏洞的利用也是花样百出，但是如果我们遵循本文提到防御原则，我们依然可以做到防止XSS攻击的发生。

有人可能会问，防御XSS的核心不就是在输出不可信数据的时候进行编码，而现如今流行的Web框架（比如Rails）大多都在默认情况下就对不可信数据进行了HTML编码，帮我们做了防御，还用得着我们自己再花时间研究如何防御XSS吗？

答案是肯定的，对于将要放置到HTML页面body里的不可信数据，进行HTML编码已经足够防御XSS攻击了，甚至将HTML编码后的数据放到HTML标签（TAG）的属性（attribute）里也不会产生XSS漏洞（但前提是这些属性都正确使用了引号），但是，如果你将HTML编码后的数据放到了直接插入到SCRIPT标签里 

– …不要在这里直接插入不可信数据…–>

插入到HTML注释里