11–20 of 84 posts
https://www.owasp.org/index.php/Cross_Frame_Scripting
> Every key press the browser user makes in the example.com frame, while trying to log into example.com, can be captured by the attacker, and reported back to evil.com.
But this is irrelevant - user can't verify if the domain of the iframe is trusted. If the attacker can modify the parent frame javascript he can just replace the iframe with a phishing page.
Iframes can leak key presses to an evil parent frame: https://www.owasp.org/index.php/Cross_Frame_Scripting > Every key press the browser user makes in the example.com frame, while trying to log into example.com, can be captured by the attacker, and reported back to evil.com. But this is irrelevant - user can't verify if the domain of the iframe is trusted. If the attacker can modify the parent frame javascript he ca…
> one of the basic principles of security is to avoid trusting people unnecessarily And asking customers to enter their CC details on your domain doesn't break this rule? > a form will be submitted to your server with a stripe_token for you to process I'm assuming it just sends the Stripe token, and not CC info? If it does send CC info, I assume it's compliant with all the laws and regulations in every country?
asking customers to enter their CC details on your page doesn't break this rule? It doesn't break that rule for me. It is a reason why other Stripe users might want to think twice before using the iframe I host, of course. I'm assuming it just sends the Stripe token, and not CC info? Yes.
Well that's the point really. You say that a "basic principle of security" is to "avoid trusting people unnecessarily" which is exactly what this service you have created is asking people to do.
Earlier quoted context omitted.
asking customers to enter their CC details on your page doesn't break this rule? It doesn't break that rule for me. It is a reason why other Stripe users might want to think twice before using the iframe I host, of course. I'm assuming it just sends the Stripe token, and not CC info? Yes.
> It is a reason why other Stripe users might want to think twice before using the iframe I host, of course. Well that's the point really. You say that a "basic principle of security" is to "avoid trusting people unnecessarily" which is exactly what this service you have created is asking people to do.
Earlier quoted context omitted.
> It is a reason why other Stripe users might want to think twice before using the iframe I host, of course. Well that's the point really. You say that a "basic principle of security" is to "avoid trusting people unnecessarily" which is exactly what this service you have created is asking people to do.
I'm not asking anyone to use this, just making it available to people who want it and showing off a concept which people can re-implement themselves.
I love Stripe, I love people hacking and creating new cool things but an emerging trend I'm seeing with Stripe is that people are really not taking the security of the CC numbers their customers have entrusted to them as cautiously and as securely as they should.
Earlier quoted context omitted.
I'm not asking anyone to use this, just making it available to people who want it and showing off a concept which people can re-implement themselves.
Do you not think the way you have presented it is encouraging people to use it? I love Stripe, I love people hacking and creating new cool things but an emerging trend I'm seeing with Stripe is that people are really not taking the security of the CC numbers their customers have entrusted to them as cautiously and as securely as they should.
I'm trusting people to decide which risks they want to take -- I'm providing tools, not dictating policy.
Earlier quoted context omitted.
Do you not think the way you have presented it is encouraging people to use it? I love Stripe, I love people hacking and creating new cool things but an emerging trend I'm seeing with Stripe is that people are really not taking the security of the CC numbers their customers have entrusted to them as cautiously and as securely as they should.
It's available for people to use if they want, sure. I expect Stripe to offer a similar service soon too (at which point that issue goes away, since people are already trusting Stripe with their card details). I'm trusting people to decide which risks they want to take -- I'm providing tools, not dictating policy.
The change for that paymentiframe.com get comprimised I see is way higher, than Stripe is getting comprimised.