网络安全HTTP协议_http网络稳定性

HTTP协议

HTTP介绍

• HTTP（超文本传输协议）
• HTTP设计用来将超文本标记语言 (HTML) 文档从Web 服务器传送到 Web 浏览器
• HTTP是一个请求和回应协议：客户机发送请求，服务器对请求给出回应
• HTTP 使用可靠的TCP 连接，默认TCP端口是80。
• 承载于TLS或SSL协议层之上，默认端口为443. （https）

HTTP非持久连接与持久连接

• 浏览器首先初始化与运行http服务器主机的TCP连接，使用URL指定端口
• 浏览器通过与TCP连接相关联的本地套接字发出一个HTTP请求消息
• 服务器接收到请求之后，解析请求并处理请求，然后通过一个套接字发出相应消息
• 服务器通知TCP需要关闭连接（在浏览器收到相应消息之后才会真正终止连接）
• 浏览器收到响应消息，TCP连接终止
• 持久连接没有关闭连接这一步，服务器响应后会继续让TCP连接保持打开状态

HTTP报文

• HTTP的一个会话，由Request和response组成
• HTTP 请求（Requests）由请求行、消息报头、请求正文三个部分组成
• 请求行：方法，URL，协议/版本（Method-URI-Protocol/Version）
• 消息报头/请求头(Request headers) • 请求正文（Entity body）
• HTTP 响应（Responses) 也包含三个部分:状态行、消息报头、响应正文
• 状态行：协议状态代码描叙（Protocol-Status code-Description）
• 消息报头（Response headers）
• 响应正文（Entity body）

设置代理

• 根据协议的学习我们了解HTTP协议分为两个部分：请求和回应。
• 而平时浏览网页，请求报文是经过浏览器包装好的，不通过工具直接访问只能够控制很少的部分。
• 要想真正的人为控制与服务器交互，只能通过代理抓包的方法。
• 代理：作为客户端和服务器的中间者，在利用http协议交互时，所有请求和回应都不会直接发送给目标而是由代理接受和转发。

HTTP请求报文

• HTTP 请求（Requests）由请求行、消息报头、请求正文三个部分组成
• 请求行：方法，URL，协议/版本（Method-URI-Protocol/Version）
• 消息报头(Request headers) • 请求正文（Entity body）

HTTP请求方式

HTTP请求首部

• Host:主要用于指定被请求资源的Internet主机和端口号
• User-Agent:向服务端传递客户端操作系统、浏览器、和其他属性
• Referer:包含一个URL，代表当前URL的上一个URL
• Cookie:是一段文本，通常来表示请求者的身份
• Range:Range可以请求实体部分内容，多线程下载一定会用到此请求头
• x-forward-for:即XFF头，代表请求端的IP，也可以是多个，中间用逗号隔开
• Accept:用于指定客户端接收哪些MIME类型的信息
• Accept-Charset:用于指定客户端接收的字符集
• 信息：就是实体内容的属性，包括实体信息类型，长度，压缩方法，最后一次修改时间等
• Content-Type:用于向接收方指示实体的介质类型
• Content-Encoding:被用作媒体类型的修饰符，表示了已经被用到实体正文的附加内容编码，想要获得content-type报头域中所引用的媒体类型，必须采用相应的解码机制
• Content-Length:用于指明实体正文的长度，以字节方式存储的十进制数字来表示
• Last-Modified:用于指示资源的最好修改时间和日期

HTTP响应

• HTTP 响应（Responses) 也包含三个部分:状态行、消息报头、响应正文
• 状态行：协议状态代码描叙（Protocol-Status code-Description）
• 消息报头（Response headers）
• 响应正文（Entity body）
• 1、状态行：HTTP-Version Status-Code Reason-Phrase
• HTTP-Version表示服务器HTTP协议的版本；
• Status-Code表示服务器发回的响应状态代码
• Reason-Phrase表示状态代码的文本描述。
• 状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
• 1xx：指示信息–表示请求已接收，继续处理，范围是100~101
• 2xx：成功–表示请求已被成功接收、理解、接受，范围是200~206
• 3xx：重定向–要完成请求必须进行更进一步的操作，范围是300~305
• 4xx：客户端错误–请求有语法错误或请求无法实现，范围是400~415
• 5xx：服务器端错误–服务器未能实现合法的请求，范围是500~505
• 2、响应报头
• 3、响应正文就是服务器返回的资源的内容

HTTP安全问题

• HTTP协议的使用极为广泛，但是在设计时并没有考虑到信息的加密和验证问题，因此HTTP面临着数据明文传送和缺乏对消息完整性的验证这两个问题。
• HTTP协议在数据传输过程中，只要攻击者能够控制到受害者的网络，便可以轻易的嗅探、修改HTTP传输的内容。
• HTTP协议在传输客户端请求和服务端响应时，仅仅在报文头部包含了传输数据长度，没有任何校验数据完整性的机制。

