济南IT培训 > 达内新闻
HTTP协议在安全性方面存在什么问题?
- 发布:互联网
- 来源:互联网
- 时间:2017-06-22 10:25
济南达内培训开设Java课程、UI课程、Web前端课程、Linux等多种培训课程,HTTP协议在安全性方面存在什么问题?下面小编就为大家来讲解一下.
HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,存在的问题如下: 济南达内培训开设Java课程、UI课程、Web前端课程、Linux等多种培训课程,HTTP协议在安全性方面存在什么问题?下面小编就为大家来讲解一下.
HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,存在的问题如下:
通信使用明文(不加密),内容可能会被窃听; 不验证通信方的身份,有可能遭遇伪装;无法证明报文的完整性,所以有可能已遭篡改; 其实这些问题不仅在HTTP上出现,其他未加密的协议中也会存在这类问题.想知道更详细的问题记得详细请咨询济南达内.
(1) 通信使用明文可能会被窃听
按TCP/IP协议族的工作机制,互联网上的任何角落都存在通信内容被窃听的风险.而HTTP协议本身不具备加密的功能,所传输的都是明文.即使已经经过过加密处理的通信,也会被窥视到通信内容,这点和未加密的通信是相同的.只是说如果通信经过加密,就有可能让人无法破解报文信息的含义,但加密处理后的报文信息本身还是会被看到的.
(2) 不验证通信方的身份可能遭遇伪装
在HTTP协议通信时,由于不存在确认通信方的处理步骤,因此任何人都可以发起请求.另外,服务器只要接收到请求,不管对方是谁都会返回一个响应.因此不确认通信方,存在以下隐患:
无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器.有可能是已伪装的 Web 服务器;无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端.有可能是已伪装的客户端;无法确定正在通信的对方是否具备访问权限.因为某些Web服务器上保存着重要的信息,只想发给特定用户通信的权限;无法判定请求是来自何方、出自谁手;即使是无意义的请求也会照单全收,无法阻止海量请求下的DoS攻击;
(3) 无法证明报文完整性,可能已遭篡改
所谓完整性是指信息的准确度.若无法证明其完整性,通常也就意味着无法判断信息是否准确.HTTP协议无法证明通信的报文完整性,在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉.
比如,从某个Web网站下载内容,是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的.文件内容在传输途中可能已经被篡改为其他的内容.即使内容真的已改变,作为接收方的客户端也是觉察不到的.像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack,MITM).
(4) 安全的HTTP版本应该具备的几个特征
由于上述的几个问题,需要一种能够提供如下功能的HTTP安全技术:
(1) 服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话);
(2) 客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话);
(3) 完整性(客户端和服务器的数据不会被修改);
(4) 加密(客户端和服务器的对话是私密的,无需担心被窃听);
(5) 效率(一个运行的足够快的算法,以便低端的客户端和服务器使用);
(6) 普适性(基本上所有的客户端和服务器都支持这些协议);
更多济南达内相关资讯请关注下方二维码

最新开班时间
- 北京
- 上海
- 广州
- 深圳
- 南京
- 成都
- 武汉
- 西安
- 青岛
- 天津
- 杭州
- 重庆
- 哈尔滨
- 济南
- 沈阳
- 合肥
- 郑州
- 长春
- 苏州
- 长沙
- 昆明
- 太原
- 无锡
- 石家庄
- 南宁
- 佛山
- 珠海
- 宁波
- 保定
- 呼和浩特
- 洛阳
- 烟台
- 运城
- 潍坊
HTTP协议在安全性方面存在什么问题?
- 发布:互联网
- 来源:互联网
- 时间:2017-06-22 10:25
济南达内培训开设Java课程、UI课程、Web前端课程、Linux等多种培训课程,HTTP协议在安全性方面存在什么问题?下面小编就为大家来讲解一下.
HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,存在的问题如下: 济南达内培训开设Java课程、UI课程、Web前端课程、Linux等多种培训课程,HTTP协议在安全性方面存在什么问题?下面小编就为大家来讲解一下.
HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,存在的问题如下:
通信使用明文(不加密),内容可能会被窃听; 不验证通信方的身份,有可能遭遇伪装;无法证明报文的完整性,所以有可能已遭篡改; 其实这些问题不仅在HTTP上出现,其他未加密的协议中也会存在这类问题.想知道更详细的问题记得详细请咨询济南达内.
(1) 通信使用明文可能会被窃听
按TCP/IP协议族的工作机制,互联网上的任何角落都存在通信内容被窃听的风险.而HTTP协议本身不具备加密的功能,所传输的都是明文.即使已经经过过加密处理的通信,也会被窥视到通信内容,这点和未加密的通信是相同的.只是说如果通信经过加密,就有可能让人无法破解报文信息的含义,但加密处理后的报文信息本身还是会被看到的.
(2) 不验证通信方的身份可能遭遇伪装
在HTTP协议通信时,由于不存在确认通信方的处理步骤,因此任何人都可以发起请求.另外,服务器只要接收到请求,不管对方是谁都会返回一个响应.因此不确认通信方,存在以下隐患:
无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器.有可能是已伪装的 Web 服务器;无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端.有可能是已伪装的客户端;无法确定正在通信的对方是否具备访问权限.因为某些Web服务器上保存着重要的信息,只想发给特定用户通信的权限;无法判定请求是来自何方、出自谁手;即使是无意义的请求也会照单全收,无法阻止海量请求下的DoS攻击;
(3) 无法证明报文完整性,可能已遭篡改
所谓完整性是指信息的准确度.若无法证明其完整性,通常也就意味着无法判断信息是否准确.HTTP协议无法证明通信的报文完整性,在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉.
比如,从某个Web网站下载内容,是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的.文件内容在传输途中可能已经被篡改为其他的内容.即使内容真的已改变,作为接收方的客户端也是觉察不到的.像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack,MITM).
(4) 安全的HTTP版本应该具备的几个特征
由于上述的几个问题,需要一种能够提供如下功能的HTTP安全技术:
(1) 服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话);
(2) 客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话);
(3) 完整性(客户端和服务器的数据不会被修改);
(4) 加密(客户端和服务器的对话是私密的,无需担心被窃听);
(5) 效率(一个运行的足够快的算法,以便低端的客户端和服务器使用);
(6) 普适性(基本上所有的客户端和服务器都支持这些协议);
更多济南达内相关资讯请关注下方二维码

最新开班时间
- 北京
- 上海
- 广州
- 深圳
- 南京
- 成都
- 武汉
- 西安
- 青岛
- 天津
- 杭州
- 重庆
- 厦门
- 哈尔滨
- 济南
- 福州
- 沈阳
- 合肥
- 郑州
- 长春
- 苏州
- 大连
- 长沙
- 昆明
- 温州
- 太原
- 南昌
- 无锡
- 石家庄
- 南宁
- 中山
- 兰州
- 佛山
- 珠海
- 宁波
- 贵阳
- 保定
- 呼和浩特
- 东莞
- 洛阳
- 潍坊
- 烟台
- 运城