See_You

冲鸭！！

web安全知识整理

常见漏洞

sql注入

原理：SQL注入攻击是通过将恶意的SQL查询语句插入到应用的输入参数中，欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息

分类：

  1. 注入类型：字符型， 数字型
  2. 提交方式：GET ，POST， COOKIE
  3. 获取信息的方式：基于报错，盲注，基于回显

防御：

  1. 校验用户输入，过滤特殊字符
  2. 进行参数绑定，限制用户输入
  3. 使用SQL语句预处理，对SQL语句首先进行预编译，然后进行参数绑定，最后传入参数。

判断方式：

  1. 单引号判断法
  2. and 1=1 and 1=2 同真为真，其余为假
  3. or 1=1 or 1=2 同假为假，其余为真

注入方法：

　　https://blog.csdn.net/weixin_43915762/article/details/87909751

宽字符注入的原理？如何利用宽字符注入漏洞，payload如何构造？

原理：mysql数据库在使用宽字节（GBK）编码时，会认为两个字符是一个汉字（前一个ascii码要大于128（比如%df），才到汉字的范围），而且当我们输入单引号时，mysql会调用转义函数，将单引号变为\’，其中\的十六进制是%5c,mysql的GBK编码，会认为%df%5c是一个宽字节，也就是’運’，从而使单引号闭合（逃逸），进行注入攻击
%df' 会被PHP当中的addslashes函数转义为%df\' ，“\”既URL里的“%5C”，那么也就是说，%df'会被转成%df%5C%27倘若网站的字符集是GBK，MYSQL使用的编码也是GBK的话，就会认为%df%5C%27是一个宽字符。也就是“縗’”

绕过方法：参考文章

报错注入

XSS跨站脚本攻击

分类：反射型、存储型、DOM型

反射性xss: 攻击者构造的特殊的包含恶意代码的URL被用户访问，服务器将恶意代码从url中取出拼接在返回给浏览器的HTML中，客户端收到服务端响应后恶意代码被浏览器执行。

存储型xss：攻击者将恶意代码提交到目标服务器中，用户打开目标网站，恶意代码就被访问执行，常存在于论坛发帖、评论，用户私信中。

DOM型xss:攻击者构造的恶意的url被用户访问，用户浏览器接到响应后，前端js取出url中的恶意代码执行。

XSS防御

  • 可以在cookie中设置httponly,禁止浏览器通过js访问带有httponly的cookie
  • xss filter (检查输入，设置白名单)
  • 输出编码（针对输出到不同的位置，使用不同的编码）

 三种xss区别:存储型xss是存储于恶意代码存储于数据库中，可以进行持久性攻击，反射性xss是通过服务器解析url,返回给用户端浏览器解析执行，dom型xss不需要服务器解析参与，触发xss靠的是浏览器的DOM解析。

CSRF跨站请求伪造

原理：利用网站可以预测特定操作、且浏览器可以自动发送会话cookie凭证这一特点，创建恶意请求，诱导用户访问执行敏感操作。

危害：存在漏洞的网站，攻击者可以让受害者修改任何允许修改的数据，执行任何用户允许的操作，例如修改密码，删除信息

如何检测

1、GET类型的CSRF的检测

如果有token等验证参数，先去掉参数尝试能否正常请求。如果可以，即存在CSRF漏洞

2、 POST类型的CSRF的检测

如果有token等验证参数，先去掉参数尝试能否正常请求。如果可以，再去掉referer参数的内容，如果仍然可以，说明存在CSRF漏洞，可以利用构造外部form表单的形式，实现攻击。如果直　　接去掉referer参数请求失败，这种还可以继续验证对referer的判断是否严格，是否可以绕过。

防御

　　1.验证码

  • 验证码强制用户必须与应用进行交互，才能完成最终请求。

　　2.Referer Check

  • 检查请求是否来自合法的源。但服务器并非什么时候都能取得 Referer。

　　3.Token

  • CSRF 能够攻击成功的本质原因是重要操作的所有参数都可以被攻击者猜测得到。
    • 保持原参数不变，新增一个参数 Token，值是随机的，在实际应用中，Token 可以放在用户的 Session 中，或浏览器的 Cookies 中。
    • Token 一定要足够随机。此外，Token 的目的不是为了防止重复提交，所以为了使用方便，可以允许在一个用户的有效生命周期内，在 Token 消耗掉之前都使用同一个 Token，但如果用户已经提交了表单，则这个 Token 已经消耗掉，应该重新生成 Token。
      Token 还应注意其保密性，如果 Token 出现在 URL 中，则可能会通过 Referer 泄露，应尽量把 Token 放在表单中，把敏感操作由 GET 改为 POST，以表单或 AJAX 的形式提交，避免 Token 泄露。

SSRF服务端请求伪造

参考

原理：由攻击者构造形成，由服务端发起请求的一个安全漏洞，一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。

