{"id":32768,"date":"2020-10-19T11:38:09","date_gmt":"2020-10-19T09:38:09","guid":{"rendered":"https:\/\/wpkraken.io\/?p=32768"},"modified":"2020-10-19T11:38:09","modified_gmt":"2020-10-19T09:38:09","slug":"wordpress-code-security","status":"publish","type":"post","link":"https:\/\/wpkraken.io\/blog\/wordpress-code-security\/","title":{"rendered":"3 Essential Rules For WordPress Code Security"},"content":{"rendered":"\n

WordPress code security should never be overlooked, but this doesn\u2019t mean it isn\u2019t. While plenty of other factors can affect you or your client\u2019s website safety, introducing simple rules to your code can go a long way<\/strong>.<\/p>\n\n\n\n

WordPress may seem a fantastic solution to create your website or offer it to your client. Thanks to its robust plugin and theme environment, WordPress\u2019s capabilities extend far beyond a simple blogging system. But, just like superheroes, developers must remember that with great power comes great responsibility (yes, I know this quote is overused, but it\u2019s true).<\/p>\n\n\n\n

Ensuring that your code is secure is no easy feat, and web application security is a topic of pretty much infinite complexity. The amount of plugin vulnerabilities popping up in databases<\/a> every day is terrifying. So unless you have some superpowers up your sleeve, here are three elementary guidelines that should help you stay on the right track<\/strong>!<\/p>\n\n\n\n

\"WordPress<\/figure>\n\n\n\n

Don\u2019t Trust User Input<\/h2>\n\n\n\n

When it comes to processing user input, being paranoid is the only valid strategy<\/strong>. Always assume the worst.<\/p>\n\n\n\n

All the HTML and JS running on the client\u2019s side can be altered. Expect to get values different from the ones you define in your dropdowns, checkboxes, or radios. Don\u2019t be surprised when you receive an array instead of a string. What makes matters worse is that hackers can inject code both in your $_GET and $_POST variables. SQL injection is the #1 threat on the OWASP Top Ten list<\/a>, and XSS (Cross-Site-Scripting) is #7. Both are caused by improper user input handling.<\/p>\n\n\n\n

SQL injection happens when you include user input in your SQL queries without proper escaping. Avoid adding it to your queries whenever you can.<\/strong> For example, when you need to include some string in the query based on the users\u2019s choice, but the range of input is known and limited, you could use a ternary operator or an array with a whitelist or any other means that will allow you to get the user input out of the equation.<\/p>\n\n\n\n

$order_by = $_GET['order-by'] === 'asc' ? 'asc' : 'desc';\n\n$categories = ['fruits', 'vegetables', 'meat'];\n$category = in_array($_GET['category'], $categories, true) ? $_GET['category'] : 'all';<\/code><\/pre>\n\n\n\n
 When all you need to get from the user is an integer, cast the variable to an integer. <\/p>\n\n\n\n
$id = (int) $_GET['id'];<\/code><\/pre>\n\n\n\n
\/\/ ...\n\nif (isset($_GET['show-product'])) {\n    global $wpdb;\n    $results = $wpdb->get_results(\n        'SELECT * FROM ' . $wpdb->prefix . 'posts WHERE post_type = \"product\" AND ID =' \n        . $_GET['show-product'], \/\/ SQL Injection opportunity, not sanitized input from $_GET\n        ARRAY_A\n    );\n\n    foreach ($results as $result) {\n        $content .= '<div class=\"product\">'\n            . '<div class=\"product__title\">' . $result['post_title'] . '<\/div>'\n            . '<div class=\"product__content\">' . $result['post_content'] . '<\/div>'\n            . '<\/div>';\n    }\n\n    return $content;\n}<\/code><\/pre>\n\n\n\n
\n\nIn the following code we\u2019d of course be better off using WordPress post functions, but let\u2019s see what could happen if we were to skip input sanitization:\n\n<\/p>\n\n\n\n
Now, if we replace the ID in the URL by adding an always true condition OR 1=1 like so:<\/p>\n\n\n\n
http:\/\/example.com\/?show-product=7%20OR%201=1<\/code><\/pre>\n\n\n\n
it will print out not only product posts, but all the WordPress posts. Not the end of the world, right? Wrong! Using tools like sqlmap<\/a>, you can dump entire database through blind SQL injection<\/a>.<\/p>\n\n\n\n
When you need to include user input in your query, use a parametrized one, but make sure to do preparation only once, as double preparation isn\u2019t secure at all.<\/p>\n\n\n\n
\/\/ ...\n\n$query = $wpdb->prepare(\n    'SELECT * FROM ' . $wpdb->prefix . 'posts WHERE post_type = \"product\" AND ID = %d',\n    $_GET['show-product']\n);\n\n$results = $wpdb->get_results(\n    $query,\n    ARRAY_A\n);\n\n\/\/ ...<\/code><\/pre>\n\n\n\n
That being said, keep in mind that there were issues with $wpdb in the past<\/a>. Connecting to the database directly brings its own set of headaches<\/strong>, so think twice before deciding to go for it.<\/p>\n\n\n\n
In an XSS attack, hackers aim to execute their JS code in other clients\u2019 browsers. If you think this isn\u2019t game over yet, think again. If the browser belongs to the administrator, hackers can take advantage of it and send a request to WordPress to create a new admin account. The possibilities are endless, user data can leak in more subtle ways and you won\u2019t even notice. XSS vulnerability arises when attackers are able to inject a <script><\/code> tag or other tag allowing to pass JS code that will execute like <img onerror=\"...\"><\/code>. The best solution is to escape HTML entities altogether and allow users to format their text in some other way if necessary.<\/p>\n\n\n\n
echo '<input type=\"text\" name=\"some-search-field\" value=\"'\n    . ($_GET['search-query'] ?? '') \/\/ XSS opportunity - not sanitized $_GET input passed to value\n    .  '\">';<\/code><\/pre>\n\n\n\n
The above code is an example of Reflected XSS vulnerability. To perform a Reflected XSS, hackers prepare a malicious link that they send to other users of the website. This simply means that they embed JS in GET argument like so:<\/p>\n\n\n\n
http:\/\/example.com\/?search-query=%22%3E%3Cscript%3Ealert(%60hey%60)%3C\/script%3E<\/code><\/pre>\n\n\n\n
When an unsuspecting user clicks the link above, the embedded code gets echoed out as HTML and is executed. This method requires user interaction and may not be very efficient, but you still need to remember it can happen.<\/p>\n\n\n\n
Stored XSS works the same way as Reflected XSS, with the difference that it doesn\u2019t require user interaction as the malicious code is stored on the server and sent to visitors with the rest of the content. This way, users (including admins) can get hacked just by visiting the site.<\/p>\n\n\n\n
Don\u2019t Trust Client-Side Code<\/h2>\n\n\n\n
One of the key WordPress security code issues is forgetting that all the code and HTML running in the client\u2019s browser can be altered. Form validation on the front-end is purely a UX feature and offers no security benefits. Another thing to remember is that when something isn\u2019t visible to the user on the front-end, it absolutely doesn\u2019t mean that it\u2019s not reachable on the backend<\/strong>. Consider the following, commonly seen WordPress code:<\/p>\n\n\n\n
\/\/ Front-end JS\nfunction createProduct(name, description) {\n    var data = {\n        '_ajax_nonce': ajax_object.nonce,\n        'action': 'create_product',\n        'product_name': name,\n        'product_description': description,\n    };\n\n    return jQuery.post(ajax_object.ajax_url, data);\n}\n\/\/ Back-end PHP\nfunction create_product() {\n    check_ajax_referer('product_manager'); \/\/ reusable nonce\n    \n    \/\/ no input sanitization (persistent XSS opportunity)\n    $new_product = array(\n        'post_type'    => 'product',\n        'post_title'   => $_POST['product_name'] ?? '',\n        'post_content' => $_POST['product_description'] ?? '',\n        'post_status'  => 'publish',\n        'post_author'  => get_current_user_id(),\n    );\n\n    $new_post_id = wp_insert_post($new_product);\n\n    $data = [\n        'product_id' => $new_post_id\n    ];\n\n    wp_send_json_success($data, 'success');\n}\n\nfunction update_product() {\n    check_ajax_referer('product_manager'); \/\/ reusable nonce\n\n    \/\/ no input sanitization\n    $new_data = array(\n        'ID'           => $_POST['product_id'],\n        'post_type'    => 'product',\n        'post_title'   => $_POST['product_name'] ?? '',\n        'post_content' => $_POST['product_description'] ?? '',\n        'post_status'  => 'publish',\n    );\n\n    $post_id = wp_update_post($new_data, true);\n\n    $data = [\n        'product_id' => $post_id,\n    ];\n\n    wp_send_json_success($data, 'success');\n}<\/code><\/pre>\n\n\n\n
See anything missing aside from input sanitization? There\u2019s no access control on the back-end. Even if you don\u2019t include the handler on the front-end, nothing stops the attackers from editing the client-side code to their liking.<\/strong> So they could, for example, change it like this:<\/p>\n\n\n\n
function createProduct(name, description) {\n    var data = {\n        '_ajax_nonce': ajax_object.nonce,\n        'action': 'update_product',\n        'product_id': 7,\n        'product_name': 'Some new name',\n        'product_description': 'Some new description',\n    };\n\n    return jQuery.post(ajax_object.ajax_url, data);\n}<\/code><\/pre>\n\n\n\n
And the fact that WordPress nonces are not true nonces as stated in official documentation<\/a> only makes things easier.<\/p>\n\n\n\n
Don\u2019t Assume Security by Obscurity<\/strong><\/h2>\n\n\n\n
With the above example, you could argue that you\u2019re writing some custom code that nobody\u2019s ever going to look at, so who\u2019s going to know the appropriate action name and parameters? But that\u2019s a very poor approach to WordPress code security! You really shouldn\u2019t hope nobody\u2019s going to exploit any methods<\/a> to get your code. Take the matter into your own hands and prevent this scenario from happening instead.<\/strong> Let\u2019s consider the last example:<\/p>\n\n\n\n
\/\/ Some encrypting function found on Stack Overflow, let's not focus on it's strength but on the way it's used\nfunction xor_string($string, $key) {\n    for($i = 0; $i < strlen($string); $i++) {\n        $string[$i] = ($string[$i] ^ $key[$i % strlen($key)]);\n    }\n\n    return $string;\n}\n\nfunction create_product() {\n    \/\/ ...\n\n    \/\/ Notice that the encryption key is constant and hardcoded for all deployments\n    \/\/ and ID's here are incremental and easy to iterate through\n    $delete_key = base64_encode(xor_string(get_current_user_id() . '-' . $post_id . '-delete_post' , 'constant key'));\n\n    $data = [\n        'post_id'    => $post_id,\n        'delete_key' => $delete_key\n    ];\n\n    wp_send_json_success($data, 'success');\n}\n\nfunction delete_product($delete_key) {\n    $delete_key = xor_string(base64_decode($delete_key), 'constant key');\n    $delete_key = explode('-', $delete_key, 3);\n    \n    $post_author = get_post_field('post_author', $delete_key[1])\n\n    $deleted = false;\n    if($delete_key[2] === 'delete_post' && $post_author === $delete_key[0]) {\n        $deleted = wp_trash_post($delete_key[1]);\n    }\n}<\/code><\/pre>\n\n\n\n
Using constant and hardcoded key in combination with predictable components sounds like a bad idea straight away. Still, I came across a similar mistake in one of the immensely popular WordPress plugins. It\u2019s super easy to write a piece of code that will iterate over user and post ID\u2019s and generate links with GET argument.<\/p>\n\n\n\n
Keeping Up With WordPress Code Security<\/h2>\n\n\n\n
Like I said at the beginning, WordPress website can be compromised in many different ways<\/a>, some more obvious than others. Does this mean you get to freak out? Absolutely not! But are there measures that you can take against it? Sure thing!<\/p>\n\n\n\n
Ensuring your code is sealed-shut from the beginning is one of the best things you can do to protect the website. It\u2019ll save you many headaches and you\u2019ll be able to switch your focus elsewhere. So always think about what you\u2019re doing and try to abuse your own creation. You never know who might be looking \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
Learn some elementary guidelines on how to fortify your WordPress code and keep the hackers at bay.<\/p>\n","protected":false},"author":45,"featured_media":32817,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-gradient":""}},"footnotes":""},"categories":[39,90],"tags":[],"_links":{"self":[{"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/posts\/32768"}],"collection":[{"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/users\/45"}],"replies":[{"embeddable":true,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/comments?post=32768"}],"version-history":[{"count":0,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/posts\/32768\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/media\/32817"}],"wp:attachment":[{"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/media?parent=32768"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/categories?post=32768"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wpkraken.io\/wp-json\/wp\/v2\/tags?post=32768"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}