A little less than a month ago I took a trip up to Pictured Rocks National Lakeshore with my family. While up there, I received a disconcerting email informing me that No Page Comment, a plugin I’ve written that’s on the WordPress plugin repository, had a security vulnerability.
“I am an IT security professional and I have found few problems in your WordPress plugin.”
That’s how the email started. If you ever receive an email that begins with that, then it should make you a bit skeptic, and I was.
Fortunately, I did not immediately delete the email. I read the whole thing and it was a very good idea.
The sender listed two issues with the plugin: There was a cross-site scripting (XSS) security vulnerability and a Cross-Site Request Forgery (CSRF) security vulnerability.
What is a cross-site scripting (XSS) security vulnerability?
In layman’s terms, it means someone can inject and run arbitrary JavaScript on the page. This means that your cookies can be accessed, as well as potential active sessions. If someone had access to that, then they could potentially gain access to the site you are on. This allows them to change your password and possibly lock you out of your site.
Fortunately, on No Page Comment, that vulnerability was only found on the settings page in the admin section. It happened because I failed to sanitize a single URL on the page. By sanitizing the request URL from the server, I was able to patch this issue.
What is a Cross-Site Request Forgery (CSRF) security vulnerability?
A CSRF is where someone can create a form on another URL, and submit it to your site. Basically, if someone can submit something to the wrong form, then the results can really hurt you.
On No Page Comment, this security vulnerability affected the settings page in the admin section as well. Fortunately, it wasn’t anything major, but it could have been. If someone created an external form, and then linked to the admin page, they would be able to change the settings of no page comment. Those settings were only the comment and trackback defaults for the various post types, but it still was worrisome that someone could do that.
My solution was to add a nonce to check and make sure the form was being submitted from the admin area of the site.
How can developers prevent security vulnerabilities?
First, sanitize everything. If you don’t know what that means, take the time to learn about it. Never code anything where someone can input something. Do what you can to prevent any possible leak. If you are in doubt of whether it needs to be sanitized, then just do it.
Second, use your nonces. Nonce means “number used once”. Think of it like an always changing access token. By setting a form or action in wordpress to use a nonce, you are verifying that the user or script has access to perform that task.
How can WordPress users prevent security vulnerabilities?
Update everything!
I’m serious! Always make sure core WordPress is updated. Also, make sure your themes and plugins are up-to-date. Hopefully, if a developer learns they have a security vulnerability, they will patch it before it’s made public. As soon as that patch is released though, the vulnerability is made public. Always make sure your site is updated.
I’m lucky because the person who revealed the issues to me said that they weren’t going to release their findings yet. They wanted to make sure I had time to fix them, which was nice, considering I was on a family trip to the UP (that’s the Upper Peninsula for all of you non-Michiganders).
With that said, if you are a user of No Page Comment, please update now. While the issues aren’t anything major, it’s always best to close as many holes as possible.