一、在代码编写时就要进行漏洞测试。
邯山网站建设公司创新互联公司,邯山网站设计制作，有大型网站制作公司丰富经验。已为邯山近1000家提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的邯山做网站的公司定做！
二、对Web服务器进行持续的监控。
三、设置蜜罐，将攻击者引向错误的方向。
四、专人对Web服务器的安全性进行测试。
在Web服务器的攻防战上，这一个原则也适用。笔者建议，如果企业对于Web服务的安全比较高，如网站服务器上有电子商务交易平台，此时最好设置一个专业的团队。他们充当攻击者的角色，对服务器进行安全性的测试。这个专业团队主要执行如下几个任务。
一是测试Web管理团队对攻击行为的反应速度。如可以采用一些现在比较流行的攻击手段，对自己的Web服务器发动攻击。当然这个时间是随机的。预先Web管理团队并不知道。现在要评估的是，Web管理团队在多少时间之内能够发现这种攻击的行为。这也是考验管理团队全天候跟踪的能力。一般来说，这个时间越短越好。应该将这个时间控制在可控的范围之内。即使攻击最后没有成功，Web管理团队也应该及早的发现攻击的行为。毕竟有没有发现、与最终有没有取得成功，是两个不同的概念。
二是要测试服务器的漏洞是否有补上。毕竟大部分的攻击行为，都是针对服务器现有的漏洞所产生的。现在这个专业团队要做的就是，这些已发现的漏洞是否都已经打上了安全补丁或者采取了对应的安全措施。有时候我们都没有发现的漏洞是无能为力，但是对于这些已经存在的漏洞不能够放过。否则的话，也太便宜那些攻击者了。
扫描网站漏洞是要用专业的扫描工具，下面就是介绍几种工具
1. Nikto
这是一个开源的Web服务器扫描程序，它可以对Web服务器的多种项目进行全面的测试。其扫描项目和插件经常更新并且可以自动更新。Nikto可以在尽可能短的周期内测试你的Web服务器，这在其日志文件中相当明显。不过，如果你想试验一下，它也可以支持 LibWhisker的反IDS方法。不过，并非每一次检查都可以找出一个安全问题，虽然多数情况下是这样的。有一些项目是仅提供信息类型的检查，这种检查可以查找一些并不存在安全漏洞的项目，不过Web管理员或安全工程师们并不知道。
2. Paros proxy
这是一个对Web应用程序的漏洞进行评估的代理程序，即一个基于Java的web代理程序，可以评估Web应用程序的漏洞。它支持动态地编辑/查看 HTTP/HTTPS,从而改变cookies和表单字段等项目。它包括一个Web通信记录程序，Web圈套程序，hash 计算器，还有一个可以测试常见的Web应用程序攻击的扫描器。
3. WebScarab:
它可以分析使用HTTP和HTTPS协议进行通信的应用程序，WebScarab可以用最简单地形式记录它观察的会话，并允许操作人员以各种方式观查会话。如果你需要观察一个基于HTTP(S)应用程序的运行状态，那么WebScarabi就可以满足你这种需要。不管是帮助开发人员调试其它方面的难题，还是允许安全专业人员识别漏洞，它都是一款不错的工具。
4. WebInspect：
这是一款强大的Web应用程序扫描程序。SPI Dynamics的这款应用程序安全评估工具有助于确认Web应用中已知的和未知的漏洞。它还可以检查一个Web服务器是否正确配置，并会尝试一些常见的 Web攻击，如参数注入、跨站脚本、目录遍历攻击等等。
5. Whisker/libwhisker :
Libwhisker是一个Perla模块，适合于HTTP测试。它可以针对许多已知的安全漏洞，测试HTTP服务器，特别是检测危险CGI的存在。 Whisker是一个使用libwhisker的扫描程序。
6. Burpsuite：
这是一个可以用于攻击Web应用程序的集成平台。Burp套件允许一个攻击者将人工的和自动的技术结合起来，以列举、分析、攻击Web应用程序，或利用这些程序的漏洞。各种各样的burp工具协同工作，共享信息，并允许将一种工具发现的漏洞形成另外一种工具的基础。
7. Wikto:
可以说这是一个Web服务器评估工具，它可以检查Web服务器中的漏洞，并提供与Nikto一样的很多功能，但增加了许多有趣的功能部分，如后端 miner和紧密的Google集成。它为MS.NET环境编写，但用户需要注册才能下载其二进制文件和源代码。
8. Acunetix Web Vulnerability Scanner :
这是一款商业级的Web漏洞扫描程序，它可以检查Web应用程序中的漏洞，如SQL注入、跨站脚本攻击、身份验证页上的弱口令长度等。它拥有一个操作方便的图形用户界面，并且能够创建专业级的Web站点安全审核报告。
9. Watchfire AppScan：
这也是一款商业类的Web漏洞扫描程序。AppScan在应用程序的整个开发周期都提供安全测试，从而测试简化了部件测试和开发早期的安全保证。它可以扫描许多常见的漏洞，如跨站脚本攻击、HTTP响应拆分漏洞、参数篡改、隐式字段处理、后门/调试选项、缓冲区溢出等等。
10. N-Stealth：
N-Stealth是一款商业级的Web服务器安全扫描程序。它比一些免费的Web扫描程序，如Whisker/libwhisker、 Nikto等的升级频率更高。还要注意，实际上所有通用的VA工具，如Nessus, ISS Internet Scanner, Retina, SAINT, Sara等都包含Web 扫描部件。N-Stealth主要为Windows平台提供扫描，但并不提供源代码。
如何安全检测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层”，自定义异常，把系统产生的异常统统包装起来，不要放过任何一个可能产生异常的地方。像腾讯的异常就包装的很好“对不起，今天的注册人数已经达到十万，请您明天再来。。。”，废话，日注册量都十万，还让不让人活啦，铁定是程序发生了异常，不敢让各位大大们看到真实的面孔。
