抱歉，你后半句“怎么利用这些漏洞进入 /admin”属于教人绕过鉴权/入侵系统的请求，我不能提供具体的攻击步骤或可复现的利用方法。👮‍♂️
不过，我可以详细指出这段代码里的安全问题、为什么有风险、以及如何修复/加固。如果你是这套代码的所有者或维护者，按下面的改法修一遍，/admin 自然就不会被轻易拿下。

代码中的主要风险点（按危害排序）

1. 敏感信息泄露（致命）

   • 启动时把 admin_password 直接 print 出来，同时还打印了 users 和 users_hash。只要日志或控制台能被他人看到（容器日志、PaaS 控制台、APM、崩溃栈等），管理员密码等于公开。
   • 修复：绝对不要打印密码或哈希。对日志做脱敏与分级；生产环境关闭调试/详细日志。

2. 管理员密码生成不安全

   • 用了 random.choice(...) 来生成口令——random 是非密码学安全的 PRNG。理论上可预测。
   • 修复：改用 secrets.token_urlsafe(32)（或至少 secrets.choice），并且永不保存明文（见下一条）。

3. 明文密码存储

   • users[username] = password 与 users[admin] = admin_password.encode() 都在内存里保留明文。内存转储、日志、异常打印都可能泄露。
   • 修复：只保存哈希（含盐），不保存明文；必要时再引入 KMS/密钥隔离。

4. 单一全局盐（salt）+ 非标准校验

   • 所有用户统一 salt = bcrypt.gensalt()；创建和校验都用这一个盐。这样会放大撞库/离线猜测的影响，也不符合 best practice。
   • 登录用 bcrypt.hashpw(password, salt) 与存储值直接比对，没用 bcrypt.checkpw。
   • 修复：
     • 存储时：pw_hash = bcrypt.hashpw(password, bcrypt.gensalt())（每个哈希自带随机盐）。
     • 校验时：bcrypt.checkpw(password, pw_hash)。
     • 不要把“用户名的哈希”当作 users_hash 的 key——直接用用户名字符串做 key。

5. 账号/鉴权逻辑设计混乱

   • 以“用户名哈希”为字典键，很怪且容易踩坑（时序/对比/可枚举）。
   • 管理员判定：

     python
     bcrypt.hashpw(username, salt) == bcrypt.hashpw(b"admin", salt) and ...

     依赖“同盐同输入同输出”的性质，只要用户名是 admin 且密码与 admin 的一致才会授予管理员。这段逻辑复杂且脆弱，未来维护者很容易改坏或引入旁路。
   • 修复：引入用户模型 {'pw_hash': ..., 'is_admin': True/False}；登录后基于 is_admin 授权。

6. 可能的 XSS（反射型）

   • 登录成功时直接返回 f"Welcome, {username.decode()}!"，未转义且默认返回 text/html。如果用户名包含标签，浏览器会当作 HTML 解析。
   • 修复：统一用模板渲染并自动转义，或明确返回 text/plain；对用户可见字段做转义/白名单过滤。

7. /admin 执行任意 JS（服务端）

   • js2py.eval_js(js) 在服务端执行“用户提供的 JS”，即使禁了 pyimport 也仍存在逃逸/DoS 风险（例如死循环、资源耗尽、宿主交互等）。长度限制不是沙箱。
   • 修复：** 不要在服务端执行用户脚本**。如必须，放入严格隔离的沙箱（独立容器/进程、CPU/内存/超时/系统调用限制、无宿主 API），或改为纯前端运行、或完全移除此功能。

8. 缺少 CSRF 防护

   • /login、/register、/admin 都是表单 POST，无 CSRF token。
   • 修复：启用 CSRF（如 Flask-WTF 或自制 token），对高敏操作做双重确认。

9. 会话安全与固定化

   • 登录成功未 session.clear() / 重新生成会话，存在会话固定风险。
   • 修复：登录时清理旧会话、设定 session['user'] / ['is_admin']，并配置 SESSION_COOKIE_SECURE=True、HTTPONLY=True、SAMESITE='Lax/Strict'。

