V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
dzdh
V2EX  ›  SSL

API 接口已经有 HTTPS 的前提下,为什么还需要签名机制?

  •  4
     
  •   dzdh · 233 天前 · 8382 次点击
    这是一个创建于 233 天前的主题,其中的信息可能已经有所发展或是发生改变。

    注意场景:

    • 服务端对服务端的接口,不是客户端对服务端的接口
    • 防止中间人可以 PINNED Pub Key,因此中间人攻击不在考虑范围内
    • 极端条件可以使用客户端证书

    综合以上三点。为什么在 Https 的保护下,还要额外做签名验证?

    主要疑问,如 stripe 的退款接口

    curl https://api.stripe.com/v1/refunds -u "$密钥:" -d charge=$charge_id
    

    就可以发起一笔订单的退款或者扣款。按照某些论述的话,没有签名的 Stripe 岂不是非常危险?

    第 1 条附言  ·  232 天前

    签名指的是

    data = { "a":"1", "b":2}
    
    data = sort(data) # 按照一定规则对data进行排序
    
    signString = getSignString(data) # 按照一定规则将数据拼成一个字符串
    
    sign = sign(signString) #按照指定算法如md5/shaX等计算hash得到最终的『签名』
    
    data.sign = sign # 最终请求数据
    
    
    第 2 条附言  ·  232 天前

    初步总结:

    在使用HTTPS的前提下,已经保证了足够的安全性。完全没有必要再额外做一套『签名机制』。

    防重放攻击,依靠的是API接口本身的逻辑设计,如下场景,订单相关:

    // 根据KEY找到user
    $user = Db::table('key_user')->where('key', $request->get('key'))->find();
    // 验证key、user是否合法、有权限、balabalabala
    // 验证key、user的请求频率
    // 如上两步都可以作为中间件全局统一处理
    
    // 查: 无所谓、随便查,无所谓是否重放攻击
    return new Response(balabalabala)
    // 改: 下单、关闭、结算等balabala
    // 下单:订单是否已经存在,存在报错已存在不存在入库
    // 关闭:验证订单状态,能关闭就关闭,不能关闭报错
    

    如上PHP代码逻辑完全可以有效防止『重放』带来的『损失』,而且还可以加入一个timestamp参数,可以有效防止TCP数据包重放

    第 3 条附言  ·  232 天前
    第二次总结:

    所有人的质疑是否代表着 Stripe 和 Paypal 现在是极度危险状态?
    第 4 条附言  ·  231 天前

    第三次总结:

    公开API的接口设计,在有HTTPS的前提下,签名负数『非必要』可以不使用签名。

    要注意的是:

    1. CDN不可信(事实是如果你要使用CDN你就只能被动选择相信)
    2. CDN到源站链路不安全(需要HTTPS回源)
    第 5 条附言  ·  231 天前

    20210414-0320总结:

    收集罗列了一些国内外的一些大型API服务使用单纯的HTTPS而没有『签名』参与的厂商和认证模式。

    国外已知服务

    • Github (Http Authentication 或 OAuth 二选一)
    • Stripe (Http Authentication)
    • Paypal (access_token)
    • Facebook(Server端调用系列API)+ access_token
    • Twitter (Server端调用系列API)+ access_token
    • Instagram
    • Google Cloud API (URL传递KEY) 国内已知服务
    • 华为云(Token认证模式)

    总结: 国内还是偏向一定要有『签名』的多,不知为何。

    第 6 条附言  ·  230 天前

    最终总结

    https+签名 ¹ 会『更』安全。

    但是,https自身的安全程度足够,没有再额外增加签名 ¹ 机制的必要性。

    安全问题主要出在客户端自身网络环境安全。

    结贴

    1: 签名指的是类似 md5( sortedString + key ) 的附加请求参数

    248 条回复    2021-04-14 18:54:11 +08:00
    1  2  3  
    screen
        1
    screen   233 天前 via iPhone   ❤️ 4
    大多数攻击来自客户端的截取、伪造而非信息传递中
    xmumiffy
        2
    xmumiffy   233 天前 via Android   ❤️ 4
    是没必要
    dzdh
        3
    dzdh   233 天前
    @screen 如果 SSLPinning 无效的话,那客户端用『签名』也一样能截取啊
    dzdh
        4
    dzdh   233 天前
    @xmumiffy 国内大厂是出于什么样的考量呢?
    iyaozhen
        5
    iyaozhen   233 天前   ❤️ 1
    签名我记得是两边约定一个 token,把参数和 token 签一下,更安全

    一般用在开放接口上吧,就是接口参数大家都知道,你别的地方不小心泄露参数了,就有风险
    xmumiffy
        6
    xmumiffy   233 天前 via Android
    @dzdh 十年前 http 年代我们是这么做的 现在也没必要改
    des
        7
    des   233 天前   ❤️ 1
    我猜测可能是这几个原因
    一是方便用 http,http 也方便调试
    二是即使是服务端对服务端,走的是统一的网关,不想再搞一个域名
    三是不少人对 https 认识不那么够,不会搞证书认证,毕竟资料也少,相对于签名
    dzdh
        8
    dzdh   233 天前
    @des

    1 理解
    2 网关统一 HTTPS 不是更简单了么都不用再配置啥
    3 emmmm 理解
    momocraft
        9
    momocraft   233 天前   ❤️ 2
    签名虽然现在看觉得傻 十年前不失为一个 http 下能加密+防重放攻击的方案

    另外市场地位不一样 要是 stripe 敢像企鹅这样一个 QR 码写出不到十种 API 可能活不到上市
    akira
        10
    akira   233 天前   ❤️ 2
    你要这么说的话,服务端对服务端 http 就够了,ssl 都不需要上
    ihipop
        11
    ihipop   233 天前 via Android   ❤️ 1
    现在很多方案是前端 HTTPS 网关后面业务系统是 HTTP,如果做使用客户端做 SSL 认证,整个系统都需要要改造,不可能业务系统身份认证全做网关上吧? SSL 只 pin 服务端的证书没法验证客户身份,签名不仅仅可以防篡改,还能客户做身份认证
    dzdh
        12
    dzdh   232 天前
    @ihipop 还好吧,客户端证书在网关直接验证好的,到后面的 HTTP 业务的时候直接带着 https_s|c_xx 的 header 头的哇而且还伪造不了
    dzdh
        13
    dzdh   232 天前
    @ihipop 不是老系统改造,是新系统
    wooyuntest
        14
    wooyuntest   232 天前   ❤️ 1
    加大直接构造数据向接口发请求的难度(还得逆向 app 拿到签名算法)
    dzdh
        15
    dzdh   232 天前
    @wooyuntest 找密钥吧。这是客户端场景了,即便如此,仅使用 HTTPS 直接传递 ukey 的话也得逆向啊。
    HOOK 方案的话无论任何方案都没辙吧。
    kejialiu
        16
    kejialiu   232 天前 via Android   ❤️ 1
    签名是一次性的,只针对这个请求,就算被截获了也伤害不大。密钥不管什么原因被泄露了,后续所有请求都可以伪造,所以能不暴露就不暴露,哪怕是加密通道
    dzdh
        17
    dzdh   232 天前
    @kejialiu

    一次性的根本原因是因为有 nonce 。以此为目的达到防 Replay Attack 。

    但是究其根本,HTTPS 本身被抓到已有也是个无法篡改的普通 TCP 数据包。重放攻击也只能将这个数据包无数次发送给对方服务器。也就是说,只要在普通的请求参数中加入任意一个具备 nonce 特性的参数如 timestamp,那这个数据包依然可以被直接拦截。

    同时,如果说 HTTPS 不用构造直接可以无限次任意请求的话,签名模式难道就不是吗?
    dzdh
        18
    dzdh   232 天前
    @kejialiu

    即便没有 nonce 。如 http://domain/path?order_id=x&sign=n 。是的没错,这个请求无法被篡改,但是我依然可以肆无忌惮的发起查询啊。

    而且肯定是要有一个『某 ID 』的参数吧?如商户 ID 、用户 ID 等标记唯一应用的参数吧。那也就是说,只是某一个『用户』或『应用』能构造针对特性对象『 order_id=x 』的请求。

    那相应的,HTTPS 的话直接作为 Authentication Header 参数放进来一样的哇。
    Vegetable
        19
    Vegetable   232 天前   ❤️ 1
    这个有历史的惯性原因吧,大家都有签名,我这没签名显得不安全。

    另一个可能是,对于在网络请求中传递密钥的恐惧?我这两天正在设计一个 s2s 接口,也非常纠结到底要不要做签名
    ch2
        20
    ch2   232 天前 via iPhone   ❤️ 1
    过滤掉不会签名的傻子,仅此而已
    crab
        21
    crab   232 天前   ❤️ 1
    防中间人也要防客户
    skull
        22
    skull   232 天前 via Android   ❤️ 2
    瞎回答一下,服务端对服务端是理论场景,放出去的 api 不敢保证对方也是服务端
    ferock
        23
    ferock   232 天前 via iPhone   ❤️ 1
    防御的场景不同
    wanguorui123
        24
    wanguorui123   232 天前 via iPhone   ❤️ 1
    AppKey 安全的前提下,签名的过期时间戳有一定防止重放的功能,HTTP 下可以额外防止数据篡改,HTTPS 下除了对过期时间的验证好像没什么用
    dzdh
        25
    dzdh   232 天前
    @Vegetable 签名机制完全没必要,安全及重放等攻击的防止是靠接口逻辑设计的,不是靠签名的。
    dzdh
        26
    dzdh   232 天前
    @crab Pinned Pub Key 还怎么中间人呢?防止客户的什么呢?
    dzdh
        27
    dzdh   232 天前
    @skull 对方不是服务端能怎样呢?
    dzdh
        28
    dzdh   232 天前
    @ferock 比如?
    dzdh
        29
    dzdh   232 天前
    @wanguorui123

    参见 18 楼。

    如 http://domain/path?order_id=x&sign=n 。是的没错,这个请求无法被篡改。

    我可以直接不停的直接请求,这就是重放攻击对吧?那就单单是『签名』是怎么防止重放攻击的呢?难道不是 API 的露酒设计来检测 order_id 的请求次数么?或者 sign 的请求次数么?无论是否是签名都需要做这一步啊?
    dzdh
        30
    dzdh   232 天前
    @dzdh 漏酒 => 逻辑。

    我一直怀疑我的键盘坏了 ...
    ferock
        31
    ferock   232 天前 via iPhone
    @dzdh #28

    楼上不是很多人都说了吗?
    ssl 防御的是中间人攻击
    而签名是防御:非授权客户的额外请求

    不是一个场景
    wanguorui123
        32
    wanguorui123   232 天前
    @dzdh xxx&timestarp=xxx,timestarp 就是时间戳,通过判断过期时间和上次请求的时间戳过滤请求
    yukiww233
        33
    yukiww233   232 天前
    1 签名会把时间戳签进去;
    2 签名不能完全避免, 只是增加了一层破解客户端的难度
    3 没看懂你那段"业务逻辑"是怎么防止重放的, key 是 server 返回的, 那直接重放 server 返回 key 的请求呢?
    pkoukk
        34
    pkoukk   232 天前
    提高伪造消息的门槛啊。
    作为码农肯定都干过 F12 查 api 地址参数,然后假冒浏览器调用 api 的行为。
    有了签名就得逆向代码找到签名逻辑,如果没有签名就直接拿来用了
    dzdh
        35
    dzdh   232 天前
    @yukiww233 33
    @wanguorui123 32
    我接受请求啊,因为你的 KEY 是合法的啊( stripe 的 user)。

    但是针对某一个资源的操作如 x_id=N,只要我接口保持幂等,无所谓重放不重放吧?对实际业务 0 损失啊?即便有签名,也只是根据 timestamp 和当前服务器时间的差值决定是否拒绝请求,但是请求依然进来了啊。
    dzdh
        36
    dzdh   232 天前
    @ferock

    这个『授权』是怎么定义呢?签名怎么体现『授权』呢?客户端证书是否也能实现呢?
    dzdh
        37
    dzdh   232 天前
    @pkoukk
    注意场景 Server 端到 Server 端。没有浏览器。
    即便有客户端的场景,哪个浏览器端的接口设计是有签名的请赐教
    dzdh
        38
    dzdh   232 天前
    @yukiww233 32

    key 是 被调用方 分配 /颁发给 调用方,或调用方主动在被调用方处登记注册的。如帐号密码
    wanguorui123
        39
    wanguorui123   232 天前
    @dzdh 1 、有些时候需要防止重复下单,通过 timestarp 验证是否和上次相同来避免、2 、有些时候防止文件被盗链,这时候通过 timestarp 的过期时间来验证是否是过期资源,防止迅雷等工具盗刷流量
    dzdh
        40
    dzdh   232 天前
    @wanguorui123 39
    理解。但是:

    > 注意场景是 Server To Server

    1. API 的接口设计的逻辑是否可以要求下单的时候带上一个发起方的 ID 呢?这个 ID 不就是个 nonce 么?根据这个 ID 也可以防止某个内部服务重复下单啊(注意场景是 Server 端到 Server 端,如 stripe 、paypal 、支付宝、微信的预下单接口)

    2. 是否可以直接生成一个加密 token 在 token 里直接绑定 ip 、时间戳,然后这个 token 一次有效呢?只能由 openssl 解密(是的,没有仅仅只依靠 HTTPS )

    我指的签名仅仅指的是:按照规则排序然后拼字符串使用 shaX/mdX 的形式
    wanguorui123
        41
    wanguorui123   232 天前
    @dzdh 其实不考虑特殊情况,携带 Token 或者 Session 加 HTTPS 已经足够安全了
    wy315700
        42
    wy315700   232 天前
    其实写程序的时候,你永远要考虑对面那端的傻逼行为,要在对方傻逼的时候依然尽可能的保证程序接口可用性。
    楼主这么想一想,就知道为啥一些接口会有奇奇怪怪的设计了。


    你可能觉得 server to server 加上 标准化的 HTTPS 是一个安全的协议。。

    但是如果对面不是 server 呢,直接把接口写到客户端了呢,有见过直接客户端直接连接远程 MySQL 的程序。
    再或者是,有人嫌麻烦,HTTPS 关闭了证书验证呢,据了解这么做的不在少数。
    keyfunc
        43
    keyfunc   232 天前
    首先,你不能保证 ssl 隧道肯定安全,密钥泄漏,使用了不安全的密码套件等都会导致 ssl 存在安全漏洞。
    签名挑战机制足够简单,越简单的方法越安全。
    newmlp
        44
    newmlp   232 天前
    tls 只能保证端和端之间是安全的,如果客户端不安全你用 https 没啥用,加个自己的签名可以增加反编译的难度
    crab
        45
    crab   232 天前
    @dzdh 我是说 ssl/tls 防中间人,多个签名防使用者客户。
    wentx
        46
    wentx   232 天前
    这个应该是取决于对安全性的要求,像 stripe 这用了 HTTPS + 请求 Sign 的 API 应该就是双重保障,毕竟都是跟钱相关的,如果某个用户的本地被加了一层类似于 Charles 的 HTTPS 代理,那它还可以通过 API 签名来防一手的.
    David1119
        47
    David1119   232 天前
    主要不是为了安全,是为了反爬好吗,防止用户把数据都爬走,大部分都是 so 加密算法,增加客户端破解难度
    timedivision
        48
    timedivision   232 天前
    安全没有绝对的,为了更安全,谁都愿意多加几道锁就好比我把钱放保险柜里,我保险柜不还得放家里吗?难道我把保险柜放外面?
    kejialiu
        49
    kejialiu   232 天前
    @dzdh 一个设计合理的请求签名算法中,所有有含义的请求参数都是被签名的对象,任何参数的修改都会导致签名失效,所以被拦截了也就只能重放那一个特定请求而已。更别说还有时间戳限制有效时间。总体原则就是,如果拦截不可避免,也要把损失降到最小
    borisz
        50
    borisz   232 天前
    防抵赖
    kejialiu
        51
    kejialiu   232 天前 via Android
    安全从来都是相对的,一般我们是可以认为 https 是可以防中间人的,但这也是有前提的:
    - https 服务端的密钥是怎么管理的,都有谁经手了,不小心泄露了呢?
    - 浏览器这样的客户端是否可信任呢?里面会不会装了莫名其妙的插件钩子呢?
    - 签发 https 证书的 CA 是不是足够可信任呢?

    根据你的应用的敏感级别,这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1,意思就是你总是要多做一层防护,让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
    borisz
        52
    borisz   232 天前
    https 只能表示传输的数据时正确的, 但是能保证传输的数据对于系统时无害的,

    例如平台内部用户伪造支付请求, 或者内部大量无效请求, 测试需求发送到业务服务器.
    Telegram
        53
    Telegram   232 天前   ❤️ 1
    这是概念混淆啊,照你意思是用了 https,用户就不需要账号密码了?
    no1xsyzy
        54
    no1xsyzy   232 天前
    SSL/TLS 不能确定对方是否对你的证书进行了验证。
    双边证书使用相对麻烦。
    然后还有遗留问题和习惯问题。
    VHacker1989
        55
    VHacker1989   232 天前
    任何客户端做的校验都是多此一举,逆向,动态调试,xposed hook 都能破解和获得密钥,因为客户端完全掌握在用户手里
    Marinaaaa
        56
    Marinaaaa   232 天前
    给不怀好意的人增加更多破解成本。如
    Marinaaaa
        57
    Marinaaaa   232 天前
    如果是服务端对服务端,且都是内部系统,内网访问的话,感觉没太必要。如果非内网访问的话可能还是有点风险吧
    hxndg
        58
    hxndg   232 天前   ❤️ 1
    只能说明两个现象:
    1 很多人对于 TLS 的理解是一知半解的,TLS 本身是非常灵活的,可以根据需求变更 auth/enc/verify 等功能,好多人只知道个 enc 就完了,建议重新研读下 RFC,上面的回复里面有明显的错误。
    2 TLS 层安全开发做的不到位,很多的功能原本是明文的,为了一些安全的功能采用了打补丁的方式,而 TLS 加入以后处于兼容性功能或其他方面考虑没能去掉这些补丁。 毕竟国内做业务的和我们这些做基础服务的关注的点不同。
    walpurgis
        59
    walpurgis   232 天前 via Android
    @Telegram 因为传输层可以保证安全的话,密码可以直接明文传了,不需要将密码再套一层 HMAC 了
    3dwelcome
        60
    3dwelcome   232 天前
    "Pinned Pub Key 还怎么中间人呢?防止客户的什么呢?"

    能做到这种验证毕竟是少数,大部分服务器就校验了一下对方 CERT 有效性,因为 CERT 会过期,客户定期会换,你又没办法一直保证服务器存有对方最新的 KEY 和 CERT 来校验。

    而且我看所有有钱有关的网络支付,都带签名。

    这其实和数据库是不是存用户明文密码是同一个问题:反正用户又看不到服务器上具体有什么,不存 hash,直接存明文是不是一样的?(学一下楼主额外描述:服务器不可能被攻破,因此黑客攻击不在考虑范围内)
    hxndg
        61
    hxndg   232 天前
    @Marinaaaa 内网访问没有必要这个目前已经被认为是错误的了。

    @no1xsyzy 你的证书是谁的证书? TLS server 端还是 client 端?

    @Telegram 用户名和密码是保护什么?签名是保护什么?
    @borisz 所以签名能保证数据对系统无害?
    hxndg
        62
    hxndg   232 天前
    @3dwelcome
    那东西叫做公钥钉扎,防备中间人,已经废除了。
    此外
    签名和数据库存储明文密码根本不是一个概念,每个步骤都是有其基本目的的,签名是用来防抵赖,抗修改+重放的
    数据库不能存储明文用 hash 是对抗内部攻击,泄漏的
    3dwelcome
        63
    3dwelcome   232 天前   ❤️ 1
    @hxndg
    "那东西叫做公钥钉扎,防备中间人,已经废除了。"
    不不,楼主说的是 Server to Server 上的 PubKey 验证,就是直接在 TLS 握手阶段,读取证书里的 pubkey,看是不是和数据库里的一致,服务器要额外写一些入侵式代码。

    你说的废除,只是 chrome 浏览器里定下的规范。楼主这里没有浏览器的参与。
    xuanbg
        64
    xuanbg   232 天前
    SSL 是可以保证数据传输的安全,但也仅仅是保证数据传输过程安全而已。数据在传输前是不是伪造的?这个 SSL 可没法保证。
    hxndg
        65
    hxndg   232 天前
    @3dwelcome

    1 首先公钥钉扎,或者说公钥固定( whatever )不单纯针对浏览器,任何涉及到 TLS 的都会做,我们实现了钉扎,但是国内没人用,最后没进正式 build,代码被废除了。国内没有一个运营商采用这东西,几大银行更是提都不提。
    2 chrome 废除了这个确实,这点我确实说错了。
    AlisaDestiny
        66
    AlisaDestiny   232 天前   ❤️ 1
    其实这就像登录密码和支付密码,登录密码只能确定付款方身份是你,但这并不代表这次的支付请求是由你本人发起(比如你室友趁你睡觉的时候拿你手机给自己转账),所以需要你输入支付密码确认。
    dzdh
        67
    dzdh   232 天前
    @newmlp 如果客户端不安全『签名机制』也没啥用,这个理由不成立
    dzdh
        68
    dzdh   232 天前
    @AlisaDestiny 这个场景『签名机制』也没用,因为如果『支付密码』你泄露了呢?安全上两个方案一样的,甚至不如 HTTPS
    dzdh
        69
    dzdh   232 天前
    @xuanbg HTTPS 能够保证传输安全已经足够了,真正的 API 请求安全(身份鉴别)不是依靠其传递的参数实现的吗?直接 HTTPS+HTTP Authenctication 一样的啊?
    dzdh
        70
    dzdh   232 天前
    @3dwelcome 63

    对的,只是 Chrome 废除而已,无论是 Server 端还是 Client 端,只要你验证,依然是可以进行服务端身份鉴别的啊
    dzdh
        71
    dzdh   232 天前
    @Telegram
    几楼或者哪句话有『不需要账号密码』的意思,请指出。
    dzdh
        72
    dzdh   232 天前
    @keyfunc 43

    密钥泄露和签名所用的密钥泄露是同等效的,那同样也不能证明『签名机制』的安全。该理由不成立
    dzdh
        73
    dzdh   232 天前
    @newmlp 44

    同理可证明,如果客户端不安全(如『签名模式』的密钥摆在明面上),那『签名机制』远没有『 HTTPS 』安全。该理由不成立。
    dzdh
        74
    dzdh   232 天前
    @wentx 46

    Charles 是依靠『中间人』来进行抓包的。

    其次,如果真的使用 Charles,那是不是就意味着其已经控制了『物理机』?在控制『物理机』的前提下还有什么安全方案是可以保证『全安』的吗? 并不能证明 HTTPS 环境下,签名模式的『必要性』
    dzdh
        75
    dzdh   232 天前
    @David1119 47

    接口设计要求 CleintID,爬虫场景完全可以屏蔽 ClientID 。

    其次,标题是 Server 端到 Server 端。即便是用户不小心暴露 API,依然可以屏蔽 ClientID,中断爬虫行为。该理由不成立。
    dzdh
        76
    dzdh   232 天前
    @timedivision 48

    请阐明就目前技术手段方案中,HTTPS 前提下,签名模式的『必要性』
    dzdh
        77
    dzdh   232 天前
    @kejialiu 49

    比如?

    比如下单场景,可以要求调用方生成唯一『请求号』,在接口设计逻辑上可以进行规避。

    有没有什么场景是『无法』进行规避的?
    dzdh
        78
    dzdh   232 天前
    @kejialiu 51

    HTTPS 防止中间人有 SSLPinning 的方案,足矣无限接近 100%的保障安全(请提出反对意见)

    - https 服务端的密钥是怎么管理的,都有谁经手了,不小心泄露了呢?
    回:签名模式的密钥怎么管理的?都谁经手了,不小心泄露了呢?

    - 浏览器这样的客户端是否可信任呢?里面会不会装了莫名其妙的插件钩子呢?
    回:Server 端到 Server 端,签名模式就能规避『莫名其妙』的钩子是吗?

    - 签发 https 证书的 CA 是不是足够可信任呢?
    回:本地指定 CA 文件验证


    根据你的应用的敏感级别,这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1,意思就是你总是要多做一层防护,让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
    回:所以是 HTTPS 足矣保证安全,仅仅只是为了多加一层兜底手段,对吗?
    dzdh
        79
    dzdh   232 天前
    @borisz 52

    所以 paypal 和 stripe 两个平台是极度危险的是吗?
    dzdh
        80
    dzdh   232 天前
    @no1xsyzy 54

    - SSL/TLS 不能确定对方是否对你的证书进行了验证。
    回: ???

    - 双边证书使用相对麻烦。
    回:签名排序参数使用密钥拼接参数字符串不麻烦吗?

    - 然后还有遗留问题和习惯问题。
    回:如?
    dzdh
        81
    dzdh   232 天前
    @VHacker1989 55

    所以安全就不用做了呗?无论你做任何安全都可以被逆向、动态调试?
    dzdh
        82
    dzdh   232 天前
    @hxndg 有理。
    dzdh
        83
    dzdh   232 天前
    @xuanbg 64

    同理,如果客户端环境安全无法保证的前提下,怎么保证『签名模式』是安全的呢?
    jhdxr
        84
    jhdxr   232 天前
    Server 端到 Server 端 这一点是如何保证的?就是说,我提供了一个接口,我预期对方应该也是 server 端,但我如何可以保证这一点?
    dzdh
        85
    dzdh   232 天前
    @jhdxr

    在思考这一点之前,先思考如何保证『签名模式』下对方一定也是 Server 端。

    我的接口是为了 Server 端调用而设计,客户错误使用暴露出去,屏蔽 ClientID (调用凭证)即可
    ashuai
        86
    ashuai   232 天前
    https 能保证信息的完整传输吗?

    例如我给服务器发 123456,因为网络抖动,结果服务器有可能只收到 1234

    有以上可能吗?如果有,这就是签名的意义
    newmlp
        87
    newmlp   232 天前
    @dzdh 你没看到我说的是增加反编译难度吗
    newmlp
        88
    newmlp   232 天前
    @dzdh Xposed+JustTrustMe 就可以破解证书固定,so easy
    abersheeran
        89
    abersheeran   232 天前   ❤️ 1
    把 Token 加入签名内容的签名,可以防止 Token 明文传输。把 Timestamp 加进签名内容可以防重放攻击。

    不过如果依赖于 HTTPS (这里需要注意证书),这两都可以不要。我觉得可能现在还这么做的大厂,惯性更多一点吧,毕竟代码已经写好了,可以跑了,改设计,没必要。
    3dwelcome
        90
    3dwelcome   232 天前
    "所有人的质疑是否代表着 Stripe 和 Paypal 现在是极度危险状态?"

    你用国外网站举例没意义,国外信用卡支付没密码是安全的,放国内基本不可能。

    同理国外电子支付没有签名是安全的,国内设计的 API 没签名?想都别想,和钱有关的,必须加码,管他有没有用。

    这和软件加壳一个道理,你不知道破解者的能力和权限(说不定就是你隔壁同事),越套一层防范,单纯从理论上来说,就能阻断一部分破解者的尝试,也就变相代表着越安全。

    就安全系数来说,有签名的 API 和没签名的 API PK 一下,有签名的得分高。光刷公司的 KPI,也必须加。
    3dwelcome
        91
    3dwelcome   232 天前
    @abersheeran “我觉得可能现在还这么做的大厂,惯性更多一点吧,毕竟代码已经写好了,可以跑了,改设计,没必要。”

    为了支付系统上出 BUG 可以甩锅,小码农根本赔不起。“看,API 设计够好了,还有签名!”
    LeeReamond
        92
    LeeReamond   232 天前
    @akira 显然不对,tcp 只保证连接可靠,不保证数据可靠,单纯 http 肯定是有缺陷的,居然还有两个人点赞
    LeeReamond
        93
    LeeReamond   232 天前
    @dzdh 必要性是没有,但应该也没有非必要性。很难有 api 在设计层面说脱离开 tls 我干脆就禁用,大部分是保留支持能力的,那如果已经写好了逻辑,就没有删除的理由。哈希算法成本很低,hs256 也仅在百纳秒的数量级,而不以抗哈希攻击为目的的快速哈希可以做到远更快
    timedivision
        94
    timedivision   232 天前   ❤️ 1
    @dzdh 所以为了更安全,任何提高安全性的手段都是必要的呀
    dzdh
        95
    dzdh   232 天前
    @ashuai 86

    "有以上可能吗?如果有,这就是签名的意义"

    没可能
    dzdh
        96
    dzdh   232 天前
    @newmlp 88

    > Server 端到 Server 端。

    同理,HOOK 也可以轻松拿到用于『签名模式』的签名密钥,so easy~
    dzdh
        97
    dzdh   232 天前
    @3dwelcome 90

    > 管他有没有用
    所以并不是出于安全考虑,就是为了『加』而『加』?

    > 你用国外网站举例没意义,国外信用卡支付没密码是安全的,放国内基本不可能
    公共网络的、任何人都可以进行调用的、处于公网环境的 HTTPS 接口,甚至有详细的文档。为什么他就『安全』呢?支付宝接口如果不用『签名』设计就『不安全』了?比如如果支付宝现在开始不用签名了,会导致什么问题呢?包括但不限于下单、退款、关闭订单、转账等接口,就直接像 stripe 一样 `curl -u $key https://api.alipay.com/api/transfer?to=xxx&amount=1000` 。
    dzdh
        98
    dzdh   232 天前
    @3dwelcome 91

    如果有签名的时候被黑了呢,接口 bug 了呢 这不是一样吗
    dzdh
        99
    dzdh   232 天前
    @timedivision

    所以是,仅仅 HTTPS 已经足够安全,所谓签名只是锦上添花?
    catchexception
        100
    catchexception   232 天前   ❤️ 1
    大多数回答都不在点子上。一个是传输层,一个是业务层。
    1  2  3  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2629 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 12:28 · PVG 20:28 · LAX 04:28 · JFK 07:28
    ♥ Do have faith in what you're doing.