31 | 防人之心不可无:网站安全问题窥视
该思维导图由 AI 生成,仅供参考
鉴权和授权
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了网站安全的基础知识,重点关注了鉴权和授权的概念以及常见的Web攻击方式。在鉴权和授权方面,文章强调了它们的相关性和区别,以及在实际应用中的重要性。针对常见的Web攻击方式,文章详细介绍了XSS(跨站脚本攻击)的原理和防御方法。通过具体的例子和图示,读者可以清晰地了解攻击者如何利用恶意脚本获取用户的Cookie,以及如何通过字符转义和控制Cookie的作用范围来防御XSS攻击。此外,文章还涵盖了CSRF(跨站请求伪造)、SQL注入和HTTP劫持等攻击方式的原理和防范策略。总体而言,本文以简洁清晰的语言,深入浅出地介绍了网站安全的基础知识和常见攻击方式,适合Web全栈工程师和对网站安全感兴趣的读者阅读学习。值得一提的是,本文还强调了在防范CSRF的情况下,必须首先确保没有XSS的问题,因为一旦用户的会话以XSS的方式被劫持,所有的CSRF的防御就失去了意义。对于HTTP劫持,最理想的解决方案是将网站切换为HTTPS。文章还介绍了DNS劫持和DDoS攻击的原理及防范措施。DNS劫持会引导用户到恶意网站,而DDoS攻击则通过洪峰请求使服务崩溃。对于DDoS攻击,需要整个网络链路配合,采取入侵检测和流量过滤等多种方式来联合防范。文章最后提出了两个问题,引发读者思考。
《全栈工程师修炼指南》,新⼈⾸单¥59
全部留言(6)
- 最新
- 精选
- ttXSS和CSRF都和身份有关系,前者是劫持了某个身份,后者是假冒了某个身份。而手工输入验证码实在鉴权之前发生的,一个验证码正确不能说明任何身份信息,只能说明在网站活动的实体是一个具有识别验证码的对象,这个对象可能是人。好像叫“图灵测试”还是什么来着。 提交信用卡信息,有两个方面需要考虑,一个是信息的保密性,这个应该要依靠加解密来实现;第二个是要实现不可抵赖性,即确保这个行为是真实的用户发出的真实的请求,即第一要防止XSS,即身份被冒用;第二要防止CSRF,即行为被仿造。像老师课里讲到的,利用TOKEN信息,这个TOKEN也可以来自永和的电子令牌或U盾,做到防抵赖等。 最后,用户也要验证服务提供者的身份,这就需要HTTPS了。但是如果DNS被劫持,确实不好办,最近我们另外一个项目遇到了这个问题,但是客户端也不支持HTTP-DNS。
作者回复: 👍
2019-11-2025 - leslie这块刚好是欠缺的关于安全方面的。下面是对于今天2个问题的个人理解 1.短信验证:短信验证应当是防范了XSS攻击。 2.支付系统:多种攻击都应当要防范,支付可能是直接的网络密码支付或者密码支付;我觉得以下几种方式都要防御;XSS、SQL注入、DNS以及DDOS攻击。 如果可以的话希望老师可以适当补充这块的知识或书籍资料;其实在现在而言 ,这个大概是每个IT人员都应当有的常识。谢谢老师今天的分享,期待老师后续的分享。
作者回复: 你讲的短信验证是验证码中的特殊一种,它不但能确定对方“是真实的”,而不是机器,还能验证对方的身份,它比普通的验证码要麻烦,但是可以防范更多的攻击方式,所以你可以多想一想,再补充。 对于扩展阅读,因为这篇已经有 4 条了,考虑接受程度和需要的时间成本,除非有我认为特别好的材料,一般就不再增加了。但是安全方面的学习材料互联网上很多,我相信你也可以找得到。
2019-11-201 - Geek_89bbabDNS劫持后,如果用户没有注意到,然后在假冒网站中输入用户名密码,是不是用户名密码就泄漏了? 针对这种情况,有什么好的方案或者建议呢?
作者回复: 1) 对,有些银行卡信息就是这样泄露的。俗称“钓鱼” 2) DNS劫持的防范一般比较复杂,需要整个链路的配合,包括DNS服务提供商,现在有的浏览器支持的HTTPS加密的DNS,就是针对这个事情而设计的,参见 https://zh.wikipedia.org/wiki/DNS_over_HTTPS
2020-06-14 - 丁丁历险记小公司,遭遇过一次30G 流量的ddos ,直接被机房叫去约谈,各种理由停我们的服务。 那次后,果断上云了。
作者回复: 👍
2019-11-282 - 靠人品去赢这例子想当给劲了,没想到老师也去V2摸鱼。
作者回复: :) V2 这张图是个巧合。我想找一张 HTTP 劫持的图片,搜了一些,大多数都不太适合,这张算是相对来说比较适合的。
2019-11-26 - 八哥用户登录信息,加密和https。涉及到用户敏感数据,脱敏显示都是安全措施2020-02-26