The case of Sparkfun ‘security’

Sparkfun is an online store which sell , electronics for hobbyist. They also are my go to store when I need any small electronics (arduino, raspberry pi, etc.). Unfortunately while their store and service is great the security of their site leaves something to be desired. I am writing this article prior to disclosure, but by the time this is published hopefully Sparkfun will have addressed the weaknesses in their site. UPDATE: Sparkfun was very responsive and has taken actions to addressed all issues below :-D.

Improperly secured cookie

By default all cookies are accessible from JavaScript, this accessibility enables any JavaScript running on domain to both read an manipulate their contents. However, it is important any cookie containing sensitive data have this feature disabled by setting the HTTP flag. When this flag is set on a cookie the browser is not allow JavaScript to read or write that cookie.  As shown below the cookie used by Sparkfun to identify the current user does not have this flag set.


The more astute among you maybe questioning how this is a vulnerability as even if JavaScript able to access this cookie that JavaScript must be running in the same security context as the Sparkfun site. This is true, however the reason we set the HTTP flag is not because it is directly exploitable but because if an attack did manage to find an XSS vulnerability they could read the contents of any cookie without the HTTP flag and send it back to a server they control. This in turn would allow them to use the stolen cookie to hijack the original user’s session. This is an example of defense in depth we always want to create systems which have protection in place to limit the damage of a weakness being found. We do this because it would be an act of extreme arrogance to assume our first line of defense is without bugs or design weaknesses.

This is akin to having a giant planet destroying space station with small little hole that if hit will blow the entire thing up, and says well no one will ever get through the turbo lasers so don’t worry about it!

Well, the Empire doesn’t consider a small one-man fighter to be any threat, or they’d have a tighter defense. An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station. But the approach will not be easy. You are required to maneuver straight down this trench and skim the surface to this point. The target area is only two meters wide. It’s a small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system. A precise hit will start a chain reaction which should destroy the station. Only a precise hit will set off a chain reaction. The shaft is ray-shielded, so you’ll have to use proton torpedoes –General Dodonna


When one goes to checkout they are given the option to enter a gift certificate. Whatever value is entered is immediately echoed back into the page. As seen in the following screenshot where “trench run” was entered.

Gift Certificate Entered


What will happen though if instead of just text html is passed? If it is echoed back as properly encoded string than it is unlikely there is a XSS vulnerability. However, if in this case the words “One Man Fighter” are rendered in the page as an h1 there is almost certainly a XSS vulnerability.


At this point we know html is being rendered so let’s perform the same test with “<script>


At this point is safe to say this Sparkfun has at least one XSS vulnerability.

Misconfigured response types

Let’s did a little deeper though and see what else is going on here. In this case the page is not actually reloading when a gift certificate is submitted.



We see that the outbound request is looking for json or JavaScript to be returned by examining the Accept header. The server however does not claim to be returning json or javascript. Rather in the Content-Type of the response we see the server believes it is returning html. When we inspect the body of the response we see the following:





This is not html as the server claimed it was. This means there is a mismatch between the stated type of data and the actual type of data being returned. This is a catastrophic mistake, as if the browser were to directly make this request it would treat the results as if they were html.  Html and JavaScipt/JSON have drastically different encoding requirements, such that values that are safely encoded for JavaScript are not safely encoded for html. If for example a script tag was present in the code value the browser would render it. Using specially crafted request we are able to exploit this misconfiguration  and turn what should have been static JSON into executing JavaScript with access to the security context.



This would allow any malicious site hijack the sessions of any of their visitors who were also logged into Sparkfun without their knowledge!


As a brief aside in the initial request we do not see a CSRF token being included with the promo code. This likely indicates Sparkfun also has CSRF vulnerabilities.



Using jsfiddle we are able to quickly confirm the presence of  a CSRF vulnerability in the Sparkfun shopping cart that among other things lets us update a user’s shipping address.


Do not assume the a site is secure simply because it is popular or held in high regard by its users. As a consumer there is little you can do to protect yourself for insecure sites so be careful about which sites you allow to store your personal information. As a website builder it your job to protect your customers, conduct regular code audits, penetration tests and remember it is up to you to protect your customers.