SAFELY HANDLING DATA SO YOU DON’T GET PWNDDEVELOPER SECURITY

SUCURI SECURITYTONY “LIVE HACK” PEREZ

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…

SUCURI SECURITYDRE “I’LL CHOKE YOU” ARMEDA

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…

SO HOW DO YOU PROTECT YOURSELF?

WATCH THIS. IT’S AN OLDIE, BUT A GOODIE.

http://wordpress.tv/2011/01/29/mark-jaquith-theme-plugin-security/

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.

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

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

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.

KEEP YOUR DEV ENVIRONMENT CLEAN

KASPERSKY ANTI-VIRUS

▸ I use it.

▸ Dre uses it.

▸ Tony uses it.

▸ You should be using it.

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 );

TRUST NO ONE, TRUST NOTHING

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.

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

ZOMG…WTF?!

http://mysite.com/wp-admin/post.php?post=307&action=trash

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

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.

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

WHITELIST DATA – ONLY ACCEPT KNOWN DATA

$_POST = array('pwn' => '<script src="http://pwn.me/u.js"></script>','e' => 'email@domain.com');

// badforeach( $_POST as $key => $val ) {update_post_meta( $id, $key, $val );}

// goodupdate_post_meta( $id, 'e', sanitize_email( $_POST['e'] ) );

BLACKLIST DATA – ONLY ACCEPT DATA IF IT’S IN THE PROPER FORMAT

$_POST = array('e' => 'email@domain.com');

// badupdate_post_meta( $id, 'e', $_POST['e'] );

// goodif ( is_email( $_POST['e'] ) ) {update_post_meta( $id, 'e', sanitize_email( $_POST['e'] ) );}

SANITIZE USER GENERATED DATA - CAN CHANGE DATA AND CAUSE UNEXPECTED RESULTS

// badupdate_post_meta( $id, 'data', $_POST['name'] );

// good$safe_text_field = sanitize_text_field( $_POST['name'] );update_post_meta( $id, 'data', $safe_text_field );

ESCAPE DYNAMIC DATA ON OUTPUT – BAD DATA WILL BE TAMED IN A CONTEXT FRIENDLY WAY

$dynamic_data = get_post_meta( $id, 'data', true );

// badecho $dynamic_data;

// goodecho esc_html( $dynamic_data );

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