web服务器通用cookie注入漏洞怎么防御

Posted 2023-04-13

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了web服务器通用cookie注入漏洞怎么防御相关的知识，希望对你有一定的参考价值。

解决方案一：找到Office 2007的安装文件

第一步：因为除Visual Studio本身以外，VS安装过程中安装的其他附带安装的组件，基本上都是有单独安装包的。先找到Visual Studio Web 创作组件的独立安装包，试试单独安装能不能成功。果然，在安装DVD的\WCU\WebDesignerCore文件夹中找到了“Visual Studio Web 创作组件”的安装程序。将其复制到硬盘上并解压缩，可以发现该组件使用的是Office 2007的安装方式，运行其中的setup.exe，出现与Office 2007相同的安装程序界面。单击“立即安装”，结果出现找不到office.zh-cn文件夹中文件的对话框，选择了安装程序所在的正确位置并确定，又再一次弹出同样的窗口，安装无法继续。

第二步：仔细核对文件名，确定安装文件夹中的确有需要的文件，但为什么还是提示找不到呢？
既然这个组件使用Office 2007的安装方式，文件夹中也有office.zh-cn这个和Office 2007共有的组件，那会不会是因为Office 2007的问题，导致Visual Studio Web 创作组件无法安装呢？参考技术A 可以在腾讯智慧安全页面申请使用腾讯御点
然后使用这个软件上面的修复漏洞功能
直接对电脑的漏洞进行检测和修复就可以了

web安全知识整理

常见漏洞

sql注入

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

分类：

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

防御：

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

判断方式：

单引号判断法
and 1=1 and 1=2 同真为真，其余为假
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）：

修复方式：

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

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