Cross-Site Request Forgery involves taking over or impersonating a user’s browser session by hijacking the session cookie. CSRF attacks can trick users into executing malicious actions the attacker wants, or into taking unauthorized actions on the website. In this example, the session cookie is the ‘vehicle’ an attacker uses to impersonate a legitimate user.
In this type of injection, an attacker could upload and execute malicious binary files on the web server. Vulnerable code is again the ‘vehicle’ used by the attacker in this example.
Client-Side Logic Issues
This risk comes primarily from the function’s use to evaluate user input. If a savvy user comes across a text field on your site that is running eval(), they could use it to execute malicious code. This is known as Cross-Site Scripting (XSS), and avoiding the use of the eval() is one way to safeguard your WordPress site from that kind of attack.
There are several security tools which will help examine your website (or web application) from the outside to determine if it is vulnerable to injection and attacks. Before getting started with any of these tools, be sure to check in with your web host to check their Penetration Testing policies. Below we will explore some of the top vulnerability scanning tools.
ZAP, or Zed Attack Proxy, was developed by security authority OWASP and offers the ability to easily scan your website for a wide range of vulnerabilities. This tool can be used by a wide range of user levels because of its intuitive interface, and is widely customizable to your project’s needs.
Grabber can scan your website for vulnerabilities ranging from SQL injection and XSS to AJAX testing and File inclusion. Grabber tends to be a slower scanner than others, so it should only be used on smaller websites or web applications.
Wapiti allows users to test attack and injection vectors using both GET and POST HTTP Requests. It detects File Disclosure and File Inclusion, XSS, weak Apache configurations, and more. This is a more advanced tool that is executed via command line.
Avoid using eval()
The eval() function is used by developers to run text as code, which is by nature a dangerous practice. In most cases, substitutions can be made to where these functions are not needed. Wherever possible, replace eval() with more secure functions.
SSL, or Secure Sockets Layer, is a way of encrypting the data users send across the web when interacting with your website. It is extremely important for pages where users input data (login pages, contact forms, cart, checkout, account) to be secured with SSL.
Use CORS Headers
CORS, or Cross-Origin Resource Sharing, is a header you can set that defines the sources allowed to reference your website’s resources. These rules can be placed in your Nginx configuration file, or if you use Apache, in your .htaccess file:
Define a Content Security Policy
Content-Security-Policy: default-src: 'self'; script-src: https://apis.google.com;
Another way you can ensure user information is encrypted is by restricting the use of your cookies to secure web pages only. This means the cookie will not be sent if the page is not using SSL/HTTPS. To specify a cookie as “Secure,” or only sent over HTTPS, you can use the following syntax:
document.cookie = "tagname = test;secure";
For reference, the following attributes can be used when setting a cookie:
- Secure – The Cookie will be sent in secure channel–HTTPS
- HttpOnly– Don’t allow local scripts read cookies.
- Domain– Double-check the domain settings.
- Path – Double-check the path settings.
- Expires – Determine the user agent how to parse or how to choose the expiry-time.
The most commonly-used option is to set an API Access and Secret Key pair. These keys allow access to the API, and assign an individual secret token to each end user. If the Access and Secret Key pairs don’t match up, the access to the API is revoked or denied. Companies like Google and Facebook commonly use this method for validation of end users. While Facebook primarily depends on the Secret Key assigned to each user, Google tends to use a Secret Key on the actual server, via OAuth. The key management option is likely the best for organizations with wide, possibly unknown user bases.
Restrict Access to Specific IP Ranges
If your API will only be used within a specific group or building, you can manage API security by simply maintaining an IP whitelist of allowed IP addresses. This option can be tedious if the IP addresses tend to change often however, so it is best for limited groups of known users that don’t change often.
Rate Limit IP Addresses
Another less cumbersome option for API security would be to rate limit IP addresses, so they can only access the API a limited number of times per day before being blacklisted. Before implementing this type of system, you should gather usage statistics to determine if there is a distinct difference between users who really like your API, and attackers who are trying to exploit or abuse it.
WP Engine, is a top managed WordPress host that is serious about security. Our dedicated security team monitors for vulnerabilities to notify customers of any concerns. Additionally, our platform automatically keeps WordPress up to date with the latest functional and maintenance updates to ensure your website is secure.
Ready to learn more? Check out WP Engine hosting plans.