Forem: OWASP Foundation

[Boost]

OWASP Foundation — Thu, 02 Apr 2026 21:09:41 +0000

Ananya for OWASP BLT

Apr 1

🎉First PR? Get paid for it

#100daysofcode #github #beginners #opensource

Comments 2

2 min read

[Boost]

OWASP Foundation — Mon, 17 Feb 2025 19:41:39 +0000

How to pass the OWASP MASVS verification by design

johan sydseter for OWASP® Foundation ・ Feb 14

#appsec #mobile #cybersecurity #security

[Boost]

OWASP Foundation — Mon, 17 Feb 2025 16:44:08 +0000

How to do threat modeling for agile mobile app development?

johan sydseter for OWASP® Foundation ・ Feb 6

#agile #mobile #appsec #cybersecurity

The Case for Standards in Mobile App Security

OWASP Foundation — Wed, 31 Jul 2024 17:01:03 +0000

by Carlos Holguera and Sven Schleier

In cyber security staying ahead of potential threats and vulnerabilities is key; adherence to industry standards is not just a best practice; it's a necessity. In this article, we will explore why it's crucial to follow an industry standard like the OWASP Mobile Application Security Verification Standard (MASVS), both from the perspective of those developing tools and services to assess mobile apps and those seeking compliance.

The Benefits of Industry Standards

Thanks to industry standards like the OWASP MASVS, which provide comprehensive coverage of the attack surface, testing remains consistent and reliable over time, instilling trust in the quality of vendor services.

Standards like the OWASP MASVS are backed by a large community of security professionals who ensure that any new threats, or best practices are quickly integrated into the standard, keeping it relevant and effective. Established standards also promote transparency in the testing process, allowing customers to clearly understand the scope and coverage, preventing hidden gaps in security assessments.

Vendors adhering to recognized industry standards demonstrate professionalism, build trust, and simplify compliance efforts for organizations, ensuring credibility in delivering high-quality services. When comparing different vendors, having a known standard as a reference point makes it easier to evaluate the quality and scope of their services. It provides a common benchmark to assess their capabilities.

Additionally, by testing mobile apps against recognized standards, organizations can proactively manage and identify vulnerabilities early in the development lifecycle, minimizing the risk of costly post-release fixes.

The OWASP MAS Project and its Standards

The OWASP Mobile Application Security (MAS) flagship project provides a robust security standard for mobile apps, known as the OWASP MASVS, along with a comprehensive testing guide (OWASP MASTG). These resources cover the processes, techniques, and tools used during a mobile app security test, ensuring consistent and complete results.

The OWASP MASVS standard is divided into various groups of security controls, representing critical areas of the mobile attack surface, including:

MASVS-STORAGE: Secure storage of sensitive data on a device (data-at-rest).
MASVS-CRYPTO: Cryptographic functionality used to protect sensitive data.
MASVS-AUTH: Authentication and authorization mechanisms used by the mobile app.
MASVS-NETWORK: Secure network communication between the mobile app and remote endpoints (data-in-transit).
MASVS-PLATFORM: Secure interaction with the underlying mobile platform and other installed apps.
MASVS-CODE: Security best practices for data processing and app maintenance.
MASVS-RESILIENCE: Resilience to reverse engineering and tampering attempts.
MASVS-PRIVACY: Privacy controls to protect user privacy.

A Standard Backed by Standards

To complement the MASVS, the OWASP MAS project also provides the OWASP Mobile Application Security Testing Guide (MASTG) and the OWASP MAS Checklist. Together, these resources are the perfect companion for verifying the controls listed in the OWASP MASVS and demonstrating compliance.

The Mobile Application Security Verification Standard (MASVS) is intertwined with various industry standards, underpinning its robustness and effectiveness. MASVS-CRYPTO relies on NIST.SP.800-175B and NIST.SP.800-57, which provide established cryptographic guidelines and assurance, ensuring that sensitive data within mobile apps remains secure.

While MASVS-AUTH comprehensively covers app-side authentication and authorization, it recognizes the importance of validating security on the remote endpoint, referencing industry standards like the OWASP Application Security Verification Standard (ASVS).

MASVS-CODE encourages developers to follow best practices from OWASP Software Assurance Maturity Model (SAMM) and NIST.SP.800-218 Secure Software Development Framework (SSDF) to prevent vulnerabilities during development.

MASVS-PRIVACY draws inspiration from essential privacy regulations like GDPR, COPPA, CCPA, and ENISA, providing a foundation for privacy considerations.

Conclusion