可能出现的地方：社交分享功能、转码功能、在线翻译、图片加载、图片下载等

检测手段 ：手工检测请求、自动化测试：参考

利用方式　　

　　1.让服务端去访问相应的网址

　　2.让服务端去访问自己所处内网的一些指纹文件来判断是否存在相应的cms

　　3.可以使用file、dict、gopher[11]、ftp协议进行请求访问相应的文件

　　4.攻击内网web应用（可以向内部任意主机的任意端口发送精心构造的数据包{payload}）

　　5.攻击内网应用程序（利用跨协议通信技术）

　　6.判断内网主机是否存活：方法是访问看是否有端口开放

　　7.DoS攻击（请求大文件，始终保持连接keep-alive always）：

修复方式：

  1. 禁止跳转
  2. 过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
  3. 禁用不需要的协议，仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题
  4. 设置URL白名单或者限制内网IP（使用gethostbyname()判断是否为内网IP）
  5. 限制请求的端口为http常用的端口，比如 80、443、8080、8090
  6. 统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

XXE漏洞

测试环境：https://github.com/c0ny1/xxe-lab

定义：XXE就是XML外部实体注入。当允许引用外部实体时，通过构造恶意内容，就可能导致任意文件读取、系统命令执行、内网端口探测、攻击内网网站等危害

参考：https://www.freebuf.com/articles/web/177979.html

  • 防御：
    1.使用开发语言提供的禁用外部实体的方法，即禁用外部实体。
    PHP:
    libxml_disable_entity_loader(true);

　　　JAVA:
　　　DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();
　　　dbf.setExpandEntityReferences(false);

　　　Python：
　　　from lxml import etree
　　　xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))

　　　2.过滤用户提交的XML数据
　　　关键词：<!DOCTYPE和<!ENTITY，或者，SYSTEM和PUBLIC。

JSONP与CORS漏洞挖掘

同源策略：

同源策略限制从一个源加载的文档或脚本与来自另一个源的资源进行交互,这是一个用于隔离潜在恶意文件的关键的安全机制.简单说就是浏览器的一种安全策略。“同源”包括三个条件:同协议、同域名、同端口。

跨域

虽然同源策略在安全方面起到了很好的防护作用,但也在一定程度上限制了一些前端功能的实现,所以就有了许多跨域的手段。

可跨域的标签

所有带src或href属性的标签以及部分其他标签可以跨域:

<script src="..."></script>
<img src="...">
<video src="..."></video>
<audio src="..."></audio>
<embed src="...">
<frame src="...">
<iframe src="..."></iframe>
<link rel="stylesheet" href="...">
<applet code="..."></applet>
<object data="..." ></object>

jsonp跨域问题

<!-- jsonp_hijack.html -->
<script>
function addScriptTag(src) {
  var script = document.createElement('script');
  script.setAttribute("type","text/javascript");
  script.src = src;
  document.body.appendChild(script);
}
​
window.onload = function () {
  addScriptTag('http://ip.jsontest.com/?callback=ip');
}
​
function ip(data) {
  alert(data.ip);
};
</script>

安全问题：当这个接口没有验证Referer头的时候,就存在JSONP劫持漏洞,即在任何域下都能窃取到传输的数据。当接口返回的是一些敏感数据时(如CSRF TOKEN,用户个人信息等),危害是很大的。

CORS配置问题

Access-Control-Allow-Origin
该字段必填。它的值要么是请求时Origin字段的具体值，要么是一个*，表示接受任意域名的请求。

Access-Control-Allow-Methods

该字段必填。它的值是逗号分隔的一个具体的字符串或者*，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

Access-Control-Expose-Headers
该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。

Access-Control-Allow-Credentials
该字段可选。它的值是一个布尔值，表示是否允许发送Cookie.默认情况下，不发生Cookie，即：false。对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json，这个值只能设为true。如果服务器不要浏览器发送Cookie，删除该字段即可。

Access-Control-Max-Age
该字段可选，用来指定本次预检请求的有效期，单位为秒。在有效期间，不用发出另一条预检请求。

漏洞原因

由于配置不当，Origin源未严格，从而造成跨域问题

测试方式：请求头中添加其他origin头，看http响应

请求包
GET /c/user HTTP/1.1
Host: test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Content-Type: application/json
origin: http://evil.com

响应包
　　HTTP/1.1 304 Not Modified
　　Date: Thu, 08 Mar 2018 02:48:00 GMT
　　Connection: close
　　ETag: "ba948d94315604d965963bffecb2582a"
　　Cache-Control: max-age=0, private, must-revalidate
　　X-Request-Id: f2b00bc9-8cc5-493c-86e9-2c4e0f438553
　　Access-Control-Allow-Origin: http://evil.com
　　Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS, DELETE
　　Access-Control-Expose-Headers: 
　　Access-Control-Max-Age: 1728000
　　Access-Control-Allow-Credentials: true
　　Vary: Origin
　　Strict-Transport-Security: max-age=631152000
　　Referrer-Policy: origin-when-cross-origin
　　X-Content-Type-Options: nosniff
　　X-Download-Options: noopen
　　X-Frame-Options: SAMEORIGIN
　　X-Permitted-Cross-Domain-Policies: none
　　X-XSS-Protection: 1; mode=block

