码农翻身讲网络5:Web安全攻防战与HTTPS

黄小斜 2018-01-27

安全 算法 javascript 服务器 加密 web 浏览器 cookie

浏览器:一个家族的奋斗

原创:

刘欣 码农翻身 2017-12-12

我是你们每天都要使用的浏览器,自从90年代诞生以来,我们这个大家族变得非常的繁荣,在过去的几十年中,我们一直兢兢业业地帮助你们人类去探索外部的互联网世界。随着互联网和移动互联网的发展,我们家族终于登上了成功的巅峰:几乎占据了全球每一台电脑和手机。

 

大家只看到表面的光鲜,可是谁知道我们家族在背后充满血和泪的不懈努力呢?

 

1起步:从简单到混乱

最初的时候,我们浏览器家族的工作很简单,就是从远端的服务器下载HTML页面到本机,然后按照和你们人类的约定,把充满标签的HTML文本转换成你们容易阅读的页面。例如当我们遇到<table> 这样的标签,我们就展示一个表格,遇到<p>我们就会换行显示一个新的段落,看到<img> 就知道要显示一个图片等等。

 

由于HTML的结构很简单,我们展示起来也不难,工作相对比较轻松。

 

可是你们人类很快就不满足了,嚷嚷着说要看漂亮的页面,漂亮的布局,就像报纸杂志那样,分栏、图文混排...... 

 

于是有不少人盯上了<table>这个标签,这个标签本来的目的是为了显示数据用的,像这样:

 

 但是这些人发现,既然表格能把页面分成一块一块的,那完全可以来做页面布局啊! 比如这个单元格可以作为页面的头,那个做左边栏,右边栏......等等。

 

这个口子一开,立刻成星火燎原之势,再加上那些所见即所得的网页编辑器(如DreamWeaver, FrontPge)推波助澜,表格布局大行其道。

 

这可苦了我们浏览器家族,我们经常发现HTML中那些令人恐怖的表格,一个套着一个,我见过最极端的有上百个表格套在一起,组成超级无敌的页面。为了把这些表格解析、展示出来,我们都是战战兢兢、如履薄冰,生怕出什么差错。

 

有时候,程序员会忘记写一些标签的闭合标签,例如</a> </td>,我们还得猜测、推理、论证,最后展示出来的东西你们还不满意:这是什么玩意儿,连个HTML都显示不对!

 

我们家族的IE同学在这方面的研究可以说是登峰造极,他非常擅长处理这种乱七八糟的情形,他的纵容成功地让你们把HTML越写越乱!

 

2CSS来拯救

终于有一天这样的HTML页面连你们人类都看不懂了,你们吵了半天,放了一个“损招”出来:把结构和展示分开! 

 

HTML只负责文档的结构,一个叫做CSS的东西来控制这个结构到底展示成什么样子。

 

在CSS中,程序员只需要用声明的方式说,这个表格宽度是1px, 字体是11px, 边框颜色是 #666666,然后你们就不管了,具体怎么实现全部扔给了我们:

 

table.gridtable { 

    font-family: verdana,arial,sans-serif; 

    font-size:11px; 

    color:#333333; 

    border-width: 1px; 

    border-color: #666666; 

    border-collapse: collapse; 

}

对于你们来说变简单了,可是对我们浏览器来说就太难了。我们得老老实实地去解析HTML (这HTML有可能还不规范),形成一颗叫做DOM(Document Object Model)的树,这还不算,还要去解析CSS, 形成另外一个叫做CSSOM (CSS Object Model)的树,然后把两棵树合并成一个“渲染树” 这才能在界面上绘制出来。

 

现在的CSS都已经出到第三个版本了,可是我们家族还有不少人没法完整的支持这个规范,尤其是一些老旧的浏览器,可见这是多么不容易啊。

 

3误入歧途

我们家族也走过一段弯路,那是一段不堪回首的浏览器插件的历史。

 

当时有人提出HTML+CSS太简单了,浏览器中的页面没法和当时的桌面应用相媲美,能不能用扩展一下啊?

 

最早的尝试来自于Java Applet,这也是Java 赖以成名,从此走上第一大编程语言的绝技。那帮疯狂的家伙们竟然在我们这单薄的小身板里安装了一个Java 虚拟机,用于从服务器端下载Java 代码、运行,展示出漂亮的动画效果。

 

刚开始的时候我们努力地支持,但是它运行起来慢如蜗牛、丑陋无比。我们那些可爱的用户也不答应,不去安装或者禁止使用这傻大笨粗的Java 虚拟机,于是Java Applet就慢慢地销声匿迹了。

 

与此同时,一个叫做流氓插件的毒瘤也迅速地向我们袭来,在你浏览网页的时候,这些流氓静悄悄地潜入我们的身体,他们传播病毒、弹出广告、窥探用户隐私,并且难于卸载,让我们痛不欲生。后来数字公司推出了一个保镖,杀了一个回马枪,这次把流氓给清除了出去。

 

当然不能一棍子打死,插件中也有良民,比如Flash , 这小子可是风光了好多年,收到了人民群众的广泛喜爱,当年出现了很多的Flash 小动画,小视频,小游戏,我至今还记得有好事者竟然用Flash 去做《鹿鼎记》动画,也不知道他做完没有。

 

Flash 极为火爆,我们让他在我们家族寄宿了20多年,直到移动互联网时代的崛起,尤其是乔布斯的推波助澜,这才慢慢退出历史舞台。

 

4重装上阵:JavaScript

向我们家族里安装插件的尝试并不成功,但是我们还是想和桌面应用竞争,让浏览器应用有着桌面应用的体验,这时候有个叫JavaScript的屌丝自告奋勇,说自己可以在浏览器中执行代码,提高页面的动态性。

 

刚开始的时候我们并不待见他,本来解析HTML, CSS就够我们受的了,我们竟然还要去执行JavaScript代码。尤其烦人的是,JavaScript还可能对DOM进行修改,比如让某个元素隐藏。唉,我们只好把画好的元素重新渲染,重新绘制。

 

不仅是控制界面,JavaScript还要执行逻辑,刚开始的时候我们觉得这小子没啥用处,无非就是做点简单的判断,像什么表单中用户名不能为空了,密码和确认密码两个输入框的值必须得相等之类。

 

后来有人搞了一个叫做AJAX的东西出来,从此发展出一堆类似JQuery 、 Bootstrap、ExtJS 这样的类库,浏览器中的页面可用性越来越高,体验越来越好。

 

