Category Archives: Uncategorized

A Week with HackerOne

About three months ago I signed up with HackerOne, and created a bug bounty program for my WordPoints plugin. I’m writing this post to document my experience with HackerOne, for anyone else who may be thinking of using it.

When you first create your program, it is private. This gives you time to tweak things and gain some familiarity with the system. You also have the opportunity to invite up to 100 of the top hackers to participate and the private pre-launch program. I did invite all 100 (though not all at once), but there wasn’t any activity. That is probably because I hadn’t set a minimum bounty amount yet.

Last Friday I decided to make the program public. This timing roughly corresponded with the release of WordPoints 1.7.0, which included some security fixes that I’d discovered on my own.

What should you expect when you launch publicly? I got 15 bug reports in the first 24 hours, and about a third of them were probably in the first couple hours after launching.

The reason for the immediate spike in activity (of which there had been none previously), is probably due at least in part to my having set a minimum bounty (though this was only $25).

Of those 15 reports, most of them were low quality. The reporter obviously hadn’t read the program description, and didn’t know what kind of bugs I was looking for and what sort of vulnerabilities I would consider invalid. Of those 15, only two were vulnerabilities that actually needed fixing. I’ve received 4 more reports this week, but none of them have been valid source code vulnerabilities either.

So, now you know what you can expect with your first week after launching a bug bounty program on HackerOne. I suspect that if you wanted to avoid the first-minute slew of reports, you could wait until later to set a minimum bounty amount.

All in all, I am very pleased with HackerOne. The UI is great and has the tools you need to respond quickly. I think also that report quality will probably increase as better researchers join in in an unhurried manner. Well, at least if I decide to increase the bounty in the future. :-)

The end of PHP 5.3

PHP 5.3 is dead.

In some ways it’s sad when a version of PHP dies. But in other ways, it’s great. I mean, more time can go into making it a better language instead of backporting security fixes to old versions. Really, the only thing that makes it sad is that so many people will be using these dead and insecure versions for years to come.

The other day I wrote a post about how WordPress supports PHP back to 5.2. In fact, until recently most WordPress sites were running on 5.2. Now, it’s an even split between that and 5.3:

WordPress PHP versions pie chart

Only 21.8% of sites are now running on a living version of PHP.

I think that it is interesting to compare these stats to the number of sites running WordPress versions that receive security updates:

WordPress versions pie chart

39% of sites are running a living version of WordPress.

Why is there such a discrepancy here? Obviously, WordPress is web software, whereas PHP is a programming language, but is there another reason that more WordPress sites are up to date? I doubt that users are more conscientious about updating than web hosts are.

It’s not only that more WordPress sites are up to date, but more of them are running the latest version, 3.9. Whereas PHP 5.5 has a much smaller slice than 5.4.

I think the reason for this difference is probably that WordPress is easier to update than PHP. Not just that there is a difference in technical skill required, but that updating PHP is more likely to break things than updating WordPress. WordPress always aims for complete backward compatibility, but there are sometimes changes in PHP that can definitely break things. It could be that the difference here is the obvious: the less painful it is to update, the more people will do it.

WordPress Documentation Lookup Within TextWrangler

I use TextWrangler as my code editor. This is one reason why.

Sometimes you want to look up something in the WordPress documentation, straight from your code editor. And with WordPress, that might be a function, a filter, or an action. It’s easy to add that feature to TextWrangler, just by adding an AppleScript file to the scripts folder (~/Library/Application Support/TextWrangler/Scripts/). Then you can access it from the scripts menu, which is the one with the little script icon. (To open the scripts folder, click on “Open Scripts Folder” under the scripts menu).

Here’s what you can put in the file to look up a function on the WordPress codex:

tell application "TextWrangler"
set function to selection of window 1 as string
if function = "" then
set function to text returned of (display dialog "WordPress Function:" default answer "")
end if

if function is not "" then
set target_URL to "" & function
open location target_URL
end if
end tell

Simple, huh?

This will open a dialog prompt for you to type whatever function you want to look up, or if you have already selected the function’s name on the page, it will use that. Either way, the codex page for that function will open in your favorite browser.

You can easily customize this script to look up anything you want anywhere you want. Just change the target URL and dialog text accordingly.

Here’s a zip of my folder which includes filter and action look-up in addition to the function look-up. You can copy the entire folder to TextWrangler’s scripts folder, and it will create a new menu item named WordPress.

Quick Lookup with Browser Bookmarks

I’m a DRY person. I try not to repeat myself, or do tasks over and over manually when they could be automated. So I’ve started to create different bookmarks in my browser that automate different common tasks using JavaScript. I thought I’d share a few of these that can be used to look up WordPress related stuff in various references. Their usage is simple. Once you have bookmarked one of them in your browser, clicking on the bookmark will bring up a JavaScript prompt dialog box where you can enter whatever you are searching for. If you have already highlighted the text to search for on the page, then the prompt will be skipped.

It’s not hard to roll these, and you can make some yourself. Here’s an example. Just make a few changes and strip out the white space.

	q = document.getSelection();

	if ( q.rangeCount < 1 )
		void( q = prompt( 'WP%20Seek:', '' ) );

	void( q = escape( q ) );

	if ( q && q != 'null' ) 
		location.href = '' + q