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