1.JWT安全认证及伪造爆破
2.BJDCTF2nd-Web Writeup
3.常见的源码Web源码泄漏及其利用

JWT安全认证及伪造爆破

       Json web token (JWT) 是一种基于 JSON 的开放标准，用于在网络应用环境间传递声明，泄露设计为紧凑且安全，源码适合用于分布式站点的泄露单点登录（SSO）场景。JWT 的源码声明被用来在身份提供者和服务提供者间传递被认证的用户身份信息，用于从资源服务器获取资源，泄露模板和源码关系也可直接用于认证。源码

       相较于传统的泄露基于 session 的认证，JWT 采用无状态的源码方式，不需要在服务器端保留用户登录信息或会话信息。泄露这种机制使得应用扩展更为便利，源码不受客户端增加的泄露影响。

       JWT 的源码认证流程如下：每次请求时，token 需要传递给服务端，泄露通常存储在请求头中。源码服务端支持 CORS 策略，例如设置 Access-Control-Allow-Origin: *。JWT 由三个部分组成：头部、载荷和签证。

       头部包含两部分信息，使用 JSON 表示并进行 base 加密。JWT 支持使用“None”算法，若“alg”字段设为“None”，JWT 的gdb 源码编译安装签证部分会被置空，所有 token 均有效，便于伪造。

       载荷部分存放有效信息，包含注册的公共声明、公共声明和私有声明。公共声明可添加用户信息或其他业务所需信息，但应避免包含敏感信息，因为该部分在客户端可解密。私有声明由提供者和消费者共同定义，一般不存放敏感信息。

       签证部分由 base 加密后的头部和载荷使用特定加密方式（通过头部声明）和 secret 组合加密形成。secret 作为服务端私钥，用于生成和验证 JWT，其安全性至关重要。

       JWT 通过存储在 Cookie 或 localStorage 中，与服务器交互时自动携带。跨域时，可将 JWT 放置在 HTTP 请求的 Header Authorization 字段或 POST 请求数据主体中。

       服务器验证 JWT 的前两部分加密结果与客户端传递的第三部分对比，验证通过则允许访问资源。使用 Authorization: Bearer JWT 格式进行身份验证。

       JWT 存在安全问题，包括 token 泄露、独立用户中心源码伪造等风险。为减少盗用，JWT 有效期不宜过长。使用 HTTPS 传输更为安全。

       JWT 可通过破解或伪造实现安全绕过，如印度举办的 CTF 比赛中遇到的题目。伪造 JWT 的过程包括解密、修改内容、使用密钥加密，需确保密钥安全。使用特定工具或破解服务，可尝试破解密钥并伪造数据通过服务器验证。

       通过漏洞分析和源码恢复，如使用 base 解码、下载 .swp 文件并恢复源码，可发现 JWT 使用的加密秘钥。构造 JWT 替换浏览器中的 token，实现登录和获取 flag。

       JWT 安全问题要求严格管理密钥，避免源码泄露，并使用 HTTPS 等安全措施保护 JWT 传输。对敏感信息进行加密处理，定期更新密钥，在线名片生成源码增加安全验证步骤，以提高 JWT 的整体安全性。

