嗯，用户让我帮忙总结一下这篇文章的内容，控制在100个字以内，而且不需要用“文章内容总结”或者“这篇文章”这样的开头。直接写描述就行。首先，我得仔细阅读文章内容，理解主要信息。 文章讲的是最近在honeypot上发现了一些请求，这些请求里带有“X-Vercel-Set-Bypass-Cookie”这个头。看起来这是Vercel用来绕过某些安全保护的机制。用户可能想知道这个头的作用和潜在风险。 然后，作者提到Vercel文档中提到了类似的头，但没有详细说明这个特定的头。特别是这个头的值是“samesite-none-secure”，这在文档中没有记录。作者怀疑这可能是为了放松安全设置，甚至可能被用来窃取秘密。 此外，请求还通过了开放代理，可能是为了隐藏攻击者的身份，但最后失败了。作者建议如果有更多关于这个头的信息可以提供的话会更好。 总结一下，文章主要讨论了Vercel的一个安全绕过机制被用于潜在攻击的情况。我需要把这些关键点浓缩到100字以内，并且保持语言简洁明了。 </think> 这篇文章描述了最近发现的针对Vercel平台的潜在安全测试或攻击行为，涉及使用未公开的"X-Vercel-Set-Bypass-Cookie"头来绕过安全保护机制，并可能通过代理隐藏攻击者身份。 2026-4-28 13:28:45 Author: isc.sans.edu(查看原文) 阅读量:31 收藏
This weekend, we saw a few requests to our honeypot that included an "X-Vercel-Set-Bypass-Cookie" header. A sample request:
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/ *;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cache-Control: no-cache
Pragma: no-cache
Connection: keep-alive
X-Vercel-Set-Bypass-Cookie: samesite-none-secure
Upgrade-Insecure-Requests: 1
X-Forwarded-From: 21.235.92.139
X-Real-Iphone: 21.235.92.139
Referer: [redacted, same as "Host" header]
Host: [redacted]
Vercel documents the "x-vercel-protection-bypass" header(note: no "Cookie" part) as a secret that can be configured to disable certain protections during testing. This type of bypass feature is common in various platforms. In particular, web application firewall features often need to be disabled to allow higher request rates during CI/CD pipeline operations. The value set in the header is a user-configurable secret[1].
The X-Vercel-Set-Bypass-Cookie allows testing in browsers and maintains the bypass by having the server set a cookie to indicate the bypass. There are two options according to Vercel's documentation:
- True: enables the cookie
- samesitenone: enables the cookie, and set the same-site property to none.
I did not see the "samesite-none-secure" documented by Vercel.
The most likely intention of the header is to relax security settings, maybe even steal secrets, should Vercel expose them in the cookie. I have not had a chance to test the request against a Vercel website. Any input as to the intent is welcome.
The request was also set via an open proxy, likely to protect the attacker's identity, but it failed due to the configured proxy headers.
[1] https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
如有侵权请联系:admin#unsafe.sh