其实早就萌生了转WP的念头,但是迟迟没有动手,一是懒的折腾,二是Emlog这一轻量级的开源博客程序确实好用。EM的缺点也是优点,轻量级必然功能要相对弱些。虽然有时候可以自己折腾,但是自己精力有限,而且频繁更改源代码会导致博客可维护性下降。WP的优点众所周知,功能强大,插件也多。很多人诟病WP臃肿,运行效率低,占用资源多,但是从软件开发的角度来讲,WP主题模板化、功能插件化是必然的趋势。我对插件化产生好感是因为以前做的一个项目,使用了开源搜索引擎Nutch,里面的除了内核,其他功能都是用插件实现,二次开发很方便。另一个例子就是Firefox,本身功能一般,但是配合万能的插件,很好很强大的说。使用插件的缺点就是接口多,调用多,运行效率自然就打折扣了,资源占用必然也会飙升。
Emlog转WordPress详解
数据库插入数据长度过大,出现提示:将截断字符串或二进制数据
异常代码:
org.hibernate.exception.GenericJDBCException: could not insert: [com.huama.equma.entity.DicPackage]
java.sql.DataTruncation: Data truncation
java.sql.SQLException: 将截断字符串或二进制数据org.hibernate.exception.GenericJDBCException: could not insert: [com.yp.Person]
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2272)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2665)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:60)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at com.yp.db.PersistenceService.save(PersistenceService.java:191)
at com.yp.action.PersonAction.personAdd(PersonAction.java:216)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.struts.actions.DispatchAction.dispatchMethod(DispatchAction.java:274)
at org.apache.struts.actions.DispatchAction.execute(DispatchAction.java:194)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1194)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.yp.db.Filter.doFilter(PersistenceFilter.java:46)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.yp.util.Filter.doFilter(EncodingFilter.java:45)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.sql.DataTruncation: Data truncation
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:378)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2778)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2214)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:597)
at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:465)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:427)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeUpdate(JtdsPreparedStatement.java:397)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeUpdate(NewProxyPreparedStatement.java:105)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:23)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2252)
… 45 more
出错分析:在jdbc插入数据时,当数据库表中某列设置的长度小于要插入的字符的实际长度时就会抛出此异常。
如:数据表中某列char [4],长度为4,插入:”string”时,字符”string”长度超过4,抛出异常。据超过了字段的限制导致截断
解决方法:在.hbm配置文件中把String长度设置大一些,默认是255
sql注入
sql注入
所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.
当应用程序使用输入内容来构造动态sql语句以访问数据库时,会发生sql注入攻击。如果代码 使用存储过程,而这些存储过程作为包含未筛选的用户输入的字符串来传递,也会发生sql注入。sql注入可能导致攻击者使用应用程序登陆在数据库中执行命 令。如果应用程序使用特权过高的帐户连接到数据库,这种问题会变得很严重。在某些表单中,用户输入的内容直接用来构造(或者影响)动态sql命令,或者作 为存储过程的输入参数,这些表单特别容易受到sql注入的攻击。而许多网站程序在编写时,没有对用户输入的合法性进行判断或者程序中本身的变量处理不当, 使应用程序存在安全隐患。这样,用户就可以提交一段数据库查询的代码,根据程序返回的结果,获得一些敏感的信息或者控制整个服务器,于是sql注入就发生 了。
注入大致方法:
先猜表名
And (Select count(*) from 表名)<>0
猜列名
And (Select count(列名) from 表名)<>0
或者也可以这样
and exists (select * from 表名)
and exists (select 列名 from 表名)
返回正确的,那么写的表名或列名就是正确
这里要注意的是,exists这个不能应用于猜内容上,例如and exists (select len(user) from admin)>3 这样是不信的
现在很多人都是喜欢查询里面的内容,一旦iis没有关闭错误提示的,那么就可以利用报错方法轻松获得库里面的内容
获得数据库连接用户名:;and user>0
这个是小竹提出来的,我这里引用《SQL注入天书》里面的一段话来讲解:
----------------------------------------------------------------------------------------------------------
"重点在and user>0,我们知道,user是SQLServer的一个内置变量,它的值是当前连接的用户名,类型为nvarchar。拿一个 nvarchar的值跟int的数0比较,系统会先试图将nvarchar的值转成int型,当然,转的过程中肯定会出错,SQLServer
的出错提示是:将nvarch"
-----------------------------------------------------------------------------------------------------------
看到这里大家明白了吧,报错的原理就是利用SQLserver内置的系统表进行转换查询,转换 过程会出错,然后就会显示出在网页上,另外还有类似的and 1=(selet top 1 user from admin),这种语句也是可以爆出来的。;and db_name()>0 则
是暴数据库名。
一旦关闭了IIS报错,那么还可以用union(联合查询)来查内容,主要语句就是
Order by 10
And 1=2 union select 1,2,3,4,5,6,7,8,9,10 from admin
And 1=2 union select 1,2,3,user,5,passwd,7,8,9,10 from admin
上面的order by 10主要就是查字段数目,admin就是表名,可以自己猜,user,passwd是列名
反正就是返回正确即对,返回异常即错
另外还有十分常用的ascll码拆半法
先要知道指定列名,例如user里的内容的长度
and (select len(user) from admin)=2 就是查询长度为不为2位,返回错误的增加或减少数字,一般这个数字不会太大,太大的就要放弃了,猜也多余
后面的逻辑符号可以根据不同要求更改的,
>大于 <小于 =就是等于咯,更新语句的话,=也可以表示传递符号 <>就是不等
知道了长度后就可以开始猜解了
And (Select top 1 asc(mid(user,n,1)) from admin)>100
n就是猜解的表名的第几位,最后的长度数字就是刚才猜解出来的列名长度了,And (Select top 1 asc(mid(user,1,1)) from admin)>100 就是猜解user里内容的第一位的ASCLL字符是不是大于100
正确的话,那么表示USER第一个字符的ASCLL码大于100,那么就猜>120,返回错误就是介于100-120之间,然后再一步一步的缩少,最终得到正确字符XXX,然后用ASCLL转换器吧这个转换成普通字符就可以了
然后就是第二位 And (Select top 1 asc(mid(user,2,1)) from admin)>100 一直猜下去
加在url后面,列名表名还是先猜解,返回正确的代表帐号的ascll码大于100,那么就再向前猜,指导报错,把猜出来的ascll码拿去ascll转换器转换就可以了,中文是负数,加上asb取绝对值
And (Select top 1 asb(asc(mid(user,n,1))) from admin)>15320
得到之后就记得在数字前加-号,不然ASCLL转换器转换不来的,中文在ASCLL码里是-23423这样的,所以猜起来挺麻烦
这个猜解速度比较慢,但是效果最好,最具有广泛性
2.2.后台身份验证绕过漏洞
验证绕过漏洞就是'or'='or'后台绕过漏洞,利用的就是AND和OR的运算规则,从而造成后台脚本逻辑性错误
例如管理员的账号密码都是admin,那么再比如后台的数据库查询语句是
user=request("user")
passwd=request("passwd")
sql='select admin from adminbate where user='&'''&user&'''&' and passwd='&'''&passwd&'''
那么我使用'or 'a'='a来做用户名密码的话,那么查询就变成了
select admin from adminbate where user=''or 'a'='a' and passwd=''or 'a'='a'
这样的话,根据运算规则,这里一共有4个查询语句,那么查询结果就是 假or真and假or真,先算and 再算or,最终结果为真,这样就可以进到后台了
这种漏洞存在必须要有2个条件,第一个:在后台验证代码上,账号密码的查询是要同一条查询语句,也就是类似
sql="select * from admin where username='"&username&'&"passwd='"&passwd&'
如果一旦账号密码是分开查询的,先查帐号,再查密码,这样的话就没有办法了。
第二就是要看密码加不加密,一旦被MD5加密或者其他加密方式加密的,那就要看第一种条件有没有可以,没有达到第一种条件的话,那就没有戏了
3 防御方法
对于怎么防御SQL注入呢,这个网上很多,我这里讲几个
如果自己编写防注代码,一般是先定义一个函数,再在里面写入要过滤的关键词,如select ; “”;form;等,这些关键词都是查询语句最常用的词语,一旦过滤了,那么用户自己构造提交的数据就不会完整地参与数据库的操作。
当然如果你的网站提交的数据全部都是数字的,可以使用小竹提供的方法
Function SafeRequest(ParaName,ParaType)
'— 传入参数 —
'ParaName:参数名称-字符型
'ParaType:参数类型-数字型(1表示以上参数是数字,0表示以上参数为字符)
Dim ParaValue
ParaValue=Request(ParaName)
If ParaType=1 then
If not isNumeric(ParaValue) then
Response.write "参数" & ParaName & "必须为数字型!"
Response.end
End if
Else
ParaValue=replace(ParaValue,"'","''")
End if
SafeRequest=ParaValue
End function
然后就用SafeRequest()来过滤参数 ,检查参数是否为数字,不是数字的就不能通过
近期评论