HTTP Shaming

Can you please encrypt my traffic?!

[httpshaming]

India satellite TV provider Videocon d2h sends usernames, passwords, personal info insecurely

Videocon d2h, a direct-to-home satellite TV provider in India, does not use HTTPS on its website. All connections go over insecure HTTP.

This is particularly concerning on the "My d2h" section of the site, which collects usernames, passwords, satellite card numbers, customer ID numbers, mobile numbers, addresses, and billing information. All of these details can be intercepted on a monitored or open wi-fi network.

d2h uses third-parties to process payment card data -- Citrus, TechProcess Solutions Ltd, or CC Avenue -- all of which appear to use HTTPS, but personal information is transmitted both before and after transactions in the clear.

Videocon d2h has managed to implement HTTPS on its login form for partners and distributors. It would be great if they cared about the security of their customers as much as the security of their own company's data.

[httpshaming]

Pandora’s registration form – which loads and POSTs over insecure HTTP – collects personal information (an email address, password, and date of birth). Even worse, subscribing to Pandora One requires the entry of credit card details over an insecure HTTP page. Chrome even refuses to auto-fill the form fields with saved credit card data, because it loads over an HTTP page.

All personally-identifiable data should be transmitted securely over HTTPS, all bank card data should most definitely transmit over HTTPS, and logged-in sessions should happen over HTTPS only as well. 

Pandora is a large and established company, and there’s no excuse for exposing user and financial data to theft and fraud.

Submitted by Cameron

[httpshaming]

Toyota Owners website sends name, address, credentials, and VIN over HTTP

The website for Toyota Owners to login to for scheduling service and viewing service history uses insecure HTTP on its homepage, on certain portions of the registration process, and once authenticated.

When registering for an account, your name and email address are sent in the clear. Depending on the registration flow you proceed through, your home address, username, password, and vehicle identification number (VIN) are also transmitted without encryption.

The login form is loaded over HTTP and POSTs to HTTPS, so credentials are transmitted securely for the login (but not always the registration). However, if any form is loaded over HTTP, the POST location could be changed via injection if the connection is intercepted, and other malicious JavaScript could be added to the page.

Toyota’s website should use and enforce HTTPS on every single page, and it should also make use of HSTS.

This was submitted by David, who writes: “I have tried to discuss this with Toyota’s complaint department, but they are disinterested in the issue and ignorant of what it actually means. One person told me the info on the site is ‘internal and private,’ which means nothing and is certainly not a substitute for HTTPS.”

[httpshaming]

United States Digital Service accepts job applications without HTTPS [FIXED]

Update: The entire WhiteHouse.gov domain is entirely HTTPS now. This is resolved!

The federal government is seeking technologists to help transform the way Americans use technology to interact with their government. It's the new United States Digital Service (USDS), and you can apply on the White House website.

I cannot contain my excitement for USDS now being a thing — this is awesome. But one problem: the application form does not use HTTPS. Everything an applicant submits is sent plaintext without encryption over regular HTTP: full name, email, phone number, ZIP code, résumé file upload, links and skills, etc. All of this data could be easily intercepted by third parties on a public wi-fi network or on an employer-monitored network, for example.

If you do try to manually change the URL from ‘http’ to ‘https’ to have encryption in transit, you get a certificate name mismatch error. If you proceed beyond the error, the site redirects you back to insecure HTTP anyway — the White House uses Akamai, which is notoriously terrible at HTTPS.

Okay, this is not the worst violation of privacy on the internet – not even close. In fact, (successful) job applications may be public government data subject to disclosure pursuant to the Freedom of Information Act anyway. 

But here's a few details to keep in mind:

Privacy is not just important as an abstract concept, it's also important in context. Even if information is legally public or not a huge risk, that doesn't mean the person sitting on the other side of the café should be able to see it while you're sitting there. It doesn't mean your employer should be able to see you're applying for a new job while on your lunch break.

Just as HTTPS provides encryption to prevent against eavesdropping, it also protects against alteration of data in transit. Crazy example: it is absolutely possible to automatically change all POST data to add in offensive material if a connection is being intercepted with, for example, a WiFi Pineapple.

HTTPS does not just ensure data in transit is encrypted, it also provides authentication. The applicant in this case could be entering all their personal information on a website pretending to be WhiteHouse.gov.

If the White House is serious about getting technologists who know what they're doing and have a passion for using technology right and with the best interests of citizens in mind, there will be potential applicants who don't want to fill out an insecure form, and shouldn't have to suffer their personal information being at risk just to do so.

Finally, President Obama cited the federal government's interest in ‘cybersecurity’ at his State of the Union address. If the website for the executive branch of the United States Government does not employ HTTPS to ensure authenticity and encryption, should we have faith in the sincerity of that interest?

