Some developers take shortcuts when it comes to application security, but security is a matter Sofmen takes very seriously.

Attackers can potentially use many different paths through your application to do harm to your business or organization. The costs of a breach can be astronomical; not just the monetary cost, but also the harm to your company’s reputation and loss of trust of your users.

The below table describes the top ten risks as identified by the non-profit organization Open Web Application Security Project (OWASP).   OWASP provides tools and best practices to support the development of secure web and mobile applications.  Sofmen abides by these guidelines.

Risk Description Exploitability Prevalence Detectability Impacts How to Prevent
1 Injection Injection flaws occur when untrusted data is sent to an interpreter as part of a command, tricking it into executing unintended commands or accessing data without proper authorization. Easy Common Easy Severe Preventing injection requires keeping data separate from commands and queries.
• The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface, or migrate to use Object Relational Mapping Tools (ORMs).  Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection
2 Broken Authentication Authentication and session management are often implemented incorrectly allowing attackers to assume other users’ identities Easy Common Average Severe Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
• Do not ship or deploy with any default credentials, particularly for admin users.
• Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
• Align password length, complexity and rotation policies with NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
• Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
• Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
• Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL, be securely stored and invalidated after logout, idle, and absolute timeouts.
3 Sensitive Data Exposure Applications and APIs that don’t properly protect sensitive data allow attackers to steal it to commit credit card fraud, identity theft or other crimes. Sensitive data requires special precautions when exchanged with the browser. Average Widespread Average Severe Do the following, at a minimum, and consult the references:
• Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
• Apply controls as per the classification.
• Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
• Make sure to encrypt all sensitive data at rest.
• Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
• Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
• Disable caching for responses that contain sensitive data.
• Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
• Verify independently the effectiveness of configuration and settings.
Risk Description Exploitability Prevalence Detectability Impacts How to Prevent
4 XML External Entities Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks Average Common Easy Severe Developer training is essential to identify and mitigate XXE. Besides that, preventing XXE requires:
• Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
• Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
• Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
• Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
• Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
• SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations. If these controls are not possible, consider using virtual patching, API security gateways, or Web Application
5 Broken Access Control Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. Average Common Average Severe Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.
• With the exception of public resources, deny by default.
• Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
• Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
• Unique application business limit requirements should be enforced by domain models.
• Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
• Log access control failures, alert admins when appropriate (e.g. repeated failures).
• Rate limit API and controller access to minimize the harm from automated attack tooling.
• JWT tokens should be invalidated on the server after logout. Developers and QA staff s
6 Security Misconfiguration Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion Easy Widespread Easy Moderate Secure installation processes should be implemented, including:
• A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment.
• A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
• A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions).
• A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
• Sending security directives to clients, e.g. Security Headers.
• An automated process to verify the effectiveness of the configurations and settings in all environments.
7 Cross-Site Scripting XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites. Easy Widespread Easy Moderate Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:
• Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
• Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
• Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
• Enabling a Content Security Policy (CSP) is a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).
8 Insecure Deserialization Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. Difficult Common Average Severe The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of the following:
• Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
• Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
• Isolating and running code that deserializes in low privilege environments when possible.
• Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
• Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
• Monitoring deserialization, alerting if a user deserializes constantly
9 Using Components with Know Vulnerabilites Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts. Average Widespread Average Moderate There should be a patch management process in place to:
• Remove unused dependencies, unnecessary features, components, files, and documentation.
• Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
• Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
• Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue. Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.
10 Insufficient Logging and Monitoring Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring. Average Widespread Difficult Moderate As per the risk of the data stored or processed by the application:
• Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis.
• Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
• Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
• Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
• Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later. There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.

Mitigating the Risk

