{"id":911,"date":"2016-10-22T10:00:10","date_gmt":"2016-10-22T14:00:10","guid":{"rendered":"http:\/\/sethalling.com\/?p=911"},"modified":"2016-10-22T09:12:59","modified_gmt":"2016-10-22T13:12:59","slug":"security-vulnerability","status":"publish","type":"post","link":"https:\/\/sethalling.com\/security-vulnerability\/","title":{"rendered":"I Had a Security Vulnerability"},"content":{"rendered":"
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>, a plugin I’ve written that’s on the WordPress plugin repository, had a security vulnerability.<\/p>\n “I am an IT security professional and I have found few problems in your WordPress plugin.”<\/p>\n 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.<\/p>\n Fortunately, I did not immediately delete the email. I read the whole thing and it was a very good idea.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n My solution was to add a nonce to check and make sure the form was being submitted from the admin area of the site.<\/p>\n First, sanitize everything. If you don’t know what that means, take the time to learn about it<\/a>. 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.<\/p>\nWhat is a cross-site scripting (XSS) security vulnerability?<\/h2>\n
What is a Cross-Site Request Forgery (CSRF) security vulnerability?<\/h2>\n
How can developers prevent security vulnerabilities?<\/h2>\n