漏洞 2：Session 创建时机——登录成功后才生成

代码证据

public void createSession() {
    this.editor.putString(KEY_SESSION_TOKEN, generateSessionToken());
    this.editor.apply();
}

出处：Login.java，第 174-177 行。

---

这段代码在做什么

1. 调用 generateSessionToken() 生成一个 token
2. 用 putString(KEY_SESSION_TOKEN, token) 把它存进 SharedPreferences
3. apply() 表示提交写入

---

关键：谁调用了这个方法

在 Login.java 的登录按钮点击事件里：

boolean zCheckCredentials = Login.this.checkCredentials(...);
if (!zCheckCredentials) {
    Toast.makeText(Login.this, "Wrong Credential", 0).show();
    return;
}
Login.this.createSession();  // ← 只有验证成功才会到这里
Login.this.startActivity(new Intent(Login.this, (Class<?>) Profile.class));

---

时间线

checkCredentials() 验证用户名密码
         ↓
    验证成功
         ↓
createSession() 生成并存储 session token
         ↓
跳转到 Profile 页面

Token 的生成时间点是：登录成功之后。

---

为什么这能当证据

这段代码证明了：

Session Token 不是 App 启动时随意生成的，而是在用户证明了自己身份之后才产生的。

这意味着： - Token 的存在 = 用户刚刚成功登录过 - Token 就是这次登录的"证明"

---

Security-Sensitive 的原因

因为这个 token 的含义是：

"有一个合法用户刚刚成功登录了，这个用户就是 XXX。"

如果这个 token 可预测： - 攻击者不需要知道用户名和密码 - 只需要能预测出这个 token - 就能冒充刚登录的用户

这就是为什么它比"Random 用错了"更严重——这是一个认证凭证，而不是一个普通随机数。