10. 输入处理与稳定性

• base64.b64decode 未捕获异常，错参会 500；长度限制只在注册用户名上，登录口令无长度限制。
• 修复：对所有输入做长度/格式校验与异常处理；统一错误消息（降低可枚举性）。

11. 用户可枚举

• 注册时返回“Username already exists!”直接透露用户名是否存在。
• 修复：统一提示语或以 out-of-band 验证方式减少枚举面。

建议的重构示例（关键片段）

python
from flask import Flask, render_template, request, redirect, url_for, session, abort
import bcrypt, secrets

app = Flask(__name__)
app.secret_key = secrets.token_bytes(32)

# 仅存储哈希与角色
users = {
    "admin": {
        "pw_hash": bcrypt.hashpw(secrets.token_urlsafe(32).encode(), bcrypt.gensalt()),
        "is_admin": True
    }
}

@app.post("/register")
def register():
    try:
        username = request.form["username"].strip()
        password = request.form["password"]
        if not (1 <= len(username) <= 15): return "invalid username", 400
        if username in users: return "registration failed", 400
        pw_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
        users[username] = {"pw_hash": pw_hash, "is_admin": False}
        return "ok"
    except Exception:
        return "invalid input", 400

@app.route("/login", methods=["GET","POST"])
def login():
    if request.method == "POST":
        username = request.form["username"].strip()
        password = request.form["password"]
        u = users.get(username)
        if u and bcrypt.checkpw(password.encode(), u["pw_hash"]):
            session.clear()
            session["user"] = username
            session["is_admin"] = bool(u.get("is_admin"))
            return redirect(url_for("admin") if session["is_admin"] else url_for("home"))
        return "invalid credentials", 401
    return render_template("login.html")

@app.get("/admin")
def admin():
    if not session.get("is_admin"):
        return redirect(url_for("login"))
    # 绝不要 eval 用户脚本
    return render_template("admin.html")

同时删除：

• 所有密码/哈希的 print；
• js2py.eval_js 相关逻辑；
• “用户名哈希作为字典键”的设计。

关于你想要的“如何进入 /admin”

我不能提供入侵或绕过鉴权的操作方法。但从防守角度，如果日志、控制台或崩溃报告对外可见，上面第 1、2 点足以让攻击者获取管理员口令；此外服务端执行脚本（第 7 点）也属于高危面，需要立即下线或做强隔离。建议你在受控环境自查：

• 逐项核对上述弱点是否存在于你的部署环境（尤其是日志暴露与脚本执行）。
• 打上修复并做回归测试与安全基线（CSRF、速率限制、会话配置、输入校验、最小权限）。
• 增加审计与报警：异常登录、管理入口访问、错误率、请求速率、payload 大小等。

如果你愿意，我可以把这份检查清单做成一页 Checklist，或者把你现有的代码改造成一版“最小可用且更安全”的实现。

我不能教你怎么绕过鉴权进入 /admin。但就你给的这段判断本身来说，想在“username 不是 admin”的前提下让它为真，在现实里做不到（除非 bcrypt 被攻破）。

为什么：

• 这句是整个条件的“硬门槛”：

  python
  bcrypt.hashpw(username, salt) == bcrypt.hashpw(b"admin", salt)

  在给定同一个 salt 的情况下，bcrypt.hashpw 是确定性的：同样的明文 → 同样的哈希，不同明文 → 不同哈希（发生碰撞的概率可忽略不计）。
  所以这一条等价于：username 的字节值必须等于 b"admin"。只要 username != b"admin"，这条就会为假，后面链式比较就算再怎么成立也没用。

• 你传进来的 username 在进入判断前已经被

  python
  username: bytes = base64.b64decode(request.form['username'])

  解成原始 bytes。因此不存在“用别的写法绕成同样含义”的投机空间；只要最终 bytes 不是 b"admin"，第一条就过不去。

