Developer LAB Resources

The purpose of threat modeling is to find out what could go wrong and how to prevent that. There are different guidelines, approaches and tools available to support you with that:

STRIDE model and Microsoft Threat Modeling Tool

https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

Since Microsoft pushed the term “Threat Modeling”, their Threat Modeling Tool and STRIDE methodology is quite common.

OWASP Threat Dragon

https://owasp.org/www-project-threat-dragon/
 

OWASP Threat Dragon is a modeling tool used to create threat model diagrams as part of a secure development lifecycle. It can be used to record possible threats and decide on their mitigations, as well as giving a visual indication of the threat model components and threat surfaces. Threat Dragon supports STRIDE / LINDDUN / CIA, provides modeling diagrams and implements a rule engine to auto-generate threats and their mitigations.

OWASP Threat Modeling Cheat Sheet

https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html

There are a lot of resources that collect typical security flaws and show how to prevent them. Two well-known lists are the OWASP Top 10 project and the CWE/SANS Top 25.

OWASP Top 10 (2021)

The OWASP Top 10 project is well known for collecting the most common security flaws in web applications. These risks do not only apply to web applications only, most of them are relevant for all kinds of applications.

A1: Broken Access Control
A2: Cryptographic Failures
A3: Injection
A4: Insecure Design
A5: Security Misconfiguration
A6: Vulnerable and Outdated Components
A7: Identification and Authentication Failures
A8: Software and Data Integrity Failures
A9: Security Logging & Monitoring Failures
A10: Server Side Request Forgery (SSRF)

More information: https://owasp.org/www-project-top-ten/

CWE and CWE/SANS Top 25

CWE (Common Weakness Enumeration) is a list of common security flaws. Currently there are over 800 software weaknesses in there and there is a collection of the most important 25 ones, the CWE/SANS Top 25. CWE does not focus on web applications like OWASP, but on software in general. Some example of the CWE/SANS Top 25 are:

CWE-129: Improper Validation of Array Index
CWE-681: Incorrect Conversion between Numeric Types
CWE-250: Execution with Unnecessary Privileges
CWE-759: Use of a One-Way Hash without a Salt
CWE-863: Incorrect Authorization
CWE-494: Download of Code Without Integrity Check

More information:
https://cwe.mitre.org
https://cwe.mitre.org/top25/

OWASP Top 10 Proactive Controls

The OWASP Top 10 are well-known, but there is more from OWASP: The OWASP Top 10 Proactive Controls is a list of measures that can prevent the risks from the Top 10 list.

C1: Define Security Requirements

C2: Leverage Security Frameworks and Libraries

C3: Secure Database Access

C4: Encode and Escape Data

C5: Validate All Inputs

C6: Implement Digital Identity

C7: Enforce Access Controls
1) Design Access Control Thoroughly Up Front
2) Force All Requests to Go Through Access Control Checks
3) Deny by Default
4) Principle of Least Privilege
5) Don't Hardcode Roles
6) Log All Access Control Events

C8: Protect Data Everywhere

C9: Implement Security Logging and Monitoring

C10: Handle All Errors and Exceptions

These topics need to be addressed in the design phase of an application. As a short example you see in the box above the design principles defined for “C7: Enforce Access Controls”-

More Information: https://owasp.org/www-project-proactive-controls/

Insecure Direct Object Reference

“Insecure direct object references” are that common that it they were a separate risk in the OWAP Top 10 list from 2013. Since 2017, they are merged into the risk “Broken Access Control”.

A simple solution for the example in the LAB exercise would be the use of UUIDs. When the ID is long enough and not just incremented every time, an attacker cannot access the documents easily. Fortunately, we do not need to reinvent the wheel, because there is a well-established standard for UUIDs (sometimes also called GUIDs): https://www.itu.int/en/ITU-T/asn1/Pages/UUID/uuids.aspx

And there are already libraries for many programming languages and frameworks that implement these UUIDs, for example for Java: https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html

Next to the secure development of applications, the security level can be improved by hardening of the infrastructure.

Example: PHP Web Shell

During the LAB exercise, we uploaded our own PHP file to the server, which contained a web shell. Of course, the upload of files with extensions like .php should be prevented by the web application by only allowing certain file extensions like .png, .jpg or .png.

However, we were only able to exploit the vulnerability since the webserver also executed the PHP file. As an additional protective measure the execution of script languages like PHP should be disabled in certain directories like upload or tmp. In our example, we would be able to upload the file, but the web shell would not be executed.

Here are some hints for the configuration of the Apache and IIS web server. It is important to verify that the suggested configuration change is effective on your server since it may vary in different environments.

Apache

The following snippet can be included in the Virtual Host configuration:

<Directory /var/www/files/upload>
   # disables the PHP engine explicitly
   php_admin_value engine Off

   # disables the execution of script handlers in general, not only PHP
   SetHandler default-handler
</Directory>

More information:
https://lxadm.com/Apache:_disabling_PHP_execution_in_selected_directories 
https://httpd.apache.org/docs/2.4/handler.html

Microsoft Internet Information Server (IIS)

The following snippet can be placed in the file web.config inside the directory, where script execution should be disabled:

<configuration>
    <system.webServer>
       <handlers>
              <clear />
              <add
              name="StaticFile"
              path="*" verb="*"
              modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule"
              resourceType="Either"
              requireAccess="Read" />
         </handlers>
       <staticContent>
            <mimeMap fileExtension=".*" mimeType="application/octet-stream" />
       </staticContent>
   </system.webServer>
</configuration>

More information:
https://docs.microsoft.com/en-us/iis/configuration/system.webserver/handlers/ 
https://serverfault.com/questions/286503/how-can-i-disable-php-scripts-on-a-specific-subdir-of-my-website-on-iis7

Hardening in general

There are a lot of further configuration options that can improve the security of your web server. Some basic hardening steps are:

• Run the web server with an unprivileged user: not root on Linux or SYSTEM on Windows.
• Check that the file permissions of the web application are as restrictive as possible, especially if there are multiple applications running on the same server.
• Disable directory listing.
• Disable unused modules of the web server.
• Do not put .git or .svn directories in the web root.

The Center for Internet Security (CIS) provides detailed hardening guidelines for web servers including commands to check for the recommended settings:

Apache: https://www.cisecurity.org/benchmark/apache_http_server/ 
Nginx: https://www.cisecurity.org/benchmark/nginx/ 
IIS: https://www.cisecurity.org/benchmark/microsoft_iis/ 
Tomcat: https://www.cisecurity.org/benchmark/apache_tomcat/ 

Dependency-Check is a Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies. It does this by determining if there is a Common Platform Enumeration (CPE) identifier for a given dependency. If found, it will generate a report linking to the associated CVE entries.

https://owasp.org/www-project-dependency-check/
 

Note: OWASP Dependency-Check is a tool for identifying known vulnerabilities in project dependencies, while OWASP Dependency-Track is a platform that manages and tracks software component usage. Check out this page for distinction.

Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill of Materials (SBOM). This approach provides capabilities that traditional Software Composition Analysis (SCA) solutions cannot achieve.

https://dependencytrack.org/
 

Note: OWASP Dependency-Track is a platform that manages and tracks software component usage, while OWASP Dependency-Check is a tool for identifying known vulnerabilities in project dependencies. Check out this page for distinction.

CSP Evaluator from Google allows developers and security experts to check if a Content Security Policy (CSP) serves as a strong mitigation against cross-site scripting attacks. It assists with the process of reviewing CSP policies, which is usually a manual task, and helps identify subtle CSP bypasses which undermine the value of a policy.

https://csp-evaluator.withgoogle.com/

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html