Southwest Airlines website is a security mess

The homepage for Southwest Airlines loads over plain, unencrypted HTTP, and has form fields to book a flight, check-in, check flight status, change a flight, which all POST to unencrypted HTTP endpoints.

There’s a lot of bad things you can do with a confirmation number and full name. If that’s all Southwest requires to change a flight or check-in and obtain a boarding pass, when someone intercepts your details on a public wi-fi network, they can do a whole lot of damage to your travel plans.

The homepage also has a login form which does POST to HTTPS, but it’s still insecure for reasons covered many times in previous posts: when a form loads over HTTP, modified HTML or malicious JavaScript could be loaded to intercept the data or change the POST destination.

For all this post-9/11 security theater, one would think that a website that issues travel documents would use SSL to begin the issuance of such travel documents. But you would be wrong at Southwest Airlines.

Southwest was shamed three years ago on the FlyerTalk forums for not using SSL in critical areas; nothing appears to have changed. As highlighted in that forum, Southwest has a policy of placing the onus of security on the user, which is all sorts of wrong: 

“Southwest Airlines is not responsible for lost, stolen, or otherwise disclosed passwords. Southwest will not replace points or awards that are generated or redeemed as a result of unauthorized password activity.”

Southwest was then shamed by a security researcher who went to local news stations to report his findings that Southwest’s iPhone app apparently transmits personal information insecurely over HTTP, too. Southwest’s response: zilch. They didn’t return calls to the security researcher for two months, and they didn’t respond to requests for comment from the news station.

When purchasing a ticket on Southwest, the specific flight selection and any disability information is all transmitted over plaintext, unencrypted, unprotected HTTP.

Not to spread fear here, but it’s a well-established fact that individuals with disabilities are often targeted for crimes like theft and sexual abuse. And here, Southwest forces passengers to advertise over insecure and unencrypted HTTP exactly what disabilities they have, what assistance they need, and even if peanuts can kill them – and this is after flight selection, which means there’s a specific date, time, location, and flight number attached:

And to add more more nail to the coffin, Southwest does not let you use any special characters in your password:

I think it’s clear Southwest Airlines has no interest in protecting the security, privacy, and safety of their customers and passengers, and further has no interest in protecting aviation security. There is no reason why an airline website should not be 100% encrypted SSL.

Why we (sadly) resort to public shaming

  • Me: Hi there! Your website collects credit card numbers insecurely. Your payment forms load and POST over unencrypted HTTP. I can't find any email contact information for your company online, and had to dig for your phone number. Can you please fix this?
  • Company: Your information is safe with us! We use bank-level encryption! Do you see the lock?
  • Me: Yeah, I see a lock image you added right next to the credit card field... and the stock photo of the confident woman on her laptop with a credit card in hand. It's still insecure, and your server is not even listening on port 443. Do you have someone who handles security or even general IT that you could connect me to or leave a note for?
  • Company: No but I assure you, we take your security very seriously. Millions of customers use us every day and we've never heard of a problem like this. Have you tried restarting your computer?
  • Me: ...
  • Company: Well, we appreciate your feedback!
  • (Submitted by anonymous)

Mashable is not secure

The website for Mashable allows users to connect with their social media accounts to login and interact. On the surface, it seems good: no passwords being exchanged with Mashable.

However, the entirety of a user’s direct interaction with Mashable is over plaintext, unencrypted HTTP. While a logged-in user browses Mashable’s website on an open or masquerading wi-fi network, an attacker would be able to intercept their name, Mashable username and identifiers, social media identifiers (e.g. Facebook user ID and profile image), and email address – along with any content read or written.

As seen by Wireshark, and as could be seen by anyone on an open wi-fi network:


Mashable lets users add information to their profile: their gender, birthday, ZIP code, and a biography. Not only is that information transmitted insecurely with an HTTP POST, Mashable doesn’t tell their users how they intend to use that information at the point of collection – but a visit to their privacy policy just adds confusion.

The privacy policy summarizes all of this personal information into the vague category “information you give us or information provided through a social network“ which they use “…to provide, maintain, protect and improve our services, to develop new services and offerings and to protect our us and our users…” and to “offer you tailored content like giving you more relevant search results and ads.”

Also, “…comments sections, forums, and other similar areas of our services are public. Any information posted in those areas is viewable and usable by anyone that has access.” — “Similar areas?” Does that apply to date of birth and ZIP code? Well, it doesn’t matter if you’re sitting on a café’s open wi-fi network:


All pages after a user authenticates should be over HTTPS, with the ‘secure’ flag on any user cookies to ensure that the user’s session can’t be hijacked by an attacker on an unprotected network à la Firesheep. But, since authenticated users can access HTTP pages, users visiting Mashable could easily have their cookies intercepted and their sessions hijacked.

And, if a session is hijacked on a site that’s already auth’d to your social network accounts, an attacker will often have the ability to share an article while adding malicious or embarrassing content to the share text, which is then published to the victim’s account. However, despite Mashable requesting the permissions to post on Facebook and Twitter, I couldn’t find anywhere on the site that actually did it without using the Twitter or Facebook JavaScript ‘Tweet’ and ‘Share’ buttons, respectively, which act locally and outside of the OAuth application permission model. (That’s good.)

Now for the final issue comes something that a lot of sites could do better. It’s obscure and probably wouldn’t be worthy of shame on its own – but since we saw it…

