对另一个问题的评论（很简单）：
XSS 和 SQLi 可以通过多种方式一起使用。
这对我来说是新的，我很想知道在一个网站上可能会打开哪些额外的攻击向量，而这个网站对这两种攻击都非常脆弱。我能想到的唯一用例是 SQLi 漏洞是否存在于只能由授权用户访问的页面上：在这种情况下，XSS 可能会为您提供使 SQLi 发生所需的权限。但是，如果您自己没有经过身份验证（在这种情况下您不需要 XSS），可能不可能找到这样的漏洞，所以我不认为这是原始评论者想到的场景。
关于这两者如何相互构建并共同完成某些可能无法单独解决这些漏洞之一的其他想法？
XSS 和 SQLi 可以通过两种方式进行交互。您引用的评论来自这个问题，并且显然与第一点有关。
如果您知道某个应用程序容易受到 SQL 注入攻击，但您没有访问易受攻击组件所需的权限，则您可以利用现有的 XSS 漏洞，从而获得更高权限的用户来为您执行 SQL 注入.
正如您所指出的，在您无权访问的组件中查找漏洞可能并不容易。但是，至少有两种情况很容易发生这种情况：
对于非常简单的注入，攻击者也可能只是猜测攻击（也许攻击者知道您的应用程序根本不防御 SQLi，但他们有权访问的组件中的所有注入都使用具有受限权限的数据库用户；这里他们实际上可能能够猜测其他组件的脚本和参数名称并通过 XSS 来利用它们）。
从理论上讲，您还可以想象一个设置，其中更多特权用户始终使用与更高特权数据库用户的数据库连接，因此如果通过 XSS 通过更高特权用户利用，即使注入公共组件也可能更强大。
最后一个例子有点做作，但肯定是可能的。可能还有其他例子。
在这种情况下，您有一个 SQL 注入，但实际上并不能用它实现任何有趣的事情。注入可能发生在非常受限的数据库用户身上，例如只能读取已经公开可用的数据（但不能读取其他数据、写入数据、写入或读取系统文件、执行命令等；也没有漏洞在您可以利用的 dbms 中）。
在这种情况下，您可能能够通过 SQLi 执行反射或存储的 XSS 攻击。
一个例子：