Submitted by anonymous, anonymous, and aam.

[httpshaming]

WebMD insecurely transmits your health condition and symptom information

WebMD's website has numerous features that transmit health information: both generic information about specific health conditions and symptoms, and personal health information linked with a user account that has identifying user details.

Anytime someone is accessing or transmitting medical content online – whether generic or linked with their user account – there's no question that the information should be secure and encrypted with HTTPS to prevent others intercepting a network connection (e.g. on a public wi-fi network at a café or airport, or your employer) from discovering your medical symptoms, conditions, and medications.

Unfortunately, WebMD does not use HTTPS most anywhere on its site except when a user actually signs up or logs into the site. And once the user is logged in, the site sends them right back to unencrypted HTTP.

Even though a user may sign up using a pseudonymous username, they are still prompted for their email address, first name, last name, a profile photo, and ZIP Code, all of which can be personally identifying to others.

Writing a post on WebMD's condition-specific forums? Well, anyone monitoring or intercepting network traffic now knows that you have the condition, along with anything you write or have written in the past:

Entering an HIV medication in WebMD's medication tracker? Well, anyone monitoring the network now knows that you're HIV Positive:

As mentioned, WebMD does use HTTPS (TLS/SSL) to encrypt the sign up, authentication (login), and account management pages. However, if a site allows a user to continue onto unencrypted HTTP pages after authenticating as WebMD does, their work is for naught: a user's session data sent over HTTP can be easily be hijacked and someone across a café or airport could now continue using WebMD's site as you, and see anything that you could see.

Even the more generic portions of WebMD's site, like informational pages about specific conditions or the WebMD Symptom Checker use insecure HTTP. Although those are not tied to a specific user account unless logged in, it's still insecurely transmitting information about your specific medical symptoms and conditions, and that's not okay.

This HTTP Shame was submitted by John, who writes in below to share his email to WebMD, and their oh-so-typical we-take-your-privacy-seriously message, which is affirmatively and provably false.

As seen in WebMD's response, they encourage users not to post identifying information, but fail to think about users that – as said previously – might be using WebMD on a public network at a café or airport, or the case where an employer may be monitoring employee internet traffic. Workplace medical discrimination does happen, and WebMD is in the wrong here.

WebMD should switch to using entirely HTTPS across their entire site with long-duration HSTS and session cookies set with the 'Secure' flag to ensure that all data in transit is encrypted, authenticated user sessions only happen over HTTPS, and that users are on the authentic WebMD site.

John's comment to WebMD Customer Care Team:

WebMD asks me (via e.g. the Symptom Checker) to transmit private health information over the internet. I’m comfortable with sharing this information with WebMD, but not with unrelated third parties such as my internet service provider or strangers connected to the same wireless network.

Most sites in this situation offer access via a secure connection (HTTPS) in order to prevent third parties from viewing sensitive information. Wikipedia is a good example of this:

https://www.wikipedia.org/

When I try to access WebMD via a secure connection, however—

https://www.webmd.com/

https://symptoms.webmd.com/

—it returns an “Error 404” or “Access Denied” error message.

How can I access WebMD privately?

Thank you,

John

Response from WebMD:

Hi John,

