目录
如何理解服务器端请求伪造(SSRF)类漏洞
当服务器向用户提交的未被严格校验的URL发起请求的时候,就有可能会发生服务器端请求伪造(SSRF,即Server-Side Request Forgery)攻击。
SSRF是由攻击者构造恶意请求URL,由服务端发起请求的安全漏洞。攻击者可以利用SSRF漏洞来攻击到内部系统,因为服务器请求天然发生在系统内部。SSRF 形成的原因大都是由于服务端提供了从其他服务端应用获取数据的功能,但又没有对目标地址做校验与限制。
应用程序为了给用户提供更多更方便的功能,从另一个URL获取数据的场景越来越多,因此SSRF漏洞也越来越多。此外,由于云服务和体系结构的复杂性,SSRF攻击产生的影响也越来越大。
SSRF攻击的工作原理
-
用户输入恶意 URL:应用程序允许用户输入用于发起请求的 URL,例如,图片链接、文件下载链接、API 请求地址等。
-
没有严格校验这个 URL:应用程序没有对用户提供的 URL 进行充分的校验,或者校验不严格,给了攻击者构造或修改请求的 URL 的机会。
-
服务器端发起请求:应用程序使用用户提供的 URL 发起服务器端的 HTTP 请求或其他类型的请求。
-
攻击者利用漏洞:攻击者利用这个漏洞,构造特殊的 URL,使得服务器端应用程序向攻击者指定的目标服务器发起请求。
SSRF 攻击的类型
-
基本型SSRF:攻击者利用服务器端的请求功能,访问或操作内网中的其他服务。
-
盲目型 SSRF:攻击者无法直接看到服务器端请求的结果,但可以通过其他方式间接推断出信息,例如通过触发 DNS 查询或者观察应用行为变化。
SSRF 攻击的危害
SSRF 可能会有以下危害(当然不仅限于以下几种):
-
绕过IP限制和防火墙:攻击者可以访问仅限内网访问的服务,绕过 IP 限制和防火墙。
-
扫描内网端口:攻击者可以探测内网中的开放端口和运行的服务。
-
获取敏感信息:攻击者可以尝试数据库文件、配置文件等敏感信息。
-
远程执行代码:如果内部服务存在漏洞,SSRF 可能被用来远程执行代码。
-
作为其他攻击的跳板:SSRF 可以作为发起更广泛攻击的起点,例如配合其他漏洞进行攻击。
举个例子
假设一个电商网站,展示商品详情的时候也同时展示库存数量,库存数量需要提供商品详情信息的后端服务通过REST API查询其他后端服务得到,而其他后端服务的URL地址直接包含在查询商品详情的接口中,作为此接口的一个参数。所以展示商品详情界面会发出如下请求:
POST/product/detail HTTP/1.0
Content-Type: application/json
{"productId:66","stockApi":"http://stock.xxx.com/stock/detail"}
这种情况下,攻击者可以通过修改请求参数stockApi以指定任意URL,例如:
POST/product/detail HTTP/1.0
Content-Type: application/json
{"productId:66","stockApi":"http://localhost/admin"}
此时,服务端就会访问http://localhost/admin并将其内容返回给用户,攻击者就可以采用这用方式来尝试获取到服务器相关的信息。
如何预防SSRF攻击
-
严格校验用户输入的URL,可以使用白名单过滤来限制输入,只允许特定的协议、主机和端口。
-
不要把原始的响应数据返回给客户端。
-
限制Web应用程序的网络访问权限,可以让远程资源访问功能使用单独的网络。
-
限制Web应用程序对服务器端资源的访问权限,可以使用访问控制列表(ACL)来限制应用程序可以访问的URL和端口。
-
加强代码审核,通过人工审核和自动化审核工具审核的方式来发现潜在的SSRF漏洞。