OWASP Top 10 Security Risks – Part III

To bring awareness to what threatens the integrity of websites, we are continuing a series of posts on the OWASP top 10 security risks.

The OWASP Top 10 list consists of the 10 most seen application vulnerabilities:

  1. Injection
  2. Broken Authentication
  3. Sensitive data exposure
  4. XML External Entities (XXE)
  5. Broken Access control
  6. Security misconfigurations
  7. Cross Site Scripting (XSS)
  8. Insecure Deserialization
  9. Using Components with known vulnerabilities
  10. Insufficient logging and monitoring

In our previous posts, we explained the first four items on the OWASP Top 10 list. Today, we are going to explore items 5 and 6: broken access control and security misconfigurations.

5. Broken Access Control

In website security, access control means to put a limit on what sections or pages visitors can reach, depending on their needs.

For example, if you own an ecommerce store, you probably need access to the admin panel in order to add new products or to set up a promotion for the upcoming holidays. However, hardly anybody else would need it. Having the rest of your website’s visitors be able to reach your login page only opens up your ecommerce store to attacks.

And that’s the problem with almost all major content management systems (CMS) these days. By default, they give worldwide access to the admin panel. Most of them also won’t force you to establish a second-factor authentication method (2FA).

The above makes you think a lot about software development with a security-first philosophy. Access control issues are also present in other areas:

Examples of Access

Here are some examples of what we consider to access:

  • Access to a hosting control / administrative panel
  • Access to a server via FTP / SFTP / SSH
  • Access to a website’s administrative panel
  • Access to other applications on your server
  • Access to a database
Attackers can exploit authorization flaws to the following:
  • access unauthorized functionality and/or data;
  • view sensitive files;
  • modify other users’ data;
  • change access rights, etc.

What Are the Risks?

According to OWASP, here are a few examples of what can happen when there is broken access control:

Scenario #1:The application uses unverified data in a SQL call that is accessing account information:

pstmt.setString(1,request.getParameter(“acct”)); ResultSetresults =pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

    http://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker simply force browses to target URLs. Admin rights are required for access to the admin page.

http://example.com/app/getappInfo 

http://example.com/app/admin_getappInfo

Developers are going to be more familiar with the above scenarios, but remember that broken access control vulnerabilities can be expressed in many forms through almost every web technology out there; it all depends on what you use on your website.

Reducing the Risks of Broken Access Control

There are things you can do to reduce the risks of broken access control:

  • Employ least privileged concepts – apply a role appropriate to the task and no more.
  • Get rid of accounts you don’t need.
  • Audit your servers and websites – who is doing what, when, and why.
  • If possible, apply multi-factor authentication to all your access points.
  • Disable access points until they are needed in order to reduce your access windows.
  • Remove unnecessary services off your server.
  • Verify applications that are externally accessible versus applications that are tied to your network.
  • If you are developing a website, bare in mind that a production box should not be the place to develop, test, or push updates without testing.

How to Prevent Broken Access Control

To avoid broken access control is to develop and configure software with a security-first philosophy. That’s why it is important to work with a developer to make sure there are security requirements in place.

The technical recommendations by OWASP to prevent broken access control are:

  • With the exception of public resources, deny by default.
  • Implement access control mechanisms once and reuse them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record. Note: For example,  if a user log-ins as “John”, he could only create, read, update or delete records associated to the id of “John”. Never the data from other users.
  • Unique application business limit requirements should be enforced by domain models.
  • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
  • Log access control failures, alert admins when appropriate (e.g. repeated failures). Note: We recommend our free plugin for WordPress websites, that you can download directly from the official WordPress repository. 
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout.
  • Developers and QA staff should include functional access control unit and integration tests.

6. Security Misconfigurations

Hackers are always looking for ways to penetrate websites, and security misconfigurations can be an easy way in. Here are some examples of things that hackers usually try to exploit in order to gain unauthorized access:

  • unpatched flaws
  • default configurations
  • unused pages
  • unprotected files and directories
  • unnecessary services

One of the most common webmaster flaws is to keep the CMS default configurations.

Today’s CMS applications (although easy to use) can be tricky from a security perspective for the end users. By far the most common attacks are entirely automated. Many of these attacks rely on users to have only default settings.

This means that a large number of attacks can be avoided by changing the default settings when installing a CMS.

For example, some CMS applications are writeable by the user – allowing a user to install whatever extensions they want.

There are settings you may want to adjust to control comments, users, and the visibility of user information. The file permissions are another example of a default setting that can be hardened.

Where Can Security Misconfiguration Happen?

Security misconfiguration can happen at any level of an application stack, including:
  • network services,
  • platform,
  • web server,
  • application server,
  • database,
  • frameworks,
  • custom code,
  • pre-installed virtual machines,
  • containers,
  • storage.

One of the most recent examples of application misconfigurations is the memcached servers used to DDoS huge services in the tech industry.   

Example of Attack Scenarios

According to OWASP, here are some examples of attack scenarios:

Scenario #1: The application server comes with sample applications that are not removed from the production server.
These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console and default accounts weren’t changed, the attacker logs in with default passwords and takes over.

Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. They find and download the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.

Scenario #3: The application server’s configuration allows detailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws, such as component versions. They are known to be vulnerable.

Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows stored sensitive data to be accessed within cloud storage.

How to Have Secure Installation Systems

In order to prevent security misconfigurations:
  • A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. Automate this process in order to minimize the effort required to set up a new secure environment.
  • A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
  • A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process. In particular, review cloud storage permissions.
  • A segmented application architecture that provides effective and secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
  • Sending security directives to clients, e.g. Security Headers.
  • An automated process to verify the effectiveness of the configurations and settings in all environments.

Conclusion

In this post, we tackled OWASP Top 10 vulnerabilities number 5 and 6: broken access control and security misconfigurations, two security issues that make it to the top 10 of OWASP because of their prevalence in today’s website landscape. Soon, we will follow up with the other vulnerabilities.

If you are looking for a security solution for your website that will address the OWASP’s top 10 and more, check out our comprehensive Website Security Platform.



*** This is a Security Bloggers Network syndicated blog from Sucuri Blog authored by Gerson Ruiz. Read the original post at: https://blog.sucuri.net/2018/12/owasp-top-10-security-risks-part-iii.html