首次遭遇JSP挂马（JFolder），心惊胆战啊，想请教一下防治办法

fannyxjf 2009-09-17

网站架构是Struts2+Hibernate+Spring,数据库是sql server 2005，web容器是tomcat6，服务器的操作系统是windows server 2003,要说上传功能的话，唯一的上传渠道就是fckeditor里的上传。

昨天发现tomcat的webapps目录下有不知哪里来的war包：dream.war和userpass.war，好奇访问了一下{webroot}/dream，界面跟这个网址一样（这位可怜的站长也被挂马了）：http://informationtimes.dayoo.com/bison/go.jsp。心里顿时一凉：不会是传说中的挂马吧。。。

后来把这两个war包删除，请教了一下信息安全专业的同学的意见，检查了数据库，xp_cmdshell没有开启，排除了数据库注入的可能（其实这个我也云里雾里的不知道什么意思）。然后google了一下“fckeditor木马”，发现fckeditor还真有上传木马的漏洞，猜想可能跟这个有关。不过我这个网站只有后台管理里面有fck，而且能够登录的账号也就有限的那几个，难道账号被人破解了。。。。

现在得到的一些建议就是给系统打补丁，用杀毒软件和360查杀，经常更换系统密码等常规做法，不知道各位还有没有其他的建议？还有就是能不能解释一下，那两个war包是怎么传到webapp下的？我觉得要搞清楚挂马的原理才能确定怎么防治……

AreYouOK? 2009-09-18

引用

那两个war包是怎么传到webapp下的？我觉得要搞清楚挂马的原理才能确定怎么防治……

可能有很多种办法，不好说一定是什么通过什么途径。
很多开发人员觉得天经地义的做法，都有可能成为被利用的漏洞。有兴趣可以研究一下入侵的手段，你会发现很多利用都是非常巧妙的。

web应用，最常见的两类漏洞就是SQL注入和XSS（跨站脚本），前者对威胁服务器，后者威胁终端用户。
要杜绝这两类问题，技术、原理都是非常简单的，就是很多开发人员根本没有那个意识。另外对xss来说，每个字段都要escape一下，是个体力活。

引用

（其实这个我也云里雾里的不知道什么意思）

你最好弄清楚那是怎么回事，否则也不太可能很好的杜绝这类问题。
举个例子来说，针对注入的：
假设你是个论坛吧，他可以发个帖子（或者是其他的文本），把木马（他用来执行操作系统命令的jsp文件）放到帖子的正文里面，传到你的数据库的某个字段里面。
然后利用注入，执行数据库的命令，将字段里面的内容备份到文件系统的一个文件中，这样木马就传上去了。
问题1：他怎么知道哪个表哪个字段？
如果存在SQL注入，他是能分析你的数据库结构的。当然这需要比较高级的手段。不过针对很多通用的论坛系统或者是建站系统，数据库就是已知的了。
问题2：他怎么知道webapps的路径在哪里？
a、通过app server的漏洞可能会暴露脚本的路径；
b、有的服务器的错误页面会显示脚本的路径；
c、通过注入漏洞或其他漏洞获得管理员的帐号以后，进入管理界面，能够得到很多信息；
d、其他手段；

我这里只是个大概的说法，没有太多细节，因为我也没有专门研究过怎么黑别人的网站。不过针对注入、XSS的文章，网上一大把一大把的。

-----------------------------------------
预防措施：

一定要杜绝SQL注入问题，这个问题非常严肃，SQL注入可以利用的手段非常多，后果也非常严重。

除了操作系统的补丁，第三方软件的漏洞也会降低安全性。你这里至少包括数据库、tomcat、fck、甚至jdk、第三方jar等等都可以升级到大版本下的最新的补丁版本（即你用jdk1.5不一定要升到1.6，但要升级到1.5系列的最新版本）。

少留管理后门。管理员的密码要设置好。管理员越少越好，很多入侵都是从这里进入的，一点技术含量都没有，你还觉得黑客好高深。

最小权限原则，这个原则永远有用
针对数据库帐号，只授予最小的权限。
使用一个普通的操作系统用户运行tomcat，因为你是windows，NTFS默热是所有用户都可以读写的，所以你修改一下文件系统的权限，只让tomcat的用户能写log、tmp、fck的上传目录。fck的上传目录设置在web-inf下。这样即使黑客通过其他用户，比如数据库用户上传了jsp木马到你的war下，他也不能随意执行copy命令。
fck只允许上传特定的文件，比如pdf、doc、jsp。（总不能上传jsp吧）

关闭不需要的服务。

fannyxjf 2009-09-20

感谢二楼的耐心解答！
不过我一直以来理解的SQL注入就是利用数据库访问代码里面的sql拼凑，在页面上输入一些特殊的sql语句来达到目的。但我能够肯定我的代码里没有sql拼凑，都是通过setParameter的方式传参的。应该可以避免这个问题吧？还是说我对SQL注入的理解不够充分？我搜了一下相关资料，好像没看到还有什么特别的说法。

引用

最小权限原则，这个原则永远有用

嗯，这个我也意识到了，原先发布的时候想都没想，数据库链接用的是sa账号，这个已修正。

AreYouOK? 2009-09-22

引用

不过我一直以来理解的SQL注入就是利用数据库访问代码里面的sql拼凑，在页面上输入一些特殊的sql语句来达到目的。但我能够肯定我的代码里没有 sql拼凑，都是通过setParameter的方式传参的。应该可以避免这个问题吧？还是说我对SQL注入的理解不够充分？我搜了一下相关资料，好像没看到还有什么特别的说法。

用setXXX设置参数就是了，就没有问题了，原理很简单，但是一定要保证每个地方都是这样做的。如果每个开发人员都有良好的习惯，这应该不是个问题。

因为你自己说云里雾里的，所以我回复的时候需要强调一下。