Huge Awake / Wakeup Call for all the webmasters!
It’s been thirteen years now that Word Press is standing tall in the market. This is the fourteenth time OWASP is raising awareness of security risks. In this session, we will elucidate you, about how your website is being exposed to vulnerability, its impacts on it and how to prevent it from affecting your most valued websites.
Our Blog: We assure you that, by the time you conclude the blog by comprehending it entirely, you will very well be aware of the ongoing security vulnerability and how to avert it.
The first and most dangerous in the list is Injection.
Injection attacks refer to a broad class of attack vectors that allow an attacker to supply untrusted input to a program, which gets processed by an interpreter as part of a command or query which alters the course of execution of that program. They can result in data theft, data loss, loss of data integrity, denial of service, as well as full system compromise.
SQL Injection (SQLi) refers to an injection attack wherein an attacker can execute malicious SQL statements (also commonly referred to as a malicious payload) that control a web application’s database server (also commonly referred to as a Relational Database Management System – RDBMS). Since an SQL Injection vulnerability could possibly affect any website or web application that makes use of an SQL-based database, the vulnerability is one of the oldest, most prevalent and most dangerous of web application vulnerabilities. SQL Injections can manipulate data (add, update, delete) and corrupt or delete tables of the database.
According to a survey conducted by Ponemon 65 percent of the organizations represented in the survey had experienced a SQL-injection attack in the prior 12 months. That research was published two years ago, but should still be able to be used as estimation.
“Injection flaws, such as SQL, OS, XXE, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization” – in accordance with OWASP.
- Authentication bypass
- Information disclosure
- Data loss
- Data theft
- Loss of data integrity
- Denial of service
- Full system compromise.
How to avert?
(i) Never trust user input. (ii)Avoid constructing SQL queries with user input. (iii)Employ comprehensive data sanitization. (iv)Use a web application firewall. (v)Regularly apply software patches. (vi)Continuously monitor SQL statements from database-connected applications. (vii)Limit database privileges by context. (viii)Validate input strings on the server side. (ix)Use the principle of least access when granting database access. (x)Use testing and monitoring to guard against SQL injection
SQL injection has been around for decades and will likely continue to top the vulnerability charts for years to come. It takes a few easy, but well-calculated steps to protect yourself and your users against it. It should be among your top priorities when auditing your source code for security holes.
The key to avoid being the victim of the next huge SQL injection data breach is
- Control and validate user input.
- To be prepared for the “when it happens,” not the “if it happens.”
A2 – Broken Authentication and Session Management
The Second on the list is broken authentication and session management.
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users identities. Account credentials and sessions tokens are often not properly protected.
“Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently)” – in accordance with OWASP
- A third party can access to anyone’s account
- Attacker compromise password, keys or authentication token
- Undermined authorization and accountability controls
- Cause privacy violation
- Identity Theft
Method of attack:
- Use weaknesses in authentication mechanism
- Password Management
- Remember me
- Secret question and account update
How to avert?
(i) A single set of strong authentication and session management controls. (ii)Password Strength (iii) Password Use (iv) Password Change Controls (v) Password Storage (vi) Protecting Credentials in Transit (vii) Session ID Protection (viii) Account Lists (ix) Browser Caching (x) Trust Relationships.
Securing authentication and session management is a broad, complex area of security, but it is essential to preserve the identity and trust of the user. Always follow good practices to protect your users’ identity, including their passwords and session IDs. Hash passwords, encourage good password selection, require re-authentication to change passwords, force users to change their passwords when trying to recover accounts, never put a session ID in a URL, ensure all session IDs originate at the server, timeout and rotate session IDs at intervals and security context changes, use safe encrypted connections, and disable browser caching.
Educate both developers and users about good security practices whenever possible, and be quick to patch vulnerabilities as soon as you are made aware of them. It is vital that your users be able to trust you with their information.
A3 – Cross-Site Scripting(XSS)
The third security threat in the survey of Plug-in vulnerabilities is cross-site scripting, usually referred to as XSS.
When attackers successfully exploit XSS vulnerabilities in a web application, they can insert script that gives them access to end users’ account credentials. Attackers can perform a variety of malicious activities, such as:
- Hijack an account
- Spread web worms
- Access browser history and clipboard contents
- Control the browser remotely
- Scan and exploit intranet appliances and applications
How to avert?
With dotDefender web application firewall you can avoid XSS attacks because dotDefender inspects your HTTP traffic and determines if your web site suffers from cross-site scripting vulnerabilities or other attacks to stop web applications from being exploited.
Architected as plug & play software, dotDefender provides optimal out-of-the-box protection against cross-site scripting, SQL Injection attacks, path traversal and many other web attack techniques.
The reasons dotDefender offers such a comprehensive solution to your web application security needs are:
- Easy installation on Apache and IIS servers
- Strong security against known and emerging hacking attacks
- Best-of-breed predefined security rules for instant protection
- Interface and API for managing multiple servers with ease
- Requires no additional hardware, and easily scales with your business
Potential dangerous characters need to be sanitized, or escaped. The application should also be developed with the risk of XSS in mind, making it as little harmful as possible if it were to exist a XSS vulnerability. Most popular websites use and display content that is created by their users. This can create some issues since malicious users can submit content that other users’ browser could execute as content provided by you and have undesired security effects. It is easy but very important to sanitize any user submitted data before delivering it to other users through your website.
A4 -Broken Access Control
The fourth in the list is Broken Acess Control
Access control, sometimes called authorization, is the means by which a web application grants access to specified content and functions to some users and not others. Access control governs what “authorized” users are allowed to do.
“Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc” – in accordance with OWASP
Virtually all sites have some access control requirements. Therefore, an access control policy should be clearly documented. Also, the design documentation should capture an approach for enforcing this policy. If this documentation does not exist, then a site is likely to be vulnerable.
The code that implements the access control policy should be checked. Such code should be well structured, modular, and most likely centralized. A detailed code review should be performed to validate the correctness of the access control implementation. In addition, penetration testing can be quite useful in determining if there are problems in the access control scheme.
Find out how your website is administered. You want to discover how changes are made to webpages, where they are tested, and how they are transported to the production server. If administrators can make changes remotely, you want to know how those communications channels are protected. Carefully review each interface to make sure that only authorized administrators are allowed access. Also, if there are different types or groupings of data that can be accessed through the interface, make sure that only authorized data can be accessed as well. If such interfaces employ external commands, review the use of such commands to make sure they are not subject to any of the command injection flaws described in this paper
How to avert?
- Insecure ID’s
- Forced Browsing Past Access Control Checks
- Path Traversal
- Limit file permissions on web files
- Client Side Caching
Other tips for securing access control:
- Check authorization on every page of the application.
- Note that users can supply their own URLs, including unexpected ones. Check them.
- Do not inadvertently become a proxy for services behind a firewall.
- Only allow short amounts of time for token sessions.
- Destroy tokens on the server side on user logout.
- Remove all demo/debug code before going live with an application.
- Change/verify defaults in third party code or applications. E.g., be default, the Mysql root account does not require a password when connecting from the local host.
- Do not use higher privileges than are necessary. Web servers should run using a low-privilege account. Web applications should access database resources using an account with minimal privileges required by the application.
- Limit file permissions on web files.
- Do not create session id’s based solely on user input. Force a “sufficiently random” session id. Avoid any guessable id’s such as a time stamp or other sequential formula.
- Do not use timestamps as a token. Timestamps can be used in generating a token, but timestamps alone are easily guessable and may not be unique. Timestamps should be used for expiring tokens.
- Verify the session. Do not trust IP addresses. DSL and AOL users may have their IP addresses change at unpredictable times. Dial-up users are also likely to have an odd IP address.
- Do not embed database or other IDs or passwords in application code.
Preventing access control flaws requires selecting an approach for protecting each function and each type of data. Each use of a direct reference from an untrusted source must include an access control check to ensure the user is authorized for the requested resource. This coding pattern prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. Leverage automation to verify proper authorization deployment. This is often custom.
The fifth in the list is Security Misconfiguration
Security misconfiguration is simply that – incorrectly assembling the safeguards for a web application. These misconfigurations typically occur when holes are left in the security framework of an application by systems administrators, DBAs or developers. They can occur at any level of the application stack including the platform, web server, application server, database, framework and custom code. These security misconfigurations can lead an attacker right into the system and result in a partially or even totally compromised system
“Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date” – in accordance with OWASP
Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, and framework.
Many applications come with unnecessary and unsafe features, such as debug and QA features, enabled by default. These features may provide a means for a hacker to bypass authentication methods and gain access to sensitive information, perhaps with elevated privileges.
Likewise, default installations may include well-known usernames and passwords, hard-coded backdoor accounts, special access mechanisms, and incorrect permissions set for files accessible through web servers.
The impact varies and depends on the specific kind of misconfiguration. At worst, it could lead to a full takeover, which means stolen sensitive data and expensive recover.
How to avert?
- Make sure everything is updated. Build the system in such way that software updates and patches can be deployed in a timely manner.
- Use the very same configuration for staging, production and developing environments. Inconsistencies are a common reason for the introduction of many misconfigurations.
- Automate what can be automated. Humans are good at making mistakes, and if the same setup procedure is performed often, it is better to make sure it is secure once and then just repeat it.
- Doing scans and/or audits regularly to discover future misconfigurations.
- When possible, configure the system with the thought in mind that the system will get compromised because that is very likely. In case of a security breach, an attacker should only be able to do very little damage.
Modern software is increasingly complex and as such, has an increased attack surface area. The good news is that most “production-ready” software comes pre-baked with security mechanisms. The bad news is that there are tons of settings and many organizations don’t take the appropriate time to properly configure these systems. Part of this is because the sheer number of configurations. Also, it can be time consuming and expensive to read up on security documentation, especially if you don’t have experience with a specific technology.
A6-Sensitive Data Exposure
The sixth in the list is Sensitive Data Exposure
Sensitive Data Exposure occurs when an application does not adequately protectsensitive information. The data can vary and anything from passwords, session tokens, credit card data to private health data and more can be exposed.
“Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser” – in accordance with OWASP
We can make the distinction between two types of data:
- data that is stored (at rest)
- data that is transmitted (internally between servers, or to web browsers)
In both cases, problems occur when sensitive data (banking information, health records, Personally Identifiable Information) is not sufficiently protected:
- if transmitted or stored in clear text
- if encrypted or hashed with a weak algorithm
What you must understand is that an attacker will try the following:
- decrypt data stored on a server (previously stolen through other kind of vulnerabilities),
- intercept data between a server and the browser (of between servers)
- trick your web application to do several things like changing the content of a cart in an e-commerce application, or elevating their privileges.
As the finding only applies to sensitive data, the potential impact is always considered high. What the data consists of varies and so does the impact. The danger lies in the data being exposed, and the potential impact reflects the data’s sensitivity.
How to avert?
- It is advised not to store sensitive data unnecessarily and should be scraped as soon as possible if it is no more required.
- It is important to ensure that we incorporate strong and standard encryption algorithms are used and proper key management is in place.
- It can also be avoided by disabling autocomplete on forms that collect sensitive data such as password and disable caching for pages that contain sensitive data.
In summary, sensitive data exposure can be difficult for attackers to exploit, but they’re highly motivated because of the potential payouts. Don’t store sensitive data if you don’t need it. Be sure to encrypt the necessary sensitive data during storage, transit, and display
A7-Insufficient Attack Protection
The seventh in the list is Insufficient Attack Protection
Insufficient Attack Protection refers to the inability to detect, prevent and respond to various kinds of attacks against the application as a whole. This – due to the large number of unaudited third-party components that may contain critical vulnerabilities – necessitates the use of generic security tools such as intrusion detection systems (IDS), and web application firewalls (WAF) that can identify an ongoing attack such as SQL injection. It focuses on the consequences instead of the root causes of the weaknesses.
“The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks” – in accordance with OWASP
- If you are not prepared for attacks or worse if you negate being a potentially target.
- If you have not compiled an overall security architecture that includes all involved components. This components include all OSI layers from application until network and even physical security.
- If you don’t try to see your application from the attackers side.
- If you are not prepared to destructive attacks, e.g. (distributed) deny of service attacks.
- If you aren’t able to detect attacks.
- If you don’t define nor test you processes for Cyber Emergencies.
- If you solely rely on automatic detection and prevention systems or web application filters.
How to avert?
There are three primary goals for sufficient attack protection:
- Detect Attacks: Did something occur that is impossible for legitimate users to cause (e.g., an input a legitimate client can’t generate)? Is the application being used in a way that an ordinary user would never do (e.g., tempo too high, atypical input, unusual usage patterns, repeated requests)?
- Respond to Attacks: Logs and notifications are critical to timely response. Decide whether to automatically block requests, IP addresses, or IP ranges. Consider disabling or monitoring misbehaving user accounts.
- Patch Quickly: If your dev process can’t push out critical patches in a day, deploy a virtual patchthat analyzes HTTP traffic, data flow, and/or code execution and prevents vulnerabilities from being exploited.
The majority of applications are not prepared for attacks some even negate being a potentially target. The preparation starts best while designing the application adding defense in depth capacities (more than one security control supporting each other). There should be the ability to detect, prevent, and respond to both manual and automated attacks.
A8-Cross-Site Request Forgery(CSRF)
The eight in the list is CSRF – Cross Site Request Forgery
Cross Site Request Forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that tricks a web browser into executing an unwanted action in an application to which a user is logged in.
A successful CSRF attack can be devastating for both the business and user. It can result in damaged client relationships, unauthorized fund transfers, changed passwords and data theft—including stolen session cookies.
CSRFs are typically conducted using malicious social engineering, such as an email or link that tricks the victim into sending a forged request to a server. As the unsuspecting user is authenticated by their application at the time of the attack, it’s impossible to distinguish a legitimate request from a forged one.
“A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim” – in accordance with OWASP
- Read all cookies (that are not protected by Httponly), including session cookies. By doing so, an attacker could take over the session.
- View anything the user sees, and steal sensitive information by doing so.
- Change what the user sees and manipulate information.
- Basically do everything a normal user could, as the attacker can both see and change anything presented to the user. This includes bypass of all CSRF-protections. To put it into context; if the attacker successfully tricks an admin to execute the XSS, the attacker can do everything an admin could do.
- Do things that the vulnerable domain has access to do, which can buy access to the user’s webcam, microphone or location.
How to avert?
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
A9-Using Components with Known Vulnerabilities
The second last in the list is Using Components with known vulnerabilities
The issue is that modern software is made up of dozens, if not hundreds, of third-party components. Even if the code we write is secure, the other components we are using may not be. We might be using an out-of-date version of a library that has a known vulnerability. Or we might be using a component that depends on another component that has a known vulnerability. It can be hard to keep track of all the dependencies in our code, much less keep up-to-date with all the versions and the potential problems with those versions.
“Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts” – in accordance with OWASP.
- If the components, framework, etc. of an application are not properly designed in a secure way, then the attacker takes this as an advantage to break your system.
- If the exposed service methods are not properly validated with strong tokens, the hacker has an opportunity to break your system.
- If the application is not tested end to end properly, to validate such attacks, then the attacker may again take advantage and break your system.
- Open SSL library. A software component often used to help secure data used by web applications. In 2014 the Heartbleed bug was discovered in OpenSSL. This bug allowed data encrypted with the SSL/TLSroutines in OpenSSL to be compromised. It’s since been fixed. Update your OpenSSL if you haven’t yet!
- BASH Unix shell. The venerable BASH shell,that has been in use for two decades, was discovered in 2014 to have vulnerabilities that allowed command line injections to execute commands. These were dubbed Shellshock. The BASH shell has since been patched to address the issues. Again, update BASH if you haven’t done so recently.
How to avert?
- Identify all components and the versions that are being used in the web apps not just restricted to database/frameworks.
- Keep all the components such as public databases; project mailing lists etc. up to date.
- Add security wrappers around components that are vulnerable in nature.
Most component projects do not create vulnerability patches for old versions. Instead, most simply fix the problem in the next version. So upgrading to these new versions is critical. Software projects should have a process in place to:
- Identify all components and the versions you are using, including all dependencies. (e.g., the versionsplugin).
- Monitor the security of these components in public databases, project mailing lists, and security mailing lists, and keep them up to date.
- Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.
- Where appropriate, consider adding security wrappers around components to disable unused functionality and/ or secure weak or vulnerable aspects of the component.
The benefits of using external components in your projects are undisputable, but it is essential to remain vigilant about what vulnerabilities you allow into your systems. Stay informed about the components you use and make sure you address reported issues appropriately, either by using the latest versions and fixes or by adding your own layer of security.
The tenth and the last in the list is Underprotected APIs
An API, or “Application Program Interface”, is a set of routines and protocols that provide building blocks for computer programmers and web developers to build software applications.
The area of security vulnerabilities is a diverse field. There are many different attacks with different methods and targets. One way to categorize vulnerabilities is by target area:
- Network / OS / Driver: issues in the operating system and network components (e.g. buffer overruns, flooding with sockets, DOS attacks)
- Application layer: issues in the hosting application server and related services (e.g. message parsing, session hijacking or security misconfigurations)
- API / component: functional issues in the actual API (e.g. injection attacks, sensitive data exposure, incomplete access control)
How to avert?
The key to protecting APIs is to ensure that you fully understand the threat model and what defenses you have:
- Ensure that you have secured communications between the client and your APIs.
- Ensure that you have a strong authentication scheme for your APIs, and that all credentials, keys, and tokens have been secured.
- Ensure that whatever data format your requests use, that the parser configuration is hardened against attack.
- Implement an access control scheme that protects APIs from being improperly invoked, including unauthorized function and data references.
- Protect against injection of all forms, as these attacks are just as viable through APIs as they are for normal apps.
Be sure your security analysis and testing covers all your APIs and your tools can discover and analyze them all effectively.
Jeff Williams, a creator of OWASP Top 10 recently said that APIs represent “a major blind spot” for security programs in organizations, and OWASP is helping to refocus teams on this expanding problem.
In this Blog,
We have listed the top 10 Plug-in threats and how it is affecting the WordPress website.
It’s worth to stick already with the security protocols to prevent major security issues from happening, which is also advised by OWASP.
What we have shared is gathering of our knowledge to help others. Any comments on what we might have forgotten to mention are greatly invited.
Many might have enough personal experience already to share or mention a thing or two which we forgot to write.
We will be glad to receive those comments, that way many might be benefited.
This article clarifies the significance of hardening of WP of your most valued website and how it saves your man-hours, money and avoiding the post-attack remedial measures.
Simply put, WordPress runs near about 28 % of the entire internet. Around 15,886,000 websites on the entire websites use WordPress. The concerned part is that only 22% of the WP sites are running with an updated version. More than 70% of the WP websites are vulnerable to hack-attacks.
Web Security will never be comprehensive. It’s all about the risk management. Risks will never be nullified, but can be prevented, unless you regularly follow the process of securing your WP website using the potential tools and tips.
Let’s see some of them in this article.
A. What does Hardening mean?
B. What makes WP a target for hackers?
C. How your WP website might be a potential Target for hackers to breach-in?
D. Ways to harden the security of your WordPress website
F. Your website is hacked, What next?
G. Wrapping up
(A) What does Hardening mean?
Providing different ways of protection in a computer device is called Hardening. A more secured computer system is called a hardened system. The protection will be in multiple layers, starting from the host level to the next level which is application level and then to the OS level and the user level and goes further to all the sub-levels.
(B) What makes WP a target for hackers?
About 28.6% of all the websites, used across the globe, primary uses WordPress platform.
Market share: WordPress – 59.4%, Others – 30.3%, Joomla – 6.8%, Drupal –4.7%
Latest report elucidates that WordPress based websites who are using “version 4” accounts to 92.7% – Survey by W3Techs.
A recent report by WP White states that most popular WP are vulnerable to attacks. There are totally 40000 popular WP out of which 73% of it are considered security threats.
Below are few stats, given for your understanding about the significance of hardening.
Nearly 15886000 websites in the internet world are using WP. There are near about 77 million WordPress.com blogs. Everyday 5000 new WordPress.com websites are launched. In 2014, it was estimated that totally 123,498,018 themes and more than 1 Billion plug-ins were downloaded from wordpress.org
The sad part to tell is that, only 22% of the entire WP websites are running on the latest version. The condition of more than 70% of the total WP websites are vulnerable and are prone to be hacked any moment.
The latest Update of WP is version 4.8.1. Download it @ https://wordpress.org/download/
(C) How your WP website might be a potential Target for hackers to breach-in?
As I have said before that, WP Security Hardening does not mean to nullify the threats from happening, but to take precautions and preventive measures to lock down your Word Press website to avoid vulnerabilities and getting hacked.
Securing one’s valuable website is the primary concern these days. The worst nightmare for a WP web-owner is to get his site hacked.
Don’t ever think that getting hacked will be highly unlikely. Hacks are very common and a frequent scenario these days. Your valued website may be hacked any moment now.
By following certain security practices and norms, your WP websites may not be a potential target. In section (E) the security practices are given for your guidance.
(D) Ways to harden the security of your WP website:
Let’s discuss about the key points straightly and the security practices for Hardening your WP website from any malicious attacks. Follow these steps systematically to tighten your security, thereby not giving any chance for the intruders.
- Update – Update the WP Core, WP Themes and WP Plug-ins regularly. Analyzing the threats, most usual cause for a WordPress hack-attack is due to an outdated component. The files when not updated regularly, are easily traced and becomes a potential target for the attackers.
- Install – Install the Plug-ins and Themes only from Trusted and reputed websites. Try using wordpress.org for installing plug-ins and themes, when you plan to download from a trusted site.
- Remove – Remove the unused Plug-ins and Themes. Even your WordPress websites need housekeeping. As you keep on installing newer plug-ins and themes, delete the older ones which are no longer needed. Inorder to detect the unused plug-ins used in your website, provided you are using many WP sites, it is advised to use a plug-in like Plugin Activation Status to conduct an audit and give results of the plug-ins which are no longer used and to be removed.
- Install – Install a WP Security Plug-in and run malware scan at periodical intervals. Try using iThemes security, Bulletproof security, All in one WP security & Firewall, Securi, Acutenix WP security, Wordfence Security plugin
- Backup – Periodically backup your WP website. Considering the online security, there is never 100%. It is recommended to do a backup on daily basis, provided there are multiple updates every day.
- Strengthen – Strengthen the Username and Password. The attacker easily tries numerous times to access your login page brutally by the use of different combinations of user login and passwords again and again. This is called Brute-Force attack. It’s wise to prevent such attacks by creating a very strong, complex, long and unique passwords using password generator. Absolutely avoid the use of username as “Admin”. By doing this, you are giving half the access in the hands of hackers making him to work on the password only.
- Hide – Hide your WP version. One good practice is to hide the version your sites’s WP being used, thereby you are not displaying the current version which creates a hurdle to the hackers.
- Use – Use Secure Protocols (HTTPS). Usually when you attempt to make a connection to a website, it is normally done through HTTP protocol. It is unencrypted. Also, your password will be sent in a simple text. Similar thing happens when you log into your database via “phpMyAdmin”. It is highly recommended to use HTTPS (secured http) which encrypts your connection and keeps your network protected from any intruders from snooping around.
- Implement – Implement Two Factor Authentication. It creates a double layer protection. By enabling 2FA, it requests for a second level of information which can be provided only by you and forms an additional security. It sends a code to your mobile phone to verify activity on a particular computer device. This makes harder for the attackers in an effort to steal your credentials, by logging from a different device.
- Limit – Limit the login attempts. Though we try to stop the brute-force attacks, many determined attackers will never rest, until they get what they want. Limit Login acts as a shield to protect from these multiple login attempts by restricting the number of logins and even black-lists their IDs. By doing this, you might lose your trusted customers. It will be wise to white-list the authenticated customers IDs alone.
- Check – Check File permission. The scheme of permission will be 755 and 644 folders. There a many ways to manage this change and also variations to these permissions which comprise to changing them to more restrictive. However these are the default advice given.To avoid unfavorable effects on the performance of your website, check with the host before making any permissions change.
- Move – Move “wp-config.php” file outside the web root folder. It is to be noted that the file “wp-config” contains the details of base configuration of your website. In a measure to protect your “wp-config.php” file from any intrusion, it is recommended that you add the below mentioned code to your “.htaccess” file to deny access to anyone snooping around for it:
deny from all
- Use – Use a Web Application FireWall (WAF). A WAF must be located at the web server layer as it is not usually available to the implementer. To add protection, a WAF plug-in can be utilized, which blocks the threats as listed in the top 10 chart of vulnerabilities.
- Use – Using Logs to detect and avoid attacks. Most of the WordPress admins completely neglect the web logs. They are a sensitive source of data. Web access log and error log are the two most significant logs which are available.
You may need to communicate with the hosting provider and request them for the location and to have access to these logs. It is to be noticed that few Hosting environments create many error logs in many directories on your sites and it all depends on error occurrence.
The access log contains more information than error log. If you are searching for any malicious activity, it is wise to start with error log, as it is written when a problem takes place.
- Use – Use SSH and SFTP. Never use old FTP. Ensure that you use a SFTP connection (secured FTP) everytime you connect to your server. This makes sure that the connection between your computer and the server is secured.
There are a few ways to connect.
FTP – This sends all the information in plain text so that anyone can see it as it is unencrypted. You may use any FTP client to communicate to your server via port #21.
SFTP – It is highly recommended that you connect to your server using SFTP. Many clients who support FTP also supports SFTP via port #22.
For better understanding consider referring the below links,
A Infographic will help you for better understanding.
(E) DIY (Doing It Yourself)
WP can be monitored, updated whenever needed and can be protected from the hackers. But the protection can be compromised by hackers at any moment, as they wait for single window of opportunity for an intrusion every second.
Hence, you have to be prepared for everything. DIY the security norms and practices, at regular cycles as suggested above for preventing hack attacks, and the post-attack remedial measures, as given below will keep your website on the healthy run.
(F) Your website is hacked, what next?
It is always advisable that the security experts does this part of work for you. But, understanding and gaining knowledge doesn’t harm anything. Following are some of the steps to cleanup the hack and get back on the track.
- When you come to know that your website is hacked, you would be in immense stress and tension, so I suggest you calm down a bit and execute this process before it reaches any further.
- Always use different login password before and after the cleanup.
- Identifying the hack. There are a few ways to verifying and ask for the hosting company for assistance. 1)Are you able to login to your WordPress admin panel?. 2)Check if your WP site is getting directed to another site?. 3)Whether your WP website contains any unauthorized links? 4)See to that your website is marked insecure by Google.
- Restore from Backup. Its wise to take backup of your site daily or at regular periods, provided you are posting a new content or making any alterations in your website. By doing this, it will be easy to restore your valuable website from the backups done by you, from the archives.
Consider that you are having an automated backup which is scheduled, and if your site is hacked, try to recover your website by using the backup files available, one day/week/month before the actual attack happened. In case you are not good at taking backups, you may contact your host and request them for a backed up copy of your website. Many good hosts take systematic backups and updates.
- The Host: Initiate by making a contact to your host and follow their guidelines. If you are shared hosting, then probabilities are more for the other sites also to get affected. In that case, you might be fortune enough that the host themselves might cleanup the hack for you. Consider the attack happening from the server side, under regular circumstances, the web host must help you in restoring your websites.
- Malware scan and elimination of the hack: One of the common locations, where hacker hide their backdoor is in the inactive WP Plug-ins and themes. So run a scan and check your WordPress website for any inactive or outdated plugins and themes and delete the same. Uploading the backdoor at the first thing is what many talented hacker do. Run the security scan for the removal of the hack and the result projects the hiding locations of the hacks. Some of the most usual locations where the hacks normally hid are ” wp-includes”, “.htaccess” file, “wp-config.php”, “themes” and “plug-in” directory,”upload” directory.
- User permission check
Checking the user permissions of all your WordPress users is recommended. Ensure that the admin accounts are accessed by you and your team. Also it should not affect other user’s permission.
Try removing immediately if any suspicious new users are identified.
- Alter your keys:
Ensure that you alter the login passwords in accordance with your WP website which includes your WP dashboard password, FTP, cPanel, My SQL database and any others that might give an access for an intrusion to your website.
Its highly recommended to use a password generator to make sure that the password is long, unique, strong for a hacker, making it a tougher job to crack it using brute-force.
Try using ithemes security plugin for ensuring your WP site being secured by changing you secret keys and salt.
Having followed these steps, the hack has being cleaned and that your WordPress website is secured. Don’t ever think that the hackers wont try an attack again. The security of WordPress is a continuous process and those with a cruel intent will never cease to make an intrusion to your website.
(G) Wrapping up
Always remember that Security is an ongoing process and you can’t completely nullify the vulnerability. Having said that, you can’t just stare at your website, being crushed by some stranger. Yes, I understand how it aches you. By periodically adhering to the security norms and practices of hardening of WP, you possibly can avoid the hackers from breaching into your website.
WP is a very popular CMS and knowledge about its security is widely available. Be aware of all the security practices and apply them in your workforce. All these can be attained only if You take efforts. So simply said “SEC_RITY” will be imperfect without “U”.
Owning a WordPress site is mere a very easy thing, but the real difficulty comes it comes to safety. Its high time that YOU take security seriously and learn all the norms and practices to prevent any intrusions.
In this blog of the tightening of WordPress,
We are pretty sure that you would have gained ample information relating to WordPress vulnerabilities and its prevention techniques.
Hope you found it very resourceful.
We have suggested what we knew.
I’m also sure that you would have many personal experiences, hardening the WordPress.
If you feel that we have forgot to mention some suggestions, feel free to express yourself by sharing us all your thoughts,ideas by commenting us.
How do you Harden the WordPress?.
How a Security login plug-in becomes insecure.
Loginizer – Briefed
Word Press.org states that “Loginizer is a WordPress plugin which helps you fight against brute-force attack by blocking login for the IP after it reaches maximum retries allowed. You can blacklist or whitelist IPs for login using Loginizer. You can use various other features like Two Factor Authentication, reCAPTCHA, PasswordLess Login, etc. to improve security of your website”.
I will try to explain in simple terms,
It is usual these days that the WP site is prone to vulnerabilities, provided your website is popular. Attackers will try to penetrate your most valued website commencing the login page. There are many plugins and scripts that let you protect your login page from such hack-attacks.
Loginizer is a plug-in developed to secure your login page from the brute-force attacks.
This plug-in, after attempting a few failed logins, immediately blocks IPs and also notification is given when someone is locked out. White-listing and black-listing IPs or IP ranges are available.
The features of the loginizer plug-in:
- reCAPTCHA integration in a very lesser time.
- Restricts a number of login attempt and blocking IPs.
- Since the login attempt is reduced, Bot iteration is blocked – Brute Force protection.
- Admin will be intimated if there is any difference of WP core.
- Using this plug-in you disable XML-RPC.
- Pingbacks disabling.
- Able to White-list and Black-list IPs or IPs range.
- E-mail intimations for misusing IP’s.
How Vulnerable your website is at?
Loginizer is a WordPress Plug-in which is actively used by 550000+ WordPress websites.
The unhappy part to tell is that, they possibly might be using an outdated version 1.3.5 and are prone to vulnerabilities any moment now.
Precisely, on daily basis, near about 10000 to 12000 downloads are done.
If you feel that you might be in this; your website might be under threat; the question you have to ask yourself is, what have you done about it?.
The latest audit on LOGINIZER emerged to contain Cross-Site Request Forgery (CSRF) and a SQL Injection vulnerability. In the Loginizer, version 1.3.6 and before, SQL Injection exists for WordPress via the “X-Forwarded-for HTTP” header.
What has to be done?
Immediate Update (IU) is the Only Possible Remedy (OPR)
ASAP, upgrade to the latest version of the plug-in: version1.3.8 to avoid hacker’s abuse.
According to the NIST – National Institute of Standards and Technology – NVD – National Vulnerable Datacentre, the vulnerability is currently awaiting for analysis.
So, instead of using the post-attack measures, follow the practices, norms and protect your website from any hackers using the preventive steps.
Whether Vulnerability was fixed?
Yes. The vulnerability was fixed in the updated version1.3.6 and using the security protocols it was rectified and made free from the bug.
The following features were updated to the latest version 1.3.6, which was prone to attack.
- Pagination was added to the Blacklist and Whitelist IPs.
- The Vulnerability regarding the SQL Injection fix for “X-Forwarded-For” found by Jonas Lejon was fixed.
- The missing referrer check was fixed in Blacklist and Whitelist ID Wizard.
The vulnerability about the Plug-in version 1.3.5 was discovered on 02-08-2017.
The same was fixed on 07-08-2017 using an updated version 1.3.6 and a blog was posted on the next day 08-08-2017.
Hope this blog clarifies you, that even the security plugin is causing insecurity and in turn how it harms the WP website.
It is always recommended to stick to the security norms, especially the updates, for averting such issues.
Thus, we have discussed, how the login protector fails to protect. We have suggested what we knew.
You might have several personal experiences and close encounters or even heard one or two.
Feel free to share those comments and the suggestion which you feel we forgot to mention, that way many might benefit from it.
What do you think is the best practice to avoid such mishap in the future?.
We all know that Word Press Plug-in is the heart of Content Management System (CMS).
WordPress is standing huge in the market for over thirteen years. It is persistent amid other platforms. This is possible due to the WP Plug-ins.
Typically from my personal experience of handling numerous security based battles, I would always like to recommend you to look in for the MRV – Most Recent Version. Once you are an MRV fanatic, then getting hacked won’t be a concern for you anymore, provided you must have a keen prospect of whether the current updation is affecting your other plug-ins in any way or the other.
How plug-in can break your website?
In this world, everything comes with a price and incorporating plug-in is a costly concern.
Let’s look at many factors to get a definite understanding.
The question which is lingering in many minds is, what are the minimum and maximum number of a plug-ins should we install on a website?. What will be the consequence of adding a many plug-ins?.
Installing a new plug-in, updating your existing plug-in and updating your WordPress, breaks your website. This even applies for huge sites too.
Downloading the plug-in:
I strongly recommend you to download the plug-ins from an authorized WordPress repository, as the source of your downloaded plug-in can impact on the quality.
Consider you are in search for a plug-in and install it from WordPress dashboard, it will always come from the wordpress.com/plug-ins repository.
If you install a plug-in from an unauthorized source, it naturally opens up the door for malware installation and intruders.
1) About the recent update
The primary thing to consider is to verify about the last update.
It’s the plug-ins which needed to be developed soon after the development of WordPress to keep in-line.
The security loopholes are to noted and everything that is affecting the security, must be updated constantly.
In a situation where a plug-in has been outdated since the previous year, an alarm must be raised.
A banner alert has to be made on the top of the page, considering a plug-in, not updated more than a year.
2) Test against your existing version of WordPress?
Every time you download a plug-in, you can see a section providing information about the version compatibility.
The following can be viewed:
- Last updated
- Active Installs
- Requires WordPress Version
- Tested up to
Always be conscious that, the version you are downloading is compatible with the existing version of the WordPress, as it may lead to many issues.
3) About the ratings
It’s all about the customer ratings.
Check if the star rating is more than 3.
I recommend you to go for a 4 star rating, as they would have come across an experience and exhibiting better performance.
4) About the support
Two common questions must be answered.
- Does the developer actively support the plug-in?.
- How good are they in responding to queries quickly and provide a solution for the same?.
Theoretically, WordPress can handle any number of plug-ins without impeding the performance of your website. Considering the speed of the website and the way it is getting affected, is one among the major factors to be dealt with.
Your hosting platform’s performance is one among the significant factors. Smaller bandwidths are offered by many hosting providers. This is where the frequent myth breaks with every consecutive plug-in. The same will be installed and the website’s speed is hampered.
It is inferred that, one of the regulators of your website’s speed is the hosting service. It’s wise that you remain cautious from the start.
The secondary factor is about how a plug-in is programmed. Sometimes your site crashes completely due to specific plug-ins. Improper coding is the only cause behind this.
While we install a plug-in we would have crossed various situations and they might affect and bring down your WP website in strange ways. If the plug-in works perfectly from the start, then it is said to be reliable.
Assuming that, you have got enough memory and hosting which is fast enough, you then have to focus on your trustworthy plug-ins for your website.
Why should we not install plug-ins for everything?
Plug-ins: A mandatory evil?
The usual reason for a lot of WP issues is your choice in plug-ins. Its a known fact that plug-ins are written by various developers with varying skills and you must be cautious which you install and how many you install.
As a usual norm, we suggest to maintain, the number of plug-ins installed, under 20 for the sites.
“The thumb rule is “the higher the plug-ins, the greater the risks of your sites to get hacked”.
Delete the inactive plug-ins completely and any active plug-ins, you don’t need anymore.
Many codes are executed to provide the page to their browser when people take a visit at your website. Also, the code which got introduced by your plug-ins, runs along. Because of this, your website might get slowed down and results in increased memory requirement.
Database and file system
Usually, almost all the plug-ins occupies a little space in your file system and several plug-ins uses your WP database to store configuration information and other related data. While you are choosing a lesser cost hosting service, the plug-in files wont occupy much space, which states that you must immediately fill your space which is assigned to you.
Your plug-ins must be updated regularly.
Normally when you look for an update, you will be intimated about the direct link. But at many occasions the update might either break your website because of existing bug in the code or it might conflict with the other plug-ins.
Some of the plug-ins are written by the programmers in a way that it get conflicted with something. For example, a reasonable generic name is given to one of their plug-in variables. If this relates with a variable name of another plug-in being used in your website, then it causes issues for you. Not everyone are following the coding norms and standards which governs the plug-in development. As to plug-ins are considered, it’s not a bigger surprise that mistakes occurs in case of running the line of codes to many thousands.
It’s wise to have lesser plug-ins to reduce the conflicts.
In a motive to be resistant against the vulnerabilities, the plugins must be coded, which are pieces of code. The risks of threat will be minimal if you manage your website by updating the plug-ins and the WordPress systematically. However, it takes time for the developers of plug-in to fix the threats and release an update. This time space creates an opportunity for the hackers.
Simply put, the less frequent you update your plug-ins and more the number of plug-ins used, the chances of getting hacked is definitely more.
What happened with the top plug-ins?
Most Recent Version: 220.127.116.11 (StarPath) released on 10th July 2017.
Vulnerable Versions: If you are using a version (slightly/greatly) lesser than 18.104.22.168, then you are allowing breach into your most valued websites any moment now.
I will give you one example, which is the world’s most influential cyber attack, which attracted the global attention and how it was done using the vulnerability present in the WordPress RevSlider Plug-in.
We all, by this time, would have known about the largest data breach (in the history of journalists), into the Panamanian law firm, Mossack Fonseca (MF). The hackers made an intrusion via a vulnerable version of Revolution Slider and accessed nearly 11.5 million documents and weighing about 2.6 TB.
This data breach has brought down the Prime Minister of Iceland and made controversy among the Russian president and the British Prime Minister.
It was discovered that they were running an outdated version 2.1.7 which laid an easy path for the attackers. All the versions below 22.214.171.124 are prone to threats and hack-attacks may be possible.
It’s wise to stick to the MRV for your valuable website to have a healthy (non-threat) longer run.
Most recent Version: 0.9.5.4
Vulnerable Versions: If you are using a version (greatly/slightly) lesser than 0.9.5.4, then you are allowing breach into your valued websites any moment now.
Two examples will suffice to elucidate how the WP W3 total cache was subjected to vulnerability.
(i) In the W3 Total Cache plug-in, vulnerability was discovered in the information disclosure part. One of the sensitive information like administrator’s session cookie is prone to hack-attack due to this issue. The moment when the administrator submits the support form, exploiting the vulnerability threat is highly possible in a very short time period.
A vulnerability was found in version 0.9.4.1
It was fixed in version 0.9.5
(ii) Another vulnerability was found in the validation of Amazon SNS messages in the W3 Total Cache plug-in. Service attack denial, might be resulted because of this issue, as it permits the hacker to execute various actions relating to the server’s cache.
A vulnerability was found in version 0.9.4.1
It was fixed in version 0.9.5
Most recent Version: 1.5.3
Vulnerable Versions: If you are utilizing a version (greatly/slightly) lesser than 1.5.3, you are allowing breach into your valued websites any moment now.
Two examples will suffice to elucidate how WP SuperCache was subjected to vulnerabilities.
(i) On the setting page, the WordPress plug-in, SuperCache patches cross-site-scripting vulnerabilities.
I have been saying this many times that it’s wise to upgrade if you are using an older version because in this case, those pages were accessible by admin users only and any unknown visitor can’t come along and steal your login cookies, but with those fixes comes many bug fixes.
A vulnerability was found in the version 1.4.4
It was fixed in the version 1.4.5
(ii) If the hacker manages to inject malicious code into the legacy cache metal files, then PHP Object Injection could occur. The WordPress Super Cache plug-in is subjected to a remote PHP code-execution vulnerability attack. Within the context of the web server, hackers can easily exploit this problem to perform arbitrary PHP code.
A vulnerability was found in the version 1.4.4
It was fixed in the version 1.4.5
Most recent Version: 2.10.7 released on 2nd August 2017
Vulnerable Versions: If you are using a version (greatly/slightly) lesser than 2.10.7, your valued websites are prone to breach any moment now.
An example will suffice to elucidate how WP Rocket was subjected to vulnerability.
In the WordPress plug-in, Rocket, version 2.9.3, the LFI (Local File Inclusion) mitigation technique is to trim the traversal characters (..), but this is insufficient to put an end to the remote attacks and might be bypassed using (0x00) bytes, as demonstrated by a (.%00…/.%00…/) attack.
A vulnerability was found in the version 2.9.3
It was fixed in the version 2.10.4
What are the remedies?
- As we discussed before, more plug-ins will draw attention of the hackers. The thumb rule is “Less will suffice” or “the higher the plug-ins the greater the risks of your sites to get hacked”.
- If the plug-in update is one concern, the effect made by it to your existing WordPress and the theme is another concern. (Avoid this Caution: “This Plug-in has not been tested with your current version of Word Press”).
- Always check for plug-ins with quality reviews, a 4-star+ ratings and an optimistic user experience from the community/forum.
- Its highly recommended that you download Plug-ins from WPPR-Word Press Plug-in Repository, as some of the plug-ins can inject malware directly or contain security loopholes.
- Lesser Scripts as loading too many scripts slows down the website.
- Conflict between the plug-ins ultimately results in slowing of the website. Considering the fast load, the sites with complex codebase will load slower than the simpler ones.
We all know that plug-ins play a vital role in WordPress websites.
Yet, it attracts many hacker intrusions if the security advice and practices were not followed.
Hope the information from this blog will suffice and if you feel, anything at all, that we have forgotten to mention, we are glad to receive it as comments.
I can sense that many are curious and willing to share their personal experience.
Please, do share them also for the benefit of visitors.