INFO5995 Task 3 — Session Token Role Evidence 讲解

代码是什么

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	用来读取数据的工具

---

为什么这是证据

核心逻辑：

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

---

换个角度理解：App 怎么判断"已登录"？

方式 A：服务器 session（真实 App 常见）

• 用户登录 → 服务器返回一个 token → 存在内存 → 每次请求带上
• 服务器验证 token 是否合法

方式 B：本地 session（这个 Demo App 的做法）

• 用户登录成功 → App 在本地生成一个"身份证明"
• 下次打开 App → App 检查本地有没有这个"身份证明"
• 有就认为已登录，没有就回到登录页

这个 App 就是方式 B。

---

为什么 session token 是 security-sensitive

Session token 如果： - 可预测 → 攻击者可以伪造身份证明 → 冒充其他用户登录 - 不可预测 → 只有正常登录的用户才有 → 无法冒充

所以 session token 本身是身份凭证，它承担了安全敏感的角色。

---

这个漏洞的本质

漏洞链条：

java.util.Random 生成 token
        ↓
token 存入 SharedPreferences 作为"身份证明"
        ↓
token 可预测
        ↓
攻击者可以伪造/冒充有效用户

---

为什么这段代码是"证据"

不是因为它写了什么安全机制，而是因为它说明了一个安全敏感的操作：

这个 App 用一个本地生成的随机值来充当用户身份凭证，但这个随机值的生成算法是 java.util.Random（可预测的）。

证据链： 1. KEY_SESSION_TOKEN = "sessionToken" → 这个值叫 session token 2. createSession() → 在登录成功后调用 3. generateSessionToken() → 生成用的 java.util.Random

---

对作业的意义

这段代码回答了 Task 3 的一个关键问题：

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

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

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