5 ms·

> a random decision by Google What do you think is a random decision? > However i think that sites should make decisions on their configuration It's OK when

> a random decision by Google What do you think is a random decision? > However i think that sites should make decisions on their configuration It's OK when they have ideas what they are doing, but that's not always the case. Before my trip to Kaua'i I googled some dive shops on the island to book a scuba diving trip. Every dive shops on the island seems to be using the same vendor to process online order of the reservation, which has the same form to input credit card number, and has some text around it saying "it's secure". They are not secure. They are on HTTP: https://twitter.com/fishywang/status/895133987525476354 https://twitter.com/fishywang/status/895133987525476354

heywire 9y ago
Wow. Unless this was some accidental configuration issue, this is inexcusable.
slobotron 9y ago
Those forms sit in an IFRAME and content is loaded via https. Example from http://seasportdivers.com/ http://seasportdivers.com/ : <iframe src="https://fareharbor.com/embeds/book/seasportdivers/?full-items=yes&u=1c09ae92-71c7-438e-97a3-361bdd69f77e&from-ssl=no"...> https://fareharbor.com/embeds/book/seasportdivers/?full-item...
- eropple 9y ago
  That's not sufficient when the external page can be controlled and the iframe target set by it.
  - slobotron 9y ago
    Agreed that in situation like this it's near impossible to ascertain that iframe target wasn't altered, unless you already somehow know what it was before you got mitmd.
- fiddlerwoaroof 9y ago
  Yeah, that’s a little better but can’t an attacker inject something in the surrounding the age that compromises the iframe? Or even rewrite the iframe to use a proxy under the attackers control?
- fishywang 9y ago
  Maybe the vendor improved since then (it's still not very secure as others and Chrome pointed out), but I remembered that back last Aug I searched for "https" in the source code and that's not the case.
  - slobotron 9y ago
    Even now it doesn't inspire much confidence :)

heywire 9y ago

Wow. Unless this was some accidental configuration issue, this is inexcusable.

slobotron 9y ago

Those forms sit in an IFRAME and content is loaded via https. Example from http://seasportdivers.com/ http://seasportdivers.com/ : <iframe src="https://fareharbor.com/embeds/book/seasportdivers/?full-items=yes&u=1c09ae92-71c7-438e-97a3-361bdd69f77e&from-ssl=no"...> https://fareharbor.com/embeds/book/seasportdivers/?full-item...

eropple 9y ago
That's not sufficient when the external page can be controlled and the iframe target set by it.
- slobotron 9y ago
  Agreed that in situation like this it's near impossible to ascertain that iframe target wasn't altered, unless you already somehow know what it was before you got mitmd.
fiddlerwoaroof 9y ago
Yeah, that’s a little better but can’t an attacker inject something in the surrounding the age that compromises the iframe? Or even rewrite the iframe to use a proxy under the attackers control?
fishywang 9y ago
Maybe the vendor improved since then (it's still not very secure as others and Chrome pointed out), but I remembered that back last Aug I searched for "https" in the source code and that's not the case.
- slobotron 9y ago
  Even now it doesn't inspire much confidence :)