省流

（1）接口设计前，一定要设计好，防止通过修改传参达到查到无法查到的数据
（2）避免黑客将病毒文件传到服务器上
（3）软硬结合保证页面不受篡改（比如waf）

具体问题

信息遍历【高风险】

描述

系统的架构设计不合理，表中的id使用的是自增型主键，导致在调用的时候，可以根据生成规则攻击从而获得大量的敏感信息，特别是用户信息或者文件下载信息

举例

比如接口为

http://xxx.xx.xx/server/info?id=1

攻击者可以猜测id为自增主键，然后把id改成2，从而获得id为2的信息

解决方案

（1）主键使用uuid作为主键（此处根据数据的保密性来进行合理的处理，使用自增主键更有利于查询的速度性，使用uuid更有利于保密性）

（2）如果使用了自增主键，在调用的web端进行加密，在server端进行解密

任意文件上传【高风险】

描述

系统的文件上传接口没有做任何的格式校验，导致攻击者可以上传js、cmd、shell、py的文件，在服务器中运行脚本获取服务的账号信息等

解决方案

（1）只要web容器无法解析该目录下面的文件，致使攻击者上传了脚本文件，服务器本身也不会受到影响，因此这一点至关重要；
（2）在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者 resize 函数，在处理图片的同时破坏图片中可能包含的HTML代码。上传接口的时候，判断文件的后缀名格式，比如

文档类：doc，docx，xls，xlsx，ppt，pptx，pdf，txt，wps
视频类：avi，wav，mp3,wma，mpg
图片类：png，gif，jpg，jepg
压缩包：zip，rar

严禁上传的类：
bmp文件：此文件可以注入很多攻击信息，漏洞极大
js文件：使用js脚本可以获取到很多数据信息

邮箱验证码等轰炸【中风险】

描述

如果邮箱验证码、手机短信码没有做一段时间内有效时间验证，那么攻击者可以根据调用接口，对某用户进行无限次数据轰炸（也浪费了很多短信数据包，费钱）

解决方案

如现在很多软件的方案一样，在验证码的表中增加时间戳，进行时间判断（比如5分钟之内有效，5分钟之内不再发送验证码等）

用户名轰炸【高风险】

描述

当用户登陆的时候，后台检索改用户名不存在是，如果返回“用户名不存在”，那攻击者可以暴力破解，来检验出哪些用户名是存在的

解决方案

当用户名不存在时，提示“用户名或密码错误”

错误信息返回敏感信息【高风险】

描述

当后台异常处理不到位，对页面抛出了异常信息，会在信息中出现数据库等字段。且返回给用户此信息也不合理

举例

 \n### Erro querying database.  Cause: java.sql.SQLException,******SELECT ID,NAME,CODE FROM TEST WHERE ID=? 表CODE字段不存在

解决方案

使用切面捕获异常，统一返回固定格式信息

明文传输漏洞【高风险】

描述

敏感数据明文传输简单点来说就是当我们在网站上面提交敏感数据到服务器的过程中未进行相关加密处理，导致攻击者通过中间人攻击方式（劫持、嗅探等）即可获取到这些未加密的敏感数据。当攻击者获取到这些数据之后，就可以用这些信息以合法用户的身份进入到应用系统中——甚至可能进入到应用系统后台中，一旦进入到应用系统中那么就可以获取更多的敏感数据，以及更有机会发现更多的漏洞。

举例

比如登录接口等，不能使用明文。如使用明文，通过中间人攻击方式（劫持、嗅探等）获取未加密的敏感数据，根据web用户登陆页面，直接进行暴力破解用户信息。

解决方案

对系统内所有涉及到密码等敏感数据传输地方做加密处理，从而在一定的程度上避免这些敏感的数据受到威胁。确保所有登录请求都以加密方式发送到服务器。确保敏感信息，例如：姓名、身份证号等信息一律以加密方式传给服务器。

点击劫持漏洞【中风险】

描述

点击劫持（Click Jacking）是一种视觉上的欺骗手段，攻击者通过使用一个透明的iframe，覆盖在一个网页上可以使得伪造的页面恰好和iframe里受害页面里一些功能重合（按钮），以达到窃取用户信息或者劫持用户操作的目的。比如：

（1）打开burp复制攻击代码

（2）打开网页目标网页，执行攻击代码发现页面已被覆盖，存在漏洞

解决方案

X-FRAME-OPTIONS（修改中间件配置）
X-FRAME-OPTIONS是微软提出的一个http头，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。这个头有三个值：
DENY 拒绝任何域加载
SAMEORIGIN 允许同源域下加载
ALLOW-FROM 可以定义允许frame加载的页面地址

