网站10大常见安全漏洞及解决方案

https://blog.csdn.net/shanhanyu/article/details/80515892

1. SQL注入 安全等级★★★★★

实际上这个漏洞很严重，一旦被注入成功，后果不堪设想，但这类问题处理起来还是蛮简单的，下面以JAVA为例举例说明

推荐方案，使用预编译的prepareStatement代替statement；使用框架中的setParameter设置参数，此方案可有效处理SQL注入问题。

@Override
public List<NewsColumn> getColumnListByType(String columnType) {
String jql = " FROM "+NewsColumn.class.getName(，)+" WHERE type=:type ";
List<NewsColumn> list = entityManager.createQuery(jql).setParameter("type", columnType).getResultList();
return list;
}

 

2. 验证码必须后台校验 安全等级★★★★

前段时间一客户说后台管理看到了一堆这样用户，/etc/init.d /1=1 ./././ …. Windows/ ，本该截图的，后来处理了就给忘了~~~~，反正从注册内容来看，可以确定两点，通过注册机注册，想通过注册注入攻击。

通过机器注册：直接跳过了前端的表单校验，而恰巧这个项目在开发的时候，验证码只在前端做了校验，提交到后台没有做再一次的校验，也就是这个漏洞导致了这堆垃圾注册。

解决方案：前台提交数据到后台后做进一步校验，如验证码校验、数据格式校验、验重校验。

3. 防止表单重复提交 安全等级★★★

防止表单重复提交其实网上有很多解决方案，并且现在主流的前端框架都可以在页面上做按钮控制，不过做为一个程序员，你们懂得，这并没有什么卵用。个人还是建议采用实际的后台验证法处理。从网上爬文，看到的靠谱的解决方案如下。

解决方案：token验证，请求页面时生成token并放在session中，提交表单到后台验证token，业务逻辑处理完之后，清除token。如果表单提交了一次，token就没了，再次提交就无法通过了。

方案分析：此方法和验证码基本上一致，如果验证码在每次表单提交后都清除一次，也能达到这样的效果。

其他建议：重要的表单页面提交后重定向，取消表单的autocomplete。

4. 文件上传格式校验 安全等级★★★★

黑客攻击网站还有一个常见的方式就是通过文件上传漏洞，比如网站上传图片的功能没有严格校验后缀名。黑客可以通过此功能上传一些脚本文件，上传成功后，通过请求这些脚本文件运行脚本中的功能达到攻击的目的。

那么如果验证了上传文件的后缀名就可以吗？实际上并不是，举例说我们知道页面引入script标签时src写啥都行，比如http://www.baidu.com/123.jpg，也是可以的，攻击者只需要把一个script文件后缀名改为jpg即可通过后缀验证，后面一路畅通。所以这就提到了验证文件的真实格式。如何验证，网上一大堆…

解决方案：设置php文件、jsp文件不可直接被访问（不知道php可以不，jsp放在WEB-INF即可），这样攻击者上传此类文件也无法执行；通过文件头信息严格验证文件格式，从上传功能开始防范。

5. 熟悉使用框架或数据库版本情况 安全等级★★

实际开发中，我们都使用一些开源框架，但这些框架也不是百分百完善的，比如webwork,struts2就经常爆出一些漏洞，这个需要开发者自行关注。

解决方案：根据官方发布的方案进行版本升级；根据公开的漏洞执行方式编写拦截器。

Struts2 s2-016 漏洞处理实例（项目结构不允许版本升级），拦截器，实际上官方的版本也是升级后过滤了一些参数。

@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse res = (HttpServletResponse)response;
//禁止页面被frame
res.addHeader("x-frame-options","SAMEORIGIN");
Map parameterMap = req.getParameterMap();
for (Iterator iterator = parameterMap.keySet().iterator(); iterator.hasNext();) {
String key = (String) iterator.next();
if ((key.contains("redirect:")) || (key.contains("redirectAction:")) || (key.contains("action:"))) {
res.sendError(HttpServletResponse.SC_FORBIDDEN, "forbidden");
System.out.println("----------非法操作-----------");
return;
}
}
filterChain.doFilter(request, response);
}

6. 严禁在生产环境下使用缺省密码 安全等级★★

很多时候一些小网站，新人练手的网站（往往价格很便宜），在开发的过程中都要求很快，往往这些网站问题还是蛮多的。后台验证码处于关闭状态、账号密码常用admin/admin组合，看似方便了操作，实际是危险重重。甚至有时候，数据库链接密码都是root/空，这个危害大家都知道。由于没有验证码，用户密码又使用的缺省的，黑客爆破的概率异常的高，一旦获取了后台管理权限，剩下的就交给你了。

解决方案：通过配置测试模式和生产模式控制验证码验证，管理员账户必须使用非缺省加密处理，必要时使用物理验证。

7. 服务器端口尽可能少开 安全等级★★★

六月份一个客户的服务器被挂马了，服务器一直是他们自行维护，只在项目更新时给我们开放远程。无意中发现服务器防火墙竟然是关闭状态~~~~我的天呐，是不是所有端口都处于开放状态呐~~~~你们以为这就是惊喜，惊喜还在后面呢，客户提供的MySQL数据库用户名明码是root root，个人认为这个才是惊喜。root/root和root/空是一样的效果。分析了一下，防火墙关闭了，3306也就开了，黑客发现3306开着(3306是MySQL的默认端口)，root/root能连接，通过windows漏洞提升root用户为系统用户，bingo，竟然可以登录这台服务器欸，简直棒棒哒。

解决方案：防护墙打开，仅开放必要的端口如80，13389，设置远程登录IP白名单。再次强调不要用缺省账户(你在使用某一APP/网站时，自动登录的账号)。

8. Options方法过滤 安全等级★

这个问题网上提到的都是很严重，但现在并没有发现多少案例，或许处理方案比较简单吧。

解决方案：在web.xml添加配置 

<!-- 过滤不安全的请求方法 -->
<security-constraint>
<web-resource-collection>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>

9. XSS攻击、CSRF攻击 安全等级★

XSSS攻击处理方案一般来说也是通过拦截器过滤请求参数，都是常规的处理方案。