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