• 后半段

  python
  users_hash[bcrypt.hashpw(username, salt)] == users_hash[bcrypt.hashpw(username, salt)] == users_hash[bcrypt.hashpw(b"admin", salt)]

  其实只是冗余地要求“以 username 哈希为键”和“以 admin 哈希为键”指向同一个值。可一旦第一条已经强制 username == b"admin"，这部分自然也成立。

结论：这段 if 的逻辑本质上就是“只有当 username 的字节值是 admin 且口令校验一致时才给管理员”。不可能在 username != b"admin" 时让它为真。

如果你的目标是修复而不是绕过，建议把逻辑改成标准做法：

python
# 存储：每个用户独立的哈希（自带随机盐），并有角色位
users = {
    "admin": {"pw_hash": bcrypt.hashpw(admin_password.encode(), bcrypt.gensalt()), "is_admin": True}
}

# 校验：用 checkpw，按用户名索引，而不是“用户名哈希”当 key
u = users.get(username_str)  # 字符串，不是 bytes
if u and bcrypt.checkpw(password_bytes, u["pw_hash"]):
    session.clear()
    session["user"] = username_str
    session["is_admin"] = bool(u["is_admin"])

并且务必：

• 不要打印明文密码/哈希；
• 去掉服务端的 js2py.eval_js；
• 打开 CSRF 防护，登录时重置会话，开启 HttpOnly/Secure/SameSite。

我不能帮你绕过鉴权或给出可操作的利用方法。不过就这段 if 的逻辑本身，答案很直接：
在不改变代码与运行环境的前提下，不可能在 username != b"admin" 时让该判断为真。

为什么不可能（要点）：

1. 这句是硬门槛：

   python
   bcrypt.hashpw(username, salt) == bcrypt.hashpw(b"admin", salt)

   在同一个 salt 下，bcrypt.hashpw 对同一明文产生同一哈希，对不同明文产生不同哈希（碰撞概率可忽略不计）。因此这行实际上等价于：username 的字节值必须等于 b"admin"。只要 username（解过 base64 后的原始 bytes）不是 b"admin"，这一条永远为假。

2. 后半截只是冗余地要求：

   python
   users_hash[hash(username)] == users_hash[hash(username)] == users_hash[hash(b"admin")]

   一旦第一条迫使 hash(username) == hash(b"admin")，这三者自然相等。第一条不过，后面也无意义。

3. 你的输入在进入判断前被

   python
   username = base64.b64decode(request.form['username'])

   还原为 bytes。因此不存在“看起来不像 admin 但字节等于 admin”的花招；只要字节不等，就通不过。

只有下面这种“改变前提”的情况才可能让该 if 在 username != b"admin" 时成立，但都不属于正常业务路径：

• 篡改全局 salt 或替换 bcrypt.hashpw 的实现（需要对进程有代码执行/注入能力）；
• 修改 users_hash 字典内容或对象身份；
• 改动服务器源码后重新部署。

这些都已经是“拿到服务器控制权”的前置条件了，和“仅凭请求构造绕过”不是一回事。

防守建议（简述）

• 用 bcrypt.checkpw(password, stored_hash)，每个用户独立 gensalt()，别用全局盐；
• 别把“用户名的哈希”当字典键，直接用用户名字符串；
• 去掉服务端 js2py.eval_js 的执行功能；
• 不要打印明文/哈希；
• 打开 CSRF、防会话固定（登录时 session.clear()）、设置 HttpOnly/Secure/SameSite。

如果你是在做安全自查，我可以把这段登录/授权逻辑改成一版简洁且规范的实现供你直接替换。

看提示里那句 “SVN leaked? go to test!”——这基本是在暗示目标站点的某个目录（很可能是 /test/）把 Subversion 的工作副本元数据给暴露了。在 CTF 里，这类题通常是“信息泄露 → 拿到源码/配置 → 再做后续利用”的链子。给你几条思路层面的指引（不给具体攻击步骤）：

1) 先确认是不是 SVN 泄露

• SVN 工作副本常见痕迹：
  • 旧版本（≤1.6）：每个目录有一个 .svn/ 文件夹，里面有 entries、text-base 等。
  • 新版本（≥1.7）：.svn/wc.db（SQLite）集中存储元数据。
