In RISKS-21.84, Jeffrey Mogul ("When a 'secure site' isn't") points to some
"secure" sites which fail to properly implement https secure protocols.
In an incident from two years ago, my employer required use of an online
form which required credit-card info for cards which were billed to
employees. This "secure site" was provided by an external supplier.
Naturally I checked for https use and browser "lock" icons.
All went well until the final confirmation screen. In addition to the
"you have ordered zzzzz with credit card yyyyyy" expected, imagine my
surprise when I noticed that the URL of the page contained ALL of my
information:
"https://securesite.com/verification.htm?name=3Dyyyyyy,CardNumber=3D12345=
6789,ExpirationDate=3D12/31/2001" etc.
Being part of the URL "address", this information (including my name,
address, credit card number, and expiration date) was not protected,
even though the page was sent using "https".
A discreet call to the webmaster for this site provided a quick reply --
that all was okay, and all pages were sent using "https".
A second call (and a CC to a very-high-ranking IT manager) explaining
the difference between "PUT" and "GET" in forms processing produced a
fix -- and an apology.
Moral: Even when the technology is secure, people can still blunder
around it. The analogy which was effective in this case was talking to
their IT engineers about the US postal system -- and pointing out that
writing information on the outside of an envelope isn't secure even if
the envelope itself is protected. ["Skip La Fetra" via risks-digest Volume 21, Issue 86]
0:00
#
G!