HTTP安全协议

为了加强web服务数据传输是的安全性，提出了HTTPS协议，通过在TCP层与HTTP层增加一个SSL(安全套接字层)来增强数据传输时的安全性。使用HTTPS时，数据的传输的加密解密均有SSL进行，与上层HTTP无关。HTTPS提高了数据传输时的机密性，有着严格的完整性校验，大大提升的信息传输的安全性。

HTTP与HTTPS的区别

HTTPS是在HTTP协议基础上，HTTP请求与响应都是以相同的方式进行工作，主要区别如下：
• HTTP是超文本传输协议，信息明文传输。HTTPS是有安全性的SSL加密传输协议
• HTTP与HTTPS采用是完全不同的连接方式，HTTP是80端口，HTTPS是443端口
• HTTPS协议需要到CA申请证书，而HTTP不需要
• HTTP连接相对简单，是无状态的，而HTTPS协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议

Cookie与session

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份
Session通过在服务器端记录信息确定用户身份。
cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。
Session 与 Cookie 的作用都是为了保持访问用户与后端服务器的交互状态。

Cookie——长期门禁

Cookie：指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）
Cookie的动机：客户端在浏览多个页面时，提供事物（transaction）的功能，为服务器提供状态管理
每个cookie都有一定的URL范围，客户请求这个范围的URL，都要提供这个cookieCookie是一段文本信息，在客户端访问服务器之后，服务端会根据不同的情况，在响应HTTP头中置入Set-Cookie通知客户端设置Cookie
Cookie最初的目的是为了让服务端能够追踪到用户，一旦收到cookie，浏览器会以“name=value” 的形式保存在本地，每次进行HTTP回话时，Cookie都会以一个字段明文放置在HTTP头中，以此传递用户状态

Cookie——长期门禁

Cookie由服务器端向客户端写入，包含在http响应头中的setcookie字段，格式如下
Set-Cookie:NAME=VALUE[;domain=DOMAIN][;path=PATH][;max- age=AGE][;expire=EXPIRE][;secue][;HttpOnly]
首先是一个“名称=值”对，这个属性在cookie中必须存在
domain部分指定Cookie被发送到哪台主机上。
path部分控制哪些访问能够触发该Cookie的发送，如果没有指定path。cookie对全站生效
expire部分指明了过期时间，如果没有指定，cookie会持续到这次回话结束，现在已经被max-age
取代
secure如果指定了secure，那么该cookie只能通过安全通道传输（SSL通道）
httponly：支持httponly cookie的浏览器中，JavaScript无法读取和修改cookie，这样可以让cookie
免受脚本攻击。

Cookie的安全

• Cookie一般由服务器向客户端写入，可以包含个性化信息，有时候也会被web站点设计包含站点的认证信息。
• Cookie分为永久性cookie和会话cookie。永久性cookie保存在客户端的硬盘中，会话cookie在会话结束后，失效。
• 脚本语言，可以盗取cookie，当cookie中包含用户的敏感信息时，因此攻击者可以利用XSS技术，盗取cookie信息，这样会造成用户信息泄露，甚至重放攻击

Session——临时门禁

• Session机制，相对于cookie机制，就是将会话信息存储于服务器端，而非客户端，并且存储于服务器端内存中，会话结束而失效
• Session机制的实现，是在服务器端保存状态。相比客户端cookie存储，安全性更高
• 当用户第一次访问web站点时，由服务器记录会话，并生成sessionID用来标识一个客户端的会话。同时，通过cookie向客户端传递这个sessionID
• 客户端后续的会话，会由浏览器自动携带这个sessionID，服务器根据保存的sessionID和收到的sessionID来判断会话信息的

Session的安全

• 如果session和cookie一样安全的话，二者就没有并要同时存在了，只要cookie就好了，让客户端来分提服务器的负担，并且对于用户来说又是透明的。何乐而不为呢。
• session的sessionID是放在cookie里，要想功破session的话，第一要功破cookie。功破cookie后，你要得到 sessionID,sessionID是要有人登录，或者启动session_start才会有，你不知道什么时候会有人登录。第二，sessionID是加密的，第二次session_start的时候，前一次的sessionID就没有用了，session过期时sessionid也会失效，想在短时间内功破加了密的sessionID很难。session是针对某一次通信而言，会话结束session也就随着消失了，而真正的cookie存在于客户端硬盘上的一个文本文件，谁安全很显然了。
• 如果session这么容易被功破，这么不安全的话，我想现有的绝大部分网站都不安全了。