In this presentation I cover how to keep your code from having security vulnerabilities. This talk was given at the OC WordPress Developer Meetup in January 2017.

1. SAFELY HANDLING DATA SO YOU DON’T GET PWND
DEVELOPER SECURITY

2. SUCURI SECURITY
TONY “LIVE HACK” PEREZ

3. BRO. IF YOU DON’T ESCAPE YOUR DATA,
YOU’LL NEVER ESCAPE THE HURT I’M
GOING TO PUT ON YOU.
Tony Perez (probably said that)
IN CASE YOU NEEDED MORE REASONS…

4. SUCURI SECURITY
DRE “I’LL CHOKE YOU” ARMEDA

5. LOOK, THERE ARE BAD PEOPLE OUT THERE TRYING ALL
SORTS OF SALTY STUFF TO PWN YOUR SITE. YOU’RE NOT
GOING TO BE READY FOR THAT? COME ON NOW…DON’T LET
THEM MAKE YOU LOOK SILLY. ALSO, DON’T TOUCH MY HAT.
Dre Armeda (might have said that)
IN CASE YOU NEEDED MORE REASONS…

6. SO HOW DO YOU PROTECT YOURSELF?

7. WATCH THIS. IT’S AN
OLDIE, BUT A GOODIE.
http://wordpress.tv/2011/01/29/mark-jaquith-theme-plugin-security/

8. THAT GUY, MARK JAQUITH, PWNED A PLUGIN I WROTE LIVE
ON STAGE DURING A PLUGIN COMPETITION AT WORDCAMP
NYC IN 2009, AND IT WOKE ME UP.

9. READ THIS
HTTP://WP.TUTSPLUS.COM/TUTORIALS/CREATIVE-CODING/DATA-SANITIZATION-AND-VALIDATION-WITH-WORDPRESS/

10. IF YOU’RE GOING TO CHECK OUT NOW, HERE’S THE TL;DR
6 THINGS TO KEEP IN MIND WHEN WRITING CODE, NUMBER 2 WILL SHOCK YOU!
▸ Keep your dev environment clean
▸ Use WordPress Core code instead of custom code whenever possible
▸ Validate referrers
▸ Validate data inputs
▸ Sanitize data inputs
▸ Escape data outputs

11. KEEP YOUR DEV ENVIRONMENT CLEAN
MAC, LINUX, OR PC – IT DOESN’T MATTER
▸ Don’t think that just because you’re on a mac you’re safe from viruses.
▸ If you’re running linux, a lot of the responsibility of security is on you. Make
sure all of your system software is patched and up to date.
▸ If you’re on a PC, you should assume you’re already pwned.

12. KEEP YOUR DEV ENVIRONMENT CLEAN
KASPERSKY ANTI-VIRUS
▸ I use it.
▸ Dre uses it.
▸ Tony uses it.
▸ You should be using it.

13. WORDPRESS CORE CODE VS. YOUR CODE
WORDPRESS CORE
$request = wp_remote_get( $url );
$data = wp_remote_retrieve_body( $request );
YOUR CODE
$ch = curl_init();
$timeout = 5;
curl_setopt( $ch, CURLOPT_URL, $url );
curl_setopt( $ch,
CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch,
CURLOPT_CONNECTTIMEOUT, $timeout );
$data = curl_exec( $ch );
curl_close( $ch );

14. TRUST NO ONE, TRUST NOTHING

15. CSRF: CROSS-SITE REQUEST FORGERY
HTTP://EN.WIKIPEDIA.ORG/WIKI/CROSS-SITE_REQUEST_FORGERY
▸ Cross-site request forgery, also known as a one-click attack or session riding
and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a
type of malicious exploit of a website whereby unauthorized commands are
transmitted from a user that the website trusts.[2] Unlike cross-site scripting
(XSS), which exploits the trust a user has for a particular site, CSRF exploits the
trust that a site has in a user's browser.

16. SWEET, THIS COULD LEAD TO MY NEXT BIG DEAL! CONFIRM!

17. ZOMG…WTF?!
http://mysite.com/wp-admin/post.php?post=307&action=trash

18. NONCES FTW!
▸ Create the nonce
▸ wp_nonce_url() - for links
▸ wp_create_nonce() - generates just the nonce value
▸ wp_nonce_field() - generates entire html hidden element
▸ Verify the request
▸ wp_verify_nonce() - validates the nonce for correctness and expiration
▸ check_admin_referer() - also checks if request came from another admin screen

19. XSS: CROSS-SITE SCRIPTING
HTTP://EN.WIKIPEDIA.ORG/WIKI/CROSS-SITE_SCRIPTING
▸ Cross-site scripting (XSS) is a type of computer security vulnerability typically
found in Web applications. XSS enables attackers to inject client-side script into
Web pages viewed by other users. A cross-site scripting vulnerability may be
used by attackers to bypass access controls such as the same origin policy.
Cross-site scripting carried out on websites accounted for roughly 84% of all
security vulnerabilities documented by Symantec as of 2007.[1] Their effect
may range from a petty nuisance to a significant security risk, depending on
the sensitivity of the data handled by the vulnerable site and the nature of any
security mitigation implemented by the site's owner.

20. HOW TO MAINTAIN SAFE DATA
▸ Validate user input – verify data entered is in the proper format
▸ Sanitize data before saving – remove evil content in your data
▸ Escape dynamic data before output – the data can’t be used against a user

21. WHITELIST DATA – ONLY ACCEPT KNOWN DATA
$_POST = array(
'pwn' => '<script src="http://pwn.me/u.js"></script>',
'e' => 'email@domain.com'
);
// bad
foreach( $_POST as $key => $val ) {
update_post_meta( $id, $key, $val );
}
// good
update_post_meta( $id, 'e', sanitize_email( $_POST['e'] ) );

22. BLACKLIST DATA – ONLY ACCEPT DATA IF IT’S IN THE PROPER FORMAT
$_POST = array(
'e' => 'email@domain.com'
);
// bad
update_post_meta( $id, 'e', $_POST['e'] );
// good
if ( is_email( $_POST['e'] ) ) {
update_post_meta( $id, 'e', sanitize_email( $_POST['e'] ) );
}

23. SANITIZE USER GENERATED DATA - CAN CHANGE DATA AND CAUSE UNEXPECTED RESULTS
// bad
update_post_meta( $id, 'data', $_POST['name'] );
// good
$safe_text_field = sanitize_text_field( $_POST['name'] );
update_post_meta( $id, 'data', $safe_text_field );

24. ESCAPE DYNAMIC DATA ON OUTPUT – BAD DATA WILL BE TAMED IN A CONTEXT FRIENDLY WAY
$dynamic_data = get_post_meta( $id, 'data', true );
// bad
echo $dynamic_data;
// good
echo esc_html( $dynamic_data );

25. HELPFUL LINKS
▸ http://wordpress.tv/2011/01/29/mark-jaquith-theme-plugin-security/
▸ http://wp.tutsplus.com/tutorials/creative-coding/data-sanitization-and-validation-with-wordpress/
▸ https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data
▸ http://codex.wordpress.org/Data_Validation
▸ http://codex.wordpress.org/WordPress_Nonces
▸ https://developer.wordpress.org/plugins/security/
▸ https://wordpress.org/about/security/
▸ http://en.wikipedia.org/wiki/Cross-site_scripting
▸ http://en.wikipedia.org/wiki/Cross-site_request_forgery