<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>2026 on chleynx's blog</title><link>/tags/2026/</link><description>Recent content in 2026 on chleynx's blog</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Mon, 09 Feb 2026 16:30:37 +0800</lastBuildDate><atom:link href="/tags/2026/index.xml" rel="self" type="application/rss+xml"/><item><title>react2shell</title><link>/posts/react2shell/</link><pubDate>Mon, 09 Feb 2026 16:30:37 +0800</pubDate><guid>/posts/react2shell/</guid><description>&lt;h3 id="webcve-2025-55182-react2shell"&gt;Web（CVE-2025-55182-react2shell）&lt;/h3&gt;
&lt;blockquote&gt;
&lt;p&gt;&lt;strong&gt;最近遇到一个CTF题再次看到了前端时间比较火的react2shell。&lt;/strong&gt;
&lt;strong&gt;这个题目大概的意思是在next@16.0.6，react@19.0.3-xx版本去绕一个特别疯狂的关键词检测waf，虽然之前这个洞刚出的时候我也去简单审了一下这个洞，但是只有个大概的了解，刚好遇到这个题，就又花时间去学习啦一下。&lt;/strong&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;h3 id="1ssrrscserveractionsflight协议"&gt;1.SSR、RSC、ServerActions、Flight协议&lt;/h3&gt;
&lt;p&gt;在开始之前我们得先了解这个几个概念&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;SSR&lt;/strong&gt; ：React原本是一个前端框架，但为了SEO优化和提升首次渲染速度，开发者使用SSR技术将首次渲染放在后端执行，并将渲染后的HTML代码返回给浏览器。但此后浏览器需要下载所有组件代码和依赖库，通过Hydration过程重新执行组件逻辑来绑定交互功能，这导致JavaScript bundle过大，可交互时间很长。（纯前端）&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;RSC&lt;/strong&gt; ：React 18引入了React Server Components（React 19中稳定）。与传统SSR不同，&lt;strong&gt;ServerComponents的代码永远不会下载到浏览器&lt;/strong&gt; ——它们只在服务器执行，输出结果发送给客户端，不需要Hydration，这样可以使用庞大的依赖库（如数据库驱动）而不影响前端性能。（加了点后端的东西放一起了）&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;ServerActions&lt;/strong&gt; ：React 19以后引入，Server Actions允许开发者直接在组件中调用服务器端函数来修改数据，无需创建API端点。React会自动处理客户端-服务器通信、数据序列化和页面更新，大幅简化了表单提交和数据修改的开发流程。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;strong&gt;RSC/Flight&lt;/strong&gt; 是一种“在网络上传递 React 组件树信息”的协议，客户端用一个解码器把服务器返回的“帧”（frame）解析成可恢复的 React 结构，再进行局部更新和渲染。&lt;/p&gt;
&lt;p&gt;响应类型：RSC 载荷的响应头是 content-type: text/x-component（又称 Flight payload）。&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;总的来说就是因为有了&lt;strong&gt;ServerActions&lt;/strong&gt;之后前后端再次揉在一起从而导致了这个漏洞&lt;/p&gt;</description></item><item><title>Self-XSS</title><link>/posts/self-xss/</link><pubDate>Mon, 19 Jan 2026 09:40:41 +0800</pubDate><guid>/posts/self-xss/</guid><description>&lt;h1 id="selfxss定义风险评估与进阶利用含-credentialless-iframe"&gt;Self‑XSS：定义、风险评估与进阶利用（含 Credentialless Iframe）&lt;/h1&gt;
&lt;h2 id="0-摘要"&gt;0. 摘要&lt;/h2&gt;
&lt;p&gt;Self‑XSS（自触发 XSS）经常被当成“自嗨洞”，因为默认只炸在攻击者自己的会话里。但只要加上合适的东西（CSRF/会话切换/同站落点/credentialless iframe），它也能变成可复现的攻击链。&lt;/p&gt;
&lt;p&gt;抓两条主线：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Self‑XSS 能不能打，核心看“执行点”能不能搬到受害者可控/可被影响的上下文里（能否完成链路闭环）。&lt;/li&gt;
&lt;li&gt;credentialless iframe 的坑点不在“不同源”，而在“存储隔离 + 同源 DOM 仍可能互访”的组合拳。&lt;/li&gt;
&lt;/ol&gt;</description></item></channel></rss>