免责声明 本教程仅为合法的教学目的而准备，严禁用于任何形式的违法犯罪活动及其他商业行为，在使用本教程前，您应确保该行为符合当地的法律法规，继续阅读即表示您需自行承担所有操作的后果，如有异议，请立即停止本文章阅读。
目录
一、CSRF漏洞
1.理解应用:
2.查找没有使用CSRF令牌的敏感操作:
3.重放攻击:
4.构建并测试CSRF攻击:
5.验证:
二、 同源策略
一、同源策略
二、CSRF攻击与同源策略
三、处理CSRF攻击与同源策略的方法
三、CSRF能出现高危操作的点
一、涉及资金交易的操作
二、涉及用户信息修改的操作
三、涉及权限管理的操作
四、CSRF配合XSS的攻击场景
五、csrf与oauth2.0的危害
1、授权码泄露：
2、CSRF攻击：
在OAuth 2.0授权码流程中，客户端应用程序通过授权码来获取访问令牌。如果这个过程没有妥善保护，可能会遭受CSRF攻击，导致用户的授权信息被窃取。3、客户端安全问题：
六、csrf 在post 和get 中的利用
1、GET请求中的CSRF利用
2、POST请求中的CSRF利用
一、CSRF漏洞
渗透测试以寻找CSRF漏洞时，你可以按照以下步骤进行:
1.理解应用:
理解应用程序的工作原理是至关重要的。这包括理解应用程序的各个部分如何相互交互，理解它的请求和响应，理解使用的技术堆栈等。所有这些信息都可能会帮助你找到CSRF漏洞。
2.查找没有使用CSRF令牌的敏感操作:
要找到CSRF漏洞，你需要寻找那些没有使用CSRF令牌(或者使用方式不正确)的敏感操作。这可能包括更改态码，更改用户信息、创建新的用户帐户等。
3.重放攻击:
你可以尝试重放攻击，看看是否可以在不包含CSRF令牌的情况下重复执行操作。如果可以，那么这就是一个潜在的CSRF漏洞。
4.构建并测试CSRF攻击:
一旦你找到了一个潜在的CSRF漏洞，你就可以构建一个CSRF攻4.击来测试它。这通常涉及创建一个将执行恶意操作的HTML页面或脚本。
5.验证:
最后，你需要验证攻击是否成功。这可能涉及检查是否真的进行了恶意操作，或者查看是否接收到了预期的响应。
二、 同源策略
一、同源策略
同源策略（Same-Origin Policy）是浏览器的一种安全机制，它限制了一个源（协议、域名和端口）的文档或脚本如何与另一个源的资源进行交互。这意味着，默认情况下，一个源下的脚本不能读取或修改另一个源下的文档。
二、CSRF攻击与同源策略
CSRF攻击依赖于浏览器自动发送Cookie的能力，而同源策略正是为了防止这种攻击而设计的。然而，同源策略并不能完全阻止CSRF攻击，因为以下原因：
Cookie的存在：即使两个源不同，如果用户的浏览器已经向第一个源（例如网站A）发送了Cookie，那么在用户访问第二个源（例如恶意网站B）时，浏览器会自动附带上这些Cookie。
跨域请求：当恶意网站B发送一个请求到网站A时，如果网站A没有实施额外的安全措施，它可能会处理这个请求，因为请求中包含了有效的Cookie。
三、处理CSRF攻击与同源策略的方法
1. 使用CSRF Token
原理：在用户的会话中生成一个唯一的Token，并在每个表单或请求中包含这个Token。
实现：用户提交表单时，服务器验证表单中的Token是否与会话中存储的Token匹配。
效果：即使请求来自不同源，由于Token的验证，服务器也能区分请求是否由用户发起。
2. 验证Referer头
原理：检查HTTP请求头中的
Referer字段，确保请求来自信任的源。限制：
Referer头部可以被用户修改，因此这不是一个完全可靠的方法。3. 使用CORS（跨源资源共享）
原理：通过设置CORS头部，允许来自不同源的请求。
实现：在服务器响应中设置
Access-Control-Allow-Origin头部。限制：CORS允许跨源请求，如果不当配置，可能会引入安全风险。
4. 双重提交Cookie
原理：在客户端请求中同时提交两个Cookie，一个用于客户端存储，另一个用于服务器验证。
实现：客户端发送两个Cookie，服务器验证这两个Cookie是否匹配。
效果：这种方法可以减少CSRF攻击的风险，但需要用户端和服务器端的额外支持。
5. 使用HTTP Only和Secure标志的Cookie
原理：设置Cookie的
HttpOnly标志可以防止JavaScript访问Cookie，而Secure标志确保Cookie只通过HTTPS传输。效果：这可以减少通过XSS攻击窃取Cookie的风险。
三、CSRF能出现高危操作的点
一、涉及资金交易的操作
转账操作：当银行或金融类网站存在CSRF漏洞时，攻击者可利用用户已登录状态，伪造转账请求。例如，用户登录银行网站A后，若访问恶意网站B，B网站中的恶意代码（如利用img的GET请求方式或者构造自动提交的POST表单）可在用户不知情的情况下，以用户身份向银行网站A发送转账请求，从而导致用户资金被盗转，造成财产损失。
支付操作：在电商平台上，如果存在CSRF漏洞，攻击者可以以用户名义进行商品购买支付。例如，用户登录电商网站并已授权支付功能，攻击者可伪造请求来完成支付流程，使受害者在未同意的情况下购买商品，遭受经济损失。
二、涉及用户信息修改的操作
修改密码：如果网站在修改密码功能处存在CSRF漏洞，攻击者可以构造恶意请求修改用户密码。一旦成功，攻击者就可以完全掌控用户账号，获取账号内的所有信息，并可能进行更多恶意操作，如冒用身份发布信息等。
修改用户资料：例如姓名、联系方式、地址等用户资料的修改。攻击者可利用CSRF漏洞，以用户身份修改这些信息，这可能导致用户隐私泄露，或者被用于进一步的诈骗活动，如修改收货地址以获取用户购买的商品等。
三、涉及权限管理的操作
添加管理员权限：在一些系统中，如果存在CSRF漏洞，攻击者可能以普通用户身份发送伪造请求，为自己或其他恶意账号添加管理员权限。这样攻击者就可以对系统进行更多恶意操作，如篡改系统数据、删除重要信息等。
权限提升：将低权限账号提升为高权限账号，使得攻击者能够访问原本无权访问的功能和数据，从而对系统的安全性和数据完整性造成严重威胁。
四、CSRF配合XSS的攻击场景
利用XSS获取CSRF Token：在某些情况下，网站可能会使用CSRF Token来防止CSRF攻击。然而，如果同一网站存在XSS漏洞，攻击者可以通过XSS漏洞注入恶意脚本，窃取用户的CSRF Token。一旦攻击者获得了CSRF Token，他们就可以构造合法的CSRF请求，绕过CSRF防护机制，执行恶意操作。
增强攻击效果：SS攻击通常局限于在受害者浏览器中执行恶意脚本，而CSRF攻击则可以利用受害者的身份在其他网站上执行操作。当这两种攻击结合在一起时，攻击者可以先通过XSS攻击获取受害者的敏感信息（如CSRF Token、会话ID等），然后利用这些信息发起CSRF攻击，进一步扩大攻击的效果和范围。
五、csrf与oauth2.0的危害
OAuth 2.0是一种授权框架，用于保护API和资源免受未授权访问。尽管OAuth 2.0本身是为了提高安全性而设计的，但它也可能成为攻击的目标，特别是在实现和使用不当的情况下。OAuth 2.0的相关危害包括：
1、授权码泄露：
如果授权码在传输过程中被拦截，攻击者可以利用这个授权码来获取访问令牌，从而访问用户的敏感信息。
2、CSRF攻击：
在OAuth 2.0授权码流程中，客户端应用程序通过授权码来获取访问令牌。如果这个过程没有妥善保护，可能会遭受CSRF攻击，导致用户的授权信息被窃取。
3、客户端安全问题：原生客户端（如移动应用）在授权码模式下，客户端clientID和clientSecret的安全性是无法得到保证的，因此有可能被攻击者利用。为了解决这个问题，OAuth 2.0提供了PKCE（Proof Key for Code Exchange）增强的授权码模式，通过在客户端和授权服务器之间进行交互，确保授权码只能由预先与客户端关联的应用程序使用。
六、csrf 在post 和get 中的利用
1、GET请求中的CSRF利用
GET请求通常是用于从服务器请求数据的，它将所有参数都包含在URL中。由于GET请求的参数是可见的，并且可以很容易地通过链接或图像标签等方式来触发，因此GET请求中的CSRF利用相对较为简单和直接。攻击者可以构造一个恶意URL，并诱使受害者点击该链接，从而触发CSRF攻击。例如，攻击者可以创建一个包含恶意请求的图像标签：
，当受害者加载这个图像时，实际上是在向服务器发送一个GET请求，要求删除用户ID为12345的账户。
2、POST请求中的CSRF利用
POST请求通常是用于向服务器提交数据的，它将参数包含在请求体中。由于POST请求的参数是隐藏的，并且需要通过表单提交或Ajax请求等方式来触发，因此POST请求中的CSRF利用相对较为复杂和隐蔽。攻击者需要构造一个包含恶意请求的表单，并诱使受害者提交该表单，从而触发CSRF攻击。例如，攻击者可以创建一个包含恶意请求的表单：
，当受害者提交这个表单时，实际上是在向服务器发送一个POST请求，要求将1000元转账到账户ID为67890的账户。GET和POST请求都可以被用来进行CSRF攻击，但它们的利用方式和效果有所不同。GET请求中的CSRF利用相对较为简单和直接，而POST请求中的CSRF利用相对较为复杂和隐蔽。为了有效防范CSRF攻击，开发者需要采取一系列有效的防御措施，包括使用CSRF Token、验证请求来源、使用同源策略以及限制敏感操作的请求方式等。
未完待续！！！！！
