本文目录一览：
- 1、写的java web页面会被人入侵数据库，然后我的数据库的数据都是null，怎么办，怎么防
- 2、java编程中如何在前台登录页面用js处理不让嗅探工具获得到密码？
- 3、用这个 *** ， 可以入侵攻击那个网站吗？
- 4、如果网站被攻击了，要怎么处理？
- 5、如何用java入侵？
- 6、如何安全检测Java Web应用网站漏洞
写的java web页面会被人入侵数据库，然后我的数据库的数据都是null，怎么办，怎么防
页面有输入框的，尽量不要使用字符串拼接出sql语句进行查询等操作；sql语句要用到url链接里的参数时，要进行判断；或通过Hibernate API编写访问数据库的代码，这样可以减少被sql注入的危险
java编程中如何在前台登录页面用js处理不让嗅探工具获得到密码？
js加密的问题是，不论单向双向，加密方式没办法隐藏，会被人家看到。例如我密码是123abc,输入表单后发送，js给加密成了乱码。发给服务端再加密下和数据库比对。问题来了，如果入侵者截获到js加密后的乱码，他可以禁用js，然后直接把乱码输入表单后发送，效果和直接得到用户密码产生1.js加密这里的作用除黑客不知道密码是啥外，其他都没用，乱码也能够登录。js的加密的直接pass掉。这里根本行不通！
用这个 *** ， 可以入侵攻击那个网站吗？
不能， 你这个 *** 只是每个一段时间检查所有网页上的元素，修改一部分找到的元素的可见状态。这代码只是改变客户端的显示，直白点说就是修改你在自己电脑上看到的网页效果。
这和入侵半毛钱关系都没有，。
如果网站被攻击了，要怎么处理？
事先你要了解你的网站是如何被攻击的。下面这四种是常规的攻击方式：
1，流量攻击，就是我们常说的DDOS和DOS等攻击，这种攻击属于最常见的流量攻击中的带宽攻击，一般是使用大量数据包淹没一个或多个路由器、服务器和防火墙，使你的网站处于瘫痪状态无法正常打开。但是这种攻击成本都会很高，所以遇到这样的攻击的时候大家不要惊慌，另外可以试试防御系统，这样的话攻击不会主要针对你的网站。
2， CC攻击，也是流量攻击的一种，CC就是模拟多个用户（多少线程就是多少用户）不停地进行访问那些需要大量数据操作（就是需要大量CPU时间）的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就 *** 拥塞，正常的访问被中止。而CC攻击基本上都是针对端口的攻击，以上这两种攻击基本上都属于硬性流量的攻击， 下面说一下针对数据库的安全进行的一些攻击。
3，破坏数据性的攻击，其实这里说的也就不算是硬性的攻击了，这种是拿到网站的管理权限后可以对页面的内容进行修改，这样的入侵对于网站来说是致命性的，不仅搜索引擎会降权，还会丢失大量的用户。降低这样的入侵带来的危害需要经常备份网站数据和网站关键程序，更好打包到本地电脑里;做好关键文件的权限设置;网站更好采用全静态页面，因为静态页面是不容易被黑客攻击的;ftp和后台相关密码不要用弱口令
4，挂马或者挂黑链，这种不会像第二种危害那么大，但是也是不容忽视的，搜索引擎一旦把你的网站视为木马网站就会被封杀甚至还会列入黑名单，所以问题也不可以忽视。
下面是一些简单的解决 *** ：
1、修改网站后台的用户名和密码及后台的默认路径。
2、更改数据库名,如果是ACCESS数据库，那文件的扩展名更好不要用mdb，改成ASP的，文件名也可以多几个特殊符号。
3、接着检查一下网站有没有注入漏洞或跨站漏洞，如果有的话就相当打上防注入或防跨站补丁。
4、检查一下网站的上传文件，常见了有欺骗上传漏洞，就对相应的代码进行过滤。
5、尽可能不要暴露网站的后台地址，以免被社会工程学猜解出管理用户和密码。
6、写入一些防挂马代码，让框架代码等挂马无效。
7、禁用FSO权限也是一种比较绝的 *** 。
8、修改网站部分文件夹的读写权限。
9、如果你是自己的服务器，那就不仅要对你的网站程序做一下安全了，而且要对你的服务器做一下安全也是很有必要了！
如果攻击很严重，可以进行 *** 报警，网上有很详细的资料。就不细说了。
如何用java入侵？
虽然我不懂JAVA,但是我还是帮你找了找一些JAVA入侵的资料.不知道管用不管用,呵呵,谢谢了
如何安全检测Java Web应用网站漏洞
如何安全检测Java Web应用网站漏洞.txt32因为爱心，流浪的人们才能重返家园；因为爱心，疲惫的灵魂才能活力如初。渴望爱心，如同星光渴望彼此辉映；渴望爱心，如同世纪之歌渴望永远被唱下去。web开发应用程序（网站），是目前应用最广泛的程序。但是开发者的水平参差不齐，导致了各种各样web漏洞的出现。本文站在分层架构的角度，分析一下如何在java web程序中找到可能出现的种种漏洞。 本文讨论的只是web程序上的漏洞，和其它漏洞，是相对独立的。这句话看似废话，实际上却说明了时常被忽略的因素，即：“很多人认为只要我开发web程序没有漏洞，web服务器就安全了”，事实上，并非如此。一个合格的web程序开发人员，应该时刻清楚自己开发的程序会在什么环境中被使用，以及一旦自己的程序产生某种漏洞，最终会导致什么后果。简单的说，web程序被安装在一台或多台（分布式）web服务器上，一旦安装成功，就等于在为广大用户提供服务的同时，给入侵者打开了一条或N条新的思路。如果服务器管理员刚好对安全配置不了解（事实上，国内这种管理员居多），那么只好由我们的程序来守好最后的关卡最后一道防线。 看了本文题目，一定有一部分人会认为，“不就是讲 *** P漏洞么，用得着披着这么厚的包装么？”，为了回答这个疑问，我们先看看 *** P和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、 *** 、CSS，完了，这活还干不成。而这些只是简单的页面修改，如果客户今天说，MYSQL服务器承担不了这个数据量，要挂Oracle，可怜的程序员就要在一片一片的代码海洋里寻找执行SQL语句的代码，而每一个文件都可能存放着SQL语句，意味着每一个文件都可能在受SQL注入的威胁。
而 *** P采用MVC模式分层架构进行开发，就可以把所有的文件分开，根据其用途，分别放在不同的文件夹下（分层），每个文件夹下的文件只负责自己的事情。例如数据访问层的代码就放在数据访问层的文件夹下，业务逻辑层的代码也都放在自己的文件夹下，当显示层（这一层是为了把最终的运算结果显示给用户看）的需求发生变化，就像前面的客户需求，我们只要修改这一层的文件就是了，其他层的代码根本不需要动，而修改者也不需要懂得其它层的代码。 代码分层了，意味着漏洞也在跟着分层，我们寻找 *** P漏洞的思路也要跟着分层，才能与时俱进。 下面在讲述寻找漏洞的过程中，本文就拿一个简单的分层架构例子来做样板。样板程序的名称为“XX文章系统”，系统使用了STRUTS框架，和安全有关的层分为： “DB层”，这一层存放了链接数据库的字符串，以及JdbcTemplate类，直接访问数据库。因为在java中，执行SQL语句的函数按照返回值可以分为三类，所以在这一层定义了JDBC模版类（JdbcTemplate），每一次使用操作数据库时都要执行这一层的三个 *** 其中一个。 “DAO层（Data Access Object数据访问对象层）”，从安全角度上看，这一层存放了SQL语句（并不执行SQL语句，语句传给DB层执行）。这一层调用“DB层”访问数据库，它只知道“DB层”的存在，不知道数据库的存在。 “SERVICE层”，业务逻辑层，因为一个业务的实现，并不是一次数据库访问就可以完成的，所以这一层通过N次调用“DAO层的 *** ”实现业务逻辑，它只知道“DAO层”的存在，不知道“DB层”和数据库的存在。 “ACTION层”，调用业务逻辑层，根据返回的结果，控制 *** P页面显示。它只知道业务层的存在。这一层是入侵者的攻击平台。 “Form层”，把用户POST提交的信息封装成Form对象，经过验证后提交给ACTION层处理。 “ *** P层”(显示层)，这一层是最终显示给用户看的页面，同时也是入侵者的攻击平台。 用户通过访问ACTION层，自动会发生：“ACTION调用SERVICE，SERVICE调用DAO，DAO调用DB，DB执行SQL语句返回结果给DAO，DAO返回给SERVICE，SERVICE返回给ACTION，ACTION把数据显示到 *** P里返回给用户”。 有了样板，我们来分析这套程序中可能出现的各种web漏洞。 1、SQL注入漏洞 从SQL注入漏洞说起吧，在web漏洞里，SQL注入是最容易被利用而又更具有危害性的。怎么快速的找到呢？先分析流程，就拿用户查看文章这个流程为例：用户访问一个
action，告诉它用户想看ID为7的文章，这个action就会继续完成前面所说的流程。 如果是ASP程序，这就是最容易产生问题的时候，ASP是弱类型，接到参数后不需要转换类型，就和SQL语句连加起来。但是 *** P就不一样， *** P是强类型的语言，接受有害的参数后：对于GET请求（直接在地址栏访问页面），如果这里要的是int型，即使不懂安全的程序员，也会把它（文章的ID）立刻转换成int，因为这里转换后在后面的处理中会更容易操作，而这时程序就出错了；对于POST请求，如果这里要的是int型，程序会在把它封装成Form对象时，因为自动要进行类型转化，同样发生错误，这两种错误发生后，根本不会访问后面的流程就跳出了，或许这就是 *** P天生的安全性。所以，通常提交的变量是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程序里找注入时的思路就是这样子，但是我们现在是在使用了开发模式分层架构的 *** P程序里，应该按照分层架构的思维去找漏洞。在回答这个问题之前，我们还得绕个弯子，看看怎么在这里预防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、暴露程序信息漏洞 这个漏洞是怎么来的呢？我们需要从异常说起。有经验的入侵者，可以从 *** P程序的异常中获取很多信息，比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等，这个漏洞很容易防御，却很难快速定位漏洞文件。出现这样漏洞的时候，通常是我们在写代码的时候，少了一些可能性的考虑而导致的。这样的问题都是经验造成的，而寻找漏洞也要通过经验加运气（要有仙缘。。。），我个人技术有限，就不多说了。防御的 *** 就是在程序中加上“Exception层”，自定义异常，把系统产生的异常统统包装起来，不要放过任何一个可能产生异常的地方。像腾讯的异常就包装的很好“对不起，今天的注册人数已经达到十万，请您明天再来。。。”，废话，日注册量都十万，还让不让人活啦，铁定是程序发生了异常，不敢让各位大大们看到真实的面孔。