Blaise's notes - richnadeau/Secure-Web-Application-CTF-Nadeau-Notter GitHub Wiki

OWASP Top 10

#1 - Broken Access Control

Access Control is enforcement policies to ensure that users are restricted to their intended authorization. Broken Access Control is when these policies are misconfigured, allowing unintended users to gain have disclose to unauthorized information, make modifications, or cause destruction across the business. Some examples of broken access control are: Exploiting web-based applications to bypass security checks, user access without being logged in, manipulating the metadata to elevate privileges.

Some strategies to prevent Broken Access Control are: deny all by default, logging/alerting access control failures, disable web server directory listings, implement access control mechanisms, JSON Web Token (JWT) should have short lifespans to limit window of attack.

Scenarios

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

 pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

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

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

An attacker simply forces browses to target URLs. Admin rights are required for access to the admin page.

https://example.com/app/getappInfo https://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it's a flaw. If a non-admin can access the admin page, this is a flaw.

#5 - Security Misconfigurations

This topic encompasses all application configurations. This includes: Failure in security hardening, improper permissions, default accounts and passwords are left enabled, error handling reveals too much information, information is not transmitted securely, unnecessary features are enabled, and software is left outdated.

To prevent security configurations, an automated and repeatable security hardening process should be implemented. Do not install unnecessary features and frameworks or remove them. Configurations should be reviewed and updated regularly, including an automated process to verify the efficiency of configurations.

Scenarios

  • The application server comes with sample applications not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. Suppose one of these applications is the admin console, and default accounts weren't changed. In that case, the attacker logs in with default passwords and takes over.

  • Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a severe access control flaw in the application.

  • 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 that are known to be vulnerable.

  • A cloud service provider (CSP) has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

#6 - Vulnerable and Outdated Components

This category covers all components which are not upgraded to their latest release version. This includes all components server-side, client-side, those you directly use, and even dependencies: Operating Systems, web or sever applications, database management systems, applications, APIs, runtime environments, and libraries. It is important to know the versions of all these components and that they are upgraded to their latest versions to patch certain egregious exploits.

Prevention of this issues is straightforward: scan for vulnerabilities regularly and follow cybersecurity news closely to know when something is vulnerability. In addition, all components should be upgraded in a timely manner when needed rather than some standard monthly or quarterly task. It's also smart to remove all unused or unnecessary libraries, dependencies, features, etc.

Scenarios

Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g., coding error) or intentional (e.g., a backdoor in a component). Some example exploitable component vulnerabilities discovered are:

  • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables the execution of arbitrary code on the server, has been blamed for significant breaches.

  • While the internet of things (IoT) is frequently difficult or impossible to patch, the importance of patching them can be great (e.g., biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from Heartbleed vulnerability patched in April 2014.

Work Cited

Potential Web Apps