11–20 of 58 posts
My interest is certainly peaked about the 10% off coupons.
And if the obvious, public part of the site is like that, I can only wonder what hackers would find probing deeper.
client-side payments is totally normal, when done right, unlike dominos's's buggy version -- what usually happens is that the vendor sends you to a payment processor, and you pay them, and the payment processor sends a verification token to the vendor , and the vendor delivers your product to you. Domino's skipped one critical step.
I would just add one more critical step: the vendor actually verifies the verification token rather than just checking that it exists (since the token is often passed through the client, it can't be inherently trusted either). This should involve either hitting the processor's server or verifying a cryptographic signature, and verifying that the payment associated with the token matches what the vendor expects.
Why doesn't Google do more to prevent Android apps from being decompiled, inspected and recompiled into modified apps? Yes, there's source code obfuscation, but that only slows down the amateurs.
Why doesn't Google do more to prevent Android apps from being decompiled, inspected and recompiled into modified apps? Yes, there's source code obfuscation, but that only slows down the amateurs.
> Why doesn't Microsoft do more to prevent C# apps from being decompiled, inspected and recompiled into modified apps?
There's not much you can do when you have a very simple interpreted language (or JITed). Take C for example. Sure, you can take the outputted assembly and turn it into something readable, but because it's been optimized, it's not easy to figure out what it means. C# and Java OTOH compile down to a very simple set of assembly instructions. AFAIK, "stack variables" aren't reused as each variable is referenced by its index. If you were to take the JITed output from CIL or Java bytecode, making something readable would be hard.
My interest is certainly peaked about the 10% off coupons.
The word you are looking for is piqued.
My interest is certainly peaked about the 10% off coupons.
Always 25% off with PapaJohns! Use coupon code 25OFF — it's even valid until December 31, 2017. Unless you mean how they're generated.
Most payment gateway have a security mechanism to ensure the response from payment server have its integrity remain intact. Most of the time by hashing some combination of responses value and shared secret key between merchant and the payment server, and comparing if both marchant calculated value and payment server hash matches. If it doesn't match, then it is safe to to throw an error and prompt appropriate message to said attacker. When implemented as such, the system are expected to immune to such attack as described by the author.
The article is a perfect case study to showcase the consequences when the developer decided to skip the security part. (yes it's entirely up to the web master if they want this or not, the payment server won't care).
Why doesn't Google do more to prevent Android apps from being decompiled, inspected and recompiled into modified apps? Yes, there's source code obfuscation, but that only slows down the amateurs.
It's not that processing payment client-side is wrong, it's that the Dominos app implement it wrongly, or DataCash simply doesn't provide any security feature for protecting against http request data tampering, which I believe the latter is not the case. Most payment gateway have a security mechanism to ensure the response from payment server have its integrity remain intact. Most of the time by hashing some combinat…
I've definitely seen SSL pinning used to this effect. The simple solution to Dominos' problems seems like a server-verifiable transaction token that coming from DataCash (or whatever gateway service). I agree that client-side payment processing isn't wrong -- in fact, it makes more sense than attempting PCI compliance on their middleman server.