事情得从一个公家单位的网站检测报告说起。最近网络安全领域的执法活动高频密集，特别是浦东新区网络安全这块，动作频频。客户跟我说他们单位被检测出单位网站有安全漏洞，需要我处理，然后发了一份安全检测报告给我。大致看了一下，问题不大，不要慌，先拍个朋友圈就能解决的事情。遂记录如下。
列名了三个漏洞名称，第一个TLS1.0漏洞、CSRF漏洞和点击劫持漏洞，分别被标注了中危、中危、低危。
TLS1.0实际上是https加密协议1.0版，对应的是SSL3.1。这个协议有些年头了，在2011年的时候被攻破。并且这些年来浏览器陆续在抛弃TLS1.0了，所以修复漏洞的最简单方法就是弃用TLS1.0.方法也很简单，在nginx配置中删除TLS1.0即可，删除后重启下nginx。
ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
然后使用myssl.com网站检测I下，看到TLS1.0 不支持就表示成功了，如果你网站使用了CDN，阿里云CDN控制台里面可以直接操作关闭TLS1.0
CSRF攻击其实就是跨站脚本攻击，原理就不讲了，学开发的都懂。处理方式主要有两种，一是验证请求头中的Referer，当然这个要依赖浏览器正确传输Referer字段。有一定的局限性。第二种就是生成一个token，然后去校验token。这个检测报告上还列了第三种方法，原理和token差不多。
我找了一下这个客户网站，很明显的就是一个查询表单，虽然我后台校验了用户输入数据，仅限于汉字字母和数字，可能当时忘了设个token，所以在表单里面补上一个token隐藏域，后端去校验这个token就好了。
点击劫持其实就是构造了一个iframe的页面，把你网站套在里面，看似是你的网站，实际上是在iframe框架上做了手脚，当你点击的时候执行了跳转。
先来复现一下这个漏洞吧，拿我的网站举例，先再本地建一个html页面，套下iframe框架。为了显眼，我给iframe来个红色边框，运行这个html后可以看到我的网站成功被嵌在了一个iframe框架中了。
如何修复这个漏洞，也简单，给X-Frame-Options响应头配置一个DENY的参数，具体nginx在server中配置一下add_header X-Frame-Options DENY;即可。配置后重启下nginx，再来运行下刚才的html页面，就会报一个拒绝连接的错误页了。当然DENY参数是直接禁止，别人无法iframe你，如果你网站自己有iframe同样会无法使用，如果你自己网站使用了iframe结构，记得将参数设置为SAMEORIGIN。
至此三个问题修复完成，网络安全无小事，此类相关赶紧自查自纠吧。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。