HTTP协议
第一章 了解Web及网络基础
1.1 使用HTTP协议访问Web
client ---- HTTP(resource) ---- server
HTTP - HyerText Transfer Protocol, 超文本传输(转移)协议.
1.2 HTTP的诞生
最初设想: 借助多文档之间相互关联形成的超文本(HyperText),连成可相互参阅的WWW(World Wide Web, 万维网).
WWW构建技术:
把SGML作为页面的文本标记语言的HTML;
作为文档传输协议的HTTP
指定文档所在地址的URL
- SGML: Standard Generalized Markup Language, 标准通用标记语言
- HTML: HyperText Markup Language, 超文本标记语言
- URL: Uniform Resource Locator, 统一资源定位符
1.3 网络基础 TCP/IP
不同的硬件/操作系统之间的通信, 都需要一种规则, 而这种规则称为协议(protocol).
TCP/IP是互联网相关的各类协议族的总称
TCP / IP / IEEE 802.3 / FDDI / ICMP / HTTP / FTP / DNS / UDP / SNMP / PPPoE ...
协议中存在各式各样的内容: 从电缆的规格到IP地址的选定方法/寻找异地用户的方法/双方建立通信的顺序,以及Web页面显示需要的步骤,等等
TCP/IP的分层管理, 分为: 应用层 , 传输层 , 网络层 , 数据链路层 .
- 应用层
应用层决定了向用户提供应用服务时通信的活动.
TCP/IP协议族内预存了各类通用的应用服务. 比如, FTP(File Transfer Protocol, 文件传输协议) / DNS(Domain Name System, 域名系统) / HTTP - 传输层
传输层对上层应用层, 提供处于网络连接中的两台计算机之间的数据传输
在传输层有两个性质不同的协议: TCP(Transmission Control Protocol, 传输控制协议) 和 UDP(User Data Protocol, 用户数据报协议) - 网络层
网络层用来处理网络上流动的数据包. -- 路由, 网络拓扑 - 数据链路层
用来处理连接网络的硬件部分. 包括控制操作系统/硬件的设备驱动程序/NIC(Network Interface Card, 网络适配器, 网卡),及光纤等物理可见部分.
发送端在层与层之间传输数据时,每经过一层时必定会被打上一个该层所属的首部信息.反之,接收端在层与层传输数据时,没经过一层时会把对应的首部消去. 这种把数据信息包装起来的做法称为封装(encapsulate).
1.4 与HTTP关系密切的协议: IP TCP 和 DNS
1.4.1 负责传输的IP协议
按层次分,IP(Internet Protocol)网际协议位于网络层.
IP协议的作用是把各种数据包传送给对方.而要保证准确传送到对方那里,则需要满足各类条件.其中两个重要的条件是__IP地址__和__MAC地址__(Media Access Control Address).
IP地址指明节点被分配到的地址,MAC地址是指网卡所属的固定地址. IP地址可以和MAC地址进行配对. IP地址可变换,但MAC地址基本上不会更改.
1.4.2 确保可靠性的TCP协议
按层次分,TCP位于传输层,提供可靠的字节流服务.
所谓的字节流服务(Byte Stream Service)是指,为了方便传输,将大块数据分割成以报文段(segment)为单位的数据包进行管理.而可靠的传输服务是指,能够把数据准确可靠地传给对方.
为了准确无误地将数据送达目标处,TCP协议采用了三次握手(three-way handshaking)策略.握手过程中使用了TCP的标识(flag) ---- SYN(synchronize) 和 ACK (acknowledgement).
三次握手
发送端首先发送一个带SYN标识的数据包给对方.接收端收到后,回传一个带有SYN/ACK标识的数据包以示传达确认信息.最后,发送端再回传一个带ACK标识的数据包,代表"握手"结束.
1.5 负责域名解析的DNS服务
DNS服务是和HTTP协议一样位于应用层的协议. 它提供域名到IP地址之间的解析服务.
URL(Uniform Resource Locator, 统一资源定位符) <=== URI(Uniform Resource Identifier, 统一资源标识符)
第二章 简单的HTTP协议
-
请求和响应
请求报文是由请求方法, 请求URI, 协议版本, 可选的请求首部字段和请求实体构成的.
响应报文是由协议版本, 状态码, 用以解释状态码的原因短语, 可选的响应首部字段, 以及实体主体构成.
-
HTTP是不保存状态的协议
HTTP是无状态(stateless)协议, 自身不对请求和响应之间的通信状态进行保存, 即在HTTP中, 协议对于发送过的请求和响应都不做持久化处理,确保了协议的可伸缩性.
针对于用户状态保存的需求, 引入了Cookie技术, ===> redis 单点登录出场, token上线(手动狗头) -
告知服务器意图的HTTP方法
- GET: 获取资源
- POST: 传送实体主体
- PUT: 传输文件 尽量配合REST标准
- HEAD: 获得报文首部, 和GET方法一样,只是不返回报文主体部分. 用于确认URI的有效性及资源更新的日期时间等.
- DELETE: 删除文件 尽量配置REST标准
- OPTIONS: 询问支持的方法, 用来查询针对请求URI指定的资源支持的方法
- TRACE: 追踪路径, 极不常用
- CONNECT: 要求用隧道协议连接代理, CONNECT方法要求在与代理服务器通信时建立隧道,实现用隧道协议进行TCP通信.主要使用SSL(Secure Sockets Layer, 安全套接层)和TLS(Transport Layer Security, 传输层安全)协议把通信内容加密后经网络隧道传输.
-
持久连接节省通信量
最初每次进行HTTP通信都要断开一次TCP连接, 为避免多次通信的问题,引入了持久连接(HTTP Persistent Connections / HTTP keep-alive / HTTP connection reuse)的方法. 持久连接的特点是, 只要任何一端没有明确提出断开连接,则保持TCP连接状态.
持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载. 另外, 减少开销的那部分时间, 使HTTP请求和响应能够更早地结束,这样Web页面的显示速度也响应提高.
==> 管线化(pipelining) -
使用Cookie的状态管理
第三章 HTTP报文内的HTTP信息
内容协商返回最合适的内容
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉,然后提供给客户端最为合适的资源.内容协商会以响应资源的语言/字符集/编码方式等作为判断的基准.
第四章 返回结果的HTTP状态码
4.1 状态码告知从服务器端返回的请求结果
类别 | 原因短语 | |
---|---|---|
1XX | Informational(信息性状态码) | 接收的请求正在处理 |
2XX | Success(成功状态码) | 请求正常处理完毕 |
3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
5XX | Server Error(服务端错误状态码) | 服务器处理请求出错 |
- 200 OK
- 204 No Content
一般在只需要从客户端往服务器发送信息,而对客户端不需要发送新信息内容的情况下使用. - 206 Partial Content
该状态码表示客户端进行了范围请求,而服务器成功执行了这部分的GET请求.响应报文中包含由Content-Range指定范围的实体内容. - 301 Moved Permanently
永久性重定向.请求资源的URI已变更. - 302 Found
临时性重定向. - 303 SEE OTHER
该状态码表示由于请求对应的资源存在着另一个URI,应使用GET方法定向获取请求的资源 - 304 Not Modified
该状态码表示客户端发送附带条件的请求时,服务器端允许请求访问资源,但为满足条件的情况. - 307 Temporary Redirect
临时重定向,类似302 - 400 Bad Request
该状态码表示请求报文中存在语法错误 - 401 Unauthorized
需要认证/认证失败 - 403 Forbidden
未被授权 - 404 Not Found
- 500 Internal Server Error
- 503 Service Unavailable
该状态码表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求.
第五章 与HTTP协作的Web服务器
5.1 通信数据转发程序: 代理/网关/隧道
HTTP通信时,除客户端和服务器以外,还有一些用于通信数据转发的应用程序,例如代理/网关和隧道,它们可以配合服务器工作.
代理
代理是一种有转发功能的应用程序,它扮演了位于服务器和客户端"中间人"的角色,接收由客户端发送的请求并转发给服务器,同时也接收服务器返回的响应并转发给客户端
网关
网关是转发其它服务器通信数据的服务器,接收从客户端发送来的请求时,它就像自己拥有资源的源服务器一样对请求进行处理.
隧道
隧道是在相隔较远的客户端和服务器两者之间进行中转,并保持双方通信连接的应用程序
使用代理服务器的理由有: 利用缓存技术减少网络带宽的流量,组织内部针对特定网站的访问控制,以获取访问日志为主要目的,等等.
代理有多种使用方法,按两种基准分类.一种是 是否使用缓存, 另一种是 是否会修改报文.
- 缓存代理
代理转发响应时,缓存代理(Caching Proxy)会预先将资源的副本保存在代理服务器上.
当代理再次接收到对相同资源的请求时,就可以不从源服务器那里获取资源,而是将之前缓存的资源作为响应返回. - 透明代理
转发请求或响应时,不对报文做任何加工的代理类型被称为透明代理(Transparent Proxy),反之,对报文内容进行加工的代理被称为非透明代理.
网关的工作机制和代理相似.而网关能使通信线路上的服务器提供非HTTP协议服务.利用网关能提高通信的安全性,因为可以在客户端与网关之间的通信线路上加密以确保连接的安全.
第六章 HTTP头部
4种HTTP首部字段类型:
- 通用首部字段(General Header Fields)
请求报文和响应报文双方都会使用的首部 - 请求首部字段(Request Header Fields)
从客户端向服务器端发送请求报文时使用的首部.补充了请求的附加内容/客户端信息/响应内容相关优先级等信息 - 响应首部字段(Response Header Fields)
从服务器端向客户端返回响应报文时使用的首部.补充了响应的附加内容,也会要求客户端附加额外的内容信息 - 实体首部字段(Entity Header Fields)
针对请求报文和响应报文的实体部分使用的首部.补充了资源内容更新时间等与实体有关的信息
HTTP/1.1 首部字段一览
通用首部字段
首部字段名 | 说明 | 备注 |
---|---|---|
Cache-Control | 控制缓存的行为 | Cache-Control:private,max-age=0,no-cache 多指令 |
Connection | 逐跳首部/连接的管理 | 1. 控制不能转发给代理的首部字段 2. 管理持久连接 |
Date | 创建报文的日期时间 | |
Pragma | 报文指令 | 作为与HTTP/1.0的向后兼容而定义 |
Trailer | 报文末端的首部一览 | 实现说明在报文主体后记录了哪些首部字段 |
Transfer-Encoding | 指定报文主体的传输编码方式 | HTTP/1.1的传输编码方式仅对分块传输编码有效 |
Upgrade | 升级为其他协议 | 使用时还需额外指定Connection:Upgrade |
Via | 代理服务器的相关信息 | Via的首部是为了追踪传输路径,配合TRACE方法使用 |
Warning | 错误通知 | 110 111 112 113 199 214 299 |
请求首部字段
首部字段名 | 说明 | 备注 |
---|---|---|
Accept | 用户代理可处理的媒体类型 | 文本文件 text/html 图片文件 image/jpeg 视频文件 video/mpeg 应用程序使用的二进制文件 eg: application/json |
Accept-Charset | 优先的字符集 | |
Accept-Encoding | 优先的内容编码 | |
Accept-Language | 优先的语言(自然语言) | |
Authorization | Web认证信息 | |
Expect | 期待服务器的特定行为 | |
From | 用户的电子邮箱地址 | |
Host | 请求资源所在服务器 | |
If-Match | 比较实体标记(ETag) | |
If-Modified-Since | 比较资源的更新时间 | |
If-None-Match | 比较实体标记(与If-Match相反) | |
If-Range | 资源未更新时发送实体Byte的范围请求 | |
If-Unmodified-Since | 比较资源的更新时间(与If-Modified-Since相反) | |
Max-Forwards | 最大传输逐跳数 | |
Proxy-Authorization | 代理服务器要求客户端的认证信息 | |
Range | 实体的字节范围请求 | |
Referer | 对请求中URI的原始获取方 | |
TE | 传输编码的优先级 | |
User-Agent | HTTP客户端程序的信息 | 创建请求的浏览器 用户代理名称等信息 |
响应首部字段
首部字段名 | 说明 |
---|---|
Accept-Ranges | 是否接受字节范围请求 |
Age | 推算资源创建经过时间 |
ETage | 资源的匹配信息 |
Location | 令客户端重定向至指定URI |
Proxy-Authenticate | 代理服务器对客户端的认证信息 |
Retry-After | 对再次发起请求的时机要求 |
Server | HTTP服务器的安装信息 |
Vary | 代理服务器缓存的管理信息 |
WWW-Authenticate | 服务器对客户端的认证信息 |
实体首部字段
首部字段名 | 说明 | 备注 |
---|---|---|
Allow | 资源可支持的HTTP方法 | 不支持,返回405 Method Not Allowed |
Content-Encoding | 实体主体使用的编码方式 | 内容编码在不丢失实体信息的前提下所进行的压缩 eg: gzip compress deflate identity 四种主要内容编码 |
Content-Language | 实体主体的自然语言 | |
Content-Length | 实体主体的大小(字节) | |
Content-Location | 替代对应资源的URI | |
Content-MD5 | 实体主体的报文摘要 | |
Content-Range | 实体主体的位置范围 | |
Content-Type | 实体主体的媒体类型 | 实体主体内对象的媒体类型, 和首部字段Accept一样, 字段值用type/subtype形式赋值. eg: application/json |
Expires | 实体主体过期的日期时间 | |
Last-Modified | 资源的最后修改日期时间 |
为Cookie服务的首部字段
为Cookie服务的首部字段
首部字段名 | 说明 | 首部类型 |
---|---|---|
Set-Cookie | 开始状态管理所使用的Cookie信息 | 响应首部字段 |
Cookie | 服务器接收到的Cookie信息 | 请求首部字段 |
Set-Cookie字段的属性
属性 | 说明 |
---|---|
NAME=VALUE | 赋予Cookie的名称和其值 |
expires=DATE | Cookie的有效期 |
path=PATH | 将服务器上的文件目录作为Cookie的适用对象 |
domain=域名 | 作为Cookie适用对象的域名 |
Secure | 仅在HTTPS安全通信时才会发送Cookie |
HttpOnly | 加以限制,使Cookie不能被JS脚本访问 |
其它首部字段
X-Frame-Options
HTTP响应首部,用于控制网站内容在其他Web网站的Frame标签内的显示问题.主要目的是为了防止点击劫持(clickjacking)攻击.指定字段值:
- DENY: 拒绝
- SAMEORIGIN: 仅同源域名下的页面匹配时许可
X-XSS-Protection
HTTP响应首部, 针对跨站脚本攻击(XSS)的一种对策,用于控制浏览器XSS防护机制的开关
- 0: 将XSS过滤设置成无效状态
- 1: 将XSS过滤设置成有效状态
DNT
HTTP请求首部, DNT - Do Not Track , 拒绝个人信息被收集,是表示拒绝被精准广告追踪的一种方法.
- 0: 同意被追踪
- 1: 拒绝被追踪
P3P
HTTP响应首部, 通过利用P3P(The Platform for Privacy Preferences,在线隐私偏好平台)技术,让Web网站上的个人隐私变成一种仅供程序可理解的形式,以达到保护用户隐私的目的.
第七章 确保Web安全的HTTPS
7.1 HTTP的缺点
7.1.1 通信使用明文可能会被窃听
- TCP/IP 是可能被窃听的网络
互联网上流动的数据可能被恶意窥视, 被抓包(Packet Capture)或嗅探器(Sniffer)工具收集到数据包并解析,eg: Wireshark, 可以获取HTTP协议的请求和响应的内容,并对其进行解析 - 加密处理防止被窃听
- 通信的加密
HTTP协议中没有加密机制,可以通过和SSL或TLS的组合使用,加密HTTP的通信内容. - HTTPS === HTTP + SSL === HTTP Secure / HTTP over SSL - 内容的加密
对报文主体进行机密处理,前提是要求客户端和服务端同时具备加密和解密机制.
- 通信的加密
7.1.2 不验证通信方的身份,因此有可能遭遇伪装
- 任何人都可发起请求
- 查明对手的证书
SSL不仅提供加密处理,而且使用了证书以确定通信方的身份.
7.1.3 无法证明报文的完整性,所以有可能已遭篡改
- 接收到的内容可能有误
中间人攻击(Man-in-the-Middle attack,MITM): 请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击. - 如何防止篡改
常用的是 MD5和SHA-1等散列值校验的方法,以及用来确认文件的数字签名方法.
提供下载服务的网站,比如Apache相关的软件下载,会提供以PGP(Pretty Good Privacy,完美隐私)创建的签名及MD5算法生成的散列值.
7.2 HTTP+加密+认证+完整性保护 = HTTPS
HTTPS --- HTTP通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)协议代替而已.
SSL采用公开秘钥加密(Public-key cryptography)的加密处理方式.
加密和解密同用一个秘钥的方式称为共享秘钥加密(Common key crypto system),也叫 对称秘钥加密.
使用两把秘钥的公开秘钥加密
公开秘钥加密加密使用一对非对称的秘钥.一把叫私钥(private key),一把叫公钥(public key).
使用公开秘钥加密方式,发送密文的一方使用对方的公开秘钥进行加密处理,对方收到被加密的信息后,再使用自己的私有秘钥进行解密.
- HTTPS采用混合加密机制
公开秘钥加密处理起来比共享秘钥加密方式更为复杂,因此若在通信时使用公开秘钥加密方式,效率就很低.- 使用公开秘钥加密方式安全地交换在稍后的共享秘钥加密中要使用的秘钥
- 确保交换的秘钥是安全的前提下,使用共享秘钥加密方式进行通信
- 证明公开秘钥正确性的证书
证明公开秘钥是货真价实的公开秘钥 >>> 使用由数字证书认证机构(CA,Certificate Authority)和其相关机构颁发的公开秘钥证书. - 可证明组织真实性的EV SSL证书
- 用以确认客户端的客户端证书
网上银行 >>> 客户端证书 >>> 确认用户是否从特定的终端访问网银
HTTPS的安全通信机制
- Handshake: ClientHello >>>
- Handshake: ServerHello <<<
- Handshake: Certificate <<<
- Handshake: ServerHelloDone <<<
- Handshake: ClientKeyExchange >>>
- ChangeCipherSpec >>>
- Handshake: Finished >>>
- ChangeCipherSpec <<<
- Handshake: Finished <<<
- Application(HTTP) >>>
- Application Data(HTTP) <<<
- Alert: warning, close notify.
- Client >>> <<< Server
HTTPS使用SSL(Secure Socket Layer)和TLS(Transport Layer Security),SSL-网景,TLS-IETF,SSL3.0 ≈ TLS1.0,亦是当前主流版本.
HTTPS中存在一些问题:
- 处理速度会变慢
a. 通信慢
b. 由于大量消耗CPU及内存等资源,导致处理速度变慢 - SSL必须进行加密处理
解决 ---> 使用SSL加速器 -- SSL通信专用硬件,相对软件来讲,能够提高数倍SSL的计算速度.仅在SSL处理时发挥SSL加速器的功效,以分担负载.
第八章 确认访问用户身份的认证
HTTP/1.1使用的认证方式如下所示:
- BASIC认证(基本认证)
- DIGEST认证(摘要认证)
- SSL客户端认证
- FormBase认证(基于表单认证)
8.1 BASIC认证
HTTP/1.0定义的认证方式,是Web服务器与通信客户端之间进行的认证方式,因未做加密处理且一般浏览器无法实现认证注销操作,不够灵活,并不常用.
8.2 DIGEST认证
HTTP/1.1开始的DIGEST认证,DIGEST认证同样使用质询/响应的方式(challenge/response),但不会像BASIC认证那样直接发送明文密码.
DIGEST认证不存在防止用户伪装的保护机制,且使用上不便捷灵活,适用范围受限.
8.3 SSL客户端 认证
8.4 基于表单认证
- 认证多半为基于表单认证
- Session管理与Cookie应用
一般会使用Cookie来管理Session.- 客户端把用户ID和密码等登录信息放入报文的实体部分,通常是以POST方法把请求发送给服务器.而这时,会使用HTTPS通信来进行HTML表单画面的显示和用户输入数据的发送
- 服务器会发放用以识别用户的Session ID. 通过验证从客户端发送过来的登录信息进行身份认证,然后把用户的认证状态与Session ID绑定后记录在服务器端.
向客户端返回响应 时,会在首部字段Set-Cookie内写入Session ID.
可以把Session ID想象成一种用以区分不同用户的等位号.为防止Session ID被盗用: Session ID应使用难以推测的字符串,且服务器端也需要进行有效期的管理,保证其安全性.
另外,为减轻跨站脚本攻击(XSS)造成的损失,建议事先在Cookie内加上httponly属性. - 客户端接收到从服务器端发来的Session ID后,会将其作为Cookie保存在本地.下次向服务器发送请求时,浏览器会自动发送Cookie,所以Session ID也随之发送到服务器.服务器端可通过验证接收到的Session ID识别用户和其认证状态.
安全的保存方法: 一种方法 密码加盐-增加额外信息,再使用hash函数计算散列值后保存
第九章 基于HTTP的功能追加协议
HTTP标准带来的快速推送瓶颈:
- 一条连接上只可发送一个请求
- 请求只能从客户端开始.客户端不可以接收除响应以外的指令
- 请求/响应首部未经压缩就发送.首部信息越多延迟越大.
- 发送冗长的首部.每次互相发送相同的首部造成的浪费较多.
- 可任意选择数据压缩格式.非强制压缩发送
Ajax(Asynchronous JavaScript and XML,异步JavaScript与XML技术)是一种有效利用JavaScript和DOM(Document Object Model,文档对象模型)的操作,已达到局部Web页面替换加载的异步通信手段.
9.1 SPDY的设计与功能
SPDY是在TCP/IP的应用层与传输层之间通过新加会话层的形式运作.同时,考虑到安全性问题,SPDY规定通信中使用SSL.
SPDY以会话层的形式加入,控制对数据的流动,但还是采用HTTP建立通信连接.因此,可照常使用HTTP的GET和POST等方法/Cookie以及HTTP报文等.
使用SPDY后,HTTP协议额外获得以下功能:
- 多路复用流
- 赋予请求优先级
- 压缩HTTP首部
- 推送功能
- 服务器提示功能
9.2 使用浏览器进行全双工通信的WebSocket
WebSocket,即Web浏览器与Web服务器之间全双工通信标准.
一旦Web服务器与客户端之间建立起WebSocket协议的通信连接,之后所有的通信都依靠这个专用协议进行.通信过程中可互相发送JSON/XML/HTML或图片等任意格式的数据.
WebSocket的主要特点:
- 推送功能
- 减少通信量
握手 · 请求
为了实现WebSocket通信,需要使用HTTP的Upgrade首部字段,告知服务器通信协议发生改变,以达到握手的目的.
Sec-WebSocket-Key字段内记录着握手过程中必不可少的的键值.Sec-WebSocket-Protocol字段内记录使用的子协议
子协议按WebSocket协议标准在连接分开使用时,定义那些连接的名称
握手 · 响应
对于之前的请求,返回状态码101 Switching Protocols 响应
Sec-WebSocket-Accept的字段值是由握手请求中的Sec-WebSocket-Key字段值生成的.
成功握手确立WebSocket连接之后,通信时不再使用HTTP的数据帧,而采用WebSocket独立的数据帧.
第十章 构建Web内容的技术
10.1 HTML
HTML(HyperText Markup Language,超文本标记语言)是为了发送Web上的超文本(HyperText)而开发的标记语言.
HTML标签(Tag) -- 解析 -- 渲染
W3C(World Wide Web Consortium) - 万维网联盟,指定标准
CSS(Cascading Style Sheets, 层叠样式表)
10.2 动态HTML
Dynamic HTML JS 操作DOM 动态更新/渲染
10.3 Web应用
与Web服务器及程序协作的CGI(Common Gateway Interface,通用网关接口), CGI是指Web服务器在接收到客户端发送过来的的请求后转发给程序的一组机制.
使用CGI的程序叫做CGI程序,通常是用Perl/PHP/Ruby/C等编写.
因Java而普及的Servlet
Servlet是一种能在服务器上创建动态内容的程序.
CGI技术存在每次接到请求,程序都要跟着启动一次的问题.因此一旦访问量过大,Web服务器要承担相当大的负担.而Servlet运行在与Web服务器相同的进程中,因此收到的负载较小.Servlet的运行环境叫做Web容器或Servlet容器.
10.4 数据发布的格式及语言
XML(eXtensible Markup Language,可扩展标记语言)是一种可按应用目标进行扩展的通用标记语言.
XML和HTML都是从标准应用标记语言SGML(Standard Generalized Markup Language)简化而成.
XML和HTML一样,使用标签构成树形结构,并且可自定义扩展标签.
RSS(简易信息聚合,也叫聚合内容)和Atom都是发布新闻或博客日志等更新信息文档的格式的总称.两者都用到了XML.
JSON(JavaScript Object Notation)是一种以JavaScript的对象表示法为基础的轻量级数据标记语言.能够处理的数据类型有false/null/true/对象/数组/数字/字符串,这7种类型.
第十一章 Web的攻击技术
11.1 针对Web的攻击技术
来自互联网的攻击大多是冲着Web站点来的,它们大多把Web应用作为攻击目标.
11.1.1 HTTP不具备必要的安全功能
11.1.2 在客户端即可篡改请求
11.1.3 针对Web应用的攻击模式
攻击模式有以下两种:
- 主动攻击
- 被动攻击
以服务器为目标的主动攻击
主动攻击(active attack)是指攻击者通过直接访问Web应用,把攻击代码传入的攻击模式.
主动攻击模式里具有代表性的攻击是 SQL注入攻击__和__OS命令注入攻击
以服务器为目标的被动攻击
被动攻击(passive attack)是指利用圈套策略执行攻击代码的攻击模式.
被动攻击主要攻击用户的资源和权限,具体步骤如下:
- 攻击者诱使用户触发已设置好的陷阱,而陷阱会启动发送已嵌入攻击代码的HTTP请求
- 当用户不知不觉中招之后,用户的浏览器或邮件客户端就会触发这个陷阱
- 中招后的用户浏览器会把含有攻击代码的HTTP请求发送给作为攻击目标的Web应用,运行攻击代码
- 执行完攻击代码,存在安全漏洞的Web应用会成为攻击者的跳板,可能导致用户所持的Cookie等个人信息被窃取,登录状态中的用户权限遭恶意滥用等后果
被动攻击模式中具有代表性的攻击是__跨站脚本攻击__和__跨站点请求伪造__
利用用户的身份攻击企业内部网络 == 邮件钓鱼 等陷阱
11.2 因输入值转义不完全引发的漏洞
实施Web应用的安全策略可大致分为以下两部分:
- 客户端的验证
- Web应用端(服务器端)的验证
- 输入值验证
- 输出值验证
11.2.1 跨站脚本攻击
跨站脚本攻击(Cross-Site Scripting,XSS)是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击.
跨站脚本攻击有可能造成以下影响:
- 利用虚假输入表单骗取用户个人信息
- 利用脚本窃取用户的Cookie值,被害者在不知情的情况下,帮助攻击者发送恶意请求
- 显示伪造的文章或图片
11.2.2 SQL注入攻击
SQL注入(SQL Injection)是指针对Web应用使用的数据库,通过运行非法的SQL而产生的攻击.
SQL注入有可能会造成以下影响:
- 非法查看或篡改数据库内的数据
- 规避认证
- 执行和数据库服务器业务关联的程序等
11.2.3 OS命令注入攻击
OS命令注入攻击(OS Command Injection)是指通过Web应用,执行非法的操作系统命令达到攻击的目的.
11.2.4 HTTP首部注入攻击
HTTP首部注入攻击(HTTP Header Injection)是指攻击者通过在响应首部字段内插入换行,添加任何响应首部或主体的一种攻击.属于被动攻击模式.
HTTP首部注入攻击有可能造成以下影响:
- 设置任何Cookie信息
- 重定向至任何URL
- 显示任意的主体(HTTP响应截断攻击, HTTP Response Splitting Attack)
11.2.5 目录遍历攻击
目录遍历(Directory Traversal)攻击是指对本无意公开的文件目录,通过非法截取其目录路径后,达到访问目的的一种攻击. -- nginx