undefined | Better HN

0 pointschatmasta10y ago0 comments

I've seen DOM manipulation in the wild for other purposes (e.g. clickjacking for sending invites to friends). Beyond that, mostly speculation, yes. But there's nothing preventing the DOM hijacking from grabbing the password right out of the <input> field. (Unless there's some HTML5 permissions on those fields that I'm unaware of, certainly possible).

0 comments

3 comments · 1 top-level

supergeek13310y ago· 2 in thread

The other thing here IMO is if I'm a bank, and I have a 3rd party app making OAuth requests... I'll want to verify code before mass release. Or at least limit the amount of bearer tokens issued without approval (Nest does this for example).

Someone should internally want to review code, especially for a bank.

chatmastaOP10y ago

As a bank, if you provide an SDK for 3rd party developers to use, you are not in a position to review the app before release. Only Apple/Google gets to see that code.

The proper solution would be either 1) the ability to register 3rd party libraries with apple and require some kind of integrity check before approval (but even then, the 3rd party app could override library methods at runtime), or 2) code signing the binary blob library separately for every 3rd party developer (but then the problem is enforcement of where developers get the library from -- how do you verify SDK integrity from the bank server side?)

The fundamental problem is that, as soon as you give 3rd party developers the ability to natively integrate with your service via an SDK in their own app, you are playing a cat and mouse game.

supergeek13310y ago

It depends if that SDK has an API key barrier or not. I mean if I'm providing 3rd party access, I want to see how each individual app is performing and what it is doing.

But yes, aside from that potential difference, I understand what you're saying.

1 more reply

j / k navigate · click thread line to collapse