I recently got in touch with On Your Bike, a cycle shop with stores in Birmingham and London, to alert them to a number of security issues in their website. I’d raised the matter with a very friendly chap at the shop, and he advised me to send an email to the manager. This I duly did, in early June, with a reminder in mid July of this year, seemingly to no avail: at least one vulnerability is still there, and I’ve not heard back from him. I am therefore publishing this advisory in accordance within generally accepted principles of responsible disclosure. My hope is that the owners of the business will become aware of this post via the search engines, and will then take the necessary steps to fix the problem. They are cordially invited to comment below.
First up, there’s an XSS vulnerability in their customer sign-up form. For readers unfamiliar with web application security, XSS stands for “Cross Site Scripting” (the ‘X’ is a cross, see?) and, in simple terms, is an unintended security flaw in a website that permits a cracker to run their own browser code on behalf of another user. The primary attack method is to steal another user’s cookie via a piece of unauthorised code, dump it on a server controlled by the attacker, and then use it to impersonate that user. Here, the cookie a security adversary would most be interested in would belong to an administrator, which would presumably grant unauthorised access to any customer data contained within the website.
I noticed also that apostrophes are badly handled in the form too: names like “O’Brien” are saved as “O\’Brien”. This suggests that backslashes are being escaped character to prevent SQL injection (a good thing) but that it is being done incorrectly (obviously not good). This also hints at the possibility that their development company is using the legacy mysql PHP library, rather than the more modern PDO or mysqli alternatives. If they were to switch, they could simply make use of parameterisation, which renders manual escaping a thing of the past anyway.
The second security flaw is that passwords are limited in size (no more than 20 characters) and may only consist of alphabetic characters. Thus, numbers and punctutation marks that would improve the security of a password are expressly disallowed! Worse still is that if the user gets this wrong (or, indeed, triggers form validation at all) it is all wiped and the poor customer has to start over.
A third vulnerability is that error reporting is enabled in the production site. One of my cookies expired, I visited the checkout and ended up with this dumped into the source:
<b>Fatal error</b>: Call to a member function get() on a non-object in <b>/home/oybike/public_html/checkout.php</b> on line <b>121</b><br />
Lastly, the password reminder feature sends the user their password in plaintext, rather than offering to reset it. A password should be regarded as compromised as soon as it has been emailed, but moreover it should not be stored in plain text at all. This site explains why this is a problem.
Great find and great writeup. Though this is from 2014, do you know if this has been addressed yet?
Hi Harry, I’m afraid I don’t – I wonder if it has been brushed under the carpet.
I persisted with OYB, and eventually copied in the web design firm, who did not reply. I did hear back from OYB at that point – who I think had ignored my earlier communications – but where it is now is anyone’s guess.
I suspect the problem with not having a technical perspective is that a business owner might think his security woes are “none of my business”, but of course it’s a community issue – there is presumably a whole customer database that risks being leaked or damaged.