WebMD takes very seriously the privacy and security of our users. The information submitted by our users is used as outlined and defined in our Privacy Policy (http://www.webmd.com/about-webmd-policies/about-privacy-policy).

Further, WebMD does not rent, lease, sell or otherwise disclose Personally Identifiable Information (PII) about our users to any third party without proper notice, consent and choice.

We encourage our users not to disclose any information in a public forum (message boards, chat rooms etc.) which might allow an unauthorized third party to contact them, including email address.

Thanks for making WebMD your site of choice for all of your health and wellness information needs.

Yours in health,

WebMD Customer Care

[httpshaming]

Twitter account management service ManageFlitter uses insecure HTTP, allowing others access to control your account

ManageFlitter is a company that provides a Twitter account management service. You connect your Twitter account, and you can do analytics, schedule posts, and do some follower cleanup. But, the entire website (except payment transactions) is all loading over insecure HTTP.

When you give ManageFlitter access to your Twitter account, you're giving the same access to anyone who might be listening in on a public wi-fi network or between you and their servers. If ManageFlitter cares about the security of their data and their users' data, they should immediately make the entire site HTTPS to encrypt data in transit.

As an example, when you click ‘unfollow’ on the below page, the action (unfollow) and the Twitter user ID to unfollow is sent back to ManageFlitter. Since anyone has access to your session and data in transit on a public wi-fi network, anyone could perform actions like unfollowing users, tweeting on your behalf, or worse.

ManageFlitter's privacy policy is light on details on the topic of security:

“89n operates secure data networks protected by industry standard firewall and password protection systems. Our security and privacy policies are periodically reviewed and enhanced as necessary and only authorized individuals have access to the information provided by our customers.”

Protecting systems and data with passwords – or in this case, Twitter API keys/tokens and session cookies – does nothing if they're not transmitted securely.

[httpshaming]

[RESOLVED] jsFiddle login and registration was over insecure HTTP, said no plans to add HTTPS

UPDATE: February 12, 2015 –  jsFiddle added HTTPS (an EV SHA-2 certificate too!) and it's enforced to ensure that data isn't transmitted insecurely over HTTP. Thanks jsFiddle!

––––––––

Dear Piotr and Oskar,

I absolutely love jsFiddle, can't imagine life as a developer without it, and owe enormous gratitude to you. I think the entire developer community owes you a huge thanks for advancing knowledge, encouraging experimentation, and enabling information sharing.

But I'm concerned that user registration data and logins are sent completely in the clear over HTTP. On an insecure network, an attacker could intercept personal information and passwords. And for sites that are all-HTTPS, they can't embed fiddles. Trying a manual connection over HTTPS to jsfiddle.net throws a connection error.

I get that you work very hard, you didn't expect it to get this big, it's probably screwing you over because you haven't made much (or any?) money from it, and users aren't always as appreciative as they should be.

Demand for SSL is just that — demanding — because threats are changing, wi-fi sniffing is much more prevalent, and then there's that whole NSA thing. The users above didn't seem to get a response.

This request could have been worded nicer, but I'm a bit shocked by the response:

Security is everyone's responsibility, and secure web practices are critical for an open and safe internet. I'd really like to encourage you to reconsider — it's a matter of protecting your users' personal information.

That last Twitter user offered to pay for the certificate. Of course, I realize it's not that simple when you're running at JSFiddle scale, but if it's a matter of money and time, I'm sure contributions can be organized.

I hope SSL can wind up on JSFiddle's roadmap for the near future. If not, could you please encourage users to use single-use passwords and a password manager? If there's anything the developer and information security community can do, your work makes our lives better and I'm sure many of us would love to help.

(Submitted by anonymous)

[httpshaming]

MyFitnessPal does not protect your health information with HTTPS

MyFitnessPal is a service that tracks your food intake, daily activity and exercise, and body measurements such as weight. Of course, one would expect MyFitnessPal to force HTTPS on every single page to protect this private health information, but they don't — none of that data is transmitted securely.

When signing up or logging into MyFitnessPal, the forms POSTs to a secure HTTPS endpoint, but the forms load over insecure HTTP. This is a terrible security practice, as malicious code could be injected into an HTTP page, which transmits the information elsewhere.

When logged into MyFitnessPal, all of the pages transmit over insecure HTTP. Everything you eat, your body measurements, your daily activity, and any activity imported from third party services are all transmitted insecurely over HTTP. If you're on a public wi-fi network, anyone can easily intercept this private health information.

Even worse, if you manually change the logged-in URL from insecure HTTP to secure HTTPS, MyFitnessPal forces you back onto insecure HTTP.

MyFitnessPal has been asked repeatedly use SSL on their login page, and even to add SSL on the entire site. MyFitnessPal's founder Mike Lee said over two years ago that the company was “planning on moving the entire site to SSL.” As of December 1, 2014, that still hasn't happened.

MyFitnessPal's privacy policy states that it has “...implemented and maintains reasonable security procedures and practices designed to protect against the unauthorized access, use, modification, destruction or disclosure of Your Personal Information...” and goes onto state that in the event that such information is “...compromised as a result of a breach of security, MyFitnessPal will promptly notify You...”

This is an outright lie. HTTPS is the most basic, primary, and significant way to protect user data in transit using encryption, and at least help ensure a user is communicating with the authentic website (for example, HTTPS with HSTS would help prevent a DNS poisoning attack where a user is served a fake website). When MyFitnessPal forces a user to go back onto insecure HTTP, it is demonstrating that it has no desire to comply with its own privacy policy. It should consider every user's data to be ‘compromised’ and take immediate steps to add HTTPS with HSTS.

[httpshaming]

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.

[httpshaming]

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)

[httpshaming]

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.

[httpshaming]

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)

[httpshaming]

Apple’s EFI and SMC firmware updates are listed on a page that loads over insecure HTTP, and the downloads are also served insecurely over HTTP. This should be hosted on SSL, even if there's code signing.

(Submitted by Abraham Williams)

[httpshaming]

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)

[httpshaming]

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)

[httpshaming]

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)

[httpshaming]

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)