Web前端技能树

Web前端技能树的思维导图，包括Javascript、CSS、HTML 5、浏览器兼容、HTTP协议、JS源文件管理、性能优化等内容。

Web前端技能树

Javascript

JavaScript基础

类型及类型判别

JSON以及XML的区别和各自优缺点

定时器

数组

对象和函数

事件绑定

JavaScript高级

闭包

prorotype原型连

内存分配

对象声明

继承

作用域链

Ajax基础

Ajax运行原理

ajax跨域请求

ajax异步文件上传

返回数据合法性校验

框架

emberjs

angularjs

ionic（移动端框架）

KISSY(KISSY,Kimi,Mobile)

库

核心库

jquery

underscore

zepto

KISSY(Alibaba-inc)

报表库

HighChart/Stock

DataTable

动画库

Raphael

D3.js &&衍生库

其他功能库

语法

手册

语法糖增强 Coffeescript

包管理

bower

NPM

自建仓库CNPM

单元测试

QUnit

YUI Test

Jasmine

Mocha

调试工具

Chrome Developer Tools

Firefox Firebug

Opera蜻蜓

IE 开发者工具/IE 调试条for IE6

Fiddler/Charles/Wireshark

部署工具

Gulp

Grunt

Broccolli

CSS

预编译框架

Less

Sass

Stylus

主流版本

2.1

3.0

浏览器兼容

css hacks

selectors

property/value

“新”版本“新”特性

基于内核

webkit

ms

etc

现代浏览器的通用新特性

跨职责调用DOM属性接口

媒体属性

layout

布局方法论

中文可视优化

typo.css

yue.css

HTML5

浏览器兼容性

HTML5标签

本地存储

canvas

语义化

浏览器兼容

浏览器内核判断

IE个版本之间的差异

常见的浏览器内核

移动终端设备

IE和非IE事件的绑定

HTTP协议

URL

http

host

port

abs_path

HTTP请求

GET

POST

PUT

DELETE

HTTP响应

2xx

200

3xx

301

302

304

4xx

400

401

403

404

5xx

500

503

HTTP消息报头

普通报头

Cache-Control

Date

Connection

请求报头

Accept

Authorization

Host

User-Agent

响应报头

Location

Server

实体报头

Content-Encoding

Content-Language

Content-Length

Content-Type

Last-Modified

Expires

JS源文件管理

混淆与压缩

注释与文档管理

版本控制

按需加载与依赖注入

采用MVC架构

性能优化

雅虎网站页面性能优化的34条黄金守则

尽量减少HTTP请求次数

终端用户响应的时间中，有80%用于下载各项内容。这部分时间包括下载页面中的图像、样式表、脚本、Flash等。通过减少页面中的元素可以减少HTTP请求的次数。这是提高网页速度的关键步骤。 减少页面组件的方法其实就是简化页面设计。那么有没有一种方法既能保持页面内容的丰富性又能达到加快响应时间的目的呢？这里有几条减少HTTP请求次数同时又可能保持页面内容丰富的技术。 合并文件是通过把所有的脚本放到一个文件中来减少HTTP请求的方法，如可以简单地把所有的CSS文件都放入一个样式表中。当脚本或者样式表在不同页面中使用时需要做不同的修改，这可能会相对麻烦点，但即便如此也要把这个方法作为改善页面性能的重要一步。 CSS Sprites是减少图像请求的有效方法。把所有的背景图像都放到一个图片文件中，然后通过CSS的background-image和background-position属性来显示图片的不同部分； 图片地图是把多张图片整合到一张图片中。虽然文件的总体大小不会改变，但是可以减少HTTP请求次数。图片地图只有在图片的所有组成部分在页面中是紧挨在一起的时候才能使用，如导航栏。确定图片的坐标和可能会比较繁琐且容易出错，同时使用图片地图导航也不具有可读性，因此不推荐这种方法； 内联图像是使用data:URL scheme的方法把图像数据加载页面中。这可能会增加页面的大小。把内联图像放到样式表（可缓存）中可以减少HTTP请求同时又避免增加页面文件的大小。但是内联图像现在还没有得到主流浏览器的支持。 减少页面的HTTP请求次数是你首先要做的一步。这是改进首次访问用户等待时间的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage - Exposed!中所说，HTTP请求在无缓存情况下占去了40%到60%的响应时间。让那些初次访问你网站的人获得更加快速的体验吧！

减少DNS查找次数

域名系统（DNS）提供了域名和IP的对应关系，就像电话本中人名和他们的电话号码的关系一样。当你在浏览器地址栏中输入www.dudo.org时，DNS解析服务器就会返回这个域名对应的IP地址。DNS解析的过程同样也是需要时间的。一般情况下返回给定域名对应的IP地址会花费20到120毫秒的时间。而且在这个过程中浏览器什么都不会做直到DNS查找完毕。 缓存DNS查找可以改善页面性能。这种缓存需要一个特定的缓存服务器，这种服务器一般属于用户的ISP提供商或者本地局域网控制，但是它同样会在用户使用的计算机上产生缓存。DNS信息会保留在操作系统的DNS缓存中（微软Windows系统中DNS Client Service）。大多数浏览器有独立于操作系统以外的自己的缓存。由于浏览器有自己的缓存记录，因此在一次请求中它不会受到操作系统的影响。 Internet Explorer默认情况下对DNS查找记录的缓存时间为30分钟，它在注册表中的键值为DnsCacheTimeout。Firefox对DNS的查找记录缓存时间为1分钟，它在配置文件中的选项为network.dnsCacheExpiration（Fasterfox把这个选项改为了1小时）。 当客户端中的DNS缓存都为空时（浏览器和操作系统都为空），DNS查找的次数和页面中主机名的数量相同。这其中包括页面中URL、图片、脚本文件、样式表、Flash对象等包含的主机名。减少主机名的数量可以减少DNS查找次数。 减少主机名的数量还可以减少页面中并行下载的数量。减少DNS查找次数可以节省响应时间，但是减少并行下载却会增加响应时间。我的指导原则是把这些页面中的内容分割成至少两部分但不超过四部分。这种结果就是在减少DNS查找次数和保持较高程度并行下载两者之间的权衡了。

