全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2318 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈回顾 (1讲)
全栈回顾 | 成为更好的全栈工程师!
全栈工程师修炼指南
登录|注册

31 | 防人之心不可无:网站安全问题窥视

四火 2019-11-20
你好,我是四火。
今天,我们来学习一些网站安全的基础知识。作为一名 Web 全栈工程师,不可避免地会经常性地面对网站安全的问题,因此有关安全的学习是十分必要的。这一讲我们就来看一些常见的安全问题,并了解它们相应的解决办法,加强安全意识。

鉴权和授权

我把这两个概念的比较放在开头,是因为这两个概念有相关性且很常用,还有就是这二者太容易被混用了,但是实际上,它们却又是大不相同的。鉴权,Authentication,指的是对于用户身份的鉴别;而授权,Authorization,指的是允许对于特定资源的指定操作。
我们可以借助具体的例子来深入了解。
先说说鉴权。网站的登录系统,输入正确的用户名和密码以便登陆,这个过程就是一个鉴权参与的过程。输入了正确的用户名和密码,系统就能够确认用户的身份,鉴权也就成功了。再比如我们在 [第 02 讲] 中介绍的 HTTPS 通信,其中的密钥也是起到了“鉴别身份”的作用,这个起作用的过程也属于鉴权。
为了安全考虑,在实际应用中鉴权有时不是靠“单因子”(Single-Factor)就够了的,我们还会采用“多因子”(Multi-Factor)的方式。
举个例子,银行转账的时候,你光输入账号和转账密码,这是属于单因子,一般是不够的,还必须有其它的因子,比如说 U 盾等等。多个因子之间一般要求是独立的,无依赖关系。再比如说,你通过电话去办理通讯业务的时候,有时候为了证明你的身份,你会被要求提供 PIN 或者密码以外的其他“个人信息”,像是说出最近三次通话的电话号码,这些方式,都是为了增加“鉴权因子”的种类,从而提高安全级别。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 丁丁历险记
    小公司,遭遇过一次30G 流量的ddos ,直接被机房叫去约谈,各种理由停我们的服务。
    那次后,果断上云了。

    作者回复: 👍

    2019-11-28
  • 靠人品去赢
    这例子想当给劲了,没想到老师也去V2摸鱼。

    作者回复: :) V2 这张图是个巧合。我想找一张 HTTP 劫持的图片,搜了一些,大多数都不太适合,这张算是相对来说比较适合的。

    2019-11-26
  • tt
    XSS和CSRF都和身份有关系,前者是劫持了某个身份,后者是假冒了某个身份。而手工输入验证码实在鉴权之前发生的,一个验证码正确不能说明任何身份信息,只能说明在网站活动的实体是一个具有识别验证码的对象,这个对象可能是人。好像叫“图灵测试”还是什么来着。

    提交信用卡信息,有两个方面需要考虑,一个是信息的保密性,这个应该要依靠加解密来实现;第二个是要实现不可抵赖性,即确保这个行为是真实的用户发出的真实的请求,即第一要防止XSS,即身份被冒用;第二要防止CSRF,即行为被仿造。像老师课里讲到的,利用TOKEN信息,这个TOKEN也可以来自永和的电子令牌或U盾,做到防抵赖等。

    最后,用户也要验证服务提供者的身份,这就需要HTTPS了。但是如果DNS被劫持,确实不好办,最近我们另外一个项目遇到了这个问题,但是客户端也不支持HTTP-DNS。

    作者回复: 👍

    2019-11-20
  • leslie
    这块刚好是欠缺的关于安全方面的。下面是对于今天2个问题的个人理解
     1.短信验证:短信验证应当是防范了XSS攻击。
     2.支付系统:多种攻击都应当要防范,支付可能是直接的网络密码支付或者密码支付;我觉得以下几种方式都要防御;XSS、SQL注入、DNS以及DDOS攻击。
        如果可以的话希望老师可以适当补充这块的知识或书籍资料;其实在现在而言 ,这个大概是每个IT人员都应当有的常识。谢谢老师今天的分享,期待老师后续的分享。

    作者回复: 你讲的短信验证是验证码中的特殊一种,它不但能确定对方“是真实的”,而不是机器,还能验证对方的身份,它比普通的验证码要麻烦,但是可以防范更多的攻击方式,所以你可以多想一想,再补充。

    对于扩展阅读,因为这篇已经有 4 条了,考虑接受程度和需要的时间成本,除非有我认为特别好的材料,一般就不再增加了。但是安全方面的学习材料互联网上很多,我相信你也可以找得到。

    2019-11-20
收起评论
4
返回
顶部