The importance of following industry standards like the OWASP MASVS in mobile app security cannot be overstated. It ensures consistency, comprehensiveness, and up-to-date protection against evolving threats. For vendors and customers alike, adherence to these standards is not just a matter of trust; it's a strategic choice that enhances security, credibility, and long-term cost-effectiveness in an increasingly mobile-centric world. So, choose your mobile app security provider wisely, and together, let's build a more secure mobile future.

OWASP Mobile Application Security - https://mas.owasp.org/
OWASP MASVS - https://mas.owasp.org/MASVS/
OWASP MASTG - https://mas.owasp.org/MASTG/
OWASP MAS Checklist - https://mas.owasp.org/checklists/

OWASP is a non-profit foundation that envisions a world with no more insecure software. Our mission is to be the global open community that powers secure software through education, tools, and collaboration. We maintain hundreds of open source projects, run industry-leading educational and training conferences, and meet through over 250 chapters worldwide.

Security for Citizen Developers: Low-Code/No-Code Cybersecurity Threats

OWASP Foundation — Tue, 07 May 2024 14:10:16 +0000

by Ziv Daniel Hagbi

Hello to all Citizen Developers out there!

Are you using Low-Code/No-Code platforms to accelerate your digital adoption? That is a question I would ask if this was 2021. 2024 has proven that it is no longer a question of “If”, but of volume (how much do you use it) and depth (how much do you depend on it for your business process)? While this monumental leap in productivity is great for business, and you personally, you should be mindful of the responsibility you now have securing your application and business.

As low-code/no-code platforms become the go-to solution for many companies, security isn’t always the first thing on the minds of business users. Yet, the simplicity of drag-and-drop functionalities and minimal to no coding requirement does not eliminate the risks associated with application development. It just hides it. This is even heightened with the introduction of generative AI as an enabler for citizen developers. Today, more than ever, citizen developers should ask themselves, “Is my app secured?”

The OWASP Low-Code/No-Code Top 10 can help you navigate major cybersecurity risks and how to mitigate them. Here's an overview:

Account Impersonation (LCNC-SEC-01): Be vigilant about who can act as whom within your applications.
Authorization Misuse (LCNC-SEC-02): Ensure proper controls are in place to prevent unauthorized access.
Data Leakage (LCNC-SEC-03): Secure your data from unintentional exposure due to misconfigurations or errors.
Authentication and Communication Security (LCNC-SEC-04): Strengthen your authentication processes and secure all communications.
Security Misconfiguration (LCNC-SEC-05): Avoid default settings and configure all security settings appropriately.
Injection Handling Failures (LCNC-SEC-06): Be careful with data input and outputs that could be manipulated.
Vulnerable Components (LCNC-SEC-07): Use trusted and up-to-date components in your applications.
Data and Secret Handling (LCNC-SEC-08): Manage sensitive data and secrets securely.
Asset Management Failures (LCNC-SEC-09): Keep a tight inventory and control over your digital assets.
Security Logging and Monitoring (LCNC-SEC-10): Implement robust logging and monitoring to enable auditing while securely handling sensitive data in logs.

Read the whole OWASP Low-Code/No-Code Top 10 here.

Understanding these risks is just the beginning. You should integrate security best practices into your development process, and make sure you keep your knowledge and applications up-to-date. Remember, security is a moving target. Exploring resources from OWASP can help you stay in the know. By adopting a security-minded approach, you not only protect your apps but also enhance the overall security posture of your organization.

Welcome to the world of secure application development!

SQL Injection Isn't Dead Yet

OWASP Foundation — Mon, 15 Apr 2024 12:51:14 +0000

by Erlend Oftendal and Naane Baars

SQL injection was introduced in an article by Rain Forrest Puppy (Jeff Forristal) in Phrack 25 years ago. Even though it is a well-known bug with a well-known remedy, it still frequently occurs even in today's products.

If we look at the OWASP Top 10, injection risk started in the 6th position in the initial 2003 version, and then moved across the top three spots in the later versions.

SQL injection is also number 3 on the SANS CWE Top 25 Most Dangerous Software Errors, and is still frequently on the reports from penetration tests and bug bounty programs, although there is a declining trend. If we look at CVE details of 2023 we get a list of 2159 of 29065 vulnerabilities found.

CISA, together with the FBI, recently released a Design Alert called Eliminating SQL Injection Vulnerabilities in Software, asking for all call to action to remediate this vulnerability once and for all.

That begs the question: why, after all these years, does SQL injection still crop up? It should be a thing of the past.

What Is an SQL Injection?

SQL injection typically occurs where attacker-controlled data is concatenated with strings to build SQL queries. The classic example is logins where the application attempts to look up a username and password in the database:



query = "SELECT * FROM users WHERE username='" + username + "' AND password='" + password "'"
result = db.execute(query)

