安全 - 常见web攻击

攻与防

Posted on 2020-08-12   Access💚 : TBD

前言

网络世界, 没有所谓的安全, 任何系统都存在漏洞, 只要时间足够以及具备值得被攻破的价值. 就会被攻击.

攻与防之间,本来就没有绝对的安全。我们能做的就是,尽量提高攻击的成本。有时有些方案虽然有漏洞,但是实现起来足够简单,但是并不会过度影响业务性能(比如响应时间)。所以,权衡安全性、开发成本、对系统性能的影响,选择比较折中、比较合理的方案更为重要。

https://www.freebuf.com/articles/web  //Web安全 20200710

1.XSS 参见 极客时间 - 浏览器工作原理与实践 - 浏览器安全 实践:TBD

2.CSRF/XSRF https://xueyuanjun.com/post/19444.html  //CSRF 保护  //请多阅读并实践几遍 https://xueyuanjun.com/post/9616.html  //表单方法伪造与跨站请求伪造(CSRF)攻击防护  https://xueyuanjun.com/post/19927.html   //CSRF 保护

3.SQL注入 https://blog.csdn.net/william_n/article/details/103186508 实践:TBD

4.代码注入 TBD

5.DDoS攻击 TBD

6.重放攻击 概念:  https://zh.wikipedia.org/wiki/重放攻击 https://baike.baidu.com/item/重放攻击/?fr=aladdin

简要定义: 重放攻击(Replay Attacks)又称重播攻击、回放攻击,是指攻击者发送一个目的主机已接收过的包,来达到欺骗系统的目的,主要用于身份认证过程,破坏认证的正确性。重放攻击可以由发起者,也可以由拦截并重发该数据的敌方进行。攻击者利用网络监听或者其他方式盗取认证凭据,之后再把它重新发给认证服务器。重放攻击在任何网络通过程中都可能发生,是计算机世界黑客常用的攻击方式之一。

引子: https://time.geekbang.org/column/article/171760

网友一:

重放攻击防止方式有三种: 1、加时间戳 客户端与服务端有时间差,例如60s内的都算有效。那么黑客可以60s以内进行重放攻击,就有效。 2、时间戳+nonce(随机数) 每次请求成功后,保存nonce,例如放在redis和数据库中,再次请求如果nonce相同,则为重放攻击。 3、基于record的方案,就是和你说的保存token的意思差不多 把每次请求保存在数据库中,接收到新请求后,校验是否存在,如果存在,则请求非法。也可以与1结合时间戳只保存60s以内的数据。 参考: https://cloud.tencent.com/document/product/214/1526 https://juejin.im/post/5ad43b86f265da239236cedc

网友二:

OAuth 2.0 + 网关(如Zuul)+ 认证中心 + AOP可以实现。 极客时间《微服务架构实战160讲》里介绍了OAuth 2.0企业级的解决方案,小争哥的方案适合快速落地。 实际业务中如果安全等级没这么高,直接生成Token鉴权就可以。通过业务模型规避风险: 1. 充值类业务,就算对方篡改接口,最终结果可以通调用证金融机构的接口验证是否有效,不会给公司带来损失。 2. 如果安全等级非常高,比如提现、转账可以通过发送手机短信,确保是本人操作。 3. 如果是商品信息查询类接口,防止第三方爬取数据,可以在调用一定次数后加入”人机验证“(输入图片识别码、拼图)。 4. 根据IP限制访问次数。 5. 服务器间调用可以绑定mac地址、IP。 6. 服务器、客户端通过架设私有VPN进行通信,将安全问题转移到VPN上,降低业务复杂度的同时还可以避免加解密带来的性能损耗,提升性能。 7. 调用接口时通过付费方式(如实名认证、银行四要素验证这些调用一次都是要收费的),防止恶意调用。 8. 通过独立加密硬件(如U盾)+ 独立密码验证器(Google验证器)+ 语音识别 + 面部识别(刷脸支付) + 指纹 + 多人同时输入动态秘钥(核打击时发射程序)。 9. 安全性会降低系统性能适可而止。 极客时间《左耳听风》专栏中介绍了亚马逊在设计开发微服务时,就已经做好了随时对外网开放的准备,由于没有阅读完整个专栏,不知道后面有没有详细介绍。

网友三[小白]:

防止重放攻击的方案在老师的基础做进一步的迭代设计: 1.要求客户端生成一个唯一的请求id,如以uuid方式 2.客户端在以sha等加密哈希方式生成token时,也将请求id加入其中 3.客户端也要将请求id作为参数传递到服务端,如果是rest api就是也要将请求id拼接到url参数中 4.服务端检查服务端的缓存中(可以是redis)是否有客户端传递的请求id,如果有,则判定为重放攻击,拒绝请求。如果没有,则将请求id放到缓存中同时设置在token失效的时间窗内缓存的请求id自动失效(如redis key的TTL) 这个实现思路是: 在时间窗内的重放攻击,以服务端在时间缓存了在时间窗内的所有请求id的形式来防护,而在时间窗外的重放攻击就是老师的方案中检查客户端传过来的时间(时间戳)和服务端当前时间(时间戳)相减的绝对值不能超过时间窗的长度来实现。另外,时间戳、请求id等都hash在了token 中,所有客户端是无法篡改的。 这个实现思路的缺点是: 改实现方案要求客户端的时间和服务端的时间之间的差距不能超过时间窗,如果时间窗设置为1分钟这种比较小的,则要求客户端时间和服务端时间不能超过1分钟,这个有点苛刻,比如客户端如app所在的手机的时间不准确了,但就差1分钟,将无法访问接口。如果时间窗设置过长,如30分钟,则要求服务端缓存中缓存最近30分钟的请求id,如果接口的访问并发挺大的话,缓存占用空间也将很大,需要评估。

请继续技术调研 …

7.问题/补充 产品团队必须能够阻止,监视和警告HTTP请求中的常见攻击模式或技术(如果适用于您的服务):

OWASP Top 10和其他应用程序安全漏洞(例如SSRF,SQLi,XSS,XXE,LFI,RCE,CSRF,业务逻辑漏洞等)。

蛮力攻击(例如,用户枚举,凭据填充,密码猜测)。 产品滥用或滥用(例如帐户接管,滥用业务逻辑缺陷)。— SEEK RFC022

8.参考

https://www.cnblogs.com/morethink/p/8734103.html //常见web攻击总结

https://www.jianshu.com/p/67408d73c66d  //安全|常见的Web攻击手段之CSRF攻击

XSS实战:我是如何拿下你的百度账号

总结几种常见web攻击手段及其防御方式

浅谈CSRF攻击方式

http://blog.csdn.net/zzhongcy/article/details/20133883 //jQueue 动态设置form表单的action属性的值和方法

https://www.thinksaas.cn/group/topic/304242/ //javascript的String到int(32位)的hash算法

https://cloud.tencent.com/document/product/214/1526

https://juejin.im/post/5ad43b86f265da239236cedc

https://www.jianshu.com/p/b0c8ae980fea  //PHP_SELF漏洞

https://blog.csdn.net/xuanyuan_fsx/article/details/104967382  //程序猿应该知道的黑客技术大汇总  — 需要实践 code 推到 github  ==> TBD

后续补充