0x01 什么是安全隐患

安全隐患就是"能够用于作恶的BUG"
应用程序出现了BUG,就会出现各种各样的问题,骇客最关心的BUG就是能够被恶意利用的BUG,这就是安全隐患,也是骇客的攻击点

常见的恶意利用的案例:

>> 未经过他人许可查看用户个人隐私信息
>> 篡改网页内容,xss,crsf
>> 使得网页浏览者的计算机感染病毒
>> 越权伪装其他用户来浏览隐私信息、转账、购物、发表不当言论等
>> 使得目标网站瘫痪,无法被其他用户访问
>> 在确认自己的信息是能够查看其它用户的信息(越权)
>> 在游戏中使得自己无敌,开局一把刀,装备随便爆

0x02 HTTP协议

Request请求
1、 在浏览器进行搜索时,浏览器会向服务器发送 HTTP 请求,而收到浏览器请求的服务器则会向浏览器发回 HTTP 响应
2、 使用 Fiddler 来详细看看 HTTP 的通信内容,如下:
3、 请求消息的第一行是请求行,相当于浏览器给服务器下达的指令。请求行由请求方法、URL(URI)和协议版本组成
4、 HTTP 常见的请求方法除了 POST 之外,还有 GET、HEAD 等等。GET 和 POST 与 html 中的 form 元素的 method 属性指定的值相同
5、 请求消息第二行及其以后的内容成为请求头信息(header),请求头的格式是名称与值用冒号相隔,请求头信息里面有很多内容,但只有 HOST 是必须的
6、 HOST 表示接收信息的主机名(FQDN)和端口号

例如:
POST http://ocsp.digicert.com/ HTTP/1.1        //此行为请求行
Host: ocsp.digicert.com                        //此行及其以下为请求头
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/ocsp-request
Content-Length: 83
Connection: keep-alive

#######################################################################
POST http://oscp.digicert.com/ HTTP/1.1    //请求方法 : 请求URL :版本协议
#############################################################

Response请求
1、 响应消息,是指从web服务器返回的内容,这些内容就被成为响应消息(Response Message)
2、 响应消息包含状态行、响应头消息和响应正文
3、 响应链的构造:状态行、响应头
4、 状态行:状态行的内容是请求消息经过服务器处理以后的状态
5、 状态码:状态码是状态行里面的数字。状态码的百位数有特殊的含义,代表了响应的几种状态:200(成功)、301和302(重定向)、404(找不到资源)、500(服务器内部发生错误)
6、 响应消息第2行及其以后得内容就是响应头消息,以下是比较典型的响应头消息:

例如:
HTTP/1.1 200 OK            //状态行
Accept-Ranges: bytes       //该行及其以下都是响应头
Age: 6380
Cache-Control: max-age=119846
Content-Type: application/ocsp-response
Date: Tue, 14 Jul 2020 09:48:48 GMT
Etag: "5f0c97bb-1d7"
Expires: Wed, 15 Jul 2020 19:06:14 GMT
Last-Modified: Mon, 13 Jul 2020 17:19:55 GMT
Server: ECS (hhp/9AD2)
X-Cache: HIT
Content-Length: 471
Connection: close

HTTP协议里面的常见攻击面
1、 目标网站使用 GET 方法时,可以获取到目标Referer信息,比如cookie等
2、 使用 GET 方法会使得URL中的参数残留在访问日志(Access Log)中,攻击者可以在URL中写入一句话木马等。。。
3、 由于浏览器和服务器能够处理的URL长度只有6,当传递的信息量很大时,GET方法可能会导致缓冲区溢出
//服务端程序在接收客户端表单提交的数据时,需要先将数据存储到一个内存空间,然后做解析等后续工作,这个内存空间一般称之为接收缓冲区。对于post数据因为有Content-Length标记,服务端可以按标记的长度创建一个等于或稍大于提交数据的缓冲区;对于get,因为事先不知道提交的数据有多少,需要估计缓冲区长度,如果缓冲区很大而接收数据很小会造成内存浪费,而如果缓冲区小于接收数据,就可能造成缓冲区溢出

WEB开发者需要注意的是:
1 请求中包含数据更新时务必使用POST方法
2 发送敏感信息时使用POST方法
3 发送的消息量很多时使用POST方法