最后随着前端框架(Angular, Backbone, React 等)出现,我们家族在浏览器中完全实现了界面的展示和页面的调整,成功地做了前后端分离,把端服务器做的生意给抢过来一大部分,把他们气得够呛。

 

5替人类保存数据

HTML来负责结构,CSS负责展示,JavaScript负责行为,这是我们每天要做的三件大事,还有一件重要的事情就是存储数据。

想当年,人类把HTTP设计成一个没有状态的协议,即使是同一个人,在极短的时间内访问同一个服务器,服务器也会认为这是完全两个不同的请求,根本不知道是同一个人发出的。

 

当有成千上万的人都来访问同一个服务器的时候,服务器怎么才能把大家区分开呢?要是不区分开,服务器端怎么才能实现购物车的功能?服务器怎么才能记住这个裤子是张三买的,那个羽绒服是李四买的?

 

后来人类出了一个损招:当用户使用我们访问服务器的时候,会给每个用户都建立一个会话,每个会话都有一个独一无二的ID。这个ID服务器端会保存,同时也会发回到我们浏览器这边,让我们暂存起来,美名其曰小饼干(cookie),听起来不错,但是这个小饼干却不能吃。

 

当用户访问同一网站的时候,我们还得把这个cookie 向服务器发送过去,服务器通过cookie取到那个会话ID,于是就知道是谁在访问它了。

 

 

 

我们保存了这个小饼干,但是大家觉得这个小饼干能保存的数据量太小,于是我们就在浏览器中又开辟了两块巨大的空间,给JavaScript 那小子提供了接口,让他把字符串存储到浏览器中。

这两块空间一个叫localStorage, 一个叫sessionStorage 。他们俩的用法非常相似,例如:

 

localStorage.setItem("username", "Andy");

alert("username=" + localStorage.getItem("username"));

 

这样以来用户就可以放心地在我们这里存储大量的数据了。只不过这个sessionStorage 和cookie类似,表示的是一个会话的概念,所以一般来说,页面一旦关闭,存储的数据就会消失。

 

但是这个localStorage 就不同了,只要你不把数据删除,它会一直存在。这引起了我们家族有些人的强烈抗议:如果JavaScript那小子忘记删除,那垃圾岂不越来越多?

 

没办法,只有拜托各位程序员了,对于无用的数据,及时删除吧。

6向多媒体和游戏进军

要让浏览器变成一个和桌面应用相媲美的平台,仅仅有展示页面和存储数据的能力是不够的。我们决定增加对视频和音频的支持,这一次直接撕去了插件的伪装,“赤裸裸”地在HTML中加了<video>和<audio>这两个新标签,从此以后,家族的每个成员都得想办法去播放音频和视频了:

 

<video src="movie.mp4" width="320" height="240" controls="controls">

你的浏览器不支持video标签

</video>

 

<audio src="song.mp3" controls="controls"> 你的浏览器不支持audio标签 </audio>

 

我们在手机上的浏览器兄弟们更加地努力,他们还支持直接调用手机的摄像头去拍摄照片,这实在是太方便了。

 

既然都能支持音频、视频、摄像头了,何不更进一步,在浏览器中搞一把实时通信?

 

不用额外安装插件或者第三方软件,在两个浏览器之间就能进行语音或者视频的聊天,这个想法确实是挺激动人心的,我们把它称为WebRTC。不过这个想法的实现比较困难,虽说我们家族的Chrome再不遗余力地推动,但是要让我们家族在所有的平台上(Windows, Android, iOS,mac)都实现了还需要继续努力。

 

此外我们还一直惦记着游戏这个令人垂涎三尺的大市场,绝对不能放过! 于是我们添加了<canvas>的标签,意思是画布,这样JavaScript那小子就可以在画布上去绘制路径、各种形状、添加图片...... 总而言之,程序员终于可以写出一个只依赖浏览器就可以运行的游戏了,完全不用什么Flash 。

 

看看下面这两个简单的小游戏,如果我不告诉你,估计你都不知道这完全是HTML+JavaScript  做出来的吧:

 

 

水果忍者

中国象棋

 

7让服务器从被动变为主动

你们人类原来指定的HTTP协议都是从我们这里向服务器端发出请求,然后服务器响应,一个请求,一个响应,严格对应。

 

后来大家发现这样不好,服务器一直处于被动的地位,服务器端的数据有了变化(例如股票又涨了)后,浏览器如果不主动访问的话是不知道的,所以浏览器只好一遍遍不厌其烦地发送请求: 

浏览器:股票涨了没有? 服务器:没有

浏览器:股票涨了没有? 服务器:没有

浏览器:股票涨了没有? 服务器:没有

......

浏览器:股票涨了没有? 服务器:涨了 

 

这种方式叫做轮询,效率极为低下。

 

能不能让服务器向我们主动地推送数据呢 ?股票一涨,立刻就向浏览器推送,浏览器即刻展示。

 

我们和服务器做了多次谈判,终于建立了这么一个办法:双方建立连接以后就不要断开了,一直保持住,我们可以通过这个通道向服务器发送数据,服务器也可以主动向我们推送数据。

 

这个技术,我们把它称为Web socket。

 

8总结

CSS, JavaScript , 本地存储,多媒体和游戏,Web Socket ...... 这只是我们家族提供的一部分服务,还有很多其他的服务例如HTML标签的语义化:我们提供了很多诸如<article> , <section> , <nav> ,<aside>, <header>,<footer>这样的标签来帮助你们人类更好的定义网页的结构。

 

这样的东西非常非常的多,我想你应该明白我们家族的不断努力了吧,如果你一边听我讲一边在思考,也许会悟出我们的使命:不断提升应用程序在Web端的体验。

 

也许有一天,所有的桌面应用都消失了,全部变成了在浏览器中运行的程序,那将是我们浏览器家族荣耀的顶峰,我们期待着这一天早日到来。

 

(完)

 

黑客三兄弟

原创: 老刘 码农翻身 2017-12-26

建立Beauty.com的黑客三兄弟最近可谓是春风得意,他们的这个网站精准地利用了人类的本性,窃取了不少登录用户的cookie。

 

(码农翻身注:参见前文《浏览器的安全反击战》)

 

利用别人的cookie,他们可以冒充真实的用户,在颁发cookie的那个网站中为所欲为,个人隐私在他们面前根本不存在。

 

