第一次被渗透测试

开发工作基本完成后，我却感到一阵空虚，有时候到达目的地，还不如在旅途中，真怀念那段和 Vue、Django rest framework 相伴的夜晚，他们带给我百思不解的郁闷和拍案叫绝的惊喜。上线前需要接受渗透测试，说是今天给结果，导致我昨晚做梦都在想渗透的结果到底是什么。

结果出来后，打开一看，一半是出乎意料，一半是意料之中，将一件事情做好是真不容易，学习无止境，代码无休止。今天就分享一下漏洞及自己想到的对策。

高危一：开启了不安全的 HTTP 方法。

什么是不安全的 HTTP 方法？我搜索了很多资料，都没有讲清楚为什么是不安全的，大体上是这个意思：看起来像是会修改服务器端数据或文件的方法称作不安全的 HTTP 方法。HTTP通常有GET、POST、DELETE、OPTIONS、PUT、PATCH 五种，当然也有拓展。我们将 PUT、DELETE 这种明显含有上传和删除文件权限的方法称作不安全的 HTTP 方法。

我个人觉得，方法安不安全看使用者个人，你可以使用 POST 方法删除服务器资源，也可以使用 DELETE 方法删除服务器资源，只要加入权限控制，就是安全的，网上说的可以直接上传 jsp 文件挂马，我只能说这服务器就是测试用的，真正上线使用的，谁会允许任意用户上传任意类型的文件。

漏洞危害：攻击者可能利用此漏洞在 WEB 服务器上传、修改、删除脚本和文件，从而达到网页篡改，控制服务器的目的。

修复建议：如果服务器不需要支持 WeDAV，就禁用此功能，或者禁用不安全的 HTTP 方法。

我是不会禁用的，REST 风格的 API 是我的最爱，我可以加入严格的权限控制，而不会禁用如此优雅的 HTTP 方法，尽管他看起来不安全。

高危二：开启了 OPTIONS 方法。

服务器如果开启了 OPTIONS 方法，你用 OPTIONS 方法请求服务器，服务器会返回它允许的 HTTP 方法。

漏洞危害：攻击者可能利用 OPTIONS 方法获取服务器支持何种 HTTP 请求，进而准备进一步攻击。

修复建议：禁用 OPTIONS 方法。

这个没什么好说的，自己开发的 API 还不知道支持哪种方法吗？禁用就行了。

高危三：任意用户注册。

现在我明白了很多网站注册流程的繁琐了，各种奇葩的验证码，信息填写，就是为了防止机器人注册的。虽然我设置了邮箱验证码，但只有四位数字，容易被暴力破解。

漏洞危害：验证码可通过暴力破解，造成任意用户注册。

修复建议：增加到 6 位数字字母混合的验证码，缩短验证码的时效性。

中危一：用户枚举漏洞。

用户登录时，用户存在和不存在服务器返回的结果不一样，黑客可以利用这一点来进行用户名枚举。看到这点我是有点惊呆的，如果返回结果一样，前端怎么判断用户是否是注册用户呢？不过我利用这一点，查到了老赖的身份证号码，见前文：只有名字，如何查到老赖的身份证号？

漏洞危害：攻击者进行信息搜集和用户名搜集工作利用此漏洞可轻松实现。

修复建议：

1、对涉及用户信息的 API 访问进行频次限制。

2、登录操作应该设定有效的验证码机制。

3、限制单个 IP 的尝试次数。

低危一：X-Frame-Options 未配置。

漏洞危害：服务器没有返回 X-Frame-Options 响应 header，这意味着该网站可能面临 clickjacking attack（点击劫持攻击）的风险。X- Frame-Options HTTP 响应头可用于指示是否应允许浏览器在框架或 iframe 内呈现页面。点击劫持，clickjacking，也被称为 UI-覆盖攻击。它是通过覆 盖不可见的框架误导受害者点击。虽然受害者点击的是他所看到 的网页，但其实他所点击的是被黑客精心构建的另一个置于原网 页上面的透明页面。这种攻击利用了 HTML 中 <iframe> 等标签的透明属性。

修复建议：在 web 容器上进行配置，添加 X-Frame-Options 响应头。配置参考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

就这些了，第一次被渗透测试，还是挺新鲜的。经验教训就是在一开始就要考虑所开发的程序的安全问题，如果网站没有什么重要数据，仅仅展示，或者内网使用，效率优先，相反如果公网访问，必须考虑安全问题。

开发网站的人也写写爬虫，写爬虫的人也要学学开发网站，相互理解一下彼此的良苦用心。

本文来源于：第一次被渗透测试-变化吧门户
特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。