4 ms·

I'm always nervous about 3rd party API wrappers. It's basically saying "Here's the keys to my (users) Google account, please don't do anything bad". Even if it'

I'm always nervous about 3rd party API wrappers. It's basically saying "Here's the keys to my (users) Google account, please don't do anything bad". Even if it's open source, there's no guarantee there's no malicious change in version x.x.N+1

sieabahlpark 5y ago
You could just pin to a version like a good dev and rid yourself of the problem. Just do a quick diff check when you upgrade. If you're too lazy to do that then you never really cared about security all that much in the first place.
- Firmwarrior 5y ago
  WHAT? How am I supposed to make a social media calculator flashlight app without pulling in 200 random libraries and their 5000 dependencies?
- Aachen 5y ago
  > just pin to a version like a good dev Good devs don't keep up with dependencies' security updates or was this meant ironically? Also, you'd have to pin to a hash, I imagine. Changing the version tag and pushing with -f doesn't sound like rocket science for someone with malice in mind. Next time you deploy it, you'll still get that code.
chmod775 5y ago
Any software you use might steal your YouTube credentials. It might be this API wrapper or it might be any other dependency. It might even be the scientific calculator you installed that had nothing to do with that project. What makes this especially scary?
- trinovantes 5y ago
  Technically nothing can be trusted e.g. can anyone trust their silicon, wires, device drivers, compilers, OS, routers, SSL CAs, etc.? Trust has to happen at some point. The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located. It's significantly harder for e.g. a webpack developer to insert a backdoor to steal Google credentials since they would have to first determine the code it's processing is handling oauth tokens and then figure out where they are stored. The barrier to entry is the key in assessing your threat model. 3 letter agencies may not care about the cost if the target is valuable but a bored kid on the other side of the world will give up pretty quickly.
  - cmeacham98 5y ago
    > The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located So does all the malware: your browser's cookie store
    - trinovantes 5y ago
      Not every application runs in the browser i.e. not SPA and any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model
      - cmeacham98 5y ago
        > Not every application runs in the browser We're talking about YouTube in this thread. > any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model Where did this random unrelated attack vector come from? We're going talking about running untrusted software on your computer, remember? That's the attack vector we're discussing. Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".
        trinovantes 5y ago
        > We're going talking about running untrusted software on your computer, remember? You are talking about running untrusted software on your computer. This thread is about the "youtubei.js" npm package that is acting as a wrapper around YouTube's API. My point is it's trivial for this developer to add additional code to `youtube.signIn(creds)` that I'm calling vs. any developer of one of my dependency to inject code to steal the same creds. If it's frontend code, their injected code cannot execute beyond mydomain.com. If it's backend code, their injected code would have to guess how my application works. I guess they can trivially dump my env variables but that's about it.
deleted 5y ago
[deleted]

sieabahlpark 5y ago

You could just pin to a version like a good dev and rid yourself of the problem. Just do a quick diff check when you upgrade. If you're too lazy to do that then you never really cared about security all that much in the first place.

Firmwarrior 5y ago
WHAT? How am I supposed to make a social media calculator flashlight app without pulling in 200 random libraries and their 5000 dependencies?
Aachen 5y ago
> just pin to a version like a good dev Good devs don't keep up with dependencies' security updates or was this meant ironically? Also, you'd have to pin to a hash, I imagine. Changing the version tag and pushing with -f doesn't sound like rocket science for someone with malice in mind. Next time you deploy it, you'll still get that code.

chmod775 5y ago

Any software you use might steal your YouTube credentials. It might be this API wrapper or it might be any other dependency. It might even be the scientific calculator you installed that had nothing to do with that project. What makes this especially scary?

trinovantes 5y ago
Technically nothing can be trusted e.g. can anyone trust their silicon, wires, device drivers, compilers, OS, routers, SSL CAs, etc.? Trust has to happen at some point. The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located. It's significantly harder for e.g. a webpack developer to insert a backdoor to steal Google credentials since they would have to first determine the code it's processing is handling oauth tokens and then figure out where they are stored. The barrier to entry is the key in assessing your threat model. 3 letter agencies may not care about the cost if the target is valuable but a bored kid on the other side of the world will give up pretty quickly.
- cmeacham98 5y ago
  > The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located So does all the malware: your browser's cookie store
  - trinovantes 5y ago
    Not every application runs in the browser i.e. not SPA and any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model
    - cmeacham98 5y ago
      > Not every application runs in the browser We're talking about YouTube in this thread. > any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model Where did this random unrelated attack vector come from? We're going talking about running untrusted software on your computer, remember? That's the attack vector we're discussing. Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".
      - trinovantes 5y ago
        > We're going talking about running untrusted software on your computer, remember? You are talking about running untrusted software on your computer. This thread is about the "youtubei.js" npm package that is acting as a wrapper around YouTube's API. My point is it's trivial for this developer to add additional code to `youtube.signIn(creds)` that I'm calling vs. any developer of one of my dependency to inject code to steal the same creds. If it's frontend code, their injected code cannot execute beyond mydomain.com. If it's backend code, their injected code would have to guess how my application works. I guess they can trivially dump my env variables but that's about it.

deleted 5y ago

[deleted]