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.
(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:
See References Below:
define( 'DISALLOW_UNFILTERED_HTML', true );
Unsafe API methods (require sanitising/escaping):
Safe API methods (according to WordPress):
Safe code, prepared statement:
<?php $sql = $wpdb->prepare( 'query' , value_parameter[, value_parameter ... ] ); ?>
Note: Before WordPress 3.5
$wpdb->preparecould 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(); ?>
PHP Object Injection
PHP Code Execution
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.
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_VERIFYHOSTif set to 0 then does not check name in host certificate
CURLOPT_SSL_VERIFYPEERif 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.
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:
- allowing domain owners to specify which CAs are authorized to issue certificates for their domains; and
- 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:
- many domains don’t have a CAA Resource Record; and
- 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:
- The CA does not find any CAA records for the domain
- 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.
May 28 2014, 5:32 PM
by Mithun Sanghavi 8Hello,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.