development Archives - John Beales

Bug Bounties in a Small Company

The E-mail arrived quietly in our support mailbox. Pretty good English, but clearly not the writer’s first language, and :

BUG : Password Reset Link Not Expire After Mail Change.

Hey!
I found a token miss configuration flaw in…

Ok. Not the biggest deal of all time, but something that should be fixed. The submitter provided really great instructions on how to reproduce the bug and why we should care. I replied thanking the submitter and got this back:

Hi There
Is there any way to give me a bounty ?

Thanks

Baboom. This sounds like the exact situation that Justin Jackson & Jon Buda asked about on this episode of Build your SaaS. We’re a small company. We don’t have a formal bug bounty or vulnerability disclosure program, but I find security fascinating, (at least from the outside), and know bug bounties are a thing. It would be nice to pay a bounty, but how much? What happens next? What if we refuse?

This is what we did, and how it played out.

It’s our first time

My business partner had seen the initial E-mail in the support system so he knew something was up. After a quick discussion about how bug bounties work and asking if he ok with paying something we made the decision to pay small bounties in the neighbourhood of $20 – $50 US per bug, depending on severity, available funds, and how many more reports came in.

I went back to the submitter and said that we could pay but as a very small company with an extremely limited budget he should not expect Apple-style bounties. They were happy with that arrangement, so I fixed the bug.

Then they submitted another but and I fixed that. And another. In all this person submitted 5 “bugs” of varying severity. Some we could barely class as problems but we looked at them all and patched any that needed patching. Some others made us re-think some of the user interface, especially around changing contact or login information, and make plans to change it later.

The reports were both submitted and fixed close together so we lumped everything into one payment. We paid about $100 US for the lot. The submitter asked for payment to go to a random PayPal address that was nothing like the name of the person we were dealing with, then send a screenshot of the completed payment. Pretty sketchy, but they were satisfied.

Writing a Disclosure Policy

I have looked at the bug bounty programs on HackerOne and Bugcrowd, and decided to make a page to point people to when they ask about bug bounties, and to lay down some ground rules, (like don’t DDoS us!). We used Mozilla’s Bug Bounty program and some others from respected companies as inspiration. We included a requirement for detailed reproduction steps, why the bug is actually a problem. This makes it relatively easy to triage any reports we get.

Good thing we wrote a disclosure policy, because as we were finishing up with the researcher another E-mailed us with some bugs, and asking if we have a bug bounty program, and we were was able to respond with a link to the new disclosure page.

Bounty Hunter #2

On Build your SaaS Jon asked if you paid, would you end up on a list of companies that pay, then be flooded with submissions. The answer seems to be at least sort of yes. As we were finishing up with the first submitter another showed up. Submitter #2 had better English than Submitter #1, and was much more thorough. I suspect these two were somehow connected, whether they both post to the same forum or both work for the same person I don’t know, but it felt like we went from a Level 1 pen-tester to Level 2. Submitter #2’s bugs were more creative and more serious than Submitter #1’s. Since #2 showed up just as we were finishing with #1 we were short on cash for bounties, but were honest about it and paid what we could. This seemed well received. I believe we paid about $200 US to Submitter #2.

After once we were mostly wrapped up with Submitter #2 things were quiet for a while, then he submitted one more issue about a week later which we fixed, and since we hadn’t sent the payment yet added to the payment for all of his bugs. Payment was the same sketchy unrelated PayPal + screenshot of the payment method.

Was it worth it?

Short term answer: Yes. At least one of the bugs that Submitter #2 found was serious enough that it warranted immediate attention, so on that level it was worth having someone report it instead of exploit it.

Overall answer: Still yes. For the cost of about $300 US and about a week of my mornings we got outside feedback that made us reconsider some UI decisions from a security standpoint and learned about Content Security Policies and other security headers. Also, the submitted bugs and our knowledge of our systems led us to other related bugs that we fixed as well, so it was a bit like a 2-for-one sale on bug-fixes. And now we have tests written that should prevent these bugs from re-appearing.

Of course I would prefer that we found problems internally before they were deployed, and problems would be discovered at convenient times, but that’s not the real world and I’m happy the problems were found and fixed, and we improved our systems and knowledge as a result.

This all happened back in February and March, and we haven’t had any reports since.

Further Steps

I hear there’s an ISO standard for security disclosure best practices, (apparently ISO 29147 and ISO 30111). I plan on looking them up and do what we can to follow them while balancing that with continuing to improve our product. With a small team it’s always a question of balance, so we’ll keep doing our best!

Has this happened to you?

If I had to bet, I would bet that a lot of small businesses are approached by security researchers this way, but none of us have dealt with them before, we don’t know what to do, and are worried it will be a scam or that we’ll end up on a list and end up spending all our time dealing with bug reports. This feels like something we should talk about.

WP e-Commerce to WooCommerce

