• The Ultimate WordPress Plugin Security Testing Cheat Sheet

        Oct 20 2017, 8:40 PM

        by larsonr eever 2

        The security documentation provided by WordPress and found online for plugin security is sparse, outdated or unclear. This cheat sheet is intended for Penetration Testers who audit WordPress plugins or developers who wish to audit their own WordPress plugins. This cheat sheet can be effectively used to test various WordPress plugins.

        Cross-Site Scripting (XSS)

        Check if the following global PHP variables are echo'd to pages, or stored in the database and echo'd at a later time without first being sanitised or output encoded.

        • $_GET
        • $_POST
        • $_REQUEST
        • $_SERVER['REQUEST_URI']
        • $_SERVER['PHP_SELF']
        • $_SERVER['HTTP_REFERER']
        • $_COOKIE

        (Note: the list of sources above is not extensive nor complete)

        Cross-Site Scripting (XSS) Tips

        Unsafe API functions

        The following functions can cause XSS if not secured:

        • add_query_arg()
        • remove_query_arg()

        See References Below:


        When doing dynamic testing for XSS the following setting in the wp-config.php file may reduce false positive results as it prevents administrative and editor users from being able to embed/execute JavaScript/HTML, which by default they are permitted to do.

        define( 'DISALLOW_UNFILTERED_HTML', true );

        SQL Injection

        Unsafe API methods (require sanitising/escaping):

        • $wpdb->query()
        • $wpdb->get_var()
        • $wpdb->get_row()
        • $wpdb->get_col()
        • $wpdb->get_results()
        • $wpdb->replace()

        Safe API methods (according to WordPress):

        • $wpdb->insert()
        • $wpdb->update()
        • $wpdb->delete()

        Safe code, prepared statement:

        <?php $sql = $wpdb->prepare( 'query' , value_parameter[, value_parameter ... ] ); ?>

        Note: Before WordPress 3.5 $wpdb->prepare could be used insecurely as you could just pass the query without using placeholders, like in the following example:

        $wpdb->query( $wpdb->prepare( "INSERT INTO table (user, pass) VALUES ('$user', '$pass')" ) );

        SQL Injection Tips

        Unsafe escaping ('securing') API methods:

        • esc_sql() function does not adequately protect against SQL Injection - see refs below
        • escape() same as above
        • esc_like() same as above
        • like_escape() same as above

        Displaying/hiding SQL errors:

        <?php $wpdb->show_errors(); ?> <?php $wpdb->hide_errors(); ?> <?php $wpdb->print_error(); ?>

        File Inclusion

        • include()
        • require()
        • include_once()
        • require_once()

        PHP Object Injection

        • unserialize()

        Command Execution

        • system()
        • exec()
        • passthru()
        • shell_exec()

        PHP Code Execution

        • eval()
        • assert()
        • preg_replace() dangerous "e" flag deprecated since PHP >= 5.5.0 and removed in PHP >= 7.0.0.


        • is_admin() does not check if the user is authenticated as administrator, only checks if page displayed is in the admin section, can lead to auth bypass if misused.
        • is_user_admin() same as above
        • current_user_can() used for checking authorisation. This is what should be used to check authorisation.

        Open Redirect

        • wp_redirect() function can be used to redirect to user supplied URLs. If user input is not sanitised or validated this could lead to Open Redirect vulnerabilities.

        Cross-Site Request Forgery (CSRF)

        • wp_nonce_field() adds CSRF token to forms
        • wp_nonce_url() adds CSRF token to URL
        • wp_verify_nonce() checks the CSRF token validity server side
        • check_admin_referer() checks the CSRF token validity server side and came from admin screen


        • CURLOPT_SSL_VERIFYHOST if set to 0 then does not check name in host certificate
        • CURLOPT_SSL_VERIFYPEER if set to FALSE then does not check if the certificate (inc chain), is trusted
        • Check if HTTP is used to communicate with backend servers or APIs. A grep for "http://" should be sufficient.

        Further reading/references:


        • Tip How to
        • Security Risks
        • DigiCert Code Signing
        • Error messages
        • Vulnerabilities & Exploits
        • Best Practice
        • Products
        • Malware Scan
        • Vulnerability Assessment
        • Symantec Website Security
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Managed PKI for SSL
      • CAA checking: what is it, and why should it be mandatory?

        May 22 2017, 10:29 PM

        by Rufus Connell 0

        The Public Key Infrastructure (PKI) ecosystem relies on root certificates issued by various certification authorities (CAs) like Symantec. This is what browsers use to decide which websites can be trusted, and which ones can’t.

        Currently, any CA can issue a TLS certificate for any domain. That’s how the system works, and it’s good in the sense that it gives website owners choice; they can change CAs if they want to. But the downside is that unregulated certification can lead to ‘mis-issuance’, either by mistake or by rogue CAs.

        A number of technologies have been created in an attempt to limit instances of miscertification, such as Certificate Pinning and Certificate Transparency. These have been effective in making the internet a safer, more trustworthy place but they’re reactionary. Both are only able to address mis-issuance after it’s happened.

        But is it possible to prevent certificates from being mistakenly or inappropriately issued? Yes. Enter: Certification Authority Authorization (CAA).

        CAA prevents mis-issuance by:

        1. allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and
        2. giving CAs the ability to check this authorization before issuing a certificate.

        In this article we’ll explain how CAA works, and why making CAA checking mandatory is a good move for both customers and CAs.

        What is Certification Authority Authorization?

        A Certification Authority Authorization (CAA) record is a DNS Resource Record. It allows a domain owner to specify which CAs are authorized to issue certificates for their domain and, by implication, which aren’t.

        The idea is that a CA will check the CAA record(s) for a domain before issuing a certificate. If it finds that a domain has no CAA record, then it’s free to issue a certificate for it if all other validation checks succeed. However, if it does encounter one or more records, then the CA can only issue a certificate if it’s named in one of the records, indicating that it is authorized to issue a certificate for that domain. The whole process is designed to prevent CAs from inappropriately or mistakenly issuing TLS certificates.

        Sounds great. Why isn’t everyone doing this?

        Symantec has been checking CAA records for years, but it’s not a common practice. There are two reasons why CAA checking isn’t widely practiced:

        1. many domains don’t have a CAA Resource Record; and
        2. checking the record is not mandatory.

        Because it may take some work to create a CAA record, it’s a matter of consciously opting-in, not opting-out. Many domain owners use a DNS hosting provider and CAA is not yet supported in some DNS implementations.

        This is why CAA records are expected to be used by most high-value domains. These enterprises keep CAA records for their domains because it limits inappropriate (or malicious) certificate requests, and makes it easier to enforce company policies i.e. only using a particular set of CAs.

        The limitations of CAA checking

        Of course, CAA checking has its limitations.

        For one thing, a newly-issued CAA record does not invalidate any previously-issued certificates that may have been issued by a different CA than the one named by the domain owner. Secondly, it doesn’t flag whether a certificate presented by a web server is a legitimate certificate for that domain.

        Furthermore, in order for CAA checking to be effective, all CAs need to be doing it; it doesn’t work if only one or two CAs are checking CAA records as matter of process. CAA checking must be widely adopted if it is to serve its purpose, but the good news is that more than ninety percent of CAs (who are members of the CA/Browser Forum) are in favor of it.

        The times are changing: CAA checking will become mandatory

        In February 2017, the CA/Browser Forum passed a motion (on which Symantec voted in favor) requiring all CAs (even those who aren’t a member of the Forum) to check for a CAA record as part of the certificate issuance process for each domain. In accordance with RFC 6844, CAs can no longer issue a certificate for a domain unless:

        1. The CA does not find any CAA records for the domain
        2. The certificate request is consistent with the applicable CAA Resource Record(s)

        The rule is effective as of 8 September 2017. You can read the motion in full here.

        A good outcome for all companies

        Mandatory CAA record checking requires CAs to abide by the rules set out in specific CAA records, giving domain owners more control over certificate issuance. This makes it easier for companies (especially larger ones) to enforce a certificate issuance policy across business units. With CAA records applicable to every domain, a company can whitelist a set number of CAs, knowing no other authority can issue a certificate. 

        On a broader level, the new rules will mean that CAs can properly reconcile a certificate request at the domain owner’s discretion, holding themselves accountable for any mis-issuance. At Symantec, we believe this is an important step towards a securer, more transparent online ecosystem.

        • Products
        • DigiCert Code Signing
        • Symantec Website Security
        • Best Practice
      • Whitepaper - Simplify SSL Certificate Management Across the Enterprise

        May 28 2014, 5:32 PM

        by Mithun Sanghavi 8

        The need for SSL Certificates has moved well beyond the “buy” page to core functions of the enterprise. SSL Certificates are used to protect remote employee and partner communications via webmail, chat and IM. Browser-to-server communications for cloud-based services require SSL Certificates when used to display customer account information, business partner transactions and for employee productivity tools. Finally, SSL Certificates are used to secure server-to-server communications for applications and data exchange. Managing individual Certificates across a large organization quickly becomes complicated with multiple locations, many divisions, and rapidly growing Web-based services. If an SSL Certificate expires, a company not only loses sales and puts customer confidence in jeopardy, employees and business partners may not be able to do their work or risk exposure of confidential information. Managing SSL Certificates across complex networks to ensure protection and prevent unanticipated expirations has become mission critical to all businesses.
        This guide provides five simple steps for IT professionals to take control of SSL across the enterprise, and recommendations for a management platform for full visibility and single-point of  control for these Certificates throughout their lifecycle.
        To know more check the attached Whitepaper.

        • Products
        • DigiCert Code Signing
        • Tip How to
        • Features
        • Symantec Website Security
        • Best Practice