Secure e-book shopping for the holidays? Maybe, Maybe not

E-books have not been something I have been reading too much of, since I am rather old-fashioned about books, preferring physical books (and I probably spend way too much time in front of computer monitors, anyway). Among other nice things about them is that you don't have to turn them off aboard a plane during take off and landing 😉 .

Despite this I actually do have a collection of e-books on my PCs, since Baen Publishing, a Science Fiction and Fantasy publisher, has been kind enough to include CDs with several of the hardcover books I've bought from them. The CDs contain the books in several formats, including HTML, all unencumbered by DRM, even with a permission for non-commercial sharing. Baen do this because they think they will sell more physical books, and as far as I can tell it works like a charm: I bought a bunch of paperbacks from the first CD, and I know one of the authors published by Baen, Eric Flint, did some research, finding that he sold more books than he normally would have, after he had made his available for free (see this article collection, search for "There Ain’t No Such Thing as a Free Lunch" and "I can demonstrate this concretely").

Until a month ago I had not been looking into Baen's WebScription service, their e-book store (they also have a free library), since, as I mentioned above, I prefer physical books. A month ago, however, I became aware that Baen had, as they frequently do, made an early version (an ARC, Advanced Reader Copy, before proofreading) of a book I was waiting for (it will be published in March, already pre-ordered), so I decided I did not want to wait that long :), "walked" over to Webscription, registered and bought the early version (without encountering any problems with the security of the website).

Then, a couple of weeks ago, as I was winding up the backlog of books in a series (in case anyone is interested: the Lee&Miller Liaden Universe Saga – finally decided it was time to get started on that one, while flying across the Atlantic) that I've been reading the past few months, I found that there were a few collections of shorter stories available, particularly as HTML e-books (without DRM). Most of them were available via WebScription, but not all of them.

The remaining books were available through another e-book service, Smashwords, and that's when I hit the first security warning. I had followed links from Lee&Miller's home page to the Smashwords pages for the books, and clicked "Buy". Up came the the "You are about to submit an unsecure query from a secure page"-warning. What's going on? The link from Lee&Miller was (unusually enough) for a HTTPS page, most shopping sites use unencrypted pages for the presentation, so I had not noticed, and the "buy"-button was submitting a form to an unsecure server.

This, of course, triggered some more investigation, and I quickly discovered that the HTTPS page I was on was not just posting to an unsecure server, it also included an unsecure external JavaScript, in a page that also had a login form at the top (most pages had that login form, also the unencrypted ones). As I have mentioned before, this means that if anyone logs in through this page, an attacker could replace the original script, steal the account information, and assume control of the account (including the accounts of authors publishing at the site).

I also discovered that the "buy" action that submits to the unsecure server (which triggered the initial warning dialog), bounces back to a "secure" page that says you have to be logged in to see the shopping cart. This "secure" page includes both an unsecure CSS file, and an unsecure external JavaScript file, which again means that a attacker can take complete control of the user experience, and steal account data and, very likely, credit card information.

I informed Smashwords about the problems on or around December 2nd, and again December 15th after I had received no response from them, and the problems still remained. As of December 20, still nothing has happened.

After this I decided to check out a few more e-book shopping sites, and did a quick test of 14 more sites found via a wiki page, which along with Smashwords, totaled 15 sites. In this quick test I tested their support for secure presentation, sign up, log in, how securely the shopping cart was presented, and the checkout up to having to log in before being able to continue. In none of these cases did I create an account or attempt to log in, so the investigation did not test how secure the payment systems are.

  • One (1) site did not seem to provide any encryption at all. This one seemed to mostly offer free content.

Front page:

  • 5 sites provided a secure variant of their front page. All five of them had mixed secure and unsecure content, 4 of the 5 included unsecure JavaScript.


  • 3 sites provided a secure variant of the book presentation. All three of them included unsecure JavaScripts.

Shopping cart:

  • 6 of the sites provided a secure variant of the shopping cart, only one had that as the default, 3 others included unsecure JavaScript, another unsecure images.
  • 3 more required log in on a secure page before displaying the shopping cart, one mixing unsecure images, one unsecure JavaScript.

Sign up/Log in:

  • 14 of the sites provided default secure sign up and login pages, but 3 included unsecure external Javscript, another two used mixed security content.


  • In two cases it was not possible to get to checkout, due to login requirements for even adding items to the cart.
  • In another three the checkout was login protected.
  • in the remaining 9 cases, 3 were including external JavaScript, and one mixed security content.

In total, ignoring the pre-checkout navigation, for the sign up, log in, and checkout parts of my test:

  • 8 of the 15 used full encryption, without mixed security.
  • 4 included unsecure JavaScript, with some also including unsecure CSS style sheets. Some of these scripts were these scripts were Facebook related or analytics-scripts. Three of these were informed yesterday, Smashwords was, as mentioned, informed a few weeks ago.
  • 2 others included mixed security content.
  • (and one did not provide any security, at all).

In other words, only half of the tested e-book sites followed the minimum best practices for e-commerce (secure sign up, sign in and checkout, no mixing of secure and unsecure content), and a full two thirds of the rest leave their sites wide open to a JavaScript-based Man in the Middle hijacking of accounts, and in at least some cases this appears to include the author's accounts too.

So, my advice is that you should be vigilant when you are online shopping for e-books, and probably in other online shops, as well. Frequently, when the "secure" indication for a "secure" page is gone, only a detailed investigation will indicate if the problem is a true security problem, so it is better to assume that it indicates that there is a security problem. If there is no "padlock" when you are about to use your password or credit card, then I would recommend that you should do your shopping somewhere else.

Some quick advice to site administrators:

  • Avoid using absolute URLs on the form . Only use this kind of URL when you are intentionally changing to HTTPS or HTTP from a page that was loaded using the other protocol, or if you want to use that specific protocol.
  • Instead, use relative URLs:

    – Use "/foo" if the content is on the same server, or just "foo" if it has the same folder path as the current document.

    – Use "//" (note the two leading "/"s) if you are referencing content on a different server. All modern web browsers recognize this form of URL, and will automatically prepend "http:" is the document has a http-URL, and "https:" if the document has a https-URL. Example using "//"

This will ensure that you do not accidentally change from HTTPS to HTTP for some content, in particular when parts of the template for the webpage are also used on a HTTP page.

2 thoughts on “Secure e-book shopping for the holidays? Maybe, Maybe not”

  1. Originally posted by grawity:But won’t “//server/path” get interpreted on Windows as an UNC path for SMB/WebDAV?No, not when used as a URI/URL in a HTML document. The behavior is defined by RFC 3986 sec. 4.2 with examples in sec. 5.4. All URI/URLs must be resolved relative to the base URI/URL of the containing document.It might be interpreted that way if you paste it directly into the addressbar, but then it would be because there is not Base-URI/URL to resolve it against, and the browser (or OS) is left to guess what you meant, trying to complete it, e.g. by prepending “file:” in front of anything starting with “//”. A system doing that with a relative URI inside a document that have a properly defined Base-URI/URL would not be standards compliant, unless the Base-URI/URL also have “file:” as the scheme.For reference, IE9 resolves such a href=”//otherserver/foo” URL correctly to when the base-URI/URL is

Comments are closed.