漏洞类型 | 造成原因 | 修复方案 |
重定向攻击 | 跳转的URL由前端输入,存在跳转URL被篡改、构造危害URL地址,导致用户受到攻击 | 方案1、后台设置跳转白名单 方案2、前端提交跳转标识字符,后端返回约定后的URL重定向地址 |
服务器端请求伪造(SSRF) | 一般与使用场景有关,在提交http报文时,报文body参数内容包含完成URL地址,被替换为挂马等有危害URL地址。当用户浏览如后台管理员去审核时,自动会加载有危害URL导致管理员用户受到攻击。另一种构造有危害协议请求从服务端发端攻击内网。 | 1、提交报文时,前端用户不提交完整的URL 3、 只允许http、https协议,限制file、gopher、ftp等协议 |
XXE漏洞 | 在xml类型数据提交中,构造了对外部实体引用。 | 因不同的xml解析库,修复代码也不同,但都是通过以下方式解决: 1、禁止加载外部实体; 2、不允许XML中含有任何自己声明的DTD |
短信轰炸 | 总体是逻辑设计问题导致,可能是没有验证码、或验证码可重复使用 | 发送间隔60s,一次发送只能到一个手机号 或图片验证码使用一次立即失效等手段 |
容器信息泄露 | 服务端未如对如404、500类似错误没有屏蔽,直接把容器中间件等信息返回给前端。导致通过此信息查漏洞直接攻击 | 在框架里或tomcat里配置统一出错页面或信息,或在nginx里指定统一出错信息等手段,尽量避免信息泄露 |
越权访问 | 前端在做数据做增、删、改、查时,后端没有做权限 、数据归属做验证 | 对操作的数据时,验证此数据是否归此用户权并有权限操作 |
数据遍历 | 数据通过改变ID即可访问 | 1、增加ID的复杂度,设计的ID无法正常可以猜到 2、访问时对用户鉴权 |
XSS | 对危险的字符过滤不全,导致存在XSS风险 | XSS与业务密切相关,没有好的统一解决方案。一个项目无法只靠一个xss过滤器就能解决所有的XSS问题。总体就是破坏js脚本结构。 | & ; $ % @ ' " + CR LF , . = #都是有风险的字符,建议项目统一用宽一点过滤器,在接口里参数要求严格验证。 |
CSRF | CSRF是web应用的基本问题,WEB程序缺少安全设计导致黑客通过用户可攻击系统,用户或系统同时遭受损失。 | 在重要的表单提交验证http头referer参数及在接口增加验证动态验证码、页面影藏参数一起提交。具体需要看业务来实现 |
SQL注入 | 参数拼接导致 | 所有参数都应采用预编译sql写法即可避免 |
文件上传 | 未验证上传文件类型,可导致上传木马(webshell) | 根据需求验证文件类型,或排除以下文件后缀,jsp,jspx、php,vbs,ps1,exe,asp,aspx,sh,py,rb,html,htm、js、css |
第三方库漏洞 | 引用有漏洞的库。在架构项目时没有检查第三方库,引用的库版本太旧,或第三方库出了新漏洞没有及时升级。 | 在引用库时应检查一下此库的最新版本,引用最新版本。 |
任意文件下载 | 前端传入下载文件路径,服务端没有做路径验证,导致可下载服务端任意文件 | 验证前端传入路径或修改程序设计,通过前端传文件ID由服务端去查到文件后再返回 |
注释代码未清除 | 不需要功能在前端注释,被爬虫爬到此接口进行攻击。危害程度取决于注释功能的。 | 注释功能 同时在前后端同步去除不必须功能代码,减少攻击面 |
业务缺陷 | 业务实现时没有对业务需求做安全评估,没有采用安全设计去实现业务逻辑。信任前端数据输入,没有做验证导致。 | 根据具体业务做分析,应避免逻辑绕过及对前端的数据做充分验证 |
用户密码泄露 | 返回用户名和密码给前端,这是世界上最傻的安全问题 | 用户密码永远不要返回给前端 |