''

Orien Daily

  1. 📸 @MLBJapan🎆 日本人スラッガー3人のホームランを一気見!🚀 今季第11号 🚀 今季第20号 🚀 今季第9号一番興奮したのはどのホームラン?👀日本人選手のハイライト映像は公式YouTubeチャンネルでチェック👉

    📸 @MLBJapan
    🎆 日本人スラッガー3人のホームランを一気見!

    🚀 今季第11号
    🚀 今季第20号
    🚀 今季第9号

    一番興奮したのはどのホームラン?👀



    日本人選手のハイライト映像は
    公式YouTubeチャンネルでチェック👉
    https://www.youtube.com/@mlbjapan #岡本和真 #村上宗隆 #大谷翔平 #日本人選手情報
    原文 #MLB日本選手
    Media is too big
    VIEW IN TELEGRAM

  2. 「妥当」和「适当」,写论文时别搞混日语里「妥当性」在研究论文中出场率极高,但如果你把妥当读成てきとう、或者把它当成適当的兄弟,那就踩坑了

    「妥当」和「适当」,写论文时别搞混

    日语里「妥当性」在研究论文中出场率极高,但如果你把妥当读成てきとう、或者把它当成適当的兄弟,那就踩坑了。適当(てきとう)在日常对话中最常见的用法是「随便、凑合」——適当に答える是胡乱回答,適当に選ぶ是随便挑一个。但妥当(だとう)完全是另一回事,它说的是「合理的、逻辑上成立的」,用来评价论证、方法或结论是否经得起推敲。论文里写「本手法の妥当性を示す」,是在论证你的方法靠谱,不是在说「差不多能用了」。

    有趣的是,適当其实也有「恰当」的意思,比如「適当な条件」可以是合适的条件,但这个用法自带一层模糊感,学术写作基本不用它。需要精确表达「论证有效」的时候,妥当才是正确的词。

  3. JWT 算法混淆攻击:你以为签名了,其实没签JWT 在 Web 认证里几乎是标配了,但很多人只关心"token 能不能解析",很少仔细看 header 里那个 alg 字段到底意味着什么

    JWT 算法混淆攻击:你以为签名了,其实没签

    JWT 在 Web 认证里几乎是标配了,但很多人只关心"token 能不能解析",很少仔细看 header 里那个 alg 字段到底意味着什么。这个字段告诉验证方用什么算法校验签名——问题就在这里,验证方信任了 JWT 自己声明的算法。

    攻击的逻辑很直白。服务器本来用 RS256(非对称,私钥签名、公钥验证)发 token。攻击者拿到一个合法 token,把 header 的 alg 改成 HS256(对称,同一密钥既签名又验证),然后把原来用作验证的公钥当成 HMAC 密钥,重新签名整个 token。服务器收到后看到 alg: HS256,就拿公钥去做 HMAC 验证——签名自然通过,因为攻击者用的就是同一个公钥。于是一个完全伪造的 token 被当作合法 token 接受了。

    这不是理论漏洞,真实世界里多次出现过。最容易踩坑的场景是:JWT 库默认接受多种算法、不做白名单限制;或者开发者把公钥和 HMAC 密钥存在同一个配置字段里,验证逻辑根据 header 自动切换。一旦切换逻辑没加约束,攻击者就能"指定算法"来完成绕过。

    修复方式其实很简单:验证端硬编码只接受你期望的算法,比如只允许 RS256,收到 HS256 直接拒绝。不要让 token 自己决定怎么被验证——签名方案是服务端的安全决策,不是客户端的声明。