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 请求: 🤛⛴🦀♂🐂 GETHTTP/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; Secure Set-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万 ℃
|
|