Java（web）项目安全漏洞及解决方式【面试+工作】

Java（web）项目安全漏洞及解决方式【面试+工作】

一.安全性问题层次关系

大家经常会听到看到很多很多有关安全性方面的信息，可以说形形色色，对于在网络安全方面不太专业的同志来说，有点眼花缭乱，理不出头绪。在这里，我来帮大家整理一下。 　　以我个人多年来从事Web安全方面的工作经验及国外一些权威安全机构对Web安全的层次性的理解，我们通常把它分为三个层次： １.网络安全。如防火墙、路由器、网络结构等相关的安全问题 ２.系统与服务安全。如Window/Linux/Unix系统本身的漏洞或运行于其上的服务的安全，象Apache/OpenSSL/Weblogic等本身的安全性漏洞 ３.Web应用程序安全。具体应用程序的安全性漏洞，比如：某网站邮件系统因为存在脚本安全性问题，导致该邮件系统的用户在收到具有恶意代码的邮件时不知不觉的，其密码与帐号信息被人窃取。 　　说到这，大家应该清楚，不管你是在任何地方看到有关计算机安全性问题的方方面面，都逃不出这三大部分，同时我也要向读者声明一下：在这里，我主要是给大家陆续的介绍上述第三部分内容，即Web应用程序安全性相关知识与技能。 　　据权威搜索引擎公司统计数据显示，目前70%以上的网站，或多或少的存在安全隐患，这里的安全隐患指的就是Web应用程序的安全。

至于网络、系统与服务的安全性问题，我个人认为它的生存周期基本上是：发现->上报软件开发商->打补丁->下载更新程序。作为我们用户，及时的给系统与服务打上最新的补丁，配合一定的防火墙安全策略，是可以基本保证其安全的。

但是Web应用程序基本上是每个组织各持一套自己的程序，一切问题都必需自己动手去解决，恰恰因为此种特性，才导致目前运行于互联网上的Web应用的安全性普遍存在。为什么呢？因为只有少数组织或个人有能力驾驭网络安全相关的技术与经验，而绝大多数的即使是专业做网站开发的公司也不一定有知识有能力或有意识去考虑安全性问题． 　　还要向读者罗嗦一点是的：安全需要意识，没有安全意识的组织与个人，是无法保证其开发出的产品的安全性的。这一点很重要，很多人只是从媒体上看到听到一些安全性问题，总觉得安全性问题离自己很遥远，其不知安全性问题正在对其造成越来越严重的破坏......。前不久上海有一位朋友，银行卡的资金不明转出，且被人取走，报警后，经警方多方调查跟踪，最络查明：其经常使用网上银行的笔记本电脑中了“灰鸽子”木马，导致其操作电脑的行为及其电脑上的现在资源完全暴露无遗。

有人要问：“灰鸽子”是如何跑到其计算机上的呢？当然进去的途径有多种，比如我们是网友，我通过ＱＱ发给你让你运行一下；或者我向你推荐一款你比较感兴趣的免费软件，该软件内部已经绑定了“灰鸽子”木马程序......，还有一点很重要的就是通过网页来传播。比如通过脚本注入的方式，强行的不停的提示你下载并运行该程序；通过上传漏洞上传到一个你信任的网站上，当它提示你下载并安装时，你发现它来自你信任的网站，于是就接受了...... 　　总之，Web应用程序是我们接触最多最有可能通过带来安全隐患的载体。我将在之后的文章里步步向大家介绍Web应用程序安全性相关的知识、方法与我个人的多年从事web应用程序安全性检测的经验。希望我的努力就是您的需要。

二.安全性问题的本质