HTTP协议支持认证功能:
1、 根据实习方式可以分为:Basic认证、NTLM认证、Digest认证
2、 就如同HTTP协议是无状态的一样,HTTP认证也是无状态的,也正因为是无状态的认证所以也不存在注销这一个概念(Logout)
3、 同时,因为HTTP认证是无状态的,所以客户端与服务端每一次交流都是上下文无关联的,客户端每一次访问都要提供所有的必要信息

0x03 cookie与会话管理

1、 使得服务器记住ID和密码,记忆认证状态的任务一般落在服务器上面,而这种记忆应用程序状态的功能就叫做“会话管理”
为了实现会话管理,HTTP引入了cookie机制,cookie相当于服务器下达给浏览器的命令,让其记住发送给他的“名称=变量”这种格式的值

2、 在保存应用程序数据时几乎不会使用cookie,原因如下:

1、cookie能够保存的值的数量和字符串长度有限
2、cookie的值能够被用户看见或更改,所以不适用于存储敏感信息

3、 企业一般采用在cookie中保存类似于“受理编号”的会话ID,实际对应的值保存在服务器端,这种方法被称为“使用cookie的会话管理”

4、 “受理编号”不能使用简短的连续的字符,而应该使用位数足够长的随机数,否者随便修改一下“受理编号”就可以实现越权,会话ID需要满足如下要求:

1、会话ID不能被第三方推测(随机数质量要好,使用web开发工具提供的会话管理机制比较稳当)
2、会话ID不能被第三方劫持
3、会话ID不能被第三方泄露
4、认证成功后改变会话
5、采用SSL加密保护会话ID不会被监听
6、注意指定发现cookie时的属性

5、攻击面

1、劫持正规用户会话ID进行攻击,即会话固定攻击(Session Fixation Attack)
2、查看发现cookie时的属性指定是否有问题
3、能否监听目标的会话ID
4、目标站点是否有xss漏洞,获取目标会话ID
5、PHP或浏览器等平台上是否存在安全隐患
6、目标站点会话ID是否保存在URL中,可以通过Referer消息头获取
7、“cookie monster bug”,即用户使用一些旧版浏览器访问目标网站时,生成的cookie的域名与站点Domain的域名不符合,可以匹配到其他站点的域名,这意味着能对这些网站任意指定cookie

cookie的属性

Domain cookie发送对象服务器的域名(cookie不能指定不同域名)
Path cookie发送对象URL的路径
Expires cookie的有效期限,未指定则表示至浏览器关闭为止
Secure 仅仅在SSL加密的情况下发送cookie
HttpOnly 指定了此属性的cookie不能被javascript访问

设计安全性的3个重要属性为: Domain、Secure、HttpOnly

Domain属性:cookie默认只能发送到与其绑定的服务器,但有时也需要能向多个服务器发送cookie,此时就需要使用Domain属性

1、假设指定 baidu.com ,那么cookie就会被发送给 a.baidu.com 和 b.baidu.com ,而不会发送给 a.baidu.cn
2、假设 a.baidu.com 的服务器在set-cookie时指定了 Domain=baidu.cn 此cookie就会被浏览器忽略(cookie如果指定不同域名就可能发生固定会话攻击)
3、指定Domain属性时,cookie只会被发送到生成它的服务器(未指定Domain属性的cookie最安全)

//假设baidu.com 上有 a.baidu.com 和 b.baidu.com 两个域名,如果 a.baidu.com 网站发送的cookie指定Domain=baidu.com ,那么这个cookie就会泄露到 b.baidu.com
//在 Internet Explorer 8 (IE8)中使用地域型域名存在 Cookie Monster Bug

Secure属性:设置Secure属性的cookie仅仅在SSL传输的情况下能够被发送给服务器,未设置Secure属性的cookie就会无关是否为SSL都会发送

HttpOnly属性:设置该属性后,javascript就不能访问该cookie了
#其实设置了HttpOnly也不能彻底抵御xss,但能够增加攻击的难度,设置HttpOnly属性后通常不会带来坏处
#在使用php的情况下,给cookie增加HttpOnly属性,只需要在php.ini中添加如下设置即可:
session.cookie_httponly = on

转载请注明链接(笔芯)
链接地址:https://blog.csdn.net/weixin_45126664/article/details/107470691

原文链接:https://blog.csdn.net/weixin_45126664/article/details/107470691

最后修改日期:2020年7月23日