Mashable’s login options are on their insecure HTTP homepage in the form of various social media icons which open up OAuth permission pop-ups. In the example of Twitter, a user already logged-in with Twitter would be asked if they want to grant Mashable permission – but if the user is not logged into Twitter, they will be asked to enter their Twitter credentials. That’s under normal operation.

That pop-up window is served by Twitter over HTTPS as it should be, but if an attacker on an open wi-fi network injected a false address on Mashable’s HTTP site’s Twitter login button, they could send the user to an alternate Twitter (or Facebook, LinkedIn, etc.) login form.

Most users probably wouldn’t notice if the ‘S’ dropped off the Twitter login pop-up, but they trust Mashable to bring them to the right place and handle their information securely. If Mashable was on HTTPS, that link couldn’t be modified.


Of course, that last issue comes close to scraping the bottom of the barrel of issues to shame — and Twitter shares some shame too. I know this sounds tacky and ineffective, but it might help if Twitter conditioned their users with a bright green “make sure you see HTTPS” banner. (Never talk about looking for ‘the lock’ because some malicious sites use a padlock icon as a favicon, tricking users into thinking it’s secure.)

That was quite a tangent, but in any case, Mashable should use HTTPS on all pages which touch user information, handle forms, or induce a user to authenticate. Which basically means their entire site.

Gpg4win website and file downloads are over insecure HTTP

Gpg4win is the free and open-source GNU Privacy Guard for Windows; the official GnuPG distribution for Windows. The entirety of the Gpg4win website is unprotected HTTP, and the same goes for downloads of Gpg4win binaries. Manually going to the HTTPS version of the site shows an untrusted certificate error.

The site has an entire page devoted to checking Gpg4win for integrity, which provides SHA1 checksums, OpenPGP signatures, file lengths, and a code signing certificate.

Since that page is sent over HTTP, you can throw the validity of SHA1 checksums and file lengths out the window — anyone intercepting the page on a network could alter that content to make it seem like the checksum is correct, even though the code has been modified.

OpenPGP signatures sound great, but the site says it’s signed by the “Intevation File Distribution Key” — a user might wonder what Intevation is, and are they authorized to sign releases for Gpg4win?

Of course, a little research would confirm, and their public key has many signatures – but even though all users should verify this information, how many actually would? Think about all the journalists starting to use GPG without really knowing how it works. If the site was SSL, they could trust the name on that key a little more

And, how exactly is a user going to go about checking PGP signatures prior to downloading Gpg4win? Are they going to check it with the potentially compromised file they just downloaded?

I could spout off a dozen scenarios where having SSL might be a last resort — code signing private key compromise, server compromise, etc. — but even if all else goes wrong, SSL adds an extra layer of protection by ensuring authenticity and by ensuring that traffic isn’t manipulated. That’s defense in depth.

These issues might seem obscure and over-the-top, but encryption software is trusted to protect mighty secrets.

Gpg4win is an awesome product with an awesome team. They’re rightfully concerned enough to provide multiple methods of integrity checks, but they should force HTTPS on their entire site.

(Submitted by Jeff)

Bomar Security in Santa Maria, California has an online job application with form fields for name, address, employment history, security clearance information, driver’s license number, and Social Security Number – and the form is loaded insecurely over HTTP, and POSTs insecurely over HTTP.

If a job applicant is filling out this form on an open or masquerading wi-fi network, or if their connection is otherwise being intercepted, an attacker could read all of the unprotected information plaintext.

TLS/SSL is not configured on the site, but it should be made the default on all pages considering the nature of the company’s business.

(Submitted by Dallam Oliver-Lee)

Business lending website LendVantage (endorsed by Larry King!) collects business and personal information as part of its pre-approval forms. Along with business details, income, names, and addresses, the site asks for your date of birth and Social Security Number. The site loads over insecure HTTP, and POSTs over insecure HTTP.

On an open or masquerading wi-fi network, all of this unencrypted and unprotected personal data would be exposed to an attacker using network sniffing tools. LendVantage should use SSL (HTTPS) for both page loads and form submissions. 

(Submitted by Steve)

The Government of the Republic of Trinidad and Tobago: Government Assistance for Tuition Expenses

The Government of the Republic of Trinidad and Tobago’s Government Assistance for Tuition Expenses Programme (GATE) has a login form that insecurely loads over HTTP, and insecurely POSTs over HTTP.

Within the authenticated area of the site, students are expected to enter or upload information regarding their birth certificate, national ID card, marriage or divorce, school transcripts, and more.

The submitter writes, “On February 27th, 2014 local computer enthusiasts discovered that the site was not protected by SSL/TLS. This deficiency was reported by way of letter to the Ministry of Tertiary Education and Skills Training on March 5th, 2014. However, the site is still unprotected.”

GATE’s privacy statement says, “To safeguard your personal data, all electronic storage and transmission of personal data are secured with appropriate security technologies.” Not exactly true.

(Submitted by Smokin)

Navicat downloads and licensing insecure

The website for database administration tool Navicat is entirely insecure HTTP, and downloads are only accessible via insecure HTTP – eliminating any sense of authenticity in an application used to connect to databases that might contain sensitive information. Changing Navicat’s URL to HTTPS errors out, as the site doesn’t support TLS/SSL.

Navicat’s Customer Center runs on HTTPS, but the license purchasing process which collects name, address, company name, and email address, is entirely insecure HTTP right up until the payment – which is handled by a third party.

(Submitted by vistazifta)