JTalk 第八期前端安全大起底总结

本文转载于:猿2048网站➧https://www.mk2048.com/blog/blog.php?id=hc0ka02b1j

JTalk《前端安全》活动结束啦，我收录了这次讲师所讲述的内容和部分同学提出的问题与讲师的答复，遗憾的是没有全部收录下来，只收录了部分内容，文章的内容并不完全代表讲师所讲述的全部内容，有部分是我回忆补充的，会有出入，希望这部分内容能帮到大家。

活动介绍

前端安全大起底 | JTalk 掘金线下活动第八期

XSS 跨站脚本的攻击原理与防御 - 龙佳文

什么是 XSS? (XSS 会有哪些危害, 窃取凭据,窃取会话令牌)
在输入框输入标签字符可以反射得到 cookie 值，并将这个 cookie 发送到指定的地址
v-html 可以将重要的数据以任何的形式弹出这个功能类似 innerHEML
XSS 产生的原因？（常见导致 XSS的途径: 反射型，存储型，DOM based）
不使用 innerHEML 作为瀑布流展示
在地址中可以使用标签的形式得到或改变页面显示的形式
Chrome 会自带 XSS 防御，在注入标签的时候回被自动拦截,只能拦截主流的注入形式。
如何防御 XSS？（慎用数据,避免使用 innerHTML 等等）
XSS 能实现的攻击有会话劫持，通过cookie将用户的信息发送到指定的地址
使用得到的 cookie 拿到 token 可以模仿用户的信息和行为进行常规的操作。
通过JS不断创建文件进行请求通过模仿某一服务器对指定服务器进行攻击。

对内容进行做转义，防止恶意的标签注入。

内容白名单，对外部动态内容的安全过滤使用白名单，而不是使用黑名单，通过白名单对指定的标签进行过滤选择。

问题收录

攻击次数的上报
使用CSP的规范通过内部的声明，其可以将内容进行上报。
CSP 会去要求进入到所有的内容以外的进行执行。在页面执行非法的JS CSP 都会对其执行拦截。
知道概念并不深入怎么检测项目的隐患
OWSP 有安全的规范和安全的审计软件可以使用
转义只针对 HTML进行转义对于其他的转义需要后台做配合处理
XSS 对于攻击的防御，有没有好用的工具或实时监测漏洞的工具
对业务流程使用安全审计软件进行审计，如果公司对这个比较重视可以花钱去审计，安全是需要团队和老板一起进行开发和协作。第三方的数据不一定可靠，需要团队进行互相协作。

浅谈流量劫持与防治 - 刘洋河

典型的上网会经历哪些阶段
在急于将产品投入使用,导致软件开发的过程中出现很多的问题漏铜，而不知道攻击者的攻击方式，对于基础的内容只是一定要掌握。
流量劫持并不是新生的话题,流量劫持一直纯在并没有彻底的消除。
理想的上网环境,打开浏览器就可以使用,当用户打开浏览器上网的时候是需要通过路由器的IP 访问服务器网站然后通过 CDN 进行对文件进行下载。
流量劫持是怎么发生的呢？
链路本身不安全
从设计上未考虑安全性。
随着计算力发展，安全链路变得不安全。
干扰安全链路，迫使链路使用若安全方案。
DNS 投毒与防治流量劫持与防治

DNS
基于一个UDP的协议，工作的时候效率较慢,缓存的时候是比较快的。
没有缓存的情况下需要查询很久。
公共域名访问顶级域存在一个缓存时间 TTL 可以在指定的时限内如果没有请求到数据会再次请求。

污染 DNS
可以使用缓存对DNS进行攻击或污染

HTTP
在网服务其对DNS加密，用户得到加密的文件下载后进行解密再使用，增加DNS的安全性。
抵抗 DNS流量劫持
链路问题的排查
⽅案A:在某些省份、地区⾃自建监测站，定期抓取固定资源
问题:资源太固定，监测站数量也远远不够
⽅案B:业务⽅在⾃己的html中监听资源的Error事件
问题:⽆法确认问题在于链路路，也可能只是普通的js出错
⽅方案C:使⽤第三⽅企业服务进⾏监控
问题:服务越多成本越⾼
⽅方案D:CSP、SRI
问题:兼容性和灵活性差，⽆法进⾏自定义逻辑

