I’m here at WordCamp Seattle, and wanted to post my slides and a few other notes. I’m giving two talks today, one in the development track on best practices for plugin development (“Y U NO CODE WELL”), and an Ignite talk on contributing to the WordPress community.
First, during my development talk, I was asked for five tips on writing secure code. In return, I pulled up a recent email I wrote where I provided 10 tips:
Never trust the user. You need to assume that all user input is insecure, and that all output is unescaped. The primary points are:
- Always escape attributes, URLs, and text on output.
- Always sanitize, scrub and validate input.
- Always prepare database queries.
- Never trust the user.
- Never output anything that is unsanitized or unescaped.
- Never store anything that is unsanitized.
- Know the difference between authority and intention.
- Never trust the user.
- Always use the many helper functions — we make it easy to write secure code.
- Never trust the user.
Best Practices for Plugin Development
http://www.slideshare.net/andrewnacin/best-practices-in-plugin-development-wordcamp-seattle
Ignite Talk: Ask Not What WordPress Can Do For You
http://www.slideshare.net/andrewnacin/ask-not-what-wordpress-can-do-for-you-ignite-wordcamp-seattle
You’re trusting the user way too much.
Y U NO TRUST THE USER !?
Wish I could have made this camp, really like the slide, will have to watch the video on WordPress TV.
I’ve already picked up a few new tricks. Thanks buddy.
Hi Nacin,
Actually I’ve just written a post (How To Set Up Site Speed For Google Analytics In WordPress) where I’ve argued that in some cases you have to trust the user:
Joost de Valk’s Google Analytics for WordPress plugin allows the user to enter JavaScript code that’s added to the Google Analytics code. However, it doesn’t stripslashes when adding it to the page. As a result the custom code doesn’t work, at least in some cases, because the slashes change the meaning of the JavaScript code, ie:
_gaq.push([\'_trackPageLoadTime\']);So, my reasoning is that if the user is entering information that’s going to be displayed in the code, don’t trust them. But if the user is entering code that’s going to be run, as in the case above, well you have to trust them. If you really don’t trust them, then you don’t give them the ability to add code.
Another eg is the plugin / theme editors in WordPress. You have to trust the user’s input, or you have to remove the editors!
So maybe I’m just stating the obvious, but I guess what I’m really saying is that it’s not as simple as “never trust the user”. It depends on the purpose of the user input. I’d love to hear your perspective on this.
@Stephen Cronin so true! There are times users must realize that their input code will be inserted in their own site lol
Is there a video that goes with this slideshow. This stuff is gold. thanks.