运气好的话连别人的用户名和密码都能得到,那就一通百通,因为大家都嫌麻烦,总是使用同一套用户名和密码来登录各种不同系统。

 

可是好景不长,这一天黑客老三慌慌张张地找到了老大:“大哥,大事不好! ”

 

“老三,你这慌慌张张的毛病什么时候能改改? 这点儿你可得学学你二哥。” 老大训斥道。

 

“不是,大哥,这次真是大事不妙,浏览器家族最近颁布了一个什么同源策略,我们原来偷Cookie的招数都不管用了! 今天我连一个Cookie,用户名密码都没有偷到。”

 

“什么叫偷,说了多少次了,那就借,知道不?!”

 

(码农翻身注:同源策略参见前文《浏览器的安全反击战》)

 

“我早就料到了,这么重大的安全漏洞肯定肯定会补上的,他们不会这么轻易地让我们来跨域来访问别人的Cookie,修改别人的DOM,调用别人的服务的。”  老成持重的黑客老二说道。

 

“那怎么办? 没有Cookie,难道我们三兄弟以后就饿肚子了吗?”  老三很紧张。

 

“别担心,我们哥仨勾兑勾兑,他们肯定有漏洞的,” 老大安慰到,“老二,你先说说你的看法。”

 

“其实吧,我们想去借一个Cookie来用,关键是要让我们Beauty.com的JavaScript在目标浏览器上运行,然后访问爱存不存银行(icbc.com.cn)的cookie,可是现在他们用了同源策略,我们网站的JavaScript不允许访问别人网站的东西,那这条路就行不通了。”

 

 

“我想到一个招数,” 老三兴奋地说,“我们可以想办法修改下icbc.com.cn服务器端的JavaScript, 把偷Cookie的代码加上去!”

 

“你想得美,那岂不得到icbc.com.cn的服务器去修改了!还得黑掉别人的服务器,这就难了,即使你修改了,人家程序员再次发布新版本,那不就把我们的修改给覆盖掉了?” 老大再次训斥。

 

“那我们就想办法去黑掉程序员的SVN,Github,直接把上面的代码给改了.....”  老三的声音越来越小。

 

“唉,算了吧,我们盗亦有道,只做Web端黑客。” 老大重申三人组织的性质。

 

这时候老二想了一个办法:“其实老三说的也有道理,我们只要想办法把JavaScript代码注入到目标页面中,就能绕过同源策略了,这让我想到了HTML中的<input>,这个标签会在浏览器中产生一个输入框,让用户输入数据,我们可以把JavaScript代码当做数据输入进去, 等到数据提交到服务器端,会保存下来,下次展示页面的时候不就可以执行了吗?!”

 

老三说:“二哥我听不太明白,你能不能举个例子?”

 

老二说道:“好吧,有这么一个网站,可以让你对某个文章输入评论:”

“然后,你在评论区输入了这样的代码,注意,我们注入了一段'JavaScript'”

 

“等到再次有人访问这个页面的时候,会发生什么呢?”  老二启发老三。

 

“奥,我明白了,那就可以把那个人的cookie显示出来了!”老三一点都不笨。

 

兴奋之余,老三挠挠头:“ 但是这只是在人家的浏览器中显示,怎么才能发到我们的服务器呢? 用JavaScript来发? 那也不行, 因为同源策略严格限制JavaScript的跨域访问呐!”

 

老大也说:“是啊,这个人看到自己的cookie被alert出来,估计会吓一跳吧。”

 

老二说:“嗯,确实不能这么办,让我想想。”

 

一炷香时间过去,老二说:“有了! 那个同源策略并不限制<img>这样的标签从别的网站(跨域)去下载图片,我们在注入JavaScript代码的时候,同时创建一个用户不可见的<img>,通过这个<img>发cookie发给我们。”

 

老三还是不明白, 要求再详细解释一下,老二就上了代码:

 