上面的请求包，我们只要关注Origin即可。当我们把Origin设置为evil.com时，返回包的Access-Control-Allow-Origin也为evil.com,也就是evil.com可以跨域获取test.com的资源。从而产生了CORS配置不当的漏洞。

Ddos分布式拒绝服务攻击

DDOS攻击主要分为三类：流量型攻击；连接型攻击；特殊协议缺陷

详情参考

 

渗透测试

明确目标

 

  • 确定范围：测试目标的范围，ip，域名，内外网。
  • 确定规则：能渗透到什么程度，时间？能否修改上传？能否提权等。
  • 确定需求：web应用的漏洞(新上线程序)？业务逻辑漏洞（针对业务的）？人员权限管理漏洞（针对人员、权限）？等等。（立体全方位）
  • 根据需求和自己技术能力来确定能不能做，能做多少。

 

信息收集

 

方式：主动扫描，开放搜索等

 

开放搜索：利用搜索引擎获得，后台，未授权页面，敏感url等。

 

  • 基础信息：IP，网段，域名，端口

  • 系统信息：操作系统版本

  • 应用信息：各端口的应用，例如web应用，邮件应用等等

  • 版本信息：所有这些探测到的东西的版本。

  • 服务信息

  • 人员信息：域名注册人员信息，web应用中网站发帖人的id，管理员姓名等。

  • 防护信息：试着看能否探测到防护设备

 

漏洞探索

 

利用上一步中列出的各种系统，应用等使用相应的漏洞。

 

方法：

 

  • 1.漏扫，awvs，IBM appscan等。
  • 2.结合漏洞去exploit-db等位置找利用。
  • 3.在网上寻找验证poc。

 

内容：

 

  • 系统漏洞：系统没有及时打补丁
  • Websever漏洞：Websever配置问题
  • Web应用漏洞：Web应用开发问题
  • 其它端口服务漏洞：各种21/8080(st2)/7001/22/3389
  • 通信安全：明文传输，token在cookie中传送等。

 

漏洞验证

 

将上一步中发现的有可能可以成功利用的全部漏洞都验证一遍。结合实际情况，搭建模拟环境进行试验。成功后再应用于目标中。

 

  • 自动化验证：结合自动化扫描工具提供的结果
  • 手工验证，根据公开资源进行验证
  • 试验验证：自己搭建模拟环境进行验证
  • 登陆猜解：有时可以尝试猜解一下登陆口的账号密码等信息
  • 业务漏洞验证：如发现业务漏洞，要进行验证

  • 公开资源的利用

    -exploit-db/wooyun/
    -google hacking
    -渗透代码网站
    -通用、缺省口令
    -厂商的漏洞警告等等。

 

信息分析

 

为下一步实施渗透做准备。

 

  • 精准打击：准备好上一步探测到的漏洞的exp，用来精准打击
  • 绕过防御机制：是否有防火墙等设备，如何绕过
  • 定制攻击路径：最佳工具路径，根据薄弱入口，高内网权限位置，最终目标
  • 绕过检测机制：是否有检测机制，流量监控，杀毒软件，恶意代码检测等（免杀）
  • 攻击代码：经过试验得来的代码，包括不限于xss代码，sql注入语句等

 

获取所需

 

  • 实施攻击：根据前几步的结果，进行攻击
  • 获取内部信息：基础设施（网络连接，vpn，路由，拓扑等）
  • 进一步渗透：内网入侵，敏感目标
  • 持续性存在：一般我们对客户做渗透不需要。rookit，后门，添加管理账号，驻扎手法等
  • 清理痕迹：清理相关日志（访问，操作），上传文件等

 

信息整理

 

  • 整理渗透工具：整理渗透过程中用到的代码，poc，exp等
  • 整理收集信息：整理渗透过程中收集到的一切信息
  • 整理漏洞信息：整理渗透过程中遇到的各种漏洞，各种脆弱位置信息
  • 目的：为了最后形成报告，形成测试结果使用。

 

形成报告

 

  • 按需整理：按照之前第一步跟客户确定好的范围，需求来整理资料，并将资料形成报告
  • 补充介绍：要对漏洞成因，验证过程和带来危害进行分析
  • 修补建议：当然要对所有产生的问题提出合理高效安全的解决办法

 

posted @ 2019-09-30 13:59  Focusal  阅读(1053)  评论(1)  编辑  收藏  举报
Live2D