问答

这部分的问答，我只记录了讲师的回复，因为近期加班时长耳鸣，没能听清楚问题，向大家致歉。

浏览器在跑业务代码的时候，没有空余的时间去做业务计算。没有太多的资源去做,或者在SDK中嵌入，拿到文件的长度和首尾前100个字节进行判断，是否被篡改。
异步加载脚本，首先可以使用浏览器的加载机制去做，另一个方案是不使用原有的方案进行加载。使用自己定义的方案进行修改。

深入浅出 CSRF - 吴空

CSRF 是什么? CSRF 可以做什么? CSRF 攻击现状
CSRF 攻击可以伪造邮件仿制用户的信息盗取账号购买商品银行转账。

CSRF 攻击原理与防御 CSRF 漏铜检测
防御内容详见 PPT CSRF 常见防御。

CSRF Tester 漏洞检测
使用代理抓取我们在浏览器器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，如果修测试的请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进⾏CSRF攻击。
CSRF Request Build 漏洞检测
在⿊黑客圈指：观点验证程序，运⾏行行这个程序得到预期结果，就验证了了这个观点。
前端与服务器端如何在代码层面防范 CSRF 攻击
在自动化构建过程接入漏洞检测工具在提交的时候就进行漏铜的检测。
线上接口扫描，线上提供一个入口，通过漏洞扫描工具进行线上的扫描和更新。

用户安全验证探索 - 潘俊

安全验证在 Web 服务中的位置

信息的分类与网站的性质有关系，最常见的一般分为隐私和非隐私两大类。结合产品自身的特性来选择信息如何呈现给用户
常规操作和敏感操作对于验证的需求并不相同。
Case:[新买的手机有了别人的数据]
Case:[新注册了一个账号，发现了不属于自己的东西]

验证的类型和优劣强验证弱验证(对于用户识别) 扩展的动态类型的验证

密码正在演变，登录的方式多样性与多样化。
密码的安全性和重要性逐渐在降低。
短信快捷登录
短信登录的兴起
智能手机的普及和移动互联网的发展
手机资费结构变化和短信功能的转变
SIM卡实名化让手机可以从当个人账号的角色

短信开发的一些常见的问题
防范短信轰炸
短信的有效期
服务商和费用
短信登录的利弊
简单快捷安全
手机号是可以回收的
如何从产品整体层面来规划和制定策略

如何减少验证次数
设备化，将浏览器也设备化(通过⼀一个⻓长效COOKIE标识) 增加设备关联，历史数据来决定设备与账号关系地域，IP，甚⾄活跃时间段都可以当成辅助来判定当前用户是否可信。
该如何选择验证方式
密码登录
短信登录
动态令牌
扫码登录
其他
强依赖第三方登录
人脸识别，指纹识别等等

该如何选择验证方式
纯微信开发
微信登录手机短信密码登录
手机 App 为主
手机短信密码登录人工申诉微信登录扫码登录
PC 浏览器位置
密码登录手机短信动态令牌
多端并重
手机短信扫码登录密码登录微信登录动态令牌
低交互信息类
密码登录手机短信
工具类（重资产）
手机短信动态令牌人工申诉微信登录扫码登录密码登录
工具类（重信息）
动态令牌人工申诉手机短信密码登录

先后顺序代表推荐顺序和开发的优先级

总结

安全问题，不只是局限于 Web前端凡是涉及网络的地方都会有攻击的存在，大厂有自己的安全团队，中小型公司就成了黑客的练手的存在，据朋友说有很多地方在培训黑客，会拿一些中小型公司练手，听到这个感觉充满了挑战，是对自己能力和快速查错及解决问题综合的考验。产品的完成不只是功能的完善，代码的可靠性，健壮性，安全性也是很重要的，任何微小的瑕疵都会成为攻击方的入口，我认为这也是一种对自己的提升与考验，只有经历风雨存活下来的才是有能力继续前行的。