W3C世界法则 |
|
基础第一，我觉得有必要将可能涉及的语言基础部分进行系统介绍，大家将会发现许多有意思的知识。不过，对于已经非常熟悉该领域的人来说，可以跳过本帖或仅仅是粗略地过一遍。
我绝不会像教科书那样介绍一些过于基础的内容，比如，语法、函数等，这些知识可以查阅官方手册。会始终会围绕前端安全，这些基础知识点会贯穿全文。 👨🎨🩰✏😪👍 首先，看看这个松散的HTML 世界，脚本、样式、图片、多媒体等这些资源如何运作；然后，看看号称跨站之魂的JavaScript 脚本如何打破这个世界的逻辑，CSS 样式如何让这个世界充满伪装；最后，看看另一只躲藏在Flash 里的“幽灵”，它又是如何辅佐JavaScript 的。 W3C即万维网联盟（），它制定了很多推荐标准，比如：HTML、XML、JavaScript、CSS 等，是这些标准让这个Web 世界变得标准和兼容。浏览器遵循这些标准去实现自己的各种解析引擎，Web 厂商同样遵循这些标准去展示自己的Web 服务。 🧒🦺📷🤛 如果没有W3C，那么这个Web 世界将一片混乱。由于 W3C 制定的是推荐标准，很多时候网站并没严格按照这些标准执行，但是却能比较好地呈现出来。而浏览器的实现也不一定完全遵循标准，甚至可能冒出一个自己的方案，这个现象可以在微软的IE 浏览器与Mozilla 的Firefox 浏览器中随处发现，这也是前端设计师们经常苦恼的“不兼容”问题，导致出现了各种“Hack”技术，这些Hacks 就是为了解决这些不兼容问题而出现的。 比如，为了解决CSS 兼容性而发展的CSS Reset 技术，该技术会重置一些样式（这些样式在不同的浏览器中有不同的呈现），后续的CSS 将在这个基础上重新开始定义自己的样式。 👳🩳🖌😰👎 再如，为了解决JavaScript 兼容性，诞生了许多优秀的JavaScript 框架，如jQuery、YUI等，使用这些框架提供的API，就可以很好地在各个主流浏览器上得到一致的效果。 Web 世界在进步，标准化也越来越被重视。相比前端工程师来说，我们更关注安全问题，W3C 的标准设计就安全了吗？浏览器遵循W3C 标准的实现就完美了吗？浏览器之间的这些差异可能导致多少安全风险的出现？在深入了解这些知识之前，我们还需要明白一点，导致Web 安全事件的角色都有哪些，而解决方案参与者又有哪些？ Web安全事件的角色如下：🧑🚀🎒🖥😉🤝 ·W3C； ·浏览器厂商； ·Web 厂商； ·攻击者（或黑客）； 被攻击者（或用户） 解决方案的参与者除了攻击者以外，其他都需要参与，这是一个因果循环，如果W3C的标准制定具有安全缺陷，那么遵循标准去实现的浏览器厂商与Web 厂商都将带进这些安全缺陷，或者W3C 标准没安全缺陷，而浏览器厂商或者Web 厂商实现上存在缺陷，那么安全事件照样发生，而如果被攻击者能有比较好的安全意识或防御方案，那么安全事件也很难发生。 URL 🦷⛴🦀🈚 URL 是互联网最伟大的创意之一，也就是我们经常提的链接，通过URL 请求可以查找到唯一的资源，格式如下： <scheme>://<netloc>/<path>?<query>#<fragment> 比如，下面是一个最普通的URL： 🖐🗺🌰🆒🐖 对应关系是： <scheme> - http 👎🌧🔪🚭🐡 <netloc> -<path> - /path/f.php <query> - id=1&type=cool，包括<参数名=参数值>对<fragment> - new 🧑🌾🩳💊🥲🤟 对于需要HTTP Basic 认证的URL 请求，甚至可以将用户名与密码直接放入URL 中，在<netloc>之前，格式如： http://username:[email protected]/ 我们接触最多的是HTTP/HTTPS 协议的URL，这是Web 安全的入口点，各种安全威胁都是伴随着URL 的请求而进行的，如果客户端到服务端各层的解析没做好，就可能出现安全问题。 💪⛪™🐋 URL 有个重点就是编码方式，有三类：escape、encodeURI、encodeURIComponent，对应的解码函数是：unescape、decodeURI、decodeURIComponent。这三个编码函数是有差异的，甚至浏览器在自动URL 编码中也存在差异。 HTTP 协议 URL 的请求协议几乎都是HTTP，它是一种无状态的请求响应，即每次的请求响应之后，连接会立即断开或延时断开（保持一定的连接有效期），断开后，下一次请求再重新建立。这里假设一个简单的例子，对发起一个GET 请求：👴🧣📬😔👀 GET HTTP/1.1 响应如下： 👳👚💉😔👍 HTTP/1.1 200 OK 请求与响应一般都分为头部与体部（它们之间以空行分隔）。对于请求体来说，一般出现在POST 方法中，比如表单的键值对。响应体就是在浏览器中看到的内容，比如，HTML/JSON/JavaScript/XML 等。这里的重点在这个头部，头部的每一行都有自己的含义，key 与value 之间以冒号分隔，下面看看几个关键点。 👄🏠🍌☪🦟 请求头中的几个关键点如下。 GET HTTP/1.1 👍⛄🍼☪🐶 这一行必不可少，常见的请求方法有GET/POST，最后的“HTTP/1.1”表示1.1 版本的HTTP 协议，更早的版本有1.0、0.9。 Host: 这一行也必不可少，表明请求的主机是什么。 👀🗽🍼🚭🦟 User-Agent: Mozilla/5.0 (Windows 7) AppleWebKit/535.19 (KHTML, likeGecko) Chrome/18.0.1025.3 Safari/535.19 User-Agent 很重要，用于表明身份（我是谁）。从这里可以看到操作系统、浏览器、浏览器内核及对应的版本号等信息。 🤞🗺🎂🅾🐅 Referer: Referer 很重要，表明从哪里来，比如从页面点击过来。 Cookie: SESSIONID=58AB420B1D8B800526ACCCAA83A827A3:FG=1👳🥾🩺🙄👀 前面说HTTP 是无状态的，那么每次在连接时，服务端如何知道你是上一次的那个？这里通过Cookies 进行会话跟踪，第一次响应时设置的Cookies 在随后的每次请求中都会发送出去。Cookies 还可以包括登录认证后的身份信息。 响应头中的几个关键点如下。 👃🚤🍪🉑🐝 HTTP/1.1 200 OK这一行肯定有，200 是状态码，OK 是状态描述。 Server: Apache/2.2.8 (Win32) PHP/5.2.6👩🛍🪓😒✊ 上述语句透露了服务端的一些信息：Web 容器、操作系统、服务端语言及对应的版本。 X-Powered-By: PHP/5.2.6 ✊🪐🍊♀🐤 这里也透露了服务端语言的信息。Content-Length: 3635 响应体的长度。 🤛🎠🍚♻🐙 Content-Type: text/html;charset=gbk 响应资源的类型与字符集。针对不同的资源类型会有不同的解析方式，这个会影响浏览器对响应体里的资源解析方式，可能因此带来安全问题。字符集也会影响浏览器的解码方式，同样可能带来安全问题。 👍🏝🌰✔ Set-Cookie: PTOKEN=; expires=Mon, 01 Jan 1970 00:00:00 GMT; path=/;domain=.foo.com; HttpOnly; SecureSet-Cookie: USERID=c7888882e039b32fd7b4d3; expires=Tue, 01 Jan 203000:00:00 GMT; path=/; domain=.universemy.com 每个 Set-Cookie 都设置一个Cookie（key=value 这样），随后是如下内容。 🧑🚀👔⚒💩💅 expires：过期时间，如果过期时间是过去，那就表明这个Cookie 要被删。 path：相对路径，只有这个路径下的资源可以访问这个Cookie。 domain：域名，有权限设置为更高一级的域名。 HttpOnly：标志（默认无，如果有的话，表明Cookie 存在于HTTP 层面，不能被客户端脚本读取）。 Secure：标志（默认无，如果有的话，表明Cookie 仅通过HTTPS 协议进行安全传输）。 👈🛑🍭🈴🐡 请求响应头部常见的一些字段都有必要了解，这是我们在研究Web 安全时对各种HTTP 数据包分析的必备知识。
帖子热度 1.2万 ℃
|
|
|
「古黑浩劫」
变色卡
古黑论管理员，在论坛上有什么问题都可以找他。