java项目遇到风险漏洞示例与解决方案

在十九大召开之前，出于安全生产的考虑，公司的项目遭受了各种途径的测试，检出了一堆bug，然后就是加班、修改、测试、加班。。。。。。
在此把项目的一些风险漏洞和解决方案记录下来。

1. 敏感信息泄露

漏洞描述：敏感信息泄露漏洞，是一种通过提交错误请求，使系统出现异常处理并报错，并且将系统程序、配置 等敏感信息泄露出来的漏洞。工程师发现系统搜索功能模块中普遍将系统的报错通printStackTrace 方法进行反馈，可造成报错信息如实的返回到前端。

漏洞影响：攻击者可以利用此漏洞收集系统报错中泄露的数据信息，包括处理函数，系统版本等等。可以通过此 类问题获得深入和更有目的性攻击的条件。

建议对策：建议统一处理错误页面，将错误信息存储在日志中。

2. 用户名密码未加密传输

漏洞描述：用户名密码采用编码后进行传输，容易被嗅探获取认证信息，建议采用加密后进行传输。

建议对策：1.使用可逆的加密算法，在客户端使用js同时加密用户名和密码，在后台解密进行登录操作。（有风 险）2.使用不可逆加密算法在前台加密密码（只是密码），当然在数据库里存储的密码也是使用相同 算法加密的（安全性能较高）

3. 未设置跨站注入过滤器

漏洞描述：不良用户通过编写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)。

4. 短信轰炸

漏洞描述：发送短信验证码未进行次数限制，可以不断发送短信验证码，导致一定的经济损失。

建议对策：建议对发送的短信验证码进行频率限制，一段时间内仅仅发送多少条短信。

5. 越权修改用户信息

漏洞描述：修改用户信息时，仅根据参数userid进行操作，存在越权修改任意用户信息问题。

建议对策：在系统中设置session机制，用户登录时在session写入用户信息，用户在修改信息时先取session信息，验证userid与当前session中保存的userid是否一致。

6. URL跳转

漏洞描述：任意URL恶意跳转可能会导致钓鱼等风险。

建议对策:改变传值方式，可以在前台传入对应type，根据type跳转到页面

7. 文件上传

漏洞描述：项目中涉及上传下载未对文件大小以及类型进行验证，可能导致不良用户上传有害文件，危害服务器

建议对策：文件上传时在前台对文件后缀名进行验证，为避免通过特殊手段绕过了前端验证，在文件 保存时再进行一次验证，即前后台同时验证的道理。

8.注释信息泄露

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

建议对策：及时删除注释代码，有价值代码在本地备份。

9. 弱口令

漏洞描述：密码机制过于简单

建议对策:1. 建议在开发过程中增加对账户口令条件的限制，如12位长度以上包含数字、字母、特殊字符件。

2.校验密码不能与用户名相同，修改密码时不能使用前五次或上次密码

3. 增加验证码登录，增加暴力破解的难度

4.增加用户锁定机制

建议对策只是提供一种解决思路，水平有限，不免有误，不恰当的地方请指出，不胜感激！