Top 10 Plug-in Vulnerabilities
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.