相信大家都或多或少的听过关于各种Web应用安全漏洞，诸如:跨site脚本攻击(XSS)，SQL注入，上传漏洞...形形色色. 　　在这里我并不否认各种命名与归类方式，也不评价其命名的合理性与否，我想告诉大家的是，形形色色的安全漏洞中，其实所蕴含安全问题本质往往只有几个。 我个人把Web应用程序安全性本质问题归结以下三个部分： １.输入／输出验证(Input/output validation) ２.角色验证或认证(Role authentication ) ３.所有权验证(Ownership authentication) 　　说到这，读者一定想知道我这三种分类与形形色色的安全性问题有什么关系？下面我逐个给您概略解答： 输入／输出验证 　　这里的输入与输出其实都是发生在用户界面（User Interface）这一个层面上的，比如：你某一站点上提交一份注册信息，往往会收到诸多提示：“用户名非法”，“姓名不能使用英文“......其实这就是输入验证的一个实例。什么情况是输出呢？　比如说你成功提交一份注册信息后，系统会返回一个确认页（Registerred Confirmation），往往在这个页面上会显示你注册时提交的部分或全部信息，那么在这里显示的信息就是我所说的输出实例之一，输入需要做什么验证？　假如你在提交时，在Address那一栏输入：<script>alert("iwebsecurity");</script>, 当你到达注册的确认页时，会有什么发生？如果确认页没有做输出验证处理，那很显然会在到达确认页的时候出现一个Javascript打出的提示框。其实这就是跨site脚本攻击的一个小小的实例。当然了，单纯的输入／输出验证涉及的面可能够写一小本书了，努力在后续文章中给大家详解。 角色验证或认证 　　我们就拿ＣＳＤＮ来说吧，用户有这些角色：其一可以说是游客，就是浏览者没有登录时的角色；其二是免费的注册用户；或许将来ＣＳＤＮ深入发展了，业务有所更新，还会出现收费的注册用户。以上只是用户角色，那在ＣＳＤＮ公司内部还会有管理员角色，还有可能管理员又可以根据板块分为各种不同的角色。大家看到了吧，你天天访问的ＣＳＤＮ一共可能有多少角色？　接下来的问题就是权限问题了，为什么会有角色？　就是为了控制权限的。每种角色都有自己特定的与公共的权限，这些权限的逻辑关系是相当复杂的，如果一个Web应用在角色上没有一个详细的合理的设计，将会给开发人员带来无限痛苦和麻烦。那现在我要问几个问题：你能保证每种角色只能做其份内的事儿？你是如何去保证的呢？方法可靠吗？有没有漏洞？......　这，就是我要说的角色验证或认证。ＢＴＷ：为什么我会说验证或认证呢？你可以这么理解，角色性存在于两个阶段，其一进入阶段，比如你登录的那一瞬间，你进入了一个特定的角色；另一个阶段就是维持阶段，你如何确保你登录后总是以登录时的身份在操作呢？那前者可以说是：认证，后者就是验证了。（有点罗嗦不？） 　　给一个角色认证／验证方面的虚拟案例，比如：一个在线电影服务提供商，会免费给您开一个试用角色，如果这试用角色验证不当，可能会导致用户权限提升而成为一个合法的收费用户，而这个收费用户你往往却收不到他的任何费用。 所有权验证 　　这个问题的存在也是基于角色的，只不过它所关心的是同级别的角色之间的权限问题。就拿ＣSＤＮ来说吧，我是ＣＳＤＮ的一个免费用户，你也是。现在的问题是：我可以替你操作吗，我可以替你发表文章吗？我能修改你的个性设置吗？如果不能，CSDN是如何实现的？虽然你和我都是普通用户，但是你有你的隐私我也有我的隐私，如何保证严格的所有权验证就显得尤为关键了。比较简单吧，这就是我所说的所有权验证。 　　我可以很自信的告诉你，只要是Web应用安全性问题，它逃不出在这三大部分，可能你还无法把形形色色的Web应用安全性问题与这三个部分对应并合理的解释清楚，但是确实只有这么简单的几个部分。

三.安全漏洞及处理方式

1、SQL注入攻击

SQL注入攻击就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将(恶意)的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入(恶意)SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

　 随着B/S框架结构在系统开发中的广泛应用，恶意攻击者利用SQL命令在Web表单中输入合法的字符或查询字符串来欺骗服务器执行SQL命令。当注入攻击得逞后，Web程序将泄露大量用户隐私数据和数据库中数据结构。攻击者能够获得系统较高的访问权限，进行破坏操作。

SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致;后者主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。基于此，SQL注入的产生原因通常表现在以下几方面:

1）不当的类型处理;

2）不安全的数据库配置;