This type of query is not very common in modern applications for various reasons. Passwords are not stored verbatim, but hashed with a fitting hashing algorithm as per the OWASP Password Storage Cheat Sheet. Additionally, this specific type of bug is often quickly found in penetration tests and scans. As a result, developers might falsely assume that they have avoided the risk of SQL injection.

In practice, SQL injection can take many forms and attacker-controlled data can come from many different locations in the code. We typically think of attacker-controlled data as form inputs, parameters from the URL, or data from a JSON body of an HTTP request, but input can come from all parts of an incoming request. This includes header values and encoded values in tokens such as JWT, embedded in image EXIF data, or even in encrypted data, among many other forms. There are even examples of SQL injection in door entry systems where the input is coming from proprietary wire protocols.

The most common approach to avoiding SQL injection is the use of parameterized queries (or prepared statements), where the data inputs are replaced with placeholders and separated from the query itself:



select * from users where username = :username AND password = :password

With this an attacker is no longer able to change the meaning of the query. However, there are cases where using parameterized queries alone is not enough. Suppose we have an application where the user is allowed to change the sort order of the data. The query could look something like:



select * from servers order by hostname

In the code that is generating this statement, the order_by column may be added by the code like this.



def fetchServers(order_by: str):
  db.execute("select * from servers order by " + orderBy)
  ...

One thing to note is that you cannot use a parameterized query for the order by clause. The order by clause will normally be a column name, however if we look at the SQL grammar definition it can be a complete expression. This would also be a valid statement:



select * from servers
order by case when (
    select ip from servers
    where substr(ip,1,1) = '9'
) IS NOT NULL
then hostname
else id end

The attacker can look at the ordering of the results and tell you whether the query sent to the database is matching something. Again we end up with a SQL injection. This manual process can be easily accelerated with SQLMap, for example. To fix this you need to validate the column passed to our function above, preferably against a strict allow-list.

In short, many SQL injection risks can be avoided with a combination of parameterized queries and validation. For all possible mitigations have a look at the OWASP SQL Injection Cheat Sheet.

Remain Vigilant

One reason SQL injections remain a threat is a persistent lack of awareness and due diligence. Many developers use platforms like StackOverflow and tools like GitHub Copilot to quickly find answers, but end up with code vulnerable to SQL injection. A simple copy-and-paste or autocomplete, and you introduce that vulnerability inside your own code. Even if someone in the answers section on StackOverflow points out the SQL injection, it often isn't the top answer or comment.

Code scanners (SAST) and application scanners (DAST) can certainly find many of the SQL injection issues, but may miss some due to lack of framework support or because they don’t scan all the possible injection points. Maybe AI will one day be able to flawlessly detect SQL injections, and we will get rid of this threat forever. In the meantime, we must remain vigilant.

Misplaced Trust

Another source of SQL injection can be the libraries used to communicate with the database. Many developers assume that the libraries have done things right, but that trust is too often misplaced. There are cases where even if you as a developer have done everything right in your code, the application is still vulnerable to SQL injection.

One such example is the recent CVE-2024-1597 in the Java postgresql driver (although this had some really specific preconditions). Another example is CVE-2019-14900 which was a flaw in Hibernate ORM.

WordPress plugins have also been a running source of SQL injection. Some examples from 2023 alone include CVE-2023-23488, CVE-2023-23489, CVE-2023-23490, CVE-2023-26325, CVE-2023-28659 and CVE-2023-28660 released last year. This year, CVE-2024-1071 was published.

To detect these types of vulnerabilities, we should first and foremost know our dependencies and versions, and which of them have vulnerabilities. The OWASP Top 10 2021 identifies this need as A06:2021-Vulnerable and Outdated Components. OWASP has several tools for this, including Dependency Check and Dependency Track. These tools will warn about the use of components with vulnerabilities.

If the SQL injection vulnerabilities are not known, there are chances they can be detected by scanning the code, scanning the applications, or running a manual penetration test. Although these are not guaranteed to find the bugs, there is an increased chance of finding the vulnerabilities before attackers do.

Learn More About SQL Injection

It is essential that developers learn to spot, prevent, and fix SQL injections. OWASP has several resources to enable you to do just that, and have some fun in the process!

WebGoat and Juice Shop are two "deliberately insecure" applications containing hundreds of security vulnerabilities for you to find and exploit, including SQL injections. Both projects provide extensive educational material to guide you.

The SQL Injection Prevention Cheat Sheet is an indispensible reference for defending against SQL injection in your own project. You can also find some more interesting examples on the OWASP community page for SQL injection.

Remember: only you can prevent SQL injection!