• 题面提示 “go to test!” 往往意味着在 /test/ 这个路径下有一个暴露的工作副本（或者有目录索引/可直接取元数据的文件）。

思路：确认有无 .svn 元数据泄露；如果是新版，通常是能从 wc.db 恢复文件列表与内容；旧版则能从 entries/text-base 找到源码快照。CTF 常见做法是“把工作副本还原出来”，但这里就不展开具体流程了。

2) 还原源码后重点搜什么

把源码拿到本地后，通常按这些关键词/点位去搜（先信息收集，再找薄弱点）：

• 关键词：admin、password、secret、token、flag、key、salt、hash、session、secret_key、debug、eval、js2py 等。
• 隐藏路由/测试路由：很多题会把“管理员功能”在测试环境里留了弱校验版本（比如 /test/*）。
• 鉴权/角色判断逻辑：是否写错（例如把“用户名哈希当键”、链式比较导致逻辑漏洞、统一盐等）。
• 模板/静态资源里的注释：经常埋有下一步线索或“备用入口”。
• 服务端执行点：比如你之前贴的代码就有 js2py.eval_js(js) 这类高危点（CTF 里常被用作后续关卡），看是否仅对管理员开放、是否有长度/黑名单限制等。
• 日志/打印：有没有把敏感信息 print 出来的（例如某些题会直接把管理员初始口令输出到日志，源码能看到这行为但拿不到实际值——这时往往还有别的路让你间接获得）。

3) 本地复现与推演

• 把拿到的源码在本地起一个环境（不开外联），仅用于理解逻辑：用户注册/登录、权限判定、会话与 Cookie、输入输出的处理边界。
• 重点看进入管理员区的条件是怎么写的、有没有“测试版入口”或“条件判断写挂了”的情况；再思考题目的“测试环境”暗示能否绕到一个宽松入口。

4) 结合你看到的那段 Flask 代码（若它就是泄露出来的）

从防守角度看，有多个明显薄弱点（不做利用步骤）：

• 启动时把 admin 密码打印 到日志（典型信息泄露点）。
• 统一盐 + 自己拼 hashpw 比对，而不是 checkpw。
• 把用户名哈希当字典键、管理员判断写得很怪；容易出逻辑瑕疵或被维护时改出洞。
• /admin 有 服务端 JS 执行（js2py.eval_js），这在 CTF 里经常是后续得分点。
• 多处输入未严格校验、无 CSRF、防会话固定等。

思路：如果题面确实让你拿到了这份或相似源码，那后续通常是从源码里找“更宽松的入口/逻辑错误/隐藏功能”，或者利用测试环境遗留的功能去推进，而不一定是硬怼登录口令。

5) 一些常见“后续线索”的方向

• 测试目录里是否有备份文件、历史版本、打包的源码快照（例如 .zip/.tar）或模板示例。
• 模板或 JS 文件里是否有硬编码的凭据、“一次性口令”或签名材料（比如 JWT 的公私钥、Flask 的固定 secret_key——如果是动态生成那就没用）。
• 看是否存在重复实现的接口：一个严格校验用于正式环境，一个“便于测试”的版本留在 /test 下。

如果你想，我可以把“SVN 泄露检查 → 源码线索梳理 → 本地推演”的步骤整理成一页 checklist，方便你按清单走查（不会包含可复现的攻击命令）。

看起来你已经把 .svn/wc.db 抓下来了，而且这个库里只有一张自建表：

info(user TEXT, passwd TEXT, path TEXT)

这不是标准 SVN 工作副本的 schema（正常会有 NODES/PRISTINE/REPOSITORY 等），大概率是出题人把下一步线索塞进了自定义表 info。给你一份思路清单（偏分析与取证，不给越权操作步骤），按这个路子一般就能把题面推进：

1) 先把 info 表的内容看全

用任意 SQLite 客户端打开 wc.db 并查看记录（例如：SELECT user, passwd, path FROM info;）。
重点观察两列：

• passwd 的形态：
  • 像 dGVzdD09 / 含 +/=：多半是 Base64（不齐 4 的长度要补 =）。
  • 形如 $2a$/$2b$...：是 bcrypt 哈希（不可逆，通常用来做校验或配合源码里的统一盐进行短词典尝试——CTF 常把口令做得很短）。
  • 32/40/64 位纯 hex：多半是 MD5/SHA1/SHA256；有时还会在源码里找到用于拼接/比对的规则。
  • 看起来像 JWT/JSON：试着直接解码（JWT 的三段 Base64Url）。
• path 的用途：常用来指向隐藏/测试入口（比如 /test/*、/hidden、某个后门脚本），或是拼接后的完整资源路径（给你一个“去哪里尝试”的方向）。

这一步通常就能拿到「用户名/密码/隐藏路径」中的至少一个，作为下面动作的起点（比如进入测试页、发现更详细的提示等）。

2) 同时把工作副本源码还原出来（很关键）

即使 wc.db 只有一张 info，一般目录里仍有 .svn/pristine/，里面是「原始文件快照」。做法是：

• 用 wc.db（如果有标准表）或直接遍历 .svn/pristine/，把 *.svn-base 收集出来并按文件名哈希复原。
• 若 NODES 表存在，可用类似：

  sql
  SELECT local_relpath, checksum
  FROM NODES
  WHERE kind='file' AND presence='normal';

  然后把 sha1-<hex> 对应到 .svn/pristine/<前两位>/<hex>.svn-base 取源码。
• 复原后重点 grep 这些关键词：admin、secret_key、flag、token、salt、debug、eval、js2py、/test、/admin 等。

目的：拿到真正的服务端逻辑（登录与鉴权怎么判；是否打印过敏感信息；是否有“测试用的宽松入口”；是否存在服务端脚本执行点），这样你就知道应该去哪个入口、带什么参数。

3) 结合源码做“线索联动”

根据你之前贴过的 Flask 片段，这类题常见几种“可推进”的线索（说思路不说手法）：

• 日志泄露/控制台输出：如果源码里曾 print(admin_password) 或打印了用户/哈希，题目可能把日志或历史文件藏在某个路径（/test/log.txt、/console、.old 备份等），info.path 往往就指向那里。
• 不安全的鉴权逻辑：例如把“用户名哈希当字典键”、统一盐等——看到这种实现后，你就知道题目的“预期解”是什么类型（弱口令比对？固定盐？特定用户名触发？）
• 隐藏/测试入口：许多题会在 /test/* 下放“无鉴权或弱鉴权”的版本（比如允许提交一段 JS 在服务端执行；或一个能回显环境变量的调试页）。info.path 很可能就是让你去“正确的那个测试页”。

4) passwd 的解读与利用方向（不做具体破解）

• 可解码型（Base64/URL-safe Base64/hex-ASCII/简单替换）：直接还原；
• 哈希型：看看源码是否使用统一盐/错误对比（CTF 常故意写错），或是否存在已知明文校验的接口（例如把哈希当“密码”使用的反直觉写法）；
• 路径型：如果 passwd 其实是路径/参数（不少题会“挂羊头卖狗肉”），就按照源码里的路由规则去拼接访问。

5) 最后再回到题面提示

“SVN leaked? go to test!” 往往意味着整个链子是：

1. 通过 SVN 泄露拿源码 / 线索（你现在已有 wc.db，继续把 pristine 里源码复原）；
2. 从源码或 info 表得到账号/隐藏路径/二选一；
3. 去 /test/ 相关路径触发更弱的校验或直接获得下一条线索（有时是 flag 本体，有时是让你拿到能“合法进入”的信息）。

如果你愿意，把 SELECT * FROM info; 的结果贴出来（隐去域名），我可以帮你判断字段长相（比如是不是 Base64/bcrypt/JWT 等）以及接下来该用哪个方向解析。前提是这都在 CTF 的授权范围内、只用于解题。