漏洞 4：登录验证流程——Token 在验证之后才生成

代码证据

((Button) findViewById(R.id.button2)).setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) throws Throwable {
        boolean zCheckCredentials = Login.this
            .checkCredentials(editText.getText().toString(),
                             editText2.getText().toString());
        if (!zCheckCredentials) {
            Toast.makeText(Login.this, "Wrong Credential", 0).show();
            return;
        }
        Login.this.createSession();
        Login.this.startActivity(
            new Intent(Login.this, (Class<?>) Profile.class));
    }
});

出处：Login.java，第 49-60 行。

---

流程解读

用户输入用户名 + 密码
         ↓
checkCredentials() 读取本地文件验证
         ↓
   验证失败 → 显示 "Wrong Credential" → 停在登录页
         ↓
   验证成功 → createSession() → 跳转到 Profile

---

三元条件的证据意义

if (!zCheckCredentials) {
    return;         // 验证失败：不做任何会话操作
}
Login.this.createSession();  // 验证成功后才执行

这个三元条件意味着：

createSession() 只会在凭证验证成功之后才被调用。

---

为什么这个顺序很重要

"先生成 token，再验证用户" 是错的：

随机生成 token → 声称这是用户 XXX 的 token → 无法验证

"先验证用户，再生成 token" 是对的：

验证用户身份 → 确认是用户 XXX → 为用户 XXX 生成 token

这个 App 是第二种。

---

对安全的影响

当 token 生成有严格顺序时：

步骤	正常流程	如果 token 可预测
1	用户提供正确凭证	用户提供正确凭证
2	系统验证凭证	系统验证凭证
3	✅ 生成 session token	⚠️ 攻击者提前预测出 token
4	用户获得 token，进入账户	攻击者直接用预测的 token 进入账户

问题核心： 步骤 2 虽然正确，但步骤 3 的弱点使得整个认证链条被削弱。

---

这段代码还透露了什么

Log.d("result func:", "" + zCheckCredentials);

登录验证的结果被写进了 Logcat——这是安卓系统的日志输出。

这意味着什么

如果攻击者有一台已 Root 的手机，或者通过 ADB 调试模式连接： - 可以用 adb logcat 实时查看登录验证结果 - 甚至可以看到验证是"成功"还是"失败"

这是一个额外的攻击面，但它是次要发现，主漏洞仍然是 java.util.Random 用于 session token。