Top 39 most common and dangerous cyber security concerns/software weakness

Here's a list of the most common security and software issues our developers have faced over the past few years. These issues are especially dangerous as they are often easy for somebody to find and exploit, and can allow adversaries to steal data, completely take over a system, and stop an application from working. These are mistakes you'll have to pay for later. Let's get right to it.

1. SQL Injection:
   SQL injection is a top database security concern. For almost all web applications, databases are the core of storing state. Taking care of the interactions with the database is crucial to ensure the app keeps running. SQL injection attacks are a serious security concern for companies. A SQL injection attack that’s successful could result in confidential data being stolen, lost or deleted, unauthorized access to systems or accounts, websites being defaced, and, ultimately, compromise of entire networks or individual machines. Only when an application receives user input in a form it isn't expecting does SQL injection attacks work by fooling the application into executing code. Carrying out data validation and sanitization is a vital SQL injection security measure. This adds an inspection layer effectively to make sure that any submitted data isn’t unusual, which could pose a SQL injection risk.
   ORMs or Object-Relational Mappers are a set of SQL libraries that assist developers in managing the database code by abstracting them into language constructs. ORMs are extremely popular in many languages: PHP has Eloquent, Java has Hibernate, Ruby has ActiveRecord, Python has SQLAlchemy, and JavaScript has Sequelize and TypeORM. SQL ORM libraries are great to prevent SQL Injection. Sequelize is a safe package to use, security-wise. New vulnerabilities may be disclosed over time on sequelize and other packages. We recommend you practice secure coding conventions and follow best practices to find, fix, and prevent such vulnerabilities easily.
2. Broken Authentication:
   An Authentication API endpoint is the entry point to the rest of the API. Hence it is crucial to treat it differently. Firstly, assuming all others are protected by authentication tokens, it is the only open end-point. Secondly, the rest of the API access control is off if compromised. Implementing a solid layer of security for the API endpoint will protect you from many attacks like brute force, credential stuffing and token stealing. Your team should be able to correctly implement authentication measures such as JSON Web Tokens (JWT). Then you can provide a solution for exploiting and demonstrating JWT or JSON Web Tokens after finding vulnerabilities in a big code base.
3. Sensitive Data Exposure:
   When an application doesn't protect sensitive information adequately is when Sensitive Data Exposure occurs. And data anonymization is the process of protecting sensitive or private info by encrypting or erasing identifiers which connect an individual to stored data. Data anonymization is done based on different roles:
   -Passwords are SHA512 encrypted-With the same hardened key management systems we use for our own encrypted data, all data stored within Google Cloud is encrypted at rest.
4. XML External Entities (XXE):
   Also known as XXE, XML external entity injection allows an outsider to interfere with an app's processing of XML data and so is considered a web security vulnerability. The XML processor must disallow any declared DTD within the XML document and be configured to use a local static DTD.
5. Broken Access control:
   Access control enforces policy in a way that users can’t act outside their intended permissions. Failures typically lead to unauthorized modification, information disclosure, or performing a business function outside of the limits of the user or destruction of all data. The most critical step is to think through an app’s access control needs and capture it in a web app security policy. On Logout or session expiry, we make sure the user won't be able to access restricted pages. This has been validated and evidenced as part of test cases.
6. Security misconfigurations:
   Security Misconfiguration is simply defined as failing to implement all the security controls for a server or web application, or implementing the security controls, but doing so with errors. From the infra standpoint, things at GCP are secured. From App standpoint, we have implemented two factor authentication thus ensuring controlled access ensuring higher degree of security
7. Cross Site Scripting (XSS):
   These Cross-Site Scripting (XSS) attacks are a type of injection, wherein malicious scripts get injected into otherwise trusted and benign websites. 'Cross-site Scripting' or During Web Page Generation, Improper Neutralization of Input is what leads to this. It's important that you turn off HTTP TRACE support on all web servers. Even when document.cookie is disabled or not supported by the client, an attacker can steal cookie data through Javascript.
8. Insecure Deserialization:
   This kind of threat happens when components like frameworks and libraries used within the application just about always execute with complete privileges. It makes the hacker's job easier to cause a serious data loss or server takeover if a vulnerable component is exploited. We use minimum external libraries and those are standard ones with higher rating in Github and hence we would not foresee any issues.
9. Using Components with known vulnerabilities:
   This kind of threat happens when components like frameworks and libraries used within the app almost always execute with full privileges. It makes the hacker's job easier to cause a serious data loss or server takeover if a vulnerable component is exploited. We use minimum external libraries, and those are standard ones with higher rating in Github, and hence we would not foresee any issues.