To mitigate these risks, the OWASP recommends using the following top ten proactive controls. Sofmen incorporates these into our standard practice:

  1. Define Security Requirements:
    A security requirement is a statement of needed security functionality that ensures one of many different security properties of software is being satisfied. Security requirements are derived from industry standards, applicable laws, and a history of past vulnerabilities. Security requirements define new features or additions to existing features to solve a specific security problem or eliminate a potential vulnerability.  OWASP has a catalog of available security requirements Sofmen uses as one resource for accomplishing this task.
  2. Leverage Security Frameworks and Libraries:
    Secure coding libraries and software frameworks with embedded security help software developers guard against security-related design and implementation flaws. A developer writing an application from scratch might not have sufficient knowledge, time, or budget to properly implement or maintain security features. Leveraging security frameworks helps accomplish security goals more efficiently and accurately.
  3. Secure Database Access:
    Four aspects to consider when designing secure database access are:

    1. Secure Queries
      SQL Injection occurs when untrusted user input is dynamically added to a SQL query in an insecure manner, often via basic string concatenation. SQL Injection is one of the most dangerous application security risks. SQL Injection is easy to exploit and could lead to the entire database being stolen, wiped, or modified. The application can even be used to run dangerous commands against the operating system hosting your database, thereby giving an attacker a foothold on your network.In order to mitigate SQL injection, untrusted input should be prevented from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as ‘Query Parameterization’. This defense should be applied to SQL, OQL, as well as stored procedure construction.
    2. Secure configuration
      Unfortunately, database management systems do not always ship in a “secure by default” configuration. Care must be taken to ensure that the security controls available from the Database Management System (DBMS) and hosting platform are enabled and properly configured. There are standards, guides, and benchmarks available for most common DBMS.
    3. Secure authentication:All access to the database should be properly authenticated. Authentication to the DBMS should be accomplished in a secure manner. Authentication should take place only over a secure channel.  Credentials must be properly secured and available for use.
    4. Secure communication:
      Most DBMS support a variety of communications methods (services, APIs, etc) – secure (authenticated, encrypted) and insecure (unauthenticated or unencrypted). It is a good practice to only use the secure communications options per the Protect Data Everywhere control.
  4. Encode and Escape Data:
    Encoding and escaping are defensive techniques meant to stop injection attacks. Encoding (commonly called “Output Encoding”) involves translating special characters into some different but equivalent form that is no longer dangerous in the target interpreter, for example translating the “<” character into the &lt; string when writing to an HTML page. Escaping involves adding a special character before the character/string to avoid it being misinterpreted, for example, adding a “\” character before a “” (double quote) character so that it is interpreted as text and not as closing a string.Output encoding is best applied just before the content is passed to the target interpreter. If this defense is performed too early in the processing of a request then the encoding or escaping may interfere with the use of the content in other parts of the program. For example if you HTML escape content before storing that data in the database and the UI automatically escapes that data a second time then the content will not display properly due to being double escaped.
  5. Validate All Inputs:
    Input validation is a programming technique that ensures only properly formatted data may enter a software system component.
  6. Implement Digital Identity:
    Digital Identity is the unique representation of a user (or other subject) as they engage in an online transaction. Authentication is the process of verifying that an individual or entity is who they claim to be. Session management is a process by which a server maintains the state of the users authentication so that the user may continue to use the system without re-authenticating.
  7. Enforce Access Controls:
    Access Control (or Authorization) is the process of granting or denying specific requests from a user, program, or process. Access control also involves the act of granting and revoking those privileges.
  8. Protect Data Everywhere:
    Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws (EU’s General Data Protection Regulation GDPR), financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.Attackers can steal data from web and webservice applications in a number of ways. For example, if sensitive information in sent over the internet  without communications security, then an attacker on a shared wireless connection could see and steal another user’s data. Also, an attacker could use SQL Injection to steal passwords and other credentials from an applications database and expose that information to the public.
  9. Implement Security Logging and Monitoring:
    Logging is a concept that most developers already use for debugging and diagnostic purposes. Security logging is an equally basic concept: to log security information during the runtime operation of an application. Monitoring is the live review of application and security logs using various forms of automation. The same tools and patterns can be used for operations, debugging and security purposes.
  10. Handle All Errors and Exceptions:
    Exception handling is a programming concept that allows an application to respond to different error states (like network down, or database connection failed, etc) in various ways. Handling exceptions and errors correctly is critical to making your code reliable and secure.Error and exception handling occurs in all areas of an application including critical business logic as well as security features and framework code.Error handling is also important from an intrusion detection perspective. Certain attacks against your application may trigger errors which can help detect attacks in progress.

The above information has been excerpted from OWASP which is freely available under the Creative Commons Attribution ShareAlike 3.0 license (CC-BY-SA).

Like it? Share it!