JS+C#+Oracle架构下四位随机PIN码生成的防护与限制方案咨询

• 随机数安全性不足：Math.random() 是非加密安全的伪随机数生成器，输出结果可被预测，不能用于生成PIN这类涉及安全的敏感值，极易被攻击者碰撞出有效PIN。
• 生成逻辑错误：当前代码只调用一次charAt拿单个字符，生成的是1位内容，完全不符合4位PIN的要求。
• 重复校验逻辑失效：仅在第一次检测到重复时重试一次生成，若重试生成的PIN仍重复，会直接使用重复值，没有做循环校验直到拿到唯一值的逻辑。
• 高危SQL注入风险：直接把用户侧生成的PIN拼接进SQL语句，攻击者可篡改客户端提交的PIN内容构造注入语句，窃取、删除数据库数据，同时你的拼接SQL缺少空格，pin =' + pin + 'AND 会直接报语法错误无法执行。
• 并发竞争问题：多用户同时生成同一个PIN时，会出现多个请求同时查询数据库均判断PIN不存在，随后同时写入导致重复的情况，仅靠查询校验无法避免并发冲突。
• 前端校验不可靠：如果仅在JS侧做范围校验，用户可通过篡改JS代码、直接调用后端接口的方式绕过校验，提交超出范围甚至非法的PIN值，服务端无校验的话会直接写入脏数据。
• 格式不统一风险：4位PIN存在前导零场景（如0012），如果存储时混用数字类型和字符串类型，会出现12和0012被判定为不同值的问题，导致重复校验失效。

三层校验都要做，不存在二选一的情况：

• 前端JS层：作为第一层校验，生成PIN后先判断是否符合0001~9999的范围要求，不符合直接本地重新生成，不需要发起后端请求，减少无效交互。
• 服务端C#层：作为核心校验层，前端的所有校验都是不可信的，服务端接收到PIN后必须首先校验范围合法性，不符合直接驳回请求，绝对不能信任前端传递的任何未校验值。
• SQL查询层：作为最后一道冗余校验，可在查询语句中增加范围判断，避免前两层校验漏判时非法值进入后续流程，注意必须使用参数化查询，禁止SQL拼接。

• 前端生成PIN改用加密安全的随机数接口window.crypto.getRandomValues，不要使用Math.random()。
• 数据库的PIN字段添加唯一约束，即使业务逻辑出现漏洞，数据库层面也会拦截重复值写入。
• PIN的重复校验和写入操作放在同一个事务中执行，或使用数据库UPSERT逻辑，避免并发冲突导致的重复写入。
• 固定PIN的存储格式，要么用长度为4的定长字符串存储，要么统一用数字类型存储后，展示时补前导零到4位，避免格式不匹配导致的校验错误。

内容的提问来源于stack exchange，提问作者stackymacky obroedar