本文目录一览：
- 1、web漏洞扫描工具有哪些
- 2、如何测试XSS漏洞
- 3、Web应用常见的安全漏洞有哪些？
- 4、如何安全检测Java Web应用网站漏洞
- 5、发现XSS漏洞的一般做法有哪些？
- 6、xss漏洞如何防御?
web漏洞扫描工具有哪些
1、Nexpose：跟其他扫描工具不同的是，它的功能十分强大，可以更新漏洞数据库，也可以看出哪些漏洞可以被Metasploit Exploit，可以生成非常详细、强大的Report，涵盖了很多统计功能和漏洞的详细信息。
2、OpenVAS：类似Nessus的综合型漏洞扫描器，可以用来识别远程主机、Web应用存在的各种漏洞，它使用NVT脚本对剁成远程系统的安全问题进行检测。
3、WebScarab：可以分析使用HTTP和HTTPS协议进行通信的应用程序，它可以简单记录观察的会话且允许操作人员以各种方式进行查看。
4、WebInspect：是一款强大的Web应用程序扫描程序，有助于确认Web应用中已知和未知的漏洞，还可以检查一个Web服务器是否正确配置。
5、Whisker/libwhisker：是一个Perla工具，适合于HTTP测试，可以针对许多已知的安全漏洞，测试HTTP服务器，特别是检测危险CGI的存在。
6、Burpsuite：可以用于攻击Web应用程序的集成平台，允许一个攻击者将人工和自动的技术进行结合，并允许将一种工具发现的漏洞形成另外一种工具的基础。
7、Wikto：是一个Web服务器评估工具，可以检查Web服务器中的漏洞，并提供与Nikto一样的很多功能，但增加了许多有趣的功能部分。
8、Watchfire AppScan：是一款商业类的Web漏洞扫描程序，简化了部件测试和开发早期的安全保证，可以扫描许多常见的漏洞，如跨站脚本攻击、HTTP响应拆分漏洞、参数篡改、隐式字段处理、后门/调试选项、缓冲区溢出等等。
9、N-Stealth：是一款商业级的Web服务器安全扫描程序，主要为Windows平台提供扫描，但并不提供源代码。
如何测试XSS漏洞
XSS跨站漏洞分为大致三种：储存型XSS，反射型XSS，和DOM型XSS，一般都是由于网站对用户输入的参数过滤不严格而调用浏览器的JS而产生的。XSS几乎每个网站都存在，google，百度，360等都存在，存在和危害范围广，危害安全性大。
具体利用的话：
储存型XSS，一般是构造一个比如说"scriptalert("XSS")/script"的JS的弹窗代码进行测试，看是否提交后在页面弹窗，这种储存型XSS是被写入到页面当中的，如果管理员不处理，那么将永久存在，这种XSS攻击者可以通过留言等提交方式，把恶意代码植入到服务器网站上， 一般用于盗取COOKIE获取管理员的信息和权限。
反射型XSS，一般是在浏览器的输入栏也就是urlget请求那里输入XSS代码，例如：127.0.0.1/admin.php?key="scriptalert("xss")/script，也是弹窗JS代码。当攻击者发送一个带有XSS代码的url参数给受害者，那么受害者可能会使自己的cookie被盗取或者“弹框“，这种XSS一次性使用，危害比储存型要小很多。
dom型：常用于挖掘，是因为api代码审计不严所产生的，这种dom的XSS弹窗可利用和危害性并不是很大，大多用于钓鱼。比起存储型和反射型，DOM型并不常用。
缺点：
1、耗时间
2、有一定几率不成功
3、没有相应的软件来完成自动化攻击
4、前期需要基本的html、js功底，后期需要扎实的html、js、actionscript2/3.0等语言的功底
5、是一种被动的攻击手法
6、对website有http-only、crossdomian.xml没有用
所以楼主如果想更加深层次的学习XSS的话，最好有扎实的前后端开发基础，还要学会代码审计等等。
推荐的话，书籍建议看看《白帽子讲web安全》，《XSS跨站脚本攻击剖析与防御》
一般配合的话，kalilinux里面的BEFF是个很著名的XSS漏洞利用工具，楼主有兴趣可以去看看。
纯手工打字，望楼主采纳。
Web应用常见的安全漏洞有哪些？
Web应用常见的安全漏洞：
1、SQL注入
注入是一个安全漏洞，允许攻击者通过操纵用户提供的数据来更改后端SQL语句。 当用户输入作为命令或查询的一部分被发送到解释器并且欺骗解释器执行非预期的命令并且允许访问未授权的数据时，发生注入。
2、跨站脚本攻击 （XSS）
XSS漏洞针对嵌入在客户端（即用户浏览器而不是服务器端）的页面中嵌入的脚本。当应用程序获取不受信任的数据并将其发送到Web浏览器而未经适当验证时，可能会出现这些缺陷。
3、跨站点请求伪造
CSRF攻击是指恶意网站，电子邮件或程序导致用户的浏览器在用户当前已对其进行身份验证的受信任站点上执行不需要的操作时发生的攻击。
4、无法限制URL访问
Web应用程序在呈现受保护的链接和按钮之前检查URL访问权限 每次访问这些页面时，应用程序都需要执行类似的访问控制检查。 通过智能猜测，攻击者可以访问权限页面。攻击者可以访问敏感页面，调用函数和查看机密信息。
5、不安全的加密存储
不安全的加密存储是一种常见的漏洞，在敏感数据未安全存储时存在。 用户凭据，配置文件信息，健康详细信息，信用卡信息等属于网站上的敏感数据信息。
扩展资料
web应用漏洞发生的市场背景：
由于Web服务器提供了几种不同的方式将请求转发给应用服务器，并将修改过的或新的网页发回给最终用户，这使得非法闯入网络变得更加容易。
许多程序员不知道如何开发安全的应用程序。他们的经验也许是开发独立应用程序或Intranet Web应用程序，这些应用程序没有考虑到在安全缺陷被利用时可能会出现灾难性后果。
许多Web应用程序容易受到通过服务器、应用程序和内部已开发的代码进行的攻击。这些攻击行动直接通过了周边防火墙安全措施，因为端口80或443（SSL，安全套接字协议层）必须开放，以便让应用程序正常运行。
参考资料来源：百度百科-WEB安全漏洞
参考资料来源：百度百科-Web安全
如何安全检测Java Web应用网站漏洞
如何安全检测Java Web应用网站漏洞.txt32因为爱心，流浪的人们才能重返家园；因为爱心，疲惫的灵魂才能活力如初。渴望爱心，如同星光渴望彼此辉映；渴望爱心，如同世纪之歌渴望永远被唱下去。web开发应用程序（网站），是目前应用最广泛的程序。但是开发者的水平参差不齐，导致了各种各样web漏洞的出现。本文站在分层架构的角度，分析一下如何在java web程序中找到可能出现的种种漏洞。 本文讨论的只是web程序上的漏洞，和其它漏洞，是相对独立的。这句话看似废话，实际上却说明了时常被忽略的因素，即：“很多人认为只要我开发web程序没有漏洞，web服务器就安全了”，事实上，并非如此。一个合格的web程序开发人员，应该时刻清楚自己开发的程序会在什么环境中被使用，以及一旦自己的程序产生某种漏洞，最终会导致什么后果。简单的说，web程序被安装在一台或多台（分布式）web服务器上，一旦安装成功，就等于在为广大用户提供服务的同时，给入侵者打开了一条或N条新的思路。如果服务器管理员刚好对安全配置不了解（事实上，国内这种管理员居多），那么只好由我们的程序来守好最后的关卡最后一道防线。 看了本文题目，一定有一部分人会认为，“不就是讲JSP漏洞么，用得着披着这么厚的包装么？”，为了回答这个疑问，我们先看看JSP和ASP的开发有什么不同吧。在ASP时代（ASP，PHP等语言），开发一套系统往往比修改别人已经写好的系统痛苦的多，因为它们把所有的代码（包括链接数据库的代码、执行SQL语句的代码、控制页面显示的代码）统统都放在%......%中，我们时常会看到如下代码块： -----------代码来自某ASP SHELL----------- Function GetFileSize(size) Dim FileSize FileSize=size / 1024 FileSize=FormatNumber(FileSize,2) If FileSize 1024 and FileSize 1 then GetFileSize="font color=red" FileSize "/font KB" ElseIf FileSize 1024 then GetFileSize="font color=red" FormatNumber(FileSize / 1024,2) "/font MB" Else GetFileSize="font color=red" Size "/font Bytes" End If End Function ---------------------------------------- 如果客户的需求变了，要求页面不能使用“font color=red”等标签，全部应用“CSS”显示。挂了，把程序员召唤出来，一个一个的改吧。。。注意，这里强调下，特指“召唤程序员”才能改，如果是学美工的，只会HTML、JS、CSS，完了，这活还干不成。而这些只是简单的页面修改，如果客户今天说，MYSQL服务器承担不了这个数据量，要挂Oracle，可怜的程序员就要在一片一片的代码海洋里寻找执行SQL语句的代码，而每一个文件都可能存放着SQL语句，意味着每一个文件都可能在受SQL注入的威胁。
而JSP采用MVC模式分层架构进行开发，就可以把所有的文件分开，根据其用途，分别放在不同的文件夹下（分层），每个文件夹下的文件只负责自己的事情。例如数据访问层的代码就放在数据访问层的文件夹下，业务逻辑层的代码也都放在自己的文件夹下，当显示层（这一层是为了把最终的运算结果显示给用户看）的需求发生变化，就像前面的客户需求，我们只要修改这一层的文件就是了，其他层的代码根本不需要动，而修改者也不需要懂得其它层的代码。 代码分层了，意味着漏洞也在跟着分层，我们寻找JSP漏洞的思路也要跟着分层，才能与时俱进。 下面在讲述寻找漏洞的过程中，本文就拿一个简单的分层架构例子来做样板。样板程序的名称为“XX文章系统”，系统使用了STRUTS框架，和安全有关的层分为： “DB层”，这一层存放了链接数据库的字符串，以及JdbcTemplate类，直接访问数据库。因为在java中，执行SQL语句的函数按照返回值可以分为三类，所以在这一层定义了JDBC模版类（JdbcTemplate），每一次使用操作数据库时都要执行这一层的三个方法其中一个。 “DAO层（Data Access Object数据访问对象层）”，从安全角度上看，这一层存放了SQL语句（并不执行SQL语句，语句传给DB层执行）。这一层调用“DB层”访问数据库，它只知道“DB层”的存在，不知道数据库的存在。 “SERVICE层”，业务逻辑层，因为一个业务的实现，并不是一次数据库访问就可以完成的，所以这一层通过N次调用“DAO层的方法”实现业务逻辑，它只知道“DAO层”的存在，不知道“DB层”和数据库的存在。 “ACTION层”，调用业务逻辑层，根据返回的结果，控制JSP页面显示。它只知道业务层的存在。这一层是入侵者的攻击平台。 “Form层”，把用户POST提交的信息封装成Form对象，经过验证后提交给ACTION层处理。 “JSP层”(显示层)，这一层是最终显示给用户看的页面，同时也是入侵者的攻击平台。 用户通过访问ACTION层，自动会发生：“ACTION调用SERVICE，SERVICE调用DAO，DAO调用DB，DB执行SQL语句返回结果给DAO，DAO返回给SERVICE，SERVICE返回给ACTION，ACTION把数据显示到JSP里返回给用户”。 有了样板，我们来分析这套程序中可能出现的各种web漏洞。 1、SQL注入漏洞 从SQL注入漏洞说起吧，在web漏洞里，SQL注入是最容易被利用而又最具有危害性的。怎么快速的找到呢？先分析流程，就拿用户查看文章这个流程为例：用户访问一个
action，告诉它用户想看ID为7的文章，这个action就会继续完成前面所说的流程。 如果是ASP程序，这就是最容易产生问题的时候，ASP是弱类型，接到参数后不需要转换类型，就和SQL语句连加起来。但是JSP就不一样，JSP是强类型的语言，接受有害的参数后：对于GET请求（直接在地址栏访问页面），如果这里要的是int型，即使不懂安全的程序员，也会把它（文章的ID）立刻转换成int，因为这里转换后在后面的处理中会更容易操作，而这时程序就出错了；对于POST请求，如果这里要的是int型，程序会在把它封装成Form对象时，因为自动要进行类型转化，同样发生错误，这两种错误发生后，根本不会访问后面的流程就跳出了，或许这就是JSP天生的安全性。所以，通常提交的变量是int时，不会发生问题，问题会出现在string参数这里，如果要查看某用户的信息，程序可能会让你提交如下参数：showuser.do? username=kxlzx。问题来了，因为这里是string类型，所以不懂安全的程序员顶多会判断一下是不是空，就连加成为SQL语句。有漏洞的程序大概会写成这个样子： ACTION的代码： showuser.do String username = null; username = request.getParameter("username"); Service service = new Service(); service.findByUsername(username); 得到参数后调用service,service层直接交给了Dao层，dao的代码： public Object findByUsername(String username) { JdbcTemplate jt=new JdbcTemplate(); String sql = "select * from Users where username=’"+username"’"; List list = jt.query(sql); ................... } dao调用了DB层的JdbcTemplate，把SQL语句拼好后，传给了JdbcTemplate去执行。不用再看这里的JdbcTemplate，就可以知道里面的代码使用了Statement的executequery()方法执行，导致了SQL注入。 分析了这么半天，有读者会问：“难道我要费这么大的力气才能找到漏洞么？”。的确，通常在ASP程序里找注入时的思路就是这样子，但是我们现在是在使用了开发模式分层架构的JSP程序里，应该按照分层架构的思维去找漏洞。在回答这个问题之前，我们还得绕个弯子，看看怎么在这里预防SQL注入（java始终都是这么优美，它不会直接告诉你答案，而是一层一层的让你拨开云雾）。 刚才分析流程，是从正向分析的，从用户输入到产生漏洞，我们在防御的时候，不妨倒过来看看，从DB层入手。JdbcTemplate调用执行SQL语句，可以有两个类供我们选择，一个是Statement，另一个就是预处理的Statement，两者有着效率上和安全上的显著差别。在效率上，只要数据库支持预处理技术（sqlserver，mysql，oracle等都支持，只有少数access等不支持），就会在大量执行SQL语句时增加速度；在安全上，使用预处理，会把接受的参数也经过预处理，从而不会作为SQL语句的一部分执行，而是仅仅作为SQL语句中的参数部分
内容被执行。一旦DB层使用了预处理，DAO层的SQL语句也会发生变化，成为这个样子： public Object findByUsername(String username) { JdbcTemplate jt=new JdbcTemplate(); String sql = "select * from Users where username=?"; List list = jt.query(sql,new Object[1]{username}); ................... } 这样，SQL注入就和我们的程序几乎无关了，注意我说的是几乎，而不是全部。知道了怎么防御，于是一切在这里变的简单极了，我们应该直接去DB层找到JdbcTemplate，看看代码，一旦使用了Statement，很好，这个系统十有八九有漏洞，下面要做的是使用Editplus搜索“request.getParameter”。没有使用预处理的系统，可能会在action层进行防御，对参数过滤，但总有防御不到的时候，因为战线拉的太长了，每一个action里都可能接受参数并存在漏洞。 还有一种情况，系统一部分使用了预处理，一部分没有，这样的情况可能是因为项目赶的比较仓促，人员没有经过正规培训，最后艰难的整合到了一起。这种情况也好办，直接在DAO层搜索（"’）或（’"），这些符号用于和字符串变量连加，拼SQL语句，肯定是这些语句之后的代码使用了Statement。然后再往上层找，看看哪个action调用了这个有问题的dao类，也可能发生SQL注入。 即使系统使用了预处理，别忘了，程序给客户使用后，客户有权利去扩展的。程序拿到客户那里，客户有了新的需求，而这个需求又不大，很可能不愿意花钱重新雇人来实现扩展功能，在这个时候也可能出现问题，客户使用自己的程序员扩展AJAX功能，这个程序员因为怕出问题，不敢动源程序，就在web.xml里加了一个servlet，这个servlet直接去调用conn。可怕的事情发生了。所以，我们的搜索漏洞规则中又加上了一条，在非dao层的文件中，搜索“select，update，delete”等字符串。 2、暴露程序信息漏洞 这个漏洞是怎么来的呢？我们需要从异常说起。有经验的入侵者，可以从JSP程序的异常中获取很多信息，比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等，这个漏洞很容易防御，却很难快速定位漏洞文件。出现这样漏洞的时候，通常是我们在写代码的时候，少了一些可能性的考虑而导致的。这样的问题都是经验造成的，而寻找漏洞也要通过经验加运气（要有仙缘。。。），我个人技术有限，就不多说了。防御的方法就是在程序中加上“Exception层”，自定义异常，把系统产生的异常统统包装起来，不要放过任何一个可能产生异常的地方。像腾讯的异常就包装的很好“对不起，今天的注册人数已经达到十万，请您明天再来。。。”，废话，日注册量都十万，还让不让人活啦，铁定是程序发生了异常，不敢让各位大大们看到真实的面孔。
发现XSS漏洞的一般做法有哪些？
关于发现时间，要具体到是检测什么目标了。找google的，和找腾讯的时间肯定不会一样。 至于“你们一般都是如何发现xss漏洞的？” 不同类型的XSS漏洞，可能不尽相同。
1.对于反射型XSS以及一些DOM XSS，一般建议是开发一些自动化的扫描工具进行扫描，并辅以手工分析。 另外一方面，搜索引擎也是快速寻找具有缺陷参数的好办法。
2.对于存储型XSS，
1) 对于单纯的输入-存储-输出点 的情况 （输入与输出点关系：一个地方输入，会有多个地方输出；不同地方输入，同一地方输出。绕了点 T T ...）。常规测试是正向直接输入内容，然后在输出点查看是否未过滤，当然你也可以先大胆假设输出点未过滤，反向寻找在何处进行输入，进而测试。
2）对于富文本，则需要对过滤器进行fuzz测试（人脑+自动化）了，正好乌云drops上有乌乌发了一篇：fuzzing XSS filter
3）第三类，就是一些WEB应用中所出现的DOM-存储型XSS，即输出点的无害内容，会经过js的一些dom操作变得危险（本质上和 第1点里的dom xss成因是一样的）。这一类的挖掘方法，个人觉得不太好总结。 其一，需要熟悉WEB应用的功能，其二，知道功能所对应的JS代码有哪些，其三，凭直觉猜测程序员会在哪些功能出现可能导致XSS的过滤遗忘或过滤错误（直觉是唬人的，其实就是你知道某些功能会需要某些代码实现，而这些代码常常容易出错），其四，需要有较好的代码阅读跟踪能力（JS一大坨。。还是蛮难读的.... 有些代码被混淆过，十分不易阅读，就会涉及到如何下断点进行调试的小技巧）。 我想，挖掘这一类的前提可能是需要有不错的前端开发经验，写多了，才会有足够的嗅觉。
其实吧，有时候专门去找漏洞会很累的，大什么怡情，小什么伤身，因此，我们还不如开心的敲敲代码，听听歌，静待生命中那些意外的收获。 这些收获经常来自身边的人发给你的一些事物。
最后，不论如何，基础很重要吧，内力不足，招式再多也没用，反之，草木竹石皆可为剑。
xss漏洞如何防御?
1、基于特征的防御。XSS漏洞和著名的SQL注入漏洞一样，都是利用了Web页面的编写不完善，所以每一个漏洞所利用和针对的弱点都不尽相同，这就是给XSS漏洞防御带来的困难，不可能以单一特征来概括所有XSS攻击。
传统的XSS防御在进行攻击鉴别时多采用特征匹配方式，主要是针对JavaScript这个关键词进行检索，但是这种鉴别不够灵活，凡是提交的信息中各有JavaScript时，就被硬性的判定为XSS攻击。
2、基于代码修改的防御。Web页面开发者在编写程序时往往会出现一些失误或漏洞，XSS攻击正是利用了失误和漏洞，因此一种比较理想的方法就是通过优化Web应用开发来减少漏洞，避免被攻击：
①用户向服务器上提交的信息要对URL和附带的HTTP头、POST数据等进行查询，对不是规定格式、长度的内容进行过滤。
②实现Session标记、CAPTCHA系统或者HTTP引用头检查，以防功能被第三方网站所执行。
③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。
3、客户端分层防御策略。客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端，这是它与其他模型最大的区别。之所以客户端安全性如此重要，客户端在接受服务器信息，选择性的执行相关内容。这样就可以使防御XSS攻击变得容易，该模型主要由三大部分组成：
①对每一个网页分配独立线程且分析资源消耗的网页线程分析模块;
②包含分层防御策略四个规则的用户输入分析模块;
③保存互联网上有关XSS恶意网站信息的XSS信息数据库。