老二说:“看到了吧,只要这段代码被执行,用户的cookie就会发到我们服务器上(http://beauty.com/log),我们就等着收取cookie吧!”

老三感慨道:“二哥你真厉害,天马行空,竟然想到了使用<img>的src属性来发送数据!”

 

老大说:“我们干脆把这段代码封装成一个js文件,嗯,就叫做beauty.js吧, 这样以后我们用起来会很方便!”

 

老三看到又可以‘借到’cookie了,兴奋得直搓手: “大哥二哥,我这就去把JS写出来,找个网站试一试。”

 

老大说道:“我们把这种方法叫做Cross Site Scripting ,简称CSS,二弟意下如何?”

 

老二说:“大哥, CSS已经名花有主了,意思是层叠样式表,我们还是叫做XSS吧!”

 

(码农翻身注:按照XSS的分类方法, 上面介绍的叫做存储性XSS, 危害最大。 还有反射型XSS,基于DOM的XSS,本文不再展开。)

 

大家都表示同意。

 

老三很快写出了beauty.js, 也折腾出了http://beauty.com/log 专门用于记录‘借’来的cookie。

 

他找了一家网站做实验,注入了beauty.js, 没过多久,cookie就源源不断地发过来了。大家都非常高兴,马上扩大范围,在多个知名网站上都做了手脚。

 

一周以后,负责监控的老三发现,cookie越来越少,老三赶紧调查,发现很多网站的Cookie都加上了HttpOnly这样的属性:

Set-Cookie:JSESSIONID=xxxxxx;Path=/;Domain=book.com;HttpOnly

 

这个cookie一旦加上HttpOnly,浏览器家族就禁止JavaScript读取了! 自然也就无法发回到beauty.com。

 

老三赶紧向组织汇报。

 

老大说道:“看来浏览器家族又升级了啊!”

 

老二说:“其实吧, 既然我们可以往指定的页面注入JavaScript代码,那这个JavaScript可以做的事情就多了去了,不一定只是借Cookie。例如我们可以用这个JS代码画一个假的登录框,覆盖到真的登录框之上,让用户信以为真,这样就可以偷到真实的用户名和密码了。 或者通过JavaScript构造GET,POST请求,可以模拟用户在该网站做点手脚,删点什么东西,从一个账号往另外一个账户转账,都是可以的嘛!”

 

“妙极, 老二,真有你的,老三,你去找点网站,按二哥说的试试。”

 

又过了几天,老三哭丧着脸说道:“大哥二哥,这些彻底玩完,现在人类出手了,来了几个必杀技。”

 

“什么必杀技?”

 

“一方面他们有人会对输入进行过滤,发现不符合他们要求的输入例如<,>等就会过滤掉,我们的<script>可能会变成'script' 被存到数据库里。”

 

“另一方面有人还会对输出进行编码/转义操作,例如会把'<'变成 '&lt;',把 '>' 变成‘&gt;’ ,然后再输出,这样一来我们的<script>就会变成&lt;script&gt; , 浏览器收到以后,就会认为是数据,把<script>作为字符串给显示出来,而不是执行后面的代码!”

 

老二说:“三弟别失望, 干我们这行的,就是矛和盾之间的较量,虽然在原理上大家已经知道了怎么防范XSS,但是在实践中总会有漏洞,我们只要耐心寻找就行了。 此外,我们还要想想别的办法,看看能不能开辟其他路子。”

 

“什么路子?” 老三问道。

 

“你们应该知道,一个用户的会话cookie在浏览器没有关闭的时候,是不会被删除的,对吧?”

 

“是的,我和老三都知道,我们不是一直试图去拿到这个cookie吗,只是越来越难了。”

 

“我们换下思路,不再去偷这个cookie了,相反,我们在我们的Beauty.com中构造一个领奖页面,里边包含一个连接,让用户去点击,例如:”

 

恭喜你获得了iPhone X一台,快来 <a href="www.icbc.com.cn/transfer?toBankId=黑客三兄弟的账户&money=金额">领取吧!</a>

 

“当然,” 老二补充道,“我们得事先知道icbc.com.cn的转账操作的url和参数名称。如果这个用户恰好登录了icbc.com, 那他的cookie还在, 当他禁不住诱惑,点了这个链接后,一个转账操作就神不知鬼不觉的发生了。”

(码农翻身注:为了方便展示,本文举了一个非常简单的案例,银行实际的转账操作要远远比文章描述安全得多。)

 

“那要是用户就是不点击呢?”

 

“你忘了我们XSS中使用过的img了吗, 也可以应用到这里来啊,创建一个看不见的图片:”

 

<img src="www.icbc.com.cn/transfer?toAccountID=黑客三兄弟的账户&money=金额">

 

“只要他打开了这个页面,不用点击任何东西,就会发生转账操作。”  老二再次祭出了img大法。

 

“怪不得现在有很多邮箱默认不显示邮件中的图片呢!”老三说,那要是人家icbc.com.cn的转账操作需要form表单,是POST操作呢?”

 

“那也不怕啊,我们可以把这个表单创建起来,放到一个不可见的iframe中,用户只要一访问,就用JavaScript自动提交。” 老大对这种办法驾轻就熟。

 

“总之,只要这个用户在访问icbc.com.cn的时候, 访问了我们的网站,就极有可能中招,我们这种方式,只是利用了一下合法的Cookie,在服务器看来,我们发出的请求,那就是一次合法的请求啊,哈哈!” 老二很得意。

 

“老二,你这叫跨站请求伪造啊,Cross Site Request Forgery(CSRF),这个缩写应该不会重复了吧!” 老大做了总结。

 

用了CSRF, 三兄弟果然获利颇丰,但是人类也很快也意识到了这一点,应对手段马上就来了,步骤特别简单:

 

1. 用户在icbc.com.cn转账,显示转账的form,除了常用的字段之外,额外添加一个token :

这个token是icbc.com服务器端生成的,是一个随机的数字。

 

2. 用户的转账数据发送的服务器端, icbc.com就会检查从浏览器发过来的数据中有没有token,并且这个token的值是不是和服务器端保存的相等,如果相等,就继续执行转账操作,如果不相等,那这次POST请求肯定是伪造的。

 

老三愁眉苦脸地对大家说:“这个token是服务器端生成的,我们无法伪造的,CSRF的手段也不行了。”

 

老大安慰道:“钱哪有那么容易就好挣的? 我们还是想想办法,多利用XSS漏洞吧,如果可以注入JavaScript, 就可以读取Token,为所欲为了。 ”

 

老二说:“大哥,Web端的油水越来越少,我们也得与时俱进,扩展下业务啊,黑客三兄弟向服务器端进军吧!”

 

“二弟所言极是,下周我们再讨论吧。”

(完)

浏览器家族的安全反击战

原创: 老刘 码农翻身 2017-12-19

1前言

上次我说过,我们浏览器的主要工作就是把HTML,JavaScript,CSS等文件从服务器端取下来,然后解析、渲染,展示成美奂美伦的页面呈现给人类。

 

我们还替人类保护一个叫做Cookie的小东西,网站会把Cookie发送给浏览器让我们保存起来,等到访问同一个网站的时候,我们再把他发过去。

 

这个Cookie用来证明某个用户已经和服务器交互过,更重要的是证明已经登录过系统,不用再次登录了。

 

JavaScript这小子在我们这里承担了越来越重要的职责,从对DOM树的改动,到利用AJAX访问服务器端,他可以说是风光无限。

 

(详情参见上一篇文章《浏览器:一个家族的奋斗》)

 

可是我们都忽视了一个重要的问题:安全,这个东西差点让我们家族遭受灭顶之灾。

 

2Cookie失窃

有一天,我的主人登录了"爱存不存"银行(www.icbc.com),这个银行网站给我发了一个Cookie,证明主人登录过了, 主人在“爱存不存”银行网站做了一些操作,但是忘记了退出,然后开了一个新的Tab页访问了一个叫做www.beauty.com ,我知道这个网站不怀好意,拼命地提醒主人,但是他仍然经不住网站上那些图片的诱惑,执意把这个网站打开。

 

我没有办法,只好下载这个不怀好意网站的HTML,JavaScript,CSS, 让我没有想到的是这里的JavaScript竟然想访问“爱存不存”银行的Cookie。

 

“这个Cookie是爱存不存银行给我的,不属于www.beauty.com,你为啥要访问?” 我问他。

 

“没事,我好奇,想看看别的网站的Cookie长什么样”  他轻松地回答。

 

我将信将疑地把Cookie给了他,他不知道做了什么花样,似乎是往www.beauty.com发了一个请求,然后就把Cookie还给了我。

 

很快我的主人就发现,他在“爱存不存”银行的私房钱不翼而飞了。

 

FireFox嘲笑我说:“你这个家伙啊,怎么能够把Cookie这么重要的东西随随便便地给别人呢? ‘爱存不存’银行的Cookie被黑客偷走了,那些黑客不用登录就可以冒充用户在‘爱存不存’网站做操作了。”

 

“啊? 有这么严重? 可他是JavaScript,照理说可以访问啊?”

 

“唉,你要知道,这个JavaScript和那个Cookie不是同一个网站的,怎么能访问呢。”

 

由于这件事,主人再我不理我了,从此开始宠幸FireFox。

 

3密码失窃

FireFox也没得意很久,他也很快中了招。

 

这一次,主人还是忍不住去www.beauty.com看图片,FireFox这次很小心,不把任何别的网站的Cookie发给这里的JavaScript。

 

但这一次beauty.com改变了策略,它用iframe的方式放置了一个淘宝的登录网页到beauty.com页面中,淘宝恰恰是主人最喜欢的,主人一看,不错啊,还有快捷登录方式,于是主人就输入了自己真实的用户名和密码,没想到Beauty.com的JavaScript 已经把这个淘宝登录Form的action指向了自家网站,等到主人点了登录按钮以后, 用户名和明文的密码就这样被窃取了。

 

于是FireFox也被打入冷宫。

 

4家族会议

黑客猖獗,类似的安全事故不断出现,我们家族的成员纷纷中招,家族赶紧召集会议,商量对策,防止人类把我们家族给废掉。

 

我和FireFox在会议上声讨现在的人类实在是喜欢访问那些不良网站,族长Mozilla说没办法这是人类的本性,无论如何也无法改变,如果改了就不是人类了。

 

“虽然我们控制不了人类的行为,但是我们浏览器家族可以做点改变,增加安全性!” Mozilla族长充满正义感和使命感,他下达了一个命令:“以后我们家族确定一条铁规:除非两个网页是来自于统一‘源头’, 否则不允许一个网页的JavaScript访问另外一个网页的内容,像Cookie,DOM,LocalStorage统统禁止访问!” 

 

我仔细咂摸这句话的含义,其实是说各个网页如果不同源的,就被隔离了,只能在自己的一亩三分地中折腾。

 

“什么叫同一个源头?” FireFox问道。

 

“就是说{protocol,host,port} 这三个东西必须得一样! 我给你们举个例子, 例如有这么一个网页: http://www.store.com/product/page.html, 下面的表格列出了各种不同情况。

 

 

这个同源策略确实严格, 不同源的网页无法访问另外一个网页的DOM,Cookie, 像beauty.com那样的恶意网站想偷走Cookie/密码就不容易了。

 

我想到了主人之前购物经常访问的http://www.store.com/, 这个页面中有一段装载jquery.js的代码:

 

<script src="//static.store.com/jquery.js > </script>

 

这个jquery.js是来自于不同的源(static.store.com), 难道他就没法操作www.store.com页面的内容了吗? 如果不能操作,这个jquery.js就没有任何用处啦!

 

我把这个困惑给大家说了下, FireFox马上附和: “没错,难道我们要强制人类把所有的JavaScript代码放到www.store.com下吗? 人类肯定不能容忍! ”

 

“嗯,这是个好问题”  Mozilla族长说,“这样,我给你们开个口子,对于使用<script src='xxxxx'> 加载的JavaScript,我们认为它的源属于www.store.com, 而不属于static.store.com,这样就可以操作www.store.com的页面了,行不行?”

 

我和FireFox都表示赞同,其实这种“嵌入式”的跨域加载资源的方式还有<img>,<link>等,相当于我们浏览器发起了一次GET请求,取到相关资源,然后放到本地而已。

 

同源策略就这么确定下来了, 我们这些浏览器都开始严格遵守执行,果然,安全事故大大减少。

 

5凡事都有例外

过了一段时间,JavaScript这小子便跑来抱怨了:“你们这个同源策略实在太严格了,太不方便了。”

 

我说:“这也是为了大家好啊,省得那些不良网站干坏事。”

 

JavaScript说:“好什么好? 现在人类的系统越来越大,大部分都拆分成分布式的了,每个系统都有子域名,像login.store.com, payment.store.com, 虽然二级域名不同,但是他们属于一个大的系统,由于同源策略的铁规,cookie不能在这个系统之间共享,麻烦死了。”

 

这确实是个问题,我带着JavaScript找到到Mozilla组长,说明情况,希望他网开一面。

 

族长说:“好吧,我再给你们开个口子,如果两个网页的一级域名是相同的,他们可以共享cookie, 不过cookie的domain一定要设置为那个一级域名才可以,例如:”

document.cookie = 'test=true;path=/;domain=store.com'

 

JavaScript说:“还有个大问题,你们为什么不让我使用XMLHttpRequest访问不同的网站啊!”

 

我心想JavaScript说的可能是AJAX,可以创建一个XMLHttpRequest对象去异步的访问服务器端提供的服务,做到局部刷新页面,用户体验很好。

 

难道这个XMLHttpRequest对象只能访问源服务器(如book.com),不能访问其他服务器(如beauty.com)?

 

族长说:“是啊,XMLHttpReqeust也要遵守同源策略。”

 

JavaScript说:“可是这没有道理啊!我虽然是从book.com来的,但是为什么不让我访问beauty.com?”

 

族长说:“我这也是为了防止黑客攻击,给你举个例子,假设你的主人登录了book.com , 然后又去访问beauty.com,如果这个beauty.com是个恶意网站,它也要求你创建一个XMLHttpRequest对象,通过这个对象向book.com(不同源)发起请求,获取你主人的账户信息,会发生什么情况? ”

 

JavaScript恍然大悟:“奥,我懂了,由于主人登录过了book.com,登录cookie什么的都在,那beauty.com的JavaScript 向book.com发起的XMLHttpRequest请求也会成功,我主人的账户信息就会被黑客给获取了。”

 

我说:“看来对XMLHttpReqeust对象施加同源策略也是非常重要的啊!”

 

JavaScript沉默了半天说:“那怎么办?”

 

Mozilla族长说:“你可以通过服务器端中转啊,例如你是来自book.com的, 现在想访问movie.com,那可以让那个book.com把请求转发给movie.com嘛!人类好像给这种方式起了个名字,叫什么代理模式,那个book.com就是代理人。”

JavaScript急忙说:“不不, 这样太麻烦了,族长你想想,如果我要访问多个不同源的系统,要是都通过book.com中转,该多麻烦!”

 

族长想了想说:“你说得有一定道理,我给你出个主意,既然服务器(domain)之间是互信的,那一个服务器(domain)可以设置一个白名单,里边列出它允许哪些服务器(domain)的AJAX请求。假设movie.com的白名单中有book.com, 那当属于book.com的JavaScript试图访问movie.com的时候......”

 

JavaScript马上接口说:“ 这时候,我们浏览器做点手脚,悄悄地把当前的源(book.com)发过去,询问下movie.com, 看看他是否允许我们访问,如何允许,你们就继续访问,否则就报错!”

 

 

组长说:“就是这个意思,这样以来,那些黑客就没有办法假冒用户向这些互信的服务器发送请求了, 我把这个方法叫做Cross Origin Resource Sharing,简称CORS,只不过这个方法需要服务器的配合了”

 

(码农翻身注:上面说的是CORS的简单请求,对于Preflight请求,本文不在展开描述)

 

JavaScript表示同意,这也算是一个不错的妥协方法了。

(完)

 

 

一个故事讲完https

原创: 老刘 码农翻身 2017-07-17

1  序言

 

今天来聊一聊https 安全传输的原理。

 

在开始之前,我们来虚构两个人物, 一个是位于中国的张大胖(怎么又是你?!), 还有一个是位于米国的Bill (怎么还是你?!)。

 

这俩哥们隔着千山万水,通过网络联系上了, 两个人臭味相投,聊得火热。

 

此时正值米国大选, 张大胖亲切地“致电”Bill, 对米国总统大选的情况表示强烈地关注。 Bill则回电说谢谢关心米国人的事情我们米国人自己做主,不用你们歪果仁瞎操心......

 

张大胖继续“致电”说其实我们支持特朗普, 因为希拉里太情绪化,太难打交道了, 我们挺希望看到特朗普上台这样米国就会变成 The Divided State of America ......

 

Bill 回电: 拉倒你吧你, 我们米国的政体有着强大的纠错性, 虽然有时候发展得慢, 有时候会走上岔路, 但很快就会回到正途,几百年来稳定得很,不像你们像坐了过山车一样.....

 

两个人越聊越投机,天南地北,海阔天空,还夹杂着不少隐私的话题。

 

2 总是有一种被偷看的感觉

 

有一天, Bill 突然意识到: 坏了, 我们的通信是明文的, 这简直就是网络上裸奔啊, 任何一个不怀好意的家伙都可以监听我们通信,打开我们发送的数据包,窥探我们的隐私啊。

 

张大胖说: “你不早点说,我刚才是不是把我的微信号给你发过去了? 我是不是告诉你我上周去哪儿旅游了?   估计已经被人截取了吧!”

 

Bill  提议: “要不我们做个数据的加密? 每次传输之前, 你把消息用一个加密算法加密, 然后发到我这里以后我再解密, 这样别人就无法偷窥了,像这样: ”

 

 

 

张大胖冰雪聪明,一看就明白了, 这加密和解密算法是公开的,那个密钥是保密的, 只有两人才知道, 这样生成的加密消息(密文) 别人就无法得知了。 他说: “Bill 老兄,你生成一个密钥, 然后把密钥发给我, 咱们这就开启加密消息, 让那些偷窥狂人们哭去吧!”

 

(码农翻身注:这叫对称加密算法, 因为加密和解密用的是同一个密钥)

 

一炷香功夫过去了, Bill 还是没有回音, 张大胖忍不住地催促: “快发啊?!!!”

 

Bill 终于回复了: “ 我感觉有一双眼睛正在虎视眈眈地盯着我们的通话, 如果我把密钥发给你, 也被他截取了, 那加密岂不白费工夫?”

 

张大胖沉默了, 是啊, 网络是不安全的, 这密钥怎么安全地发过来啊 ? 

 

“奥,对了,我下周要去米国旅游,到时候我们见一面,把密码确定下来,写到纸上,谁也偷不走, 这不就结了?” 

 

“哈哈, 这倒是终极解决之道 ”  Bill 笑了, “不过,我不仅仅和你聊天, 我还要和易卜拉欣,阿卜杜拉, 弗拉基米尔,克里斯托夫,玛格丽特, 桥本龙太郎, 李贤俊, 许木木,郭芙蓉,吕秀才等人通信, 我总不能打着飞的,满世界的和人交换密码吧? ”

 

张大胖心里暗自佩服Bill同学的好友竟然遍布全球,看来他对加密通信的要求更加强烈啊!

 

可是这个加密解密算法需要的密钥双方必须得知道啊, 但是密钥又无法通过网络发送, 这该死的偷窥者!

3  RSA : 非对称加密

 

Bill 和 张大胖的通信无法加密,说话谨慎了不少, 直到有一天, 他们听说了一个叫做RSA的非对称加密算法,一下子来了灵感。

 

这个RSA算法非常有意思,它不是像之前的算法, 双方必须协商一个保密的密钥, 而是有一对儿钥匙, 一个是保密的,称为私钥,另外一个是公开的,称为公钥

 

更有意思的是,用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据, 只有对应的私钥才能解密。

 

有了这两个漂亮的特性, 当张大胖给Bill发消息的时候, 就可以先用Bill的公钥去加密(反正Bill的公钥是公开的,地球人都知道), 等到消息被Bill 收到后, 他就可以用自己的私钥去解密(只有Bill才能解开,私钥是保密的 )

 

 

反过来也是如此, 当Bill 想给张大胖发消息的时候,就用张大胖的公钥加密, 张大胖收到后,就用自己的私钥解密。

 

这样以来,通信安全固若金汤, 没有任何人能窥探他们的小秘密了。

 

4 非对称加密+对称加密

 

两人实验了几次,  张大胖说: “Bill  , 你有没有感觉这个RSA的加密和解密有点慢啊?”

 

Bill叹了口气 :“是啊, 我也注意到了, 刚才搜了一下,这个RSA算法比之前的对称密钥算法要慢上百倍。我们就是加个密而已,现在搞得都没法用了”

 

“回到咱们最初的问题,我们想用一个密钥来加密通信,那个对称加密算法是非常快的,但是苦于密钥无法安全传输, 现在有了RSA ,我想可以结合一下, 分两步走 (1) 我生成一个对称加密算法的密钥, 用RSA的方式安全发给你,  (2) 我们随后就不用RSA了, 只用这个密钥,利用对称加密算法来通信,  如何?   ”

 

Bill 说: “你小子可以啊, 这样以来既解决了密钥的传递问题, 又解决了RSA速度慢的问题,不错。” 

 

于是两人就安全地传递了对称加密的密钥, 用它来加密解密,果然快多了!

 

5 中间人攻击

 

 

张大胖把和Bill 聊天的情况给老婆汇报了一次。

 

老婆告诫他说: “你要小心啊, 你确定网络那边坐着的确实是Bill ?”

 

张大胖着急地辩解说:“肯定是他啊,我都有他的公钥,我们俩的通信都是加密的。”

 

老婆提醒道:"假如啊,Bill给你发公钥的时候, 有个中间人,截取了Bill的公钥, 然后把自己的公钥发给了你,冒充Bill ,你发的消息就用中间人的公钥加了密, 那中间人不就可以解密看到消息了?"

 

张大胖背后出汗了,是啊,这个中间人解密以后,还可以用Bill的公钥加密,发给Bill ,  Bill和我根本都意识不到, 还以为我们在安全传输呢!

 

 

看来问题出现在公钥的分发上!  虽然这个东西是公开的, 但是在别有用心的人看来,截取以后还可以干坏事 !

 

6 你到底是谁?

 

但是怎么安全地分发公钥呢? 似乎又回到了最初的问题: 怎么安全的保护密钥?

 

可是似乎和最初的问题还不一样,这一次的公钥不用保密,但是一定得有个办法声明这个公钥确实是Bill的, 而不是别人的。

 

怎么声明呢?

 

张大胖突然想到: 现实中有公证处,它提供的公证材料大家都信任,那在网络世界也可以建立一个这样的具备公信力的认证中心, 这个中心给大家颁发一个证书, 用于证明一个人的身份。

 

这个证书里除了包含一个人的基本信息之外,还有包括最关键的一环:这个人的公钥!

 

这样以来我拿到证书就可以安全地取到公钥了 ! 完美!

 

可是Bill 马上泼了一盆冷水:证书怎么安全传输? 要是证书传递的过程中被篡改了怎么办?

 

张大胖心里不由地咒骂起来: 我操, 这简直就是鸡生蛋,蛋生鸡的问题啊。

 

天无绝人之路, 张大胖很快就找到了突破口: 数字签名。

 

简单来讲是这样的, Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要, 这个Hash算法有个极好的特性,只要输入数据有一点点变化,那生成的消息摘要就会有巨变,这样就可以防止别人修改原始内容。

 

 

可是作为攻击者的中间人笑了: “虽然我没办法改公钥,但是我可以把整个原始信息都替换了, 生成一个新的消息摘要, 你不还是辨别不出来?”

 

张大胖说你别得意的太早 , 我们会让有公信力的认证中心(简称CA)用它的私钥对消息摘要加密,形成签名:

 

 

这还不算, 还把原始信息和数据签名合并, 形成一个全新的东西,叫做“数字证书

 

张大胖接着说:当Bill把他的证书发给我的时候, 我就用同样的Hash 算法, 再次生成消息摘要,然后用CA的公钥对数字签名解密, 得到CA创建的消息摘要, 两者一比,就知道有没有人篡改了!

 

如果没人篡改, 我就可以安全的拿到Bill的公钥喽,有了公钥, 后序的加密工作就可以开始了。

 

虽然很费劲, 但是为了防范你们这些偷窥者,实在是没办法啊。

 

中间人恶狠狠地说: “算你小子狠! 等着吧,我还有别的招。 对了,我且问你, 你这个CA的公钥怎么拿到? 难道不怕我在你传输CA公钥的时候发起中间人攻击吗? 如果我成功的伪装成了CA,你这一套体系彻底玩完。”

 

张大胖语塞了,折腾了半天,又回到了公钥安全传输的问题!

 

不过转念一想,想解决鸡生蛋,蛋生鸡的问题必须得打破这个怪圈才行,我必须得信任CA,并且通过安全的的方式获取他们的公钥,这样才能把游戏玩下去。

 

(公众号码农翻身注:这些CA本身也有证书来证明自己的身份,并且CA的信用是像树一样分级的,高层的CA给底层的CA做信用背书,而操作系统/浏览器中会内置一些顶层的CA的证书,相当于你自动信任了他们。 这些顶层的CA证书一定得安全地放入操作系统/浏览器当中,否则世界大乱。)

 

7  https 

 

 

终于可以介绍https了,前面已经介绍了https的原理, 你把张大胖替换成浏览器, 把Bill 替换成某个网站就行了。

 

一个简化的(例如下图没有包含Pre-Master Secret)https流程图是这样的, 如果你理解了前面的原理,这张图就变得非常简单:

 

 

(完)

 

深入浅出HTTPS工作原理

HTTP协议由于是明文传送,所以存在三大风险:

1、被窃听的风险:第三方可以截获并查看你的内容

2、被篡改的危险:第三方可以截获并修改你的内容

3、被冒充的风险:第三方可以伪装成通信方与你通信

HTTP因为存在以上三大安全风险,所以才有了HTTPS的出现。

HTTPS涉及到了很多概念,比如SSL/TLS,数字证书、数字签名、加密、认证、公钥和私钥等,比较容易混淆。我们先从一次简单的安全通信故事讲起吧,其中穿插复习一些密码学的概念。

一. 关于Bob与他好朋友通信的故事

这个故事的原文是:

http://www.youdzone.com/signature.html

阮一峰老师也翻译过:

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

(不过阮老师里面没有很好的区分加密和认证的概念,以及最后HTTPS的说明不够严谨,评论区的针对这些问题的讨论比较激烈,挺有意思的)

这里重新叙述一下这个故事:

故事的主人公是Bob,他有三个好朋友Pat、Doug和Susan。Bob经常跟他们写信,因为他的信是明文传输的,在传递过程可能被人截获偷窥,也可能被人截获然后又篡改了,更有可能别人伪装成Bob本人跟他的好朋友通信,总之是不安全的。他很苦恼,经过一番苦苦探索,诶,他发现计算机安全学里有一种叫非对称加密算法的东东,好像可以帮助他解决这个问题

说明:非对称加密算法(RSA)是内容加密的一类算法,它有两个秘钥:公钥与私钥。公钥是公开的钥匙,所有人都可以知道,私钥是保密的,只有持有者知道。通过公钥加密的内容,只能通过私钥解开。非对称加密算法的安全性很高,但是因为计算量庞大,比较消耗性能。

好了,来看看Bob是怎么应用非对称加密算法与他的好朋友通信的:

1、首先Bob弄到了两把钥匙:公钥和私钥。

2、Bob自己保留下了私钥,把公钥复制成三份送给了他的三个好朋友Pat、Doug和Susan。

3、此时,Bob总算可以安心地和他的好朋友愉快地通信了。比如Susan要和他讨论关于去哪吃午饭的事情,Susan就可以先把自己的内容(明文)首先用Bob送给他的公钥做一次加密,然后把加密的内容传送给Bob。Bob收到信后,再用自己的私钥解开信的内容。

说明:这其实是计算机安全学里加密的概念,加密的目的是为了不让别人看到传送的内容,加密的手段是通过一定的加密算法及约定的密钥进行的(比如上述用了非对称加密算法以及Bob的公钥),而解密则需要相关的解密算法及约定的秘钥(如上述用了非对称加密算法和Bob自己的私钥),可以看出加密是可逆的(可解密的)。

4、Bob看完信后,决定给Susan回一封信。为了防止信的内容被篡改(或者别人伪装成他的身份跟Susan通信),他决定先对信的内容用hash算法做一次处理,得到一个字符串哈希值,Bob又用自己的私钥对哈希值做了一次加密得到一个签名,然后把签名和信(明文的)一起发送给Susan。

说明:Bob的内容实质是明文传输的,所以这个过程是可以被人截获和窥探的,但是Bob不担心被人窥探,他担心的是内容被人篡改或者有人冒充自己跟Susan通信。这里其实涉及到了计算机安全学中的认证概念,Bob要向Susan证明通信的对方是Bob本人,另外也需要确保自己的内容是完整的。

5、Susan接收到了Bob的信,首先用Bob给的公钥对签名作了解密处理,得到了哈希值A,然后Susan用了同样的Hash算法对信的内容作了一次哈希处理,得到另外一个哈希值B,对比A和B,如果这两个值是相同的,那么可以确认信就是Bob本人写的,并且内容没有被篡改过。

说明:4跟5其实构成了一次完整的通过数字签名进行认证的过程。数字签名的过程简述为:发送方通过不可逆算法对内容text1进行处理(哈希),得到的结果值hash1,然后用私钥加密hash1得到结果值encry1。对方接收text1和encry1,用公钥解密encry1得到hash1,然后用text1进行同等的不可逆处理得到hash2,对hash1和hash2进行对比即可认证发送方。

6、此时,另外一种比较复杂出现了,Bob是通过网络把公钥寄送给他的三个好朋友的,有一个不怀好意的家伙Jerry截获了Bob给Doug的公钥。Jerry开始伪装成Bob跟Doug通信,Doug感觉通信的对象不像是Bob,但是他又无法确认。

7、Bob最终发现了自己的公钥被Jerry截获了,他感觉自己的公钥通过网络传输给自己的小伙伴似乎也是不安全的,不怀好意的家伙可以截获这个明文传输的公钥。为此他想到了去第三方权威机构“证书中心”(certificate authority,简称CA)做认证。证书中心用自己的私钥对Bob的公钥和其它信息做了一次加密。这样Bob通过网络将数字证书传递给他的小伙伴后,小伙伴们先用CA给的公钥解密证书,这样就可以安全获取Bob的公钥了。

二、HTTPS通信过程

通过Bob与他的小伙伴的通信,我们已经可以大致了解一个安全通信的过程,也可以了解基本的加密、解密、认证等概念。HTTPS就是基于这样一个逻辑设计的。

首先看看组成HTTPS的协议:HTTP协议和SSL/TLS协议。HTTP协议就不用讲了,而SSL/TLS就是负责加密解密等安全处理的模块,所以HTTPS的核心在SSL/TLS上面。整个通信如下:

1、浏览器发起往服务器的443端口发起请求,请求携带了浏览器支持的加密算法和哈希算法。

2、服务器收到请求,选择浏览器支持的加密算法和哈希算法。

3、服务器下将数字证书返回给浏览器,这里的数字证书可以是向某个可靠机构申请的,也可以是自制的。

4、浏览器进入数字证书认证环节,这一部分是浏览器内置的TLS完成的:

4.1 首先浏览器会从内置的证书列表中索引,找到服务器下发证书对应的机构,如果没有找到,此时就会提示用户该证书是不是由权威机构颁发,是不可信任的。如果查到了对应的机构,则取出该机构颁发的公钥。

4.2 用机构的证书公钥解密得到证书的内容和证书签名,内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性(验证过程类似上面Bob和Susan的通信)。签名通过后,浏览器验证证书记录的网址是否和当前网址是一致的,不一致会提示用户。如果网址一致会检查证书有效期,证书过期了也会提示用户。这些都通过认证时,浏览器就可以安全使用证书中的网站公钥了。

4.3 浏览器生成一个随机数R,并使用网站公钥对R进行加密。

5、浏览器将加密的R传送给服务器。

6、服务器用自己的私钥解密得到R。

7、服务器以R为密钥使用了对称加密算法加密网页内容并传输给浏览器。

8、浏览器以R为密钥使用之前约定好的解密算法获取网页内容。

备注1:前5步其实就是HTTPS的握手过程,这个过程主要是认证服务端证书(内置的公钥)的合法性。因为非对称加密计算量较大,整个通信过程只会用到一次非对称加密算法(主要是用来保护传输客户端生成的用于对称加密的随机数私钥)。后续内容的加解密都是通过一开始约定好的对称加密算法进行的。

备注2:SSL/TLS是HTTPS安全性的核心模块,TLS的前身是SSL,TLS1.0就是SSL3.1,TLS1.1是SSL3.2,TLS1.2则是SSL3.3。 SSL/TLS是建立在TCP协议之上,因而也是应用层级别的协议。其包括TLS Record Protocol和TLS Handshaking Protocols两个模块,后者负责握手过程中的身份认证,前者则保证数据传输过程中的完整性和私密性。


微信公众号【黄小斜】大厂程序员,互联网行业新知,终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」 等关键字可以获取对应的免费学习资料。 


                     wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

 

登录 后评论
下一篇
云攻略小攻
1473人浏览
2019-10-21
相关推荐
《码农翻身》之技术之路
994人浏览
2018-08-02 16:30:15
《码农翻身》之Java帝国
836人浏览
2018-07-31 21:55:43
HTTP,HTTPS和HSTS详解
993人浏览
2017-09-23 22:22:13
0
0
0
705