3）不合理的查询集处理;

4）不当的错误处理;

5）转义字符处理不合适;

6) 多个提交处理不当。

解决方法:

数据库安全通信包括SQL注入攻击的防范、安全设置、异常信息处理三个方面。

1.服务端Filter对访问者输入的字符进行过滤检验，但是攻击者经常把危险字符潜藏在用户输入的有效字符中完 成过滤检验。

2.通过正则表达式对页面的文本框输入的数据进行限制可以减少过滤检验存在的漏洞。

3.使用prepareStatment预编译sql语句

2、XSS跨站脚本攻击

跨站脚本（Cross-site scripting，简称XSS），是一种迫使Web站点回显可执行代码的攻击技术，而这些可执行代码由攻击者提供、最终为用户浏览器加载。不同于大多数攻击（一般只涉及攻击者和受害者），XSS涉及到三方，即攻击者、客户端与网站。XSS的攻击目标是为了盗取客户端的cookie或者其他网站用于识别客户端身份的敏感信息。获取到合法用户的信息后，攻击者甚至可以假冒最终用户与网站进行交互。

XSS 属于被动式的攻击。攻击者先构造一个跨站页面，利用SCRIPT、<IMG>、<IFRAME>等各种方式使得用户浏览这个页面时，触发对被攻击站点的HTTP 请求。此时，如果被攻击者如果已经在被攻击站点登录，就会持有该站点cookie。这样该站点会认为被攻击者发起了一个HTTP请求。而实际上这个请求是在被攻击者不知情情况下发起的，由此攻击者在一定程度上达到了冒充被攻击者的目的。精心的构造这个攻击请求，可以达到冒充发文，夺取权限等多个攻击目的。在常见的攻击实例中，这个请求是通过script 来发起的，因此被称为Cross Site Script。

XSS漏洞成因是由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是“>”、“<”），然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。

分为三种类型：

1）反射型（数据流向：浏览器 ->后端 -> 浏览器）

反射型XSS脚本攻击即如我们上面所提到的XSS跨站脚本攻击方式，该类型只是简单地将用户输入的数据直接或未经过完善的安全过滤就在浏览器中进行输出，导致输出的数据中存在可被浏览器执行的代码数据。由于此种类型的跨站代码存在于URL中，所以黑客通常需要通过诱骗或加密变形等方式，将存在恶意代码的链接发给用户，只有用户点击以后才能使得攻击成功实施。

2）存储型（数据流向是：浏览器 ->后端 -> 数据库 -> 后端-> 浏览器）

存储型XSS脚本攻击是指Web应用程序会将用户输入的数据信息保存在服务端的数据库或其他文件形式中，网页进行数据查询展示时，会从数据库中获取数据内容，并将数据内容在网页中进行输出展示，因此存储型XSS具有较强的稳定性。

存储型XSS脚本攻击最为常见的场景就是在博客或新闻发布系统中，黑客将包含有恶意代码的数据信息直接写入文章或文章评论中，所有浏览文章或评论的用户，都会在他们客户端浏览器环境中执行插入的恶意代码。

3）基于DOM（数据流向是：URL-->浏览器 ）

基于DOM的XSS跨站脚本攻击是通过修改页面DOM节点数据信息而形成的XSS跨站脚本攻击。不同于反射型XSS和存储型XSS，基于DOM的XSS跨站脚本攻击往往需要针对具体的javascript DOM代码进行分析，并根据实际情况进行XSS跨站脚本攻击的利用。

解决方法：

1).输入过滤。对用户的所有输入数据进行检测，比如过滤其中的“<”、“>”、“/”等可能导致脚本注入的特殊字符，或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限制等等。同时，我们也要考虑用户可能绕开ASCII码，使用十六进制编码来输入脚本。因此，对用户输入的十六进制编码，我们也要进行相应的过滤。只要能够严格检测每一处交互点，保证对所有用户可能的输入都进行检测和XSS过滤，就能够有效地阻止XSS攻击。

