目录
诱使用户执行操作--请求伪造
1.1、简介：
这种类型的攻击也称为会话叠置，它们与会话劫持攻击密切相关， 在攻击过程中， 攻击者截获一名用户的会话令牌， 因而能够作为该用户使用应用程序。但通过请求伪造，攻击者根本不需要知道受害者的会话令牌。相反攻击者利用Web浏览器的正常行为劫持用户的令牌，并通过它提出用户并不打算提出的请求。
请求伪造漏洞分为：本站点和跨站点
1.2、本站点请求伪造
简述：
1、本站点请求伪造(OSRF)是一种利用存储型XSS漏洞的常见攻击有效载荷。如蠕虫示例，在自己的用户资料中插入一段脚本，致使任何查看其资料的用户在不知情的情况下执行各种操作。即使在XSS漏洞并不存在的地方， 存储型OSRF漏洞仍有可能存在（常被人们忽视）
2、测试其中是否存在XSS漏洞。但假设应用程序对插入页面中的任何" 、<和>字符进行了正确地HTML编码，觉得攻击者无论如何也无法避开它，测试员就会继续进行下一步测试。但控制的仅仅是<img>标签目标的一部分内容，虽然无法破坏引用字符串，但可以修改URL，使得查看消息的任何用户提出任意一个本站点GET请求
3、如在type参数中提交(../admm/newUser.php?username=daf2&password=0wned&role=admin#)的值将会使任何查看消息的用户提出一个尝试创建新的管理用户的请求
4、如果一名普通用户被诱使提出攻击者专门设计的请求，攻击当然不会成功。但如果管理员查看消息，攻击者就可以建立一个秘密账户，即使无法实施XSS攻击， 但攻击者仍然能够成功执行OSRF攻击。即使管理员采取了防范措施，禁用了JavaScript，攻击依然能够成功。
5、如果a.png中a被传值为上面字符串，#符终止.png后缀前面的URL。但只需在后缀前插入一个＆ ，构成另外一个请求参数， 即可解决
6、在将其合并到响应中之前，尽可能严格地确认用户提交的输入，即可防止OSRF漏洞。例如，应用程序可能会检查参数中是否有一组值中的某一个特殊的值。如果应用程序必须接受无法预料的其他值，那么应阻止任何包含/ . \ ? &与=的请求（对这些字符进行HTML编码并不能有效防止OSRF攻击，因为浏览器在请求目标URL字符串之前，会首先对其进行解码）
过程：
1、如果一名用户提交的数据在某个位置显示给其他用户，但测试员仍然无法实施存储型XXS功击，那么在每个这样的位置，检查应用程序的行为是否使得它易于受到OSRF攻击
2、用户提交的数据被插入到超链接目标或返回页面中的其他URL等位置时往往会出现漏洞。除非应用程序特别阻止要求的任何字符（包括点、斜线及查询字符串中的分隔符）否则它肯定易于受到攻击
3、如果发现OSRF漏洞， 则应寻找一个适当的请求作为利用目标
1.3、跨站点请求伪造
简述：
1、在跨站点请求伪造(CSRF)攻击中，攻击者只需创建一个看似无害的网站，致使用户的浏览器直接向易受攻击的应用程序提交一个请求，执行某种有利于攻击者的无意操作。同源策略并不阻止一个网站向另一个域提出请求，但它确实阻止提出请求的网站处理跨域请求的响应，正常情况下，CSRF攻击只是一种“单向“ 攻击。
2、所以在纯粹的CSRF攻击中， 要想实施如XSS蠕虫中的多阶段操作，从响应中读取数据并将其合并到随后的请求中， 将很难实现
3、请求易于受到CSRF攻击可能有：请求执行特权操作、仅仅依靠HTTPcookie来追踪会话、攻击者可以确定执行操作所需的所有参数等。
4、针对这些特点表现出的缺陷， 攻击者可以构建一个Web页面，向易受攻击的应用程序提出一个跨域请求， 在其中包含执行特权操作所需的所有步骤。攻击将所有请求参数放入隐藏表单字段中， 并包含一段用于自动提交表单的脚本，用户的浏览器提交此表单时， 将自动添加用户的目标域的cookie，并且应用程序会正常处理生成的请求。如果管理用户登录到易受攻击的应用程序，并访问攻击者的包含此表单的Web页面，该请求将在管理员的会话中处理，攻击者的账户因此得以创建
5、应用程序确认站外图像方面的漏洞称为 ＂检查时间，使用时间” 漏洞。因为某个数据在一个时间确认，却在另一个时间使用，导致攻击者能够在这两个时间的间隔内修改该数据的值
利用CSRF漏洞
1、根据在应用程序解析过程中得到的结果，检查应用程序的关键功能
2、找到一项可用于代表不知情的用户执行某种敏感操作的应用程序功能，该功能仅依赖cookie来追踪用户会话，并且使用攻击者能够提前决定的请求参数，即其中并不包含任何会话令牌或其他无法预测的数据
3、创建一个HTML页面，它不需要进行任何用户交互即可提出所需请求。对于GET请求，可以使用<img>标签，并通过src参数设置易受攻击的URL。对于POST请求，可以建立一个表单， 其中包含实施攻击所需全部相关参数的隐藏字段并将其目标设置为易受攻击的URL。可以使用JavaScript在页面加载时自动提交该表单
4、登录应用程序后， 使用同一个浏览器加载专门设计的HTML页面。确认应用程序是否执行所需操作
验证与CSRF
1、由于实施CSRF攻击需要在受害用户的会话中执行某种特权操作， 因此在实施攻击时，用户需要登录到应用程序。
2、一个存在大量危险的CSRF漏洞的位置，是家庭DSL路由器使用的Web界面，这些设备大多包含敏感功能，如打开面向互联网的防火墙上的所有端口。由于这些功能通常并未采取防范CSRF的措施，并且多数用户也没有修改设备的默认内部IP地址， 因此易于受到由恶意外部站点传送的CSRF攻击。但相关设备通信需要进行验证才能执行敏感操作，而且许多用户并未登录他们的设备
3、如果设备的Web界面使用基于表单的验证，则可以通过首先使用户登录设备，然后执行经过验证的操作从而实施两步攻击，如果并未修改这类设备的默认证书， 攻击者的网页可以首先提出包含默认证书的登录请求，设备会在用户的浏览器中设置一个会话令牌，随后的任何请求，包括由攻击者生成的请求，将自动传这该令牌
4、在其他情况下，攻击者可能需要受害用户以攻击者自身的用户账户登录应用程序才能实施特定的攻击。以一个允许用户上传并存储文件的应用程序为例，这些文件随后可以进行下载，但只能由上传它们的用户下载，假设由于没有对文件内容进行过滤，该功能可用于实施存储型XSS攻击，该漏洞似乎并不会造成任何伤害，因为攻击者只能用它来攻击自己。
5、但通过使用CSRF，攻击者可以利用存储型XSS漏洞来攻破其他用户。如攻击者的网页可以提出一个CSRF请求，强制受害用户使用攻击者的证书登录。然后攻击者的网页可以提出另一个CSRF请求，以下载某个恶意文件。用户的浏览器处理该文件时，攻击者的XSS有效载荷将会执行，用户在易受攻击的应用程序中的会话将被攻破。虽然受害者当前是使用攻击者的账户登录的，但攻击并未就此结束，XSS有效载荷可以在用户的浏览器中持续存在，并执行任意操作，因而可以让用户注销其在易受攻击的应用程序中的会话，并诱使其使用自己的证书登录
防止CSRF漏洞
1、由于浏览器自动在随后的每个请求中将cookie返回给发布cookie的Web服务器，CSRF漏洞因此产生，如果某个Web应用程序主要依赖HTTPcookie传送会话令牌，那么它本身就易于受到这种攻击。
2、防范CSRF攻击的标准方法，是将HTTPcookie与其他追踪令牌的方法相结合，这类方法通常采用其他通过HTTP隐藏表单字段传输的令牌。在每次提交请求时，应用程序除确认会话cookie外，还核实表单是否传送了正确的令牌。如果攻击者无法确定该令牌的值，就无法构建跨域请求也就无法执行所需的操作
3、以这种方式使用反CSRF令牌时，必须为这些令牌提供与正常的会话令牌相同的保护。如果攻击者能够预测发布给其他用户的令牌值，就能够确定提出CSRF请求所符的所有参数， 因而仍然能够实施攻击。如果反CSRF令牌未与所属用户的会话相关联，攻击者就可以在自己的会话中获得一个有效令牌，并将此令牌用在针对其他用户的会话的CSRF攻击中。
4、一些应用程序使用相对较短的反CSRF令牌，可能因为认为这些令牌不会像较短的会话令牌一样受到蛮力攻击。任何向应用程序传送大量可能值的攻击都需要通过受害者的浏览器传送这些值，包括提交大量可能被轻易察觉的请求。如果收到太多无效的反CSRF令牌，应用程序可能会防御性地终止用户的会话， 从而阻止相关攻击。
5、但这种防御忽略了纯粹在客户端实施的蛮力攻去，而不向服务器发送任何请求的可能也在某些情况下，可以通过使用基于CSS的技巧来枚举用户的浏览历史记录，从而实走这种攻去。要想成功实施这类攻击， 必须满足以下：
A、应用程序必须某些时候在URL查询字符串中传输CSRF令牌。这种情况经常发生， 因为许多受保护的功能通过目标URL中包含令牌的简单超链接即可访问。
B、应用租序必须在整个用户会话中使用相同的反CSRF今牌，或者允许多次使用同一个令牌。这种情况也经常发生，一方面是为了改善用户的用户体验，另一方面是为了便于使用浏览器的后退和前进按钮
6、满足条件，并且目标用户已访问某个包含反CSRF令牌的URL，攻去者就可以从自己的页面实施蛮力攻击，攻击者页面上的一段脚本将动态创建指向目标应用程序上的相关URL的超链接，同时在每个链接中包括一个不同的反CSRF令牌值，然后该脚本使用JavaScript API getComputedStyle测试用户是否访问了上述链接，确定某个被访问的链接后，即可发现一个有效的反CSRF令牌，然后， 攻击者的页面将其用于代表用户执行敏感操作
7、要防范CSRF攻击，仅仅使用多阶段过程执行敏感操作并不够。如管理员在添加新用户账户时， 他可能会在第一阶段输入相关信息，然后在第二阶段检查并确认这些信息。如果未使用其他反CSRF令牌，该功能将仍然易于受到CSRF攻击， 因为攻击者只需要轮流提交两个所需的请求， 或者直接提交第二个请求（极为常见）。
8、少数情况下， 应用程序功能会采用另一个令牌；它在一个响应中设置该令牌，然后在接下来的请求中提交该令牌。但在这两个阶段之间转换需要进行重定向，因此应用程序采用的防御机制可能会失效。虽然CSRF属于单向攻击，并且无法从应用程序的响应中读取令牌，但如果CSRF响应包含预定向，而且该顶定向指向其他包含令牌的URL，受害者的浏览器将自动访问该重定向，并自动在提出的请求中提交令牌
通过XSS突破反CSRF防御
1、如果应用程序中包含任何XSS漏洞，那么反CSRF防御机制就可以被突破，这种说法并不完全正确。但支持这种观点的思考方法是正确的，因为XSS有效载荷在本站执行，可以与应用程序进行双向交互，所以能够从应用程序的响应中获取令牌，并在随后的请求中提交这些令牌
2、但如果某个本身受到反CSRF防御机制保护的页面也包含反射型XSS漏洞，那这种漏洞并不能直接用于突破防御，在反射型XSS攻击中，最初的请求为跨站点请求，攻击者会设计一个URL或一个POST请求，其中包含随后被复制到应用程序的响应中的恶意输入。如果易受攻击的页面实施了反CSRF防御，那么攻击者要想实施有效攻击，其专门设计的请求中必须已经包含必要的令牌。如果其中没有所需令牌，应用程序将会拒绝攻击者提出的请求，同时包含反射型XSS漏洞的代码路径也不会执行，问题并不在于注入的脚本是否能够读取应用程序响应中的任何令牌（它能），而在于如何首先将脚本注入到某个包含那些令牌的响应中。
3、可以利用XSS漏洞突破反CSRF防御的情况：
A、如果受保护的功能中存在任何XSS漏洞，那么攻击者总可以利用这些漏洞突破反CSRF防御。通过存储型攻击注入的JavaScript可直接读取脚本所在的应用程序响应中的令牌。
B、如果应用程序仅对一部分通过验证的功能实施反CSRF防御，并且某项未防御CSRF的功能中存在一个反射型XSS漏洞，那么攻击者就可以利用这个漏洞来突破反CSRF防御。如果应用程序仅采用反CSRF令牌保护转账功能的第二个步骤，那么攻击者就可以利用反射型XSS攻击从其他步骤中突破防御。通过这个漏洞注入的一段脚本可以向第一个转账步骤提出一个站内请求，截取令牌，然后使用这个令牌进入第二个步骤。攻击之所以能够成功， 是因为第一个没有采取CSRF防御的转账步骤返回了访问受保护页面所需的令牌。仅依赖HTTPcookic实现第一个步骤，意味着攻击者可以利用它访问保护第二个步骤的令牌，从而实施有效攻击
C、在某些应用程序中， 反CSRF令牌仅与当前用户相关联，而不是与用户的会话相关联，如果登录表单未防范CSRF攻击，则应用程序仍有可能受到多阶段攻击。攻击者使用自己的账户登录，获得一个与他的用户身份关联的有效反CSRF令牌。然后对登录表单发动CSRF攻击，迫使受害用户使用他的证书登录，一旦用户作为攻击者登录，攻击者将使用CSRF使用户提出相关请求，对XSS漏洞加以利用，同时使用他此前获得的反CSRF令牌，攻击者的XSS有效载荷将在用户的浏览器中执行。由于用户仍然作为攻击者登录，XSS有效载询可能需要使用户注销，然后诱使用户再次登录，最终用户的登录证书和生成的应用程序会话都被完全攻破。
D、如果反CSRF令牌未与用户关联，而是与当前会话关联，且攻击者可以通过某种方法在用户的浏览器中注入cookie，则只需对以上攻击稍作修改即可，攻击者不是使用自己的证书针对登录表单实施CSRF攻击， 而可以直接向用户传送他当前的会话令牌及与该会话关联的反CSRF令牌。然后该攻击的剩余部分与之前步骤相同
https://blog.csdn.net/qq_53079406/article/details/123942109?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166156857116781647589994%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=166156857116781647589994&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-123942109-null-null.nonecase&utm_term=CSRF&spm=1018.2226.3001.4450
184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