BJDCTF2nd-Web Writeup

       感谢各位师傅出题，本次比赛的Web部分难度适中，以基础知识为主，但考验思维灵活性。

       首先，遇到了一个假的Google搜索页面，通过尝试输入内容，发现页面会直接显示输入的文本，初步判断为SSTI（Server-Side Template Injection）漏洞，尝试Fuzz注入，发现页面未进行过滤，直接使用payload过关。

       随后，进入了一个站点，发现站点内容中直接提示了某些敏感信息，通过DIR溢出尝试，发现ThinkPHP5框架存在漏洞，随意运行一个控制器直接导致版本号为V5.0.的错误信息暴露，进一步搜索发现存在RCE（Remote Code Execution）漏洞，直接利用过。

       接着，预测赢家指标源码是一个征婚网站，通过泄露的.swp文件，成功进行shell反弹，直接在内网机器上运行nc命令。寻找flag成为了接下来的任务。

       在其中一个题目中，作者似乎在半夜修改了题目，原本在"/flag"的flag被移动到了一个不寻常的位置，提示玩家寻找方法。

       接着，是简单的注入题目，玩家被思维僵化所困，直接注表名、注列名，并未想到直接注入列名即可解决问题。通过Fuzz注入，发现过滤了引号和部分SQL语句，利用这一漏洞，在robots.txt下找到了hint.txt，进一步在两个注入点处进行操作，最终利用\符号绕过引号，执行布尔盲注，成功获取了flag。

       接着是关于HTTP头的掌握题目，玩家发现网站对于非X开头的头进行了限制。进入注册界面后，通过返回的页面发现了隐藏信息。通过burp suite工具研究，发现post请求返回的页面中包含了敏感信息。进一步探索登录页面，发现了一些错误提示，引导玩家进入headers研究。使用BP工具，发现cookie中包含时间戳，通过将其修改为年，以及伪造特定的IP、referer、User-Agent，最终找到了flag。

       接下来是Schrödinger主题的脑洞题，玩家发现登录界面与量子密码爆破相关，但在实际操作中发现不存在请求，下面的数字也是前端模拟的。经过长时间研究，发现cookies中包含时间戳的base值，尝试将时间改为久远的值，但无果。最终，玩家脑洞大开，输入test.php并设置特定cookie，成功获取了flag。

       最后是关于元素周期表的元素master题，玩家发现了一些奇怪的id号，通过hex2str函数转换，最终想到元素钋，直接爆破元素周期表，获取了flag。

       面对文件探测题，玩家发现Hint隐藏在头部信息中。访问home.php页面，发现其中有一个参数file可能涉及文件包含，尝试各种方法无效后，利用filter功能读取源码，发现了系统和主页的核心代码，通过格式化字符串漏洞，成功获取了flag。

       对于EasyAspDotNet题目，由于环境搭建问题，当前无法解答。

常见的Web源码泄漏及其利用

       Web源码泄漏漏洞及利用方法

       Git源码泄露是由于在执行git init初始化目录时，会在当前目录下自动创建一个.git目录，用于记录代码变更等信息。若未将.git目录删除即发布到服务器，攻击者可通过此目录恢复源代码。修复建议：删除.git目录或修改中间件配置以隐藏.git隐藏文件夹。

       SVN源码泄露源于其使用过程中自动生成的.svn隐藏文件夹，包含重要源代码信息。若网站管理员直接复制代码文件夹至WEB服务器，暴露.svn隐藏文件夹，攻击者可利用.svn/entries文件获取服务器源码。修复方法：删除web目录中的所有.svn隐藏文件夹，严格使用SVN导出功能，避免直接复制代码。

       Mercurial（hg）源码泄露通过生成的.hg文件暴露，漏洞利用工具为dvcs-ripper。运行示例需具体说明。

       CVS泄露主要针对CVS/Root和CVS/Entries目录，直接暴露泄露信息。修复工具为dvcs-ripper，运行示例同样需具体说明。

       Bazaar/bzr泄露为版本控制工具泄露问题，因其不常见但多平台支持，同样存在通过特定目录暴露源码的风险。具体修复方法与运行示例需进一步说明。

       网站备份压缩文件泄露是管理员将备份文件直接存放于Web目录，攻击者通过猜测文件路径下载，导致源代码泄露。常见备份文件后缀需具体列出，利用工具御剑用于这类漏洞的利用。

       WEB-INF/web.xml泄露暴露了Java WEB应用的安全目录，若直接访问其中文件需通过web.xml文件映射。WEB-INF目录主要包括文件或目录，通过web.xml文件推断类文件路径，最后直接访问类文件，通过反编译得到网站源码。

       .DS_Store文件泄露源于Mac系统中Finder保存文件展示数据的文件，每个文件夹下对应一个。若上传部署到服务器，可能造成文件目录结构泄漏，特别是备份文件、源代码文件的泄露。利用工具为github.com/lijiejie/ds_...

       SWP文件泄露为编辑文件时产生的临时文件，是隐藏文件，若程序意外退出则保留。直接访问并下载.swp文件，删除末尾的.swp后，可获得源码文件。

       GitHub源码泄露通过关键词搜索功能，容易找到目标站点的敏感信息，甚至下载网站源码。此类泄露源自代码托管平台，需注意个人代码管理安全。

       总结，Web源码泄漏涉及多个环节，从代码版本控制到备份存储，再到代码托管平台，每个环节都可能成为攻击点。修复策略包括删除隐藏文件、严格使用版本控制功能、加强代码备份安全措施以及提高代码托管平台安全意识。