There’s a pair of websites that I have looked after for a long time. They belong to a company that sells a few products, and have had quite a few sales over the years. This fall we’re doing some major renovations, and one of the things being changed is the underlying E-Commerce plugin for WordPress; we are changing from WP e-Commerce to WooCommerce. I expected that after installing WooCommerce it would offer to convert my WPeC store into a WooCommerce store. I was wrong. There was an official converter plugin but it was abandoned long ago.

Options to change a site from WP e-Commerce to WooCommerce

It looks like there are three ways to change a site from WP e-Commerce to WooCommerce:

Use a commercial service like Cart2Cart. Cart2Cart looks great, but is made to move a store from one site to another, and I need an in-place conversion. They also charge per-migration, so if I want to migrate my localhost, modify the theme for WooCommerce, then migrate the live site, I’ll have to pay 1.5 times, (they give a 50% discount for re-migrating a site). With two sites my bill would have been around US$450, high enough for me to look at other, more complicated options.
Create or update something like the old WooCommerce migration plugin.
Manual Migration: This would involve a lot of SQL.

Cart2Cart looks ill-suited for my use-case, and expensive. Manual migration looks difficult, highly prone to errors, and not easily repeatable. This leaves creating or updating a migration utility. This migration script by Carl Hughes is bit newer than the WooCommerce one, promises to do more out of the box, and quick read-through doesn’t show anything too mysterious. It was my starting point.

Updating and Testing

It took three times as long as expected to update & test the migration plugin. Here’s what I learned, for anyone else that might be considering the same type of process:

This should go without saying, but this migration is destructive. If it fails the database will be in a strange state between WPeC and WooCommerce. Have a backup.
Since migrating from WPeC to WooCommerce changes the database, but only the database, (no media files are touched), a backup of the WordPress database is required. A lot of time will be spent reloading from the backup, so put it somewhere easy to get. Mine was on my desktop. Bonus points: a short bash script to reload the DB from the backup will save development time.
Make the backup be the exact state that the migration should run from. It is not efficient to disable a plugin in the WP Admin every time the database is reloaded.
Some plugins really slow down the migration. The most obvious ones are WP e-Commerce itself, and any Varnish caching plugin. If they are disabled the migration will run faster.
Each payment gateway, (plugin for a payment processor, in WPeC terminology), stores transaction data a little differently. I added the ability to port data from Authorize.Net credit card transactions, but separate routines need to be written for other processors.

Updated Migration Plugin

My fork of the migration plugin is up on Github, and a I sent a pull request to the original author so he can include my work if he wants. If you need to migrate from WP e-Commerce to WooCommerce hopefully this can help a bit. Read the readme. Migrating is harder than it should be, but it is possible.

Preview Laravel Password Reset and Verification E-mails in a Browser

I’m building something on Laravel, using the built-in Auth with 5.7’s new E-mail Verification feature. Today’s task was to tweak the design of E-mail notifications a bit, so I wanted to preview them in a browser. I thought it would be easy, but the built-in E-mails use the Notification system, bypassing Mailable objects. Some Googling didn’t help much, but combining the Notifications documentation and this forum post got let me preview the messages. Hopefully this post can help someone else preview their messages much more quickly than I did today.

The concept is similar to the “Previewing Mailables” documentation: define a route to view your preview on, and return something that will render the message. The trick is that the MailMessage objects that the Notifications’ toMail() methods return don’t have a render() method like Mailable class does, so we need to find something else. Since the built-in Auth uses Markdown mail we can use the Markdown class. A Notifiable object, (the User object for the user who will get the notification), and a Notification are also needed.

For this to work you need to have the right Notifications published to your resources/views/vendor directory. This is done with the Artisan command php artisan vendor:publish --tag=laravel-notifications.

And set up the preview routes:


Route::get('/reset-notification', function () {

    // Get a user for demo purposes
    $user = App\User::find(1);

    // Make a Reset Notification object, (subclass of `Notification`)
    $resetNotification = new \Illuminate\Auth\Notifications\ResetPassword( 'some-random-string-this-will-be-much-longer-in-real-life' );

    // get the `MailMessage` object
    $mailMessage = $resetNotification->toMail($user);

    // get the `Markdown` object
    $markdown = new Illuminate\Mail\Markdown(view(), config('mail.markdown'));

    // Render the vendor.notifications.email view with data from the `MailMessage` object
    return $markdown->render('vendor.notifications.email', $mailMessage->toArray());
});


Route::get( '/verify-notification', function () {

    // Get a user for demo purposes
    $user = App\User::find(1);

    // Make a Verify Notification object, (subclass of `Notification`)
    $verifyNotification = new Illuminate\Auth\Notifications\VerifyEmail();

    // get the `MailMessage` object
    $mailMessage = $verifyNotification->toMail($user);

    // get the `Markdown` object
    $markdown = new Illuminate\Mail\Markdown(view(), config('mail.markdown'));

    // Render the vendor.notifications.email view with data from the `MailMessage` object
    return $markdown->render('vendor.notifications.email', $mailMessage->toArray());
});

Once the Notification is published and the routes created it is possible to preview the Password Reset and E-mail Verification E-mails in the browser.