可以在nginx，tomcat，iis，apache中配置，比如：https://blog.csdn.net/u014704612/article/details/115633050

不安全的http方法漏洞【中风险】（有待商榷）

描述

查看Web服务器是否在默认情况下开放了一些不必要的HTTP方法（如DELETE、PUT、TRACE、MOVE、COPY），防止增加受攻击的几率。

解决方案

这个问题其实是有异议的，后台小伙伴就懵逼了，咋Restful风格的规范，都用不了了嘛？其实当服务器配置合理的情况下，对于put和delete不会出现不安全的问题。但是为了防止出现问题，渗透测试也会将这块测试出来。这里建议根据系统的详细情况，酌情处理。反正对于TRACE，MOVE，COPY肯定是不用的，关闭即可。如果甲方大佬们要求必须使用post和get，那就换一下吧

https://blog.csdn.net/u014644574/article/details/122021773

HOST头攻击漏洞【低风险】（不是很理解）

描述

对开发人员来说，提取请求头中的Host参数写入当前页面是一个很不明智的选择。因为如果这样，攻击者就可以通过修改HTTP请求头中的Host字段，控制服务器返回页面中的URL。比如：

（1）在登录页面进行抓包

（2）修改host字段为其他域名，页面跳转至其他域名，发现问题。

解决方法

为了方便获取网站域名，开发人员一般依赖于请求包中的 Host 首部字段。例如，在 php 里用_SERVER[“HTTP_HOST”]。但是这个 Host 字段值是不可信赖的(可通过HTTP代理工具篡改)，如果应用程序没有对 Host 字段值进行处理，就有可能造成恶意代码的传入。

密码重置漏洞【高风险】

描述

最初设计时由于未考虑全找回密码、支付模块中程序的判断逻辑及程序的处理流程上存在缺陷，导致攻击者可以绕过程序的处理流程，从而达到特定的目的，如任意密码重置及各种支付漏洞。

举例

（1）修改密码界面，并抓包，发现该接口传入了账号

（2）修改了传入的账号名称，如admin，发现密码修改成功

解决方案

（1）一次性填写校验信息（原始密码、新密码等）后再提交修改密码请求；
（2）对客户端提交的修改密码请求，应对请求的用户身份与当前登录的用户身份进行校验，判断是否有权修改用户的密码并对原始密码是否正确也进行判断；
（3）不应将用于接收验证信息的手机、邮箱等信息全部明文传到客户端，应对手机、邮箱等信息进行屏蔽处理，或不将此类信息返回到客户端；
（4）对原始密码进行了验证的情况下，限制输入原始密码的错误次数，防止攻击者暴力破解原始密码；
（5）重置密码链接中的关键信息应随机化，不可预测（例如token机制），且禁止将关键信息返回到客户端。

CORS跨域漏洞【中风险】

描述

查看前后端分离的项目，为了保证正常访问，设置跨域时，是否由于配置不当造成所有的网站都可以对其进行跨站资源请求。Cors漏洞就是攻击者利用Cors技术来获取用户的敏感数据，从而导致用户敏感信息泄露。

测试过程

（1）首先对一个页面抓包

（2）修改Origin测试，发现接口仍然调用成功

解决方案

（1）不要将Access-Control-Allow-Origin字段设置为*；
（2）严格校验Origin字段的值；
（3）HTTPS 网站不要信任HTTP域；
（4）不要信任全部自身子域，减少攻击面。

功能越权访问漏洞

描述

查看赋予用户权限时，用户是否只有操作自己页面和附件的权限。（垂直越权或水平越权）。服务器过分信任用户提交的数据请求并且未对用户权限进行判定，可能导致恶意攻击者拥有其他用户的操作权限，平行越权可导致相同权限的用户之间可以进行增改删查等功能；垂直越权可导致低权限的用户拥有着高权限的执行操作能力。

测试过程

（1）先用一个高权限的账户登录，并进行抓包

（2）然后再用一个地权限的账户登录，获取到session后，调用第一步的接口，发现调用成功

解决方案

（1）前后端同时对用户输入信息进行校验，双重验证机制；
（2）执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限；
（3）特别敏感操作可以让用户再次输入密码或其他的验证信息。

敏感信息泄露漏洞

描述

比如服务忘记关闭swagger、监控、注册中心等服务，导致可通过前端访问得到服务器相关信息

解决方案

关闭相关信息页面

----------------------------------END----------------------------------

天行健，君子以自强不息；地势坤，君子以厚德载物