2).输出编码。通过前面对XSS攻击的分析，我们可以看到，之所以会产生XSS攻击，就是因为Web应用程序将用户的输入直接嵌入到某个页面当中，作为该页面的HTML代码的一部分。因此，当Web应用程序将用户的输入数据输出到目标页面中时，只要用HtmlEncoder等工具先对这些数据进行编码，然后再输出到目标页面中。这样，如果用户输入一些HTML的脚本，也会被当成普通的文字，而不会成为目标页面HTML代码的一部分得到执行.

3、CSRF跨站请求伪造漏洞防护

CSRF是CrossSite Request Forgery的缩写，乍一看和XSS差不多的样子，但是其原理正好相反，XSS是利用合法用户获取其信息，而CSRF是伪造成合法用户发起请求。

根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。

解决方案：

配置FILTER拦截用户所有请求(POST/GET)，对用户请求Referer头URL进行合法性校验。

4、URL链接注入漏洞防护

链接注入是修改站点内容的行为，其方式为将外部站点的 URL 嵌入其中，或将有易受攻击的站点中的脚本 的 URL 嵌入其中。将URL 嵌入易受攻击的站点中，攻击者便能够以它为平台来启动对其他站点的攻击，以及攻击这个易受攻击的站点本身。

解决方案：

配置FILTER拦截用户所有请求，对用户参数进行关键字符校验进行合法性校验。

5、会话COOKIE中缺少HttpOnly防护

会话cookie中缺少HttpOnly属性会导致攻击者可以通过程序(JS脚本、Applet等)获取到用户的cookie信息，造成用户cookie信息泄露，增加攻击者的跨站脚本攻击威胁。

HttpOnly是微软对cookie做的扩展，该值指定cookie是否可通过客户端脚本访问。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie属性HttpOnly。

如果在Cookie中没有设置HttpOnly属性为true，可能导致Cookie被窃取。窃取的Cookie可以包含标识站点用户的敏感信息。

如果在Cookie中设置HttpOnly属性为true，兼容浏览器接收到HttpOnly cookie，那么客户端通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这将有助于缓解跨站点脚本威胁。

解决方案：

配置filter拦截器，将服务器端返回请求，向所有会话cookie中添加“HttpOnly”属性。

示例代码：

HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;

response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");

6、点击劫持漏洞(Clickjacking)防护

点击劫持是一种视觉上的欺骗手段，攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户在不知情的情况下点击了透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

解决方案：

配置FILTER拦截器，在服务器端返回请求中，使用一个HTTP头“X-Frame-Options”值为SAMEORIGIN-同源策略 ，则frame页面的地址只能为同源域名下面的页面，防止点击劫持漏洞发生。

示例代码：

HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;

response.addHeader("x-frame-options","SAMEORIGIN");

7、HTTP host 头攻击漏洞

使用HTTP代理工具，可以篡改HTTP报文头部中HOST字段时，该值可被注入恶意代码。因为需要控制客户端的输入，故该漏洞较难利用。

解决方案：

配置FILTER拦截器，对请求输入HOST头信息进行信息安全性校验，防止HOST头信息被恶意篡改利用。

示例代码：

HttpServletRequest request =(HttpServletRequest)servletRequest; //主机ip和端口 或 域名和端口 String myhosts = request.getHeader("host"); if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx") !StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){ logger.error("======访问host非法，已拦截======"); response.sendRedirect(request.getContextPath() + "/login.jsp"); return; }

8、越权访问漏洞防护

越权访问（Broken Access Control，简称BAC）是Web应用程序中一种常见的漏洞，分为垂直越权访问和水平越权访问。垂直越权是指不同用户级别之间的越权，如普通用户执行管理员用户的权限。水平越权是指相同级别用户之间的越权操作。

Web应用程序如果存在越权访问漏洞，可能导致以下危害：

1）导致任意用户敏感信息泄露；

2）导致任意用户信息被恶意修改或删除。

解决方案：

配置FILTER拦截器，对请求所有URL进行拦截，对于需要进行授权的URL进行权限校验，防止用户越权访问系统资源。

9.弱口令漏洞

密码机制过于简单

解决方案：最好使用至少6位的数字、字母及特殊字符组合作为密码。数据库不要存储明文密码，应存储MD5加密后的密文，由于目前普通的MD5加密已经可以被破解，最好可以多重MD5加密，或者多种加密方式叠加组合。

