Ref: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
| Presentation | Controller | Model | Testing (OWASP Testing Guide V3) | |
| A1 Injection | Render:
On Submit:
| Canonicalize using correct character setPositive input validation using correct character set(NR) Negative input validation. (LR) Sanitize input.Tip: updating a negative list (such as looking for “script”, “sCrIpT”, “ßCrîpt”, etc) will require expensive and constant deployments and will always fail as attackers work out your list of “bad” words. Positive validation is simpler, faster and usually more secure and needs updating far less than any other validation mechanism. | *Parameterized queries
Tip: All SQL Injection is due to dynamic SQL queries. Strongly consider prohibiting dynamic SQL queries within your organization | 4.8.5 SQL Injection (OWASP-DV-005)4.8.6 LDAP Injection (OWASP-DV-006)4.8.7 ORM Injection (OWASP-DV-007)4.8.8 XML Injection (OWASP-DV-008)4.8.9 SSI Injection (OWASP-DV-009)4.8.10 XPath Injection (OWASP-DV-010)4.8.11 IMAP/SMTP Injection (OWASP-DV-011)4.8.12 Code Injection (OWASP-DV-012)4.8.13 OS Commanding (OWASP-DV-013)4.8.14 Buffer overflow (OWASP-DV-014) |
| A2 XSS | Render:
On Submit:
| Canonicalize using correct character setPositive input validation using correct character set(NR) Negative input validation (LR) Sanitize inputTip: Only process data that is 100% trustworthy. Everything else is hostile and should be rejected. | Tip: Do not store data HTML encoded in the database. This prevents new uses for the data, such as web services, RSS feeds, FTP batches, data warehousing, cloud computing, and so on.Tip: Use OWASP Scrubbr to clean tainted or hostile data from legacy data | 4.8.1 Testing for Reflected Cross Site Scripting (OWASP-DV-001)4.8.2 Testing for Stored Cross Site Scripting (OWASP-DV-002)4.8.3 Testing for DOM based Cross Site Scripting (OWASP-DV-003)4.8.4 Testing for Cross Site Flashing (OWASP-DV004) |
| A3 Weak authentication and session management | Render:
| Design:
| Validate role is sufficient to create, read, update, or delete dataTip: Consider the use of a “governor” to regulate the maximum number of requests per second / minute / hour that this user may perform. For example, a typical banking user should not perform more than ten transactions a minute, and one hundred per second is dangerous and should be blocked. | 4.4.2 Testing for user enumeration (OWASP-AT-002)4.4.3 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)4.4.4 Brute Force Testing (OWASP-AT-004)4.4.6 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)4.4.7 Testing for Logout and Browser Cache Management (OWASP-AT-007)4.4.8 Testing for CAPTCHA (OWASP-AT-008)4.4.9 Testing Multiple Factors Authentication (OWASP-AT-009)4.4.10 Testing for Race Conditions (OWASP-AT-010)4.5.1 Testing for Session Management Schema (OWASP-SM-001)4.5.2 Testing for Cookies attributes (OWASP-SM-002)4.5.3 Testing for Session Fixation (OWASP-SM_003)4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)4.5.5 Testing for CSRF (OWASP-SM-005)4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)4.6.3 Testing for Privilege Escalation (OWASP-AZ-003) |
| A4 Insecure Direct Object Reference | If data is from internal trusted sources, no data is sent.OrRender:
| Obtain data from internal, trusted sources.OrObtain direct value from random access reference access map. | Validate role is sufficient to create, read, update, or delete data. | 4.6.1 Testing for Path Traversal (OWASP-AZ-001) |
| A5 Cross Site Request Forgery | Pre-render:
Render:
|
Tip: CSRF is always possible if there is XSS, so make sure XSS is eliminated within your application. | Validate role is sufficient to create, read, update, or delete data | 4.5.5 Testing for CSRF (OWASP-SM-005) |
| A6 Security Misconfiguration | Ensure web servers and application servers are hardened.PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension | Ensure web servers and application servers are hardenedXML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer. | Ensure database servers are hardened | 4.2.6 Analysis of Error Codes (OWASP-IG-006)4.3.2 DB Listener Testing (OWASP-CM-002)4.3.3 Infrastructure Configuration Management Testing (OWASP-CM-003)4.3.4 Application Configuration Management Testing (OWASP-CM-004)4.3.5 Testing for File Extensions Handling (OWASP-CM-005)4.3.6 Old, Backup and Unreferenced Files (OWASP-CM-006)4.3.7 Infrastructure and Application Admin Interfaces (OWASP-CM-007)4.3.8 Testing for HTTP Methods and XST (OWASP-CM-008) |
| A7 Insufficient Cryptographic Storage | Design:
Render:
| Design:
Tip: Only certain personally identifiable information and sensitive values MUST be encrypted. Encrypt data that would be embarrassing or costly if it was leaked or stolen. Tip: It is best to encrypt data on the application server, rather than the database server. | Design:Tip: Do not use RDBMS database, row or table level encryption. The data can be retrieved in the clear by anyone with direct access to the server, or over the network using the application credentials. It might even traverse the network in the clear despite being “encrypted” on disk. | |
| A8 Failure to Restrict URL access | Design:
Pre-render:
Render:
|
Tip: It’s impossible to control access to secured resources that the web application server does not directly serve. Therefore, PDF reports or similar should be served by the web application server using binary octet streaming. Tip: Assume attackers will learn where “hidden” directories and “random” filenames are, so do not store these files in the web root, even if they are not directly linked. | Validate role is sufficient to create, read, update, or delete data | 4.4.5 Testing for bypassing authentication schema (OWASP-AT-005)4.6.1 Testing for Path Traversal (OWASP-AZ-001)4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002) |
| A9 Insufficient Transport Layer Protection |
Tip: Use TLS 1.2 always – even internally. Most snooping is done within corporate networks – and it is as easy and unethical as fishing with dynamite. |
|
| 4.3.1 SSL/TLS Testing (OWASP-CM-001)4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001) |
| A10 Unvalidated Redirects and Forwards |
or Render:
|
or
|
|
Injection Prevention Cheat Sheet in Java¶ Introduction¶ This document has for objective to provide some tips to handle Injection into Java application code. Sample codes used in tips are located here. What is Injection¶ Injection in OWASP Top 10 is defined as following. Applic ation state, or the HTML page, or simply using a custom API attack tool. OWASP Top 10 Vulnerabilities Cheat Sheet by Cam (clucinvt) via cheatography.com. OWASP Top Ten Cheat Sheet. Posted in Concepts. 4.8.9 SSI Injection (OWASP-DV-009) 4.8.10 XPath Injection (OWASP-DV-010) 4.8.11 IMAP/SMTP Injection (OWASP-DV-011). Nov 7, 2019 - OWASP API Security Top 10 at a glance as a cheat sheet poster that you can hang on your wall.
Podcast: Play in new window | Download (51.6MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
The Open Web Application Security Project (OWASP) creates a list of security vulnerabilities for web applications every few years. While the general web application security best practices also apply to application programming interfaces (APIs), in 2019 OWASP created a list of security vulnerabilities specific to APIs. This list focuses on security risks specific to APIs.
A major portion of web traffic involves accessing an API. They are at the forefront of innovation in web development providing access to almost all of the data used in web applications. A pervasive theme through out this list is poor safeguards in the APIs. Most of the time this happens because proof-of-concept code gets pushed to production when it was only ever intended to show that something was possible.
The terms Authentication and Authorization get thrown around a lot in API development as well as in the top ten list. Authentication is the first step in security. It validates that the user is who they say they are before moving forward. The most common way to do this is through username/password combinations. From here some kind of authentication token is created for subsequent calls to the API. Authorization on the other hand is a process where the system allows access to specific resources or functions based on permissions. Authorization follows authentication meaning that a user proves who they are before they are granted permission to access information.
APIs are access points for services and web applications that provide an attack surface for nefarious users. This list of the top ten vulnerabilities is just the beginning of API security. Use it as a starting point for securing the APIs you design and build. When building or securing an API you may want to consider a vulnerability scanner to help identify weaknesses in your security. To help in securing your web applications OWASP provides a series of “cheat sheets” with concise information about specific languages and/or protocols for web development.
Episode Breakdown
Broken Object Level Authorization
Owasp Cheat Sheet Pdf
APIs contain endpoints that handle object identifiers, this creates a wide attack surface. In order to maintain an semblance of state, APIs tend to track the identity of a user within the API request. While useful for maintaining state across calls, the API should not fully trust the user identity as an attacker could use another user’s ID to gain access to their private data. Object level authorization checks should be applied on all calls to the API, especially those that accesses a data source.
Broken User Authentication
Authentication protocols and mechanisms in APIs are designed to provide access to sensitive data or protected functionality to those who have permission. Improperly implemented authentication can allow attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities. If an attacker gains access to an account on an API, they are able use functionality that they should not be able to access, steal confidential or important data, or even set up denial-of-service (DoS) attacks against the API. In order to provide adequate protection, authentication at minimum needs to implement proper authentication token validation, strong credential encryption, and login attempt limiting. Using encrypted JWT (JSON Web Tokens) tokens is a way for securely sending JSON objects and is considered to be best practice for authentication.
Excessive Data Exposure
APIs are designed to expose object properties, many times without even considering that individual properties may have different levels of confidentiality or sensitivity. Developers design APIs to allow for bulk data transfer with as little as possible overhead on the client or server side then rely on the clients to filter the data before exposing it to the user. Because of this reliance on the client to filter sensitive data a nefarious listener could access sensitive data through just analyzing the traffic between the API and the client calling it. API endpoints should implement data filtering to return only properties that are needed for a specific use case. Testing should include validating all API responses to prevent excessive exposure.
Lack of Resources & Rate Limiting
APIs are built for automation and allowing programs and apps to access them without human intervention making bulk actions and repetitive operations easier and smoother. Each call to the API consumes resources such as network bandwidth, CPU cycles, memory and storage which impacts the performance of the server where the API resides. A Denial of Service (DoS) attack is an attempt to crash a server by rapid or high-volume requests to an API which either doesn’t have rate limiting parameters (execution timeout, payload size limits, etc.) or has them set too high. When designing an API make sure to include size and rate limits in the specifications, validate all queries and request parameters, and set resource limits for runtime environments.
Broken Function Level Authorization
An API can be designed to do a lot of different operations, some APIs only need a single level of access for all users and operations whereas others have varying levels of functionality so that one set of users may not have access to what another set are permitted to access (administrators vs basic users). Broken function level authentication occurs when an API doesn’t check for permission level before granting a user access to functionality. “Security through obscurity” is a flawed attempt to hide functionality that should not be public but isn’t restricted by not showing that functionality in documentation. The trick here is to act like a politician and deny access to endpoints and functions by default then only allow it based on explicit grants.
Mass Assignment
APIs, especially in Object Oriented languages, take in objects with sets of properties which may or may not be set by the user. Mass assignment occurs when an API assigns values to properties that the user should not have access to modify or create. When an API takes in properties and assigns them without checking if the user is authorized to make those changes an attacker could add in information to a request that modifies properties that should be modified such as upgrading access and user grants. Don’t map client inputs to internal variables and whitelist properties that a client can access to avoid allowing nefarious users unintended access.
Security Misconfiguration
This vulnerability is somewhat of a catch-all for any risk or problem that exposes confidential information or allows for attacks. Poor default configurations, incomplete configurations, useless HTTP methods, improper HTTP headers, poor CORS (Cross-Origin Resource Sharing) implementation, and unfiltered error messages are all potential causes of security misconfiguration. Attackers tend to target APIs because their purpose is to expose internal data, as such any vulnerability at any point in the API is an attack vector and should be treated as such. Avoid permissive configurations and sharing (CORS) and enforce consistent security across the API stack. Also, use repeatable processes for deploying APIs.
Injection
Injection has been in the OWASP Top Ten lists since it’s conception, it was number 1 in 2017’s list for web applications and number 3 in the top 25 most dangerous software errors. Whether it is SQL, NoSQL, or even Javascript, injection happens when data sent in gets interpreted as a command or query instead of as data to be stored. Improperly or un-sanitized data can be mixed with code into a single command and then the data is executed as code. Sanitize your input data by validating, filtering, and encoding all inputs from API requests, both client-supplied and coming from external systems. Parameterized APIs restrict inputs so they don’t directly use external inputs in queries or commands. Object-relational mappings (ORM) help to automate this process.
Improper Assets Management
Documentation is of even higher importance with APIs than other web applications because they often expose more endpoints. Systems change over time and so do the ways they are accessed and their dependencies. API assets need to be properly managed to avoid security risks. Endpoints may become deprecated but not removed leaving a security vulnerability for anyone calling that deprecated endpoint. Documentation is key here, if possible automate the documentation generation process so that it is always up to day. Also make sure that environments (dev, test, production) always remain separated so that you do not have access to one environment from another.
Insufficient Logging & Monitoring
Studies of API security breaches show that the average time between when a successful attack occurs and when it is detected is about 200 days and that the majority are found by external users instead of the internal monitoring. API security is not something that is set up once and forgotten, but instead needs to be constantly monitored. If not properly monitored, API attackers can disguise their attacks for long periods of time and even use them to gain access to other systems on the server. Start by defining normal activity of an API then figure out what constitutes suspicious activity and create alerts for when that happens. Use a monitoring system to maintain detailed and secure logs of all access attempts.
Tricks of the Trade
Web security principles apply in real life too.
Links
Join Us On Patreon
Level Up Financial Planning
OWASP Cheat-sheets
Owasp Api Top 10 Cheat Sheet
Related