Java开发网络安全常见问题

1、敏感信息明文传输

用户敏感信息如手机号、银行卡号、验证码等涉及个人隐私的敏感信息不通过任何加密直接明文传输。

如下图中小红书APP 的手机短信验证码登录接口，此处没有对用户手机号和验证码等信息进行加密传输，可以很简单的截取并开展一些合法的工作。

可以对比下其他的APP，如美团APP 的手机短信验证码登录接口，就不是明文传输。

解决方案

前后端敏感参数的传递，可以通过加密手段如借助AES 秘钥前后端加解密传输。最简单的用户手机号加密传输如下。

2、弱口令漏洞

这种情况其实很常见，好多后台的管理系统，甚至我之前公司的管理系统现在使用123456这种密码都可以登录进去。

解决方案

很多登录的框架都支持在配置文件开启用户登录密码强度级别和设置默认密码。
使用至少12位的数字、字母及特殊字符组合作为密码。
数据库不要存储明文密码，应存储MD5加密后的密文，由于目前普通的MD5加密已经可以被破解，最好可以多重MD5加密，或者多种加密方式叠加组合。

3、绕过密码登录直接进入后台

首先，后台登陆验证的逻辑一般的方式都是将用户在登录界面输入的账号密码拿到数据库中的相关用户表做校验，如果输入的账号密码等于数据库中某条记录，则验证通过并且程序会给用户一个sssion，然后进入后台，反之就是返回登陆界面。

出现这种绕过密码登录的情况就是很早之前的典型案例 'or'='or' 漏洞，校验用户登录的SQL如下。

select * from t_user where user_name = '’or‘='or'' And password = '123456789'

如果用户名在登录界面的用户名处输入要提交的信息为 'or'='or' ，就会变成如上SQL（（假or真or假and（真/假））= 真）执行后得到对象的结果为真，接下来就可以通过重定向进入后台了。

View Code

解决方案

通过配置，过滤掉无效用户的登录请求。
很早之前才会出现这个漏洞，现在基本上的后台验证都不会使用这类方式，而是取得用户输入的账号和密码，在SQL中先将用户名与数据库中的记录做对比，若数据库中某条记录的用户名等于用户输入的用户名，则取出该条记录中的密码，然后再与用户输入的密码对比。

4、浏览器缓存漏洞

系统正常存在的合法用户在“注销”后，但未关闭浏览器，此时点击浏览器“后退”按钮，可从本地页面缓存中读取数据，绕过了服务端filter过滤。

解决方案

在很多项目的 Config 配置文件中都有发现的如下配置，即配置filter对存放敏感信息的页面限制缓存。

httpResponse.setHeader(“Cache-Control”,“no-cache”);
httpResponse.setHeader(“Cache-Control”,“no-store”);
httpResponse.setDateHeader(“Expires”, 0);
httpResponse.setHeader(“Pragma”,“no-cache”);

5、SQL注入漏洞

在HTTP 请求中注入恶意的SQL 代码，最常见的手段就是在访问URL 后拼接SQL 代码，服务器使用参数构建数据库SQL 命令时，恶意SQL 被一起构造，并在数据库中执行。如下拼接SQL

String query = “SELECT * FROM t_users WHERE user_id = ’” + request.getParameter(“id”) + “’”;

如果参数id 中是 or 1=1 ，就会返回所有数据。
解决方案

不要拼接SQL字符串。
使用预编译的PrepareStatement，如。

PreparedStatement pstmt = con.prepareStatement(“SELECT * FROM t_users WHERE u_name = ?”);
pstmt.setString(1, “tjt”);

服务器端校验 (防止攻击者绕过web端请求)。
过滤SQL 参数中的特殊字符，比如单引号、双引号等。

6、文件上传漏洞

在文件上传前端界面，用户上传了一个可执行的脚本文件，并通过此脚本文件获得执行服务端命令的能力。

解决方案

设置文件上传的目录为不可执行。
判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。以及限制上传文件的大小。
对上传的文件类型进行白名单校验，只允许上传可靠类型。
上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。
给文件服务器设置单独的域名。

7、WEB 容器漏洞

Tomcat 有一个管理后台，其用户名和密码在Tomcat安装目录下的conf omcat-users.xml文件中配置，很多用户经常采用的是一些弱口令。而Tomcat 又支持在后台部署war包，可以直接将webshell 部署到web目录下，如果tomcat 后台管理用户存在弱口令，这很容易被利用上传webshell。

解决方案

更改其默认路径，口令及密码。
Tomcat还有一些其他的漏洞，最有效的防御就是修改配置文件，防止未授权访问、弱口令、PUT方式传文件、readonly等，然后最好更新最新版本的tomcat。

8、XSS 攻击

XSS（cross site scripting，即跨站脚本攻击），将一段Html 和JavaScript 代码注入到用户浏览的网页上。XSS 可以大概分为三类， DomXSS、反射型XSS 和存储型XSS。

<input type="text" name="name" value="tjt">

在前端界面有很多用户输入字符的操作，如上表单，如果，用户输入的不是一个正常的字符串，而是

"/><script>alert(“tjt-hello-boy-isMe”)</script><!-

然后，JS页面变成下面的内容，在输入框 input 的后面带上了一段脚本代码。

<input type="text" name="name" value="tjt">

<script>alert(“tjt-hello-boy-isMe”)</script><!-"/>

从上可以看出，XSS攻击的威力取决于用户输入的JS 脚本。攻击者提交恶意的JS 代码，客户端没有做xss校验，都会存在客户端注入问题，就会出现这段恶意执行的JS 代码。

解决方案

前后端限制字符串输入的长度限制。
前后端限制对HTML 转义处理，将其中的"<",">"等特殊字符进行转义编码。

9、CSRF 攻击

XSRF Cross-site request forgery，即跨站请求伪造，指攻击者通过跨站请求，以合法的用户身份进行非法操作。攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF 能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息，容易造成个人隐私泄露以及财产安全。

早期就会有很多这种网站，挂了很多靓妹的图片或者让人有种想要点击的那些图片，一旦你点击了，其实是打开了一个链接比如发起银行转账请求，而你的浏览器又恰巧登录浏览过该银行并且缓存未失效，不出意外的话意外就发生了。随之后来的隐藏域手段、验证码、二次确认等机制这种攻击案例就少了。

解决方案

使用安全框架，如Apache shiro，Spring Security 等。
结合安全框架充分校验Token，在HTTP 请求中进行token 验证，如果请求中没有token或者token内容不正确，则认为CSRF攻击而拒绝该请求。
验证码二次确认。通常情况下，验证码能够很好的遏制CSRF攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案。
网上还说可以通过 referer识别。在HTTP Header中有一个字段Referer，记录HTTP请求的来源地址。如果Referer是其他网站，就有可能是CSRF攻击，则拒绝该请求。但Referer 信息也极易伪造，窃取HTTP 窃取源地址，Header中添加Referer 字段。

10、DDOS 攻击

DDoS:Distributed Denial of Service，DDOS 攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。它的目的就是利用目标系统网络服务功能缺陷或者直接消耗其系统资源，使得该目标系统无法提供正常的服务。
DDoS 攻击是通过大量合法的请求占用大量网络资源，以达到瘫痪网络的目的，其具体有下面几种形式：