漏洞 1：Session Token 角色定义

代码证据

private static final String KEY_SESSION_TOKEN = "sessionToken";
private static final String SESSION_PREF_NAME = "SessionPrefs";
private SharedPreferences.Editor editor;
private SharedPreferences sharedPreferences;

出处：Login.java，第 26-29 行。

---

逐行解释

代码	含义
KEY_SESSION_TOKEN = "sessionToken"	后面存入手机的 key 叫 "sessionToken"
SESSION_PREF_NAME = "SessionPrefs"	存储文件名是 "SessionPrefs"
SharedPreferences.Editor editor	写入数据的工具
SharedPreferences sharedPreferences	读取数据的工具

---

这个值是什么

这段代码定义了一个常量： - KEY（键）："sessionToken" - 存储位置：SharedPreferences

这意味着后面会用 editor.putString("sessionToken", xxx) 来存一个值。

---

为什么这能当证据

核心逻辑：

1. 变量名叫 KEY_SESSION_TOKEN，明确说明这个值是 session token
2. 存储在 SharedPreferences 里——Android 的本地持久化存储
3. 结合 createSession() 的逻辑：这个值在登录成功后被存入本地

---

Session Token 在认证系统里是什么角色

Session Token 是用户在本地生成的"身份证明"。

App 的认证逻辑（简化版）

用户打开 App
    ↓
App 检查本地有没有 "sessionToken"
    ↓
有  → 认为已登录 → 进入 Profile
没有 → 认为未登录 → 进入 Login

也就是说：这个 App 用本地一个字符串值来代表"用户已经成功登录了"。

---

为什么它是 Security-Sensitive

如果这个 token 是可预测的： - 攻击者可以在不知道用户名密码的情况下 - 通过预测/枚举出有效的 token - 直接进入别人的账户

这就是 session hijacking（会话劫持） 的基础。

---

对作业的意义

这段代码回答了 Task 3 的一个核心问题：

"这个漏洞涉及的是什么类型的安全敏感值？"

答案是：Session Token——它不是普通随机数，而是代表"已登录状态"的身份凭证。

这就是为什么 java.util.Random 用在这里是真正的问题，而不只是"用了不安全的 API"那么简单。