校验密码不能与用户名相同，修改密码时不能使用前五次或上次密码 增加验证码登录，增加暴力破解的难度 增加用户锁定机制

10．JSP页面抛出的异常可能暴露程序信息。

有经验的入侵者，可以从JSP程序的异常中获取很多信息，比如程序的部分架构、程序的物理路径、SQL注入爆出来的信息等。

解决方案：自定义一个Exception，将异常信息包装起来不要抛到页面上。

11.本地缓存漏洞

合法用户“注销”后，在未关闭浏览器的情况下，点击浏览器“后退”按钮，可从本地页面缓存中读取数据，绕过了服务端filter过滤。 解决方案：配置filter对存放敏感信息的页面限制页面缓存。如：

httpResponse.setHeader("Cache-Control","no-cache");

httpResponse.setHeader("Cache-Control","no-store");

httpResponse.setDateHeader("Expires",0);

httpResponse.setHeader("Pragma","no-cache");

12.文件上传漏洞。

前台仅使用JS对文件后缀做了过滤，这只能针对普通的用户，而恶意攻击者完全可以修改表单去掉JS校验。

项目中涉及上传下载未对文件大小以及类型进行验证，可能导致不良用户上传有害文件，危害服务器 解决方案：文件上传时在前台对文件后缀名进行验证，为避免通过特殊手段绕过了前端验证，在文件 保存时再进行一次验证，即前后台同时验证的道理。

13.Java WEB容器默认配置漏洞。

如TOMCAT后台管理漏洞，默认用户名及密码登录后可直接上传war文件获取webshell。

解决方案：最好删除，如需要使用它来管理维护，可更改其默认路径，口令及密码。

14.敏感信息泄露 敏感信息泄露漏洞，是一种通过提交错误请求，使系统出现异常处理并报错，并且将系统程序、配置 等敏感信息泄露出来的漏洞。工程师发现系统搜索功能模块中普遍将系统的报错通printStackTrace 方法进行反馈，可造成报错信息如实的返回到前端。 攻击者可以利用此漏洞收集系统报错中泄露的数据信息，包括处理函数，系统版本等等。可以通过此 类问题获得深入和更有目的性攻击的条件。 解决方案：建议统一处理错误页面，将错误信息存储在日志中。

15.用户名密码未加密传输 用户名密码采用编码后进行传输，容易被嗅探获取认证信息，建议采用加密后进行传输。 解决方案：1.使用可逆的加密算法，在客户端使用js同时加密用户名和密码，在后台解密进行登录操作。（有风 险）2.使用不可逆加密算法在前台加密密码（只是密码），当然在数据库里存储的密码也是使用相同 算法加密的（安全性能较高）

16.未设置跨站注入过滤器 不良用户通过编写sql，或者仿制页面盗取用户信息。 解决方案：在系统中设置拦截器，对sql语句和js语句进行拦截，具体需要拦截的词汇如下：(\b(alert|iframe|frame|ascii|script|and|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|delay|waitfor|char|declare|sitename|netuser|xp_cmdshell|or|like’|exec|execute|insert|create|”+”table|from|grant|use|group_concat|column_name|information_schema.columns|table_schema|union|where|”+”reg|between|having|groupby|groupby|waitfor|waitingfor|#|cast|convert|window|local|location|”+”–|like)\b)。

17.短信轰炸 发送短信验证码未进行次数限制，可以不断发送短信验证码，导致一定的经济损失。 解决方案：建议对发送的短信验证码进行频率限制，一段时间内仅仅发送多少条短信。

18.注释信息泄露 在开发过程中会存在将暂时不用的代码注释，以备后续使用的情况，但是时间长了可能项目会有大规 模的变动，例如将管理登录入口单独分离出来，这个地址只对内部开发，并不希望被外部而恰好这个 地址在之前的页面注释了，这就导致了重要信息泄露。 解决方案：及时删除注释代码，有价值代码在本地备份。

19.URL跳转 任意URL恶意跳转可能会导致钓鱼等风险。 解决方案：改变传值方式，可以在前台传入对应type，根据type跳转到页面