10. Insufficient logging and monitoring:
    Insufficient Logging and Monitoring, rather than being a vulnerability in itself, is a category that covers the lack of various best practices, which could, in turn, damage or prevent control security breaches. We typically run the servers using PM2 for Monitoring and have the logs as well managed in the same.
11. Out-of-bounds Write:
    The software writes data before the beginning or past the end of the intended buffer. Typically this happens when pointer arithmetic results in a position outside of the valid memory location or when the pointer or its index is decremented or incremented to a position beyond the bounds of the buffer, to name a few.
12. Improper Input Validation:
    An attacker can craft the input in a manner that is unexpected by the rest of the app when software doesn't validate input properly. Our team performs proper type checking from both front end and back end systems. This is preventive and would not lead to Improper inputs.
13. Out-of-bounds Read:
    The software reads data before the beginning or past the end of the intended buffer. Here is a typically no Out-Of-bounds error in Javascript, unlike C. On usage of NodeJS versions beyond 6.7.0, 4.6.0, 0.12.16, 0.10.47 also is a recommendation. We have upgraded to 12.x.
14. Within the Bounds of a Memory Buffer, Improper Restriction of Operations:
    This is preventive. The software can write to or read from a memory location that is outside of the intended boundary of the buffer, but it performs operations on a memory buffer. We are using the NodeJS version beyond 10.9, which has certain remote known vulnerability as recommended by NVD (National Vulnerability Database). The version that we are using is 12.16.3.
15. SQL Injection or Improper Neutralization of Special Elements used in an SQL Command:
    Using input that is externally-influenced from an upstream component, the software constructs all or part of an SQL command, but it incorrectly neutralizes or does not neutralize special elements when sent to a downstream component, which can modify the intended SQL command. We don't use raw SQL queries and use Sequelize as ORM.
16. Exposure to an Unauthorized Actor of Sensitive Information:
    The product exposes sensitive info to an actor that is not explicitly authorized to have access to that info. Data anonymization is done based on different roles:
    -Passwords are SHA512 encrypted -Using the same hardened key management systems we use for our own encrypted data, all data stored within Google Cloud is encrypted at rest.
17. Use After Free:
    After it has been freed, referencing memory can cause a program to crash, execute code or use unexpected values.
18. Cross-Site Request Forgery (CSRF):
    Cross-Site Request Forgery/CSRF is an attack forcing an end-user to perform unwanted actions on a web app in which they’re currently authenticated. An attacker can trick the user of a web application with a little help of social engineering (like sending a link via chat or email) into executing actions of the attacker’s choosing. A successful CSRF attack, when the victim is a random user, can make this user perform state-changing requests like modifying their email address, transferring funds, and so forth. CSRF could compromise the complete web app if the victim is an administrative account. We have implemented anonymization where we have tokenized values as part of role permissions, in the forms in which the parameters are not exposed. And so we have the prevention layer towards something like CSRF.
19. OS Command Injection or Improper Neutralization of Special Elements used in an OS Command:
    Using externally-influenced input from an upstream comp, the software constructs all or part of an OS command, but it incorrectly neutralizes or doesn’t neutralize special elements that may change the intended OS command when sent to a downstream comp. Make it so that only restricted people with the right credentials can access the system which as mentioned earlier, passwords are SHA512 encrypted.
20. Integer Wraparound or Overflow:
    An integer wraparound or overflow happens when an integer value is incremented to a value which is too large to store in the representation associated. The value may wrap to become a negative or very small number when this occurs. There is no situation of manual increment leading to Wraparound issues, and so the increments are handled through the app. At the application level itself, it's best to handle this vulnerability.
21. Path Traversal or Improper Limitation of a Pathname to a Restricted Directory:
    Many file operations are meant to happen in a restricted directory. Attackers can escape outside of the restricted location by making use of special elements such as ".." and "/" separators to access directories or files that are elsewhere on the system. To protect the app from the weakness, it is advised to not use attacker controlled data as part of the filename or the a filename when performing operations on folders or files. When working with files or directories using user-controlled input, perform whitelist checks and also use sandbox environment.
22. NULL Pointer Dereference:
    When the app dereferences a pointer that it expects to be valid, but is NULL, a NULL pointer dereference occurs typically causing a crash or exit.
23. Improper Authentication:
    When the software does not prove or insufficiently proves that the claim is correct when an actor claims to have a given identity, its called improper authentication. Passwords can be SHA512 encrypted. There can be another layer of 2-factor authentication for signups in ensuring legitimate access. During Signup, a user can be required to validate via email and also the mobile 6 digit OTP.
24. Unrestricted Upload of File with Dangerous Type:
    Including complete system takeover, forwarding attacks to back-end systems, an overloaded file system or database, simple defacement, or client-side attacks, the consequences of unrestricted file upload can vary depending upon what the app does with the uploaded file and where it is stored, especially. We can restrict/whitelist the file types, thus managing the mentioned vulnerability.
25. Incorrect Permission Assignment for Critical Resource:
    It could lead to the modification of that resource by unintended parties or the exposure of sensitive information when a resource is given a permissions setting, which provides access to a wider range of actors than required. When the resource is related to program execution, configuration, or sensitive user data, it is especially dangerous. Permissions and roles can be managed as per the app requirement from the client. We can adopt the least access approach, thus enforcing role permissions and restrictions.
26. Code Injection or Improper Control of Generation of Code:
    It is possible for an attacker to craft the code in such a way that it alters the intended control flow of the software when software allows a user's input to contain code syntax. This kind of alteration can lead to arbitrary code execution. Implementing the right data input and output validation can restrict and manage proper data access.
27. Insufficiently Protected Credentials:
    The product stores or transmits authentication credentials, but it uses an insecure method susceptible to unauthorized retrieval and/or interception. Application data transmission should be encrypted and not store authentication credentials and so can avoid any susceptibility.
28. Improper Restriction of XML External Entity Reference:
    This refers to cases where XML parser is not properly configured and lets the attacker to directly interact with external or local files is defined as Improper Restriction of XML External Entity Reference or XXE.
29. Use of Hard-coded Credentials:
    Hard-coded credentials generally create a significant hole allowing attackers to bypass the authentication, which has been configured by the software administrator. This hole can be hard for the system administrator to detect. Even when detected, it could get hard to fix, forcing the administrator into disabling the product completely. In some of the projects we’ve worked on, we have separate config/env files through which it is managed, and there was no hard coding.
30. Deserialization of Untrusted Data:
    The method of converting an object to a sequence of bytes that can be persisted to a database or disk or can be sent through streams is known as Serialization. Creating objects from a sequence of bytes, the reverse process is called deserialization. When an application deserializes untrusted data without verifying sufficiently that the data you get will be valid, letting the attacker to control the flow or the state of the execution is when deserialization of untrusted data occurs. It can be handled from both front end and back end before object creation as the code usually expects a definable set of class, by enforcing strict type constraints.
31. Improper Privilege Management:
    The software doesn’t properly modify, assign, check, or track privileges for an actor, building an unintentional sphere of control for the actor. During the Architecture and Design, Implementation and Operation stages, the weakness is introduced. At the time of implementation of an architectural security tactic, this weakness is caused. Build an application that properly assigns, updates, and manages the privilege of the respective user, and this should be validated in the tests that are performed and which is evidenced as part of the test artifacts of the testing conducted.
32. Uncontrolled Resource Consumption:
    Limited resources include file system storage, memory, CPU, and database connection pool entries. If the size or number of the resources is not controlled, and an attacker triggers the allocation of these limited resources, then the attacker can cause a denial of service consuming every available resource. Ideally, there shouldn’t be any situation leading to uncontrolled resource consumption.
33. Missing Authentication for Critical Function:
    For functionality which consumes a significant amount of resources or requires a provable user identity the software doesn’t perform any authentication. The credentials can be tokenized and will be declined access and hence would not lead to this vulnerability of missing authentication.
34. Missing Authorization:
    Authorization is the means of determining if the user, a user with a given identity, could access a particular resource, based upon the user's any permissions & privileges or other access controlled specifications which apply to the resource. By the implementation of route auth guard, this vulnerability is managed.
35. Privilege Escalation Detection via open ports/application:
    Privilege escalation happens when a user with malicious intentions exploits a design flaw, bug, or configuration error in an operating system or app to gain elevated access to resources, which should normally be unavailable to the user. We handle the open ports through whitelisting those specific ports, and that's how access stays controlled and managed.
36. Detecting/blocking unauthorized access to system/application/database:
    Without the PEM key, one cannot access the instance/cloud server. Hence there would be no unauthorized entry.
37. Detecting/blocking unauthorized/volume download of data from the system:
    Without the PEM key, one cannot access the instance/cloud server. Hence there would be no unauthorized entry.
38. Preventing lateral movement within the infrastructure:
    Lateral movement means techniques cyber attackers use to move through a network progressively, searching for targeted key assets and data. Its controlled via the industry specified best practices like :
    Least privilege: For example, in a corporate network, only IT staff should manage devices such as desktops and notebooks. IT staff should not provide users with administrator privileges.
    Whitelisting: When there is a request to an app whose functions are fulfilled by another already, there might be no need to enable that service.
    Strong password management/policies and more.
39. Tracking all admin activities on the cloud and alert on unauthorized/unusual activities:
    Unauthorized access is prevented through certain controls. Notifications could be enabled for the IPs outside the particular ecosystem trying to access the system.

We hope this proves useful.