Coders Conquer Security OWASP Top 10 API-Serie — Sicherheitsfunktionen deaktiviert/Debug-Funktionen aktiviert/Unzulässige Berechtigungen
While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.
Before we get into the fun, see if you can solve this debug challenge:
How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?
To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.
However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True
In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.
While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.
Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities
You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False
Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.
Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.
Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Es ist wahrscheinlich etwas häufiger in APIs, aber Angreifer versuchen oft, ungepatchte Fehler und ungeschützte Dateien oder Verzeichnisse überall in einem Netzwerk zu finden. Wenn sie auf eine API stoßen, bei der Debugging aktiviert oder Sicherheitsfunktionen deaktiviert sind, wird ihre schändliche Arbeit nur ein wenig einfacher.
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.
Before we get into the fun, see if you can solve this debug challenge:
How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?
To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.
However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True
In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.
While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.
Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities
You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False
Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.
Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.
Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.
Before we get into the fun, see if you can solve this debug challenge:
How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?
To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.
However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True
In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.
While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.
Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities
You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False
Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.
Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.
Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Klicken Sie auf den Link unten und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung in der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und verfügt über mehr als 10 Patente. Wenn er nicht an seinem Schreibtisch ist, war Matias als Ausbilder für fortgeschrittene Schulungen zur Anwendungssicherheit tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat an der Universität Gent in Computertechnik promoviert, wo er Anwendungssicherheit durch Programmverschleierung studierte, um das Innenleben einer Anwendung zu verbergen.
While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.
Before we get into the fun, see if you can solve this debug challenge:
How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?
To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.
However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True
In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.
While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.
Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities
You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:
# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False
Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.
Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.
Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
Inhaltsverzeichniss
Matias Madou, Ph.D. ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent in Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen. Später kam er zu Fortify in den USA, wo er feststellte, dass es nicht ausreichte, ausschließlich Codeprobleme zu erkennen, ohne Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, die Sicherheitslast verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht als Teil von Team Awesome an seinem Schreibtisch sitzt, steht er gerne auf der Bühne und präsentiert auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
The Power of OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