避免跳转

可缓存的AJAX

推迟加载内容

预加载

减少DOM元素数量

根据域名划分页面内容

使iframe的数量最小

不要出现404错误

使用内容分发网络

为文件头指定Expires或Cache-Control

Gzip压缩文件内容

配置ETag

尽早刷新输出缓冲

使用GET来完成AJAX请求

把样式表置于顶部

避免使用CSS表达式（Expression）

使用外部JavaScript和CSS

削减JavaScript和CSS

用<link>代替@import

避免使用滤镜

把脚本置于页面底部

剔除重复脚本

减少DOM访问

开发智能事件处理程序

减小Cookie体积

对于页面内容使用无coockie域名

优化图像

优化CSS Spirite

不要在HTML中缩放图像

favicon.ico要小而且可缓存

保持单个内容小于25K

打包组件成复合文本

内存泄露

事件绑定 事件代理

Web前端攻防

CSRF攻击方式

1.CSRF是什么？ 　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。 二.CSRF可以做什么？ 　　你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。 三.CSRF漏洞现状 　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。 四.CSRF的原理 　　下图简单阐述了CSRF攻击的思想： 　　从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤： 　　1.登录受信任网站A，并在本地生成Cookie。 　　2.在不登出A的情况下，访问危险网站B。 　　看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生： 　　1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。 　　2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......） 　　3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。 　　上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>） 　　示例1： 　　银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000 　　危险网站B，它里面有一段HTML的代码如下： 　　 　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块...... 　　为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作...... 　　示例2： 　　为了杜绝上面的问题，银行决定改用POST请求完成转账操作。 　　银行网站A的WEB表单如下：　　 　　 　　　　 ToBankId: 　　　　 Money: 　　　　 　　 　　后台处理页面Transfer.php如下： 复制代码 　　 　　　　session_start(); 　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money'])) 　　　　{ 　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']); 　　　　} 　　?> 复制代码 　　危险网站B，仍然只是包含那句HTML代码： 　　 　　和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。 　　示例3： 　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下： 复制代码 　　 　　　　session_start(); 　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money'])) 　　　　{ 　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']); 　　　　} 　　?> 复制代码 　　然而，危险网站B与时俱进，它改了一下代码： 复制代码 　　 　　　　 　　　　　　function steal() 　　　　　　{ 　　　　 iframe = document.frames["steal"]; 　　 　　 iframe.document.Submit("transfer"); 　　　　　　} 　　　　 　　 　　 　　　　 　　　　　　 　　　　　　　　 　　　　　　　　 　　　　　　 　　　　 　　 复制代码 如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行! 　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。 　　理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！ 五.CSRF的防御 　　我总结了一下看到的资料，CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。 　　1.服务端进行CSRF防御 　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。 　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)： 　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:> 　　 　　　　//构造加密的Cookie信息 　　　　$value = “DefenseSCRF”; 　　　　setcookie(”cookie”, $value, time()+3600); 　　?> 　　在表单里增加Hash值，以认证这确实是用户发送的请求。 复制代码 　　 　　　　$hash = md5($_COOKIE['cookie']); 　　?> 　　 　　　　 　　　　 　　　　”> 　　　　 　　 复制代码 　　然后在服务器端进行Hash值验证 复制代码 　　 if(isset($_POST['check'])) { 　　 $hash = md5($_COOKIE['cookie']); 　　 if($_POST['check'] == $hash) { 　　 doJob(); 　　 } else { 　　　　　　　　//... 　　 } 　　 } else { 　　　　　　//... 　　 } ?> 复制代码 　　这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。 　　(2).验证码 　　这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄....这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。 　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值) 　　在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。 　　以下我的实现: 　　1).先是令牌生成函数(gen_token())： 复制代码 function gen_token() { 　　　　//这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。 　　　　//这个可以参考我写的Findbugs笔记中的《Random object created and used only once》 $token = md5(uniqid(rand(), true)); return $token; } 复制代码 　　2).然后是Session令牌生成函数(gen_stoken())： 复制代码 　　function gen_stoken() { 　　　　　　$pToken = ""; 　　　　　　if($_SESSION[STOKEN_NAME] == $pToken){ 　　　　　　　　//没有值，赋新值 　　　　　　　　$_SESSION[STOKEN_NAME] = gen_token(); 　　　　　　} 　　　　　　else{ 　　　　　　　　//继续使用旧的值 　　　　　　} 　　} ?> 复制代码 　　3).WEB表单生成隐藏输入域的函数：　　 复制代码 　　 function gen_input() { 　　 gen_stoken(); 　　 echo “ 　　 value=\”" . $_SESSION[STOKEN_NAME] . “\”> “; 　　} ?> 复制代码 　　4).WEB表单结构： 复制代码 session_start(); include(”functions.php”); ?> 复制代码 　　5).服务端核对令牌： 　　这个很简单，这里就不再啰嗦了。 　　上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。 　　其实还有很多想写，无奈精力有限，暂且打住，日后补充，如果错漏，请指出:>

XSS攻击方式

Clickjacking攻击方式

cookie劫持