Next month I’m going to be attending a wedding at Garland Resort in Michigan’s northern Lower Peninsula. When reserving a hotel room there I noticed that not only was the reservation system using plain old http, the form which accepts a credit card number is insecure. It then again uses HTTP when submitting the form:
<form name='frmRes1' method='post' Action='CCard1.asp?IRM=yes&BtrvID=4249' onSubmit='return NextPage()'>
Here’s an excerpt from a network capture of me submitting a page full of garbage info:
POST http://65.123.67.67/irm/CCard1.asp?IRM=yes&BtrvID=4249 HTTP/1.1\r\n
Line-based text data: application/x-www-form-urlencoded
[truncated] firstname=Test&phone1=987-555-1212&lastname=User&phone2=&address1=12345+No+Street&sob=WI&address2=&ccname=AMEX&city=Default&ccnum=1234567812345678&state=AZ&ccexp=01%2F12&zip=99901&cardid=555&country=&email=test%40example.com&pa
See that last line there? In case you don’t know, the & sign delineates the fields, and it’s a simple valuename=value pair. Therefore, ccnum=1234567812345678 is the garbage credit card number I submitted, cardid is the CVV2, ccexp is the expiration date, etc. This is very definitely not PCI compliant and is a thief’s dream if the victim were submitting this form across a sniffable public network.
Suffice to say, I phoned in my reservation. This is obviously not an ideal solution either, but at least I didn’t use that crap.
Leave a Comment