Server-side GraphQL Querying with Elixir Absinthe
By- January 29, 2019
GraphQL is a few years old, and its promises are well known and pretty compelling. Get only the data your front end needs to display, introspection and type constraints, relate all your data in a graph of relationships, etc.! All great things, but if you’re like us and you start to retrofit a GraphQL API onto a REST-based site, you start to notice a divide.
We decided to build GraphQL into our API scanner. Since we’ve built it using Phoenix in Elixir, Absinthe was our go-to choice for a GraphQL query engine. Where before we had a set of contexts and related queries to provide information for our views, now we also had our GraphQL schema defining relationships and queries for fetching particular sets out of the database. It’s not a huge increase in maintenance and overhead, but it does mean duplicating authorization checks and a few other concerns, like remembering to preload for particular edge cases. It would be nice if we could use our GraphQL interface on the server side, particularly if you want to, say, pre-render a single-page app… and it turns out with Absinthe, you can!
Let’s take, for example, a simple social media site. On the site, there are users and posts, where users can become friends and posts can be liked. In order to populate the initial view of this site, we would need to get the current user, preload their friends, preload the first N posts between their posts and their friends’ posts, and the likes on those posts. We'd also need to have a GraphQL query for that same information when the state changes for the current user (for instance when they scroll to the bottom of the page). This is a good amount of duplicate querying, but with Absinthe you can add the @graphql annotation before a method in your controller to query the same information that your front end would pull. The results of the query becomes the parameters map given to your controller. For instance:
Relatively compact, fairly convenient, and by nesting everything under the current user, we should be able to ensure they only access things they are allowed to see. However, it looks like we’re grabbing just about every field available on our (admittedly quite simple) GraphQL schema. Also this query will return a bare map, rather than the structs defined in our application (which could be useful to have elsewhere in the app). Absinthe comes to the rescue for both of these issues by providing a shortcut in the @graphql annotation. Given a query where a field is requested but none of its subfields are specified, it will grab all the fields and, in the case of a field backed by an Ecto schema, will use that struct instead of a bare map. From there, you can use @put inside that object to grab the associations you want to load. This leaves us with this fairly succinct query for our controller’s index action:
And there we go! Now this hypothetical app need only worry about one path for providing data to users, and can concentrate on authorization along the GraphQL path. As long as our graph is complete, we don’t need to worry about making new specific queries for our controllers. Happy coding!
What The Hack 2018?
By- December 11, 2018
As the current year comes to an end, many of us take this time to look back and reflect on how we can be a better version of ourselves for the upcoming new year. Let’s reflect on the data breaches that occurred in 2018, to encourage the companies we trust with our data to try and do better in 2019.
The past year brought us an unusual number of high profile breaches, with alarming amounts of data being exposed. Here are our 12 Hacks of Christmas:
1) The largest, in terms of records breached, was Aadhaar. For those of you who may not have heard of Aadhaar before, it’s the Unique Identification Authority of India (UIDAI). The UIDAI is mandated to assign a 12-digit unique identification (UID) number (termed "Aadhaar") to all the residents of India. According to a report by the Tribune News Services, there was a software patch that could be bought for as little as 500 Rupees and reportedly allowed unauthorized persons to generate Aadhaar numbers. An additional payment of 300 Rupees got you access to software through which anyone could print an ID card for any Aadhaar number. The data breach is believed to have compromised the personal information of nearly all 1.1 billion citizens registered in India.
2) More recently, there was a data breach of the Starwood guest reservation database, newly owned by Marriott International. This breach exposed the personal information of up to 500 million people. Hackers were able to access guests’ names, addresses, phone numbers, email addresses, passport numbers, dates of birth, genders, Starwood loyalty program account information, and reservation information. In some cases, they were also able to steal payment card numbers and expiration dates. According to Marriott, the payment card numbers were encrypted, but they are not sure yet if the hackers were also able to access the information needed to decrypt them.
3) Exactis is a marketing and data aggregation firm based in Florida that left a database containing two terabytes of information exposed on a publicly accessible server, including the personal details of hundreds of millions of Americans and businesses. This led to an estimated 340 million records being breached. The data exposed included email addresses, physical addresses, phone numbers, and highly sensitive details such as the names and genders of consumers’ children.
4) MyFitnessPal, now owned by Under Armour, was compromised, leading to 150 million records being exposed. The data exposed included customers' usernames, email addresses, and hashed passwords. Some welcome news was that their users’ payment information was not compromised, as Under Armour stores that database separately.
5) MyHeritage, an online genealogy platform, left 92 million of their users' emails exposed after a security researcher informed the company’s CISO of a file found on an external server. According to MyHeritage, they store family tree and DNA data on servers separate from those that store email addresses and they use third-party service providers to process payments, so other than email addresses, the rest of their customers’ data was not exposed.
6) The main hack most of us heard about was the whole Facebook / Cambridge Analytica exposé. Upwards of 87 million records were breached. Later, Inti De Ceukelaire (a security researcher) revealed another app, Nametests.com, had publicly exposed information of more than 120 million Facebook users as well.
7) One of the latest breaches happened to Informed Delivery, a service created by the US Postal Service (USPS), which allows customers to view their mail before it arrives at their home mailboxes. In addition to emailing the images, the USPS offers an API to allow users to connect their mail to specialized services like CRMs. However, it was discovered that the service accepted wildcards for many searches, allowing any user to see other users on the site. According to reports, hackers who accessed the data got to see where important documents and checks were being mailed, so they could go and steal them once they were delivered. The USPS has advised people sign up for the Informed Delivery service with your own email address before someone else signs up as you. Estimates say that 60 million records were exposed.
8) Panera Bread exposed 37 million of its customers’ records in early April. What was more concerning was that in August 2017, security researcher Dylan Houlihan attempted to disclose the vulnerability to Panera Bread, letting them know they had a weakness that resulted in Panerabread.com leaking customers’ records in plaintext. That data could then be scraped and indexed using automated tools. Houlihan claims that his disclosure was dismissed for almost eight months, until Houlian reached out to Brian Krebs (an investigative information security journalist) who reported the story. This finally forced Panera Bread to deal with the issue by taking their website temporarily offline so they could fix the vulnerability.
9) Ticketfly was asked to cough up a ransom for a vulnerability that was discovered by a hacker. When the company refused, the hacker vandalized, took down, and disrupted their site for a week. The hacker was also able to replace Ticketfly’s homepage and make off with 27 million records of customer and employee data, including names, physical addresses, email addresses, and phone numbers.
10) The Sacramento Bee newspaper was attacked by an anonymous hacker early in the year. The hacker gained access to 19.5 million records, after seizing two of their databases, and trying to get the paper to pay a ransom for their release. One of the databases contained data from California voter registration provided by California’s Secretary of State, and the other database stored the Sacramento Bee’s subscriber contact information. Sacramento Bee refused to pay the ransom and deleted the databases to prevent additional attacks. However, the attack still left 53,000 of their subscribers’ information and 19.4 million California voters’ data vulnerable.
11) It’s suspected that the fitness app, PumpUp, exposed 6 million of its users’ records after a backend server was found to be exposed to the Internet with no password to protect it. This vulnerability leaked sensitive customer data, such as user-entered health information, photos, and private messages sent between users. The exposed data also contained Facebook access tokens and, in some cases, unencrypted credit card data including card numbers, expiration dates and CVV numbers. ZDNet reported the story and reached out to PumpUp, after security researcher Oliver Hough discovered the vulnerability and reached out to ZDNet to disclosed the issue. PumpUp did not respond to ZDNet, but they did end up securing the server. It’s unclear for exactly how long the server had been sitting exposed.
12) Saks Fifth Avenue and Lord & Taylor became the source of 5 million credit and debit card records which were for sale on the JokerStash hacking syndicate. The discovery was made by security firm Gemini Advisory. After the discovery was disclosed, both Saks Fifth Avenue and Lord & Taylor took immediate steps to fix the issue. A class action lawsuit was filed against them by the customers whose data had been exposed and put up for sale.
In most of these situations, it was a journalist, outside researcher or a white hat hacker that found and disclosed the vulnerabilities. Often, it was too late to be dealt with. One of our Tinfoil Engineers wrote about this issue with disclosing vulnerabilities in a previous blog post. We still believe there are more good folks out there than bad folks, so we look forward to bringing joy and hope to the world of cybersecurity in 2019 and beyond!
Decking the Halls for Holiday Traditions
By- December 04, 2018
It’s that time of year when we’re thankful, our bellies are full of turkey, and we’re turning on heaters and bundling up in sweaters. The holidays are always a great time of year at Tinfoil. We’re typically working hard on fun wrap-up projects before the holiday exodus, and are most collaborative during this time. Tinfoil is a small team, and often our collaboration makes us much more like a family than most companies. Just like all families, we like to make time to celebrate the holidays with one another.
This week, we’re decking the halls with cheer. Each year, Tinfoil puts up a traditional non-denominational holiday tree, adorned nicely with hand-cut snowflakes, twinkly lights, and a hodgepodge of ornaments from different team members and different religions. Slowly it gets filled with surprise Secret Santa gifts, surprise founder-to-employee gifts, and surprise employee-to-employee gifts. Our tree is one of my favorite aspects of Tinfoil. We buy it just for a few weeks, and donate it immediately after our gift exchange to a family who can’t afford one themselves. We’ve given it to a retired firefighter with pensions too small for Bay Area rents, a family whose father was recently laid off, and a nice retired couple living frugally. Each person is so very different, and each one walked away in love with their tree.
Our Secret Santa is a simple event. Each team member automatically draws a name (thanks to drawnames.com) and anonymously picks out a gift with a price limit. We’ve had silly gifts, loving gifts, and gifts that seemed just right. Sometimes we even get visits from past employees. We have a small party to guess who Santa’d us and cider is enjoyed by many.
My cofounder and I like to make sure the tree is filled right up. We add some small additional gifts, ranging from joke gifts, to food, to fun toys for the entire team. One year each person got an animal onesie, and a different year they each got surprisingly good waterproof speakers. There are usually 2-3 gifts for each employee, making unwrapping a fun holiday evening.
Tinfoil’s traditions are similar to many startups. We keep it simple, try to incorporate as much diversity as possible, and try to end the year celebrating our successes together. I’ve heard so many wonderful ideas for holiday celebrations from other startups. What are yours?
Should I include CSRF protection on a login form?
By- November 20, 2018
Since I found Angel’s “Plain English” series of blog posts so helpful when I was first learning about different kinds of vulnerabilities on the web, I wanted to continue that series. I hope to expand into some of the nuances of more commonly known vulnerabilities, and touch on some of the less well known ones. Let’s get started with one special case that I often find questions about: CSRF on a login form.
To start, if you’re not familiar with the Cross Site Request Forgery (CSRF) attack, you should definitely give Angel’s blog post from a few years ago a read. In the typical way of thinking about a CSRF, an attacker is able to submit a form on behalf of a victim with data the attacker controls. In the classic example, you can imagine an online service that allows users to transfer money between each other, perhaps by first adding their credit card. In the absence of any protective measures against CSRF, the attacker can trick their victim into clicking a link that submits a form on their account, and transfers money into the attacker’s account. However, what if our humble service is aware of this risk, and includes some form of CSRF protection on all of their authenticated forms? Our attacker will have to get a bit more clever, and though the aforementioned example might often be the most dangerous case, it is not necessarily the only one.
Strictly speaking, a CSRF attack is one where an attacker is able to submit any request on behalf of the victim. So, the attacker begins looking for other ways to trick our poor victim, and finds that the login form is totally unprotected. Hatching a devious plan, our attacker crafts an attack that would submit the login form in the victim’s own browser, thus logging them into the attacker’s account. So our victim -- now perhaps only slightly confused as to why their credit card info is missing -- adds all of their personal information necessary to send money to their friend, and logs out, thinking nothing more of it. Now our attacker, having full control over their own account, logs back in to find that they have everything they need to siphon funds from our poor victim.
As you may have noticed, the impact of an exploit like this varies from site to site, depending a lot on how likely or possible it is for a victim to leave behind personal information. It also relies on tricking the users into completing at least one extra step, instead of just clicking a dubious link. However, the world of security frequently involves accounting for even very unlikely cases, because an attacker will often have hundreds or sometimes thousands of opportunities, and doesn’t need to succeed every time. It’s also worth mentioning that even seemingly harmless vulnerabilities can be leveraged to enable more potent attacks. You might already be able to imagine how one could use an attack like this to direct a user to a page with an injected XSS, but perhaps I’ll save that concept for a later blog post.
For these reasons, I like to err on the side of caution, and avoid giving an attacker the opportunity to exercise any functionality on another user’s behalf. For more information on how we suggest you implement your CSRF protection, you can refer to the article linked above.
I hope you found this short post helpful in understanding some of the nuance of one of the most threatening types of vulnerabilities on the web. I’m one of the support engineers here at Tinfoil Security, so if you have any thoughts, feel free to email me at firstname.lastname@example.org. I’d love to hear your feedback!
Today I Learned: Using SCSS in your Vue Components
By- November 13, 2018
If you haven’t yet looked into Vue.js, it might be time to. The front-end framework is a powerful, progressive alternative to its main rivals, Facebook’s React and Google-backed Angular, and has been continuously gaining traction among the open source community.
In this way, the CSS for a given component lives alongside the rest of its code, and with the
scoped attribute, will scope all style to only this component - preventing it from bleeding outwards and affecting global styling in unpredictable ways.
One might notice, however, that throughout much of Vue’s documentation and in countless tutorials, guides, and articles on all things Vue, the language used to this styling plain, vanilla CSS. In a world where SCSS exists, with it’s support for variables, mixins, and nested styles, can we do better? Yes we can.
Styling your Vue components with SCSS is incredibly simple - provided you have the right configuration.
Above is an example
webpack.config that makes use of
vue-loader. You’ll want to install both the
node-sass packages first, however.
npm install -D sass-loader node-sass
Once you’re configured, simply add a
lang attribute to the style tags in your components:
And you’re set! Enjoy all the features of SCSS in your Vue components.