本文目录一览：
xss漏洞如何防御?
防御方法
(1)基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同。这就给XSS漏洞防御带来了困难，不可能以单一特征来概括所有XSS攻击。
传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对“javascript”这个关键字进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有“javascript”时，就被硬性的被判定为XSS攻击。
(2)基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误和漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的方法就是通过优化Web应用开发来减少漏洞，避免被攻击：1)用户向服务器上提交的信息要对URL和附带的的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。2)实现Session标记（session tokens）、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。3)确认接收的的内容被妥善的规范化，仅包含最小的、安全的Tag（没有javascript），去掉任何对远程内容的引用（尤其是样式表和javascript），使用HTTP only的cookie。
当然，如上操作将会降低Web业务系统的可用性，用户仅能输入少量的制定字符，人与系统间的交互被降到极致，仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训，很难做到完全避免页面中的XSS漏洞。
(3)客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端(浏览器)，这是它与其他模型最大的区别，之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：（1）对每一个网页分配独立线程且分析资源消耗的“网页线程分析模块”；
（2）包含分层防御策略四个规则的用户输入分析模块；
（3）保存互联网上有关XSS恶意网站信息的XSS信息数据库。
XSS攻击主要是由程序漏洞造成的，要完全防止XSS安全漏洞主要依靠程序员较高的编程能力和安全意识，当然安全的软件开发流程及其他一些编程安全原则也可以大大减少XSS安全漏洞的发生。这些防范XSS漏洞原则包括：
（1）不信任用户提交的任何内容，对所有用户提交内容进行可靠的输入验证，包括对URL、查询关键字、HTTP头、REFER、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。尽量采用POST而非GET提交表单；对“”，“”，“；”，“””等字符做过滤；任何内容输出到页面之前都必须加以en-code，避免不小心把htmltag显示出来。
（2）实现Session 标记（session tokens）、CAPTCHA（验证码）系统或者HTTP引用头检查，以防功能被第三方网站所执行，对于用户提交信息的中的img等link，检查是否有重定向回本站、不是真的图片等可疑操作。
（3）cookie 防盗。避免直接在cookie中泄露用户隐私，例如email、密码，等等；通过使cookie和系统IP绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值，很难拿来直接进行重放攻击。
（4）确认接收的内容被妥善地规范化，仅包含最小的、安全的Tag（没有JavaScript），去掉任何对远程内容的引用（尤其是样式表和JavaScript），使用HTTPonly的cookie。
web安全测试个人阅读心得
文章中提到的东西都是工作中实践过的经验,并不保证全面性.
Web测试一般包含如下内容:
功能测试
性能测试
用户界面测试
兼容性测试
安全性测试
其实这只是大概的区分,各种不同的类别的测试之间其实是有很多交集的.比如:
当网站出现性能问题的时候,同时网站的某些功能可能会失效,比如页面打开失败,表单提交失败等等
当网站在一个它不兼容的浏览器下运行的时候,也会导致功能失效,用户界面出现混乱,甚至性能问题
以上的五项内容中的每一项都可以是一个大的主题做深入的分析.
另外,对于所有的web测试人员来说,学会使用Firebug以及Fiddler这样的抓包工具绝对是必不可少的。这些工具的使用应该始终贯穿的测试工作之中
一.功能测试
对于一般被测试的软件,我可以用"树"来比喻一个软件.一颗树有主干,分支和叶子.主干和分支代表软件的流程,叶子代表软件的局部步骤(页面). 我们测试软件的时候既要保证软件的流程正确,也要保证组成流程的各个分支步骤页面的正确性.
拿淘宝来购物来说,我们可以把登录页面,购物车页面之类的当成是叶子,完成一个购物流程,当成一个主干或者分支. 软件就是由这很多的叶子以及相对少一些的分支组成.
经典的教科书上往往会介绍如下功能测试测试用例的设计方法:
边界值划分
等价类
正交表
决策表
当我们测试单个页面的时候,往往会用到这些方法.但是这些方法只是测试到了软件的局部.
除此之外,我们还要考虑被测试软件的工作流程,保证所有的提供给用户的工作流程都可以跑通,这个时候,探索式测试可以派上用场.有时候,我们还需要化流程图来辅助测试.
关于探索式测试,详见探索式测试读书笔记一文
另外，还有更重要的几点：
每当打开页面或者提交数据的时候，多打开Fiddler或者Firebug看看到底发送了哪些http请求,以及关键请求的http response是什么.当发现功能异常之后,根据我们用Fiddler看到的数据,往往可以自己判断问题到底是出在前台的JS还是后台service. 关于Fiddler,详见Fiddler小结一文
有空多看看系统的日志,哪里能找到一些隐藏在页面之外的异常
当我们在页面上完成了一些功能之后,要彻底明白系统背后(数据库)到底完成了什么东西,我们提交的数据到底被存储到哪里去了
综上所述,我们做功能测试的总体思路是从 点(树叶)-面(主干,分支)-后台(根)
二.性能测试
性能测试主要要从前端和后台两个角度去理解,我们可以首先使用Fiddler去大概判断网站的性能问题是出在前台还是后台.
如果Http请求的大部分时间是花在html,css,js之类的静态资源加载上,那么基本是前台性能有问题.如果某个后台的service特别费时,那么后台必定存在性能问题
前台性能
除了用Fiddler看性能外,我们可以使用Yahoo的Firefox YSlow插件去检测前端的性能.此外,关于前端性能具体的优化策略,可以参阅High Performance Web Sites,其中主要涉及到http协议和浏览器缓存机制
详见Web前端优化14条原则一文
后台性能
对于大部分测试工程师来说是很难直接去优化后台性能的,但是依然能去发现一些有意义的线索
用Fiddler去查看http请求,如果某个请求特别耗时,则可能存在性能问题
后台代码设计到SQL查询的时候,往往测试员也是有基础去测试那些SQL的查询时间和执行时间,如果因为数据量大而导致查询太慢的话,可以建议使用数据库的索引
后台的cache机制: 我们的项目大量的使用了后台的cache机制
总之,做性能测试绝对不是简单地直接拿Loadrunner或者Jmeter去录制一下脚本,然后运行,分析结果.这一切的前提应该是充分了解了被测试系统的前台跟后台的性能
三.用户界面测试
这点关注不多，主要如下：
字体大小颜色(主要通过修改css文件)
弹窗的风格最好保持统一
四,兼容性测试
主要考虑如下几个因素组合：
不同的操作系统
不同的浏览器
浏览器的不同版本
显示器的不同分辨率
不同的浏览设备（PC，手机，平板）
五.安全性测试
安全性测试主要知道有如下几点:
SQL注入:后台使用Preparedstatement去处理SQL
XSS攻击:这个问题非常复杂.学习中..
做为一个测试工程师,我觉得应该记住如下3点:
前台的JS验证是不可靠的
用户进行任何输入都是有可能的
Web本身似乎也是不安全的:无法解释更多....
接下去举一些实际的例子:
隐藏的按钮
当我们用Firebug看页面的HTML的时候,往往能找到一些隐藏的内容,比如某个元素的 class="8941-35d6-9483-c252 gradient hide",或者类似的东西.当我们直接修改掉这些属性之后,这些隐藏的东西就会在页面上暴露出来,对系统的安全造成隐患.
另外如果有某些值也可能会存储在隐藏域中
Disabled按钮
与隐藏的按钮类似,页面上经常有些可见但是灰调的按钮,也可以尝试改变他的属性,让它变成可以触发的,或许会有所发现
不该被访问的URL
如果某个URL不该被某些人访问,一定要在权限上去控制.仅仅去掉某个链接/按钮是不够的
后台Service
如果网站后台的Service能被捕捉到,而且又没有权限控制,那将是灾难性的
xss 跨网站脚本攻击 会导致什么结果
1、各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号
2、读取、篡改、添加、删除敏感数据
3、窃取企业重要的具有商业价值的资料
4、非法转账
5、制发送电子邮件
6、网站挂马
7、制受害者机器向其它网站发起攻击