| Sl No | Vulnerability | Description | Recommendation |
| 1 | Cross Site Scripting: DOM | DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. | The solution to XSS is to ensure that validation occurs in the correct places and checks for the correct properties. The most secure approach to validation for XSS is to create a whitelist of safe characters that are allowed to appear in HTTP content and accept input composed exclusively of characters in the approved set. If input containing special characters must be accepted and displayed accurately, validation must encode any special characters to remove their significance. A proper output encoding should be done of each output data that is being written on the browser. |
| 2 | Cross Site Request Forgery | Cross-site request forgery (CSRF) vulnerability occurs when: 1. A Web application uses session cookies. 2. The application acts on an HTTP request without verifying that the request was made with the user’s consent. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack. | Each and every form request should be accompanied by a user specific token or secret, so that the server can identify the authorized and unauthorized requests. |
| 3 | SQL Injection | SQL Injection is a type of injection attacks. This type of attack occurs when: 1) Data enters a program from an untrusted source. 2) The data is used to dynamically construct a SQL query (when the Query is not parameterized) Thus the untrusted vulnerable data enters into the system. Further if the corresponding SQL query is not a parameterized query, then attacker can modify it accordingly, to get his intended outputs. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system, and in some cases, issue commands to the operating system. | It is recommended to use: 1) Parameterized SQL queries in place of dynamic SQL statements. 2) Perform white-list input validation for all input data. 3) Ensure that all SQL statements recognize user inputs as variables, and those statements are precompiled before the actual inputs are substituted for the variables |
| 4 | Use of Hardcoded Password | Hardcoding a password exposes the password to the people who has access to code and makes easy to guess the password. A hard-coded password typically leads to a significant authentication failure that can be difficult for the system administrator to detect. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability. This may result in system compromise. | It is recommended not to store password in plaintext. Instead, the password should be obfuscated and stored in the external source. |
| 5 | ASP.NET Misconfiguration: Missing Error Handling | An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework’s built-in error responses. In the event of an application exception, use the <customErrors> element to configure custom, generic error messages that should be returned to the client. The default error page provides detailed information about the error that occurred, and should not be used in production environments. The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used. If the custom error message mode is turned off, an ASP.NET error message with detailed stack trace and platform versions will be returned. | It is recommended to handle exceptions appropriately in application. The best practice is to use a custom error message. The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used. It should be configured to use a custom page as follows: <customErrors mode=”On” defaultRedirect=”YourErrorPage.htm” /> |
| 6 | ASP.NET Misconfiguration: Request Validation Disabled | Request validation, a feature of ASP.NET prevents the server from accepting content containing un-encoded HTML. This feature is designed to help prevent some script-injection attacks whereby client script code or HTML can be unknowingly submitted to a server, stored, and then presented to other users. Unchecked input is the leading cause of vulnerabilities in ASP.NET applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities. To prevent such attacks, ASP.NET validation framework is used to check all program input before it is processed by the application. | It is suggested to set the “validateRequest” tag as follows: <configuration> <system.web> <pages validateRequest=”true” /> </system.web> </configuration> |
| 7 | ASP.NET Misconfiguration: Debug Enabled | Deploying Web-based applications in debug mode may lead to insecure application deployment. Virtually all Web-based applications require some debugging. Usually it’s done in Web.xml file to allow debugging when we start to debug application. And, since deploying applications is as simple as copying the files from the development folder into the deployment folder, it’s easy to see how development configuration settings can accidentally make it into production, compromising application security. Debugging messages help attackers learn about the system and plan a form of attack. | Compile production binaries without debug enabled. This can be accomplished by setting the debug attribute to false on the <compilation> tag in your application’s configuration file, as follows: <configuration> <compilation debug=”false”> … </compilation> … </configuration> |
| 8 | ASP.NET Misconfiguration: MIME Sniffing | MIME sniffing, is the practice of inspecting the content of a byte stream to attempt to deduce the file format of the data within it. If MIME sniffing is not explicitly disabled, some browsers can be manipulated into interpreting data in a way that is not intended, allowing for cross-site scripting attacks. | To mitigate this finding, it is suggested to: (1) Set sniffing tag globally for all pages in the application in the web.config file, or (2) Set the required header page by page for only those pages that might contain user-controllable content. Ex: <system.webServer> <httpProtocol> <customHeaders> <add name=”X-Content-Type-Options” value=”nosniff”/> </customHeaders> </httpProtocol> </system.webServer> |
| 9 | ASP.NET Misconfiguration: Incomplete Cookie Protection | The contents of unprotected cookies could be viewed or modified by attackers. Cookies are often used to store important information about users, such as personal information, authentication tokens and a history of their activity. If this information is stored in plaintext, anyone with access to machines used to interact with the application will have access to the information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage. ASP.NET validation framework provides an excellent way to both protect the contents of the cookie and to verify that the cookie has not been modified unexpectedly. | It is recommended to set the protection level for cookies to all, which encrypts the cookie to prevent users from viewing the data stored in it and verifies a hash of the cookie to prevent users from tampering with the cookie. |
| 10 | WCF Misconfiguration: Insecure Transport | If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel. | It is suggested that HTTPS transport to be enabled for transmitting SOAP messages carrying sensitive information. |
| 11 | WCF Misconfiguration: Security Not Enabled | Applications that transmit messages without transport or message security cannot guarantee the integrity or confidentiality of the messages. When a WCF security binding is set to None, both transport and message security is disabled. | It is suggested to use transport and message security to protect the integrity and confidentiality of messages. It is advised to set <security> mode to “TransportWithMessageCredential” and clientCredentialType to “Windows” or “Certificate”. The configuration below tells the service to use transport security with message credentials. <system.serviceModel> <bindings> <wsHttpBinding> <binding name=”MyBinding”> <security mode=”TransportWithMessageCredential”/> <message clientCredentialType=”Windows”/> </binding> </bindings> |
| 12 | WCF Misconfiguration: Service Enumeration | WCF services can be configured to expose metadata. Metadata gives detailed service description information and should not be broadcast in production environments. The <serviceMetadata> tag enables the metadata publishing feature. Service metadata could contain sensitive information that should not be publicly accessible. Publicly exposing information about a service can provide attackers with valuable insight into how they might exploit the service. The HttpGetEnabled / HttpsGetEnabled properties of the ServiceMetaData class define whether a service will expose the metadata. | At a minimum, only allow trusted users to access the metadata and ensure that unnecessary information is not exposed. It is better to entirely disable the ability to publish metadata. A safe WCF configuration will not contain the <serviceMetadata> tag. |
| 13 | WCF Misconfiguration: Anonymous Transport Client | The Windows Communication Foundation (WCF) scenario uses transport security (HTTPS) to ensure confidentiality and integrity. The server must be authenticated with a Secure Sockets Layer (SSL) certificate, and the clients must trust the server’s certificate. The client is not authenticated by any mechanism and is, therefore, anonymous. A service that does not authenticate its clients allows accessing its functionality to anyone. | Configure the application to authenticate against client credentials. This can be done by setting the transport <clientCredentialType> to Windows or Certificate. <transport clientCredentialType = “Certificate”/> |
| 14 | WCF Misconfiguration: Transport security enabled | The application configuration should ensure that HTTPS is used for all access to sensitive information. If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel. | Ensure that HTTP transport is disabled and enable HTTPS transport instead. Ex replace the <httpTransport/> with <httpsTransport/> tag. |
| 15 | Cookie Security – Cookie not set with HttpOnly | HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using HttpOnly flag with a cookie helps in mitigating the risk of client side script accessing the protected cookie. If the HttpOnly flag (optional) is not included in the HTTP response header, then the cookies can be accessed through client side script. These stolen cookies can contain sensitive information identifying the user to the site, such as the session ID or forms authentication token. | Ensure that the value of the “httpOnlyCookies” attribute in the “web.config” element is set to true. |
| 16 | Cookie Security: Session Cookie not sent Over SSL | Require SSL attribute on authentication Cookies in a Web application, that use the Secure Sockets Layer (SSL) protocol to encrypt data passed between the Web server and the client. Thus a network sniffer will not be able to read the authentication token from the request cookie. By setting the require SSL attribute to true, ASP.NET Web-based applications will use a secure connection when transmitting the authentication cookie to the Web server. | It is recommended to set require SSL property to “True”. Example: <configuration> <system.web> <authentication mode=”Forms”> <forms requiressl=”true”> |
| 17 | Cookie Security: Persistent Cookie | If private information is stored in persistent cookies, attackers have a larger time window in which to steal this data – especially since persistent cookies are often set to expire in the distant future. Persistent cookies are often used to profile users as they interact with a site. Depending on what is done with this tracking data, it is possible to use persistent cookies to violate users’ privacy. | Do not store sensitive data in persistent cookies. Be sure that any data associated with a persistent cookie stored on the server side is purged within a reasonable amount of time. |
| 18 | Cookie Security: Overly Broad Path | Developers often set cookies to be accessible from the root context path (“/”). Doing so exposes the cookie to all web applications on the domain. Since cookies often carry sensitive information such as session identifiers, sharing cookies across applications can lead vulnerability in one application to cause a compromise in another. | Make sure to set cookie paths to be as restrictive as possible. |
| 19 | Weak XML Schema – Unbounded occurrences | Processing XML documents can be computationally expensive. Attackers can take advantage of schemas that allow unbounded elements by supplying an application with very large number elements causing the application to exhaust system resources. Setting a <maxOccurs> value to unbounded can lead to resources exhaustion and ultimately a denial of service. | It is suggested to set the <maxOccurs> value to a finite number depending on the need. |
| 20 | Excessive Session Timeout | The lack of proper session expiration may improve the likely success of certain attacks. For example, an attacker may intercept a session ID, possibly via a network sniffer or Cross-site Scripting attack. Although short session expiration times do not help if a stolen token is immediately used, they will protect against ongoing replaying of the session ID. Insufficient Session Expiration could allow an attacker to use the browser’s back button to access web pages previously accessed by the victim. Longer authentication timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created. | It is suggested to set session timeout to the minimal value possible depending on the context of the application and avoid using “infinite” session timeout. |
| 21 | Use of Broken or Risky Cryptographic Algorithm | Use of broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information. The use of a non-standard algorithm is dangerous because a determined attacker may be able to break the algorithm and compromise whatever data has been protected. Well-known techniques may exist to break the algorithm. | Discontinue the use of MD5 and SHA-1 for data-verification in security-critical contexts. Only use approved public algorithms such as AES and RSA public key cryptography for encryption and SHA-256 or better algorithm for hashing. |
| 22 | Use of jQuery outdated version | JQuery contains a flaw that allows a DOM-based cross-site scripting (XSS) attack. jQuery versions below 1.6.3, when using location.hash to select elements, allows remote attackers to inject arbitrary web script or HTML via a crafted tag. This flaw exists because the application does not validate certain tags while being rendered using innerHTML. This may allow a user to create a specially crafted request that would execute arbitrary script code in a user’s browser within the trust relationship between their browser and the underlying library. | It is suggested to upgrade the jQuery to higher versions like above 1.9(atleast1.6.3) which has fixes for these issues. |
| 23 | System Information Leak | An information leak occurs when system data or debugging information leaves the program to a remote machine via socket or network connection. | Write error message with keeping security in mind. In production environments, turn off detailed error information in favor of brief messages. Restrict the generation and storage of detailed output that can help administrators and programmers diagnose problems. Even brief error messages that do not reveal stack traces or database dumps can potentially aid an attacker. |
| 24 | Insecure Randomness | Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated. There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. | When unpredictability is critical, as is the case with most security-sensitive uses of randomness, use a cryptographic PRNG. |
| 25 | Privacy Violation: Auto Complete is on | With <autocomplete> enabled, some browsers retain user input across sessions, which could allow someone using the computer after the initial user to see information previously submitted. | Explicitly disable <autocomplete> on forms or sensitive inputs. By disabling <autocomplete>, information previously entered will not be presented back to the user as they type. It will also disable the “remember my password” functionality of most major browsers. |
| 26 | Possibility of Dynamic Code Evaluation: Usage of Eval method | Eval() function takes up the instructions supplied directly from the user and evaluates it as an expression. However, without proper validation, a user might specify operations the programmer does not intend. If an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of JavaScript, the attacker can utilize this vulnerability to perform a cross-site scripting attack. | It is advised to use JSON.parse as a more secure alternative for this task. |
| 27 | Java Script Hijacking | JavaScript hijacking occurs when the browser handles confidential data and browser uses JavaScript as a data transfer format. JavaScript hijacking allows the attacker to bypass the Same Origin Policy in the case that a web application serves up JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website. Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. | All programs that communicate using JavaScript should take the following defensive measures: – – Decline malicious requests by using hard-to-guess identifier, such as the session identifier, – Prevent direct execution of the JavaScript response either by validating the request or by including characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a <script> tag to witness the execution of the JavaScript. |
| 28 | Access Specifier Manipulation | Access Specifier Manipulation enables the programmer to allow a reflected object to bypass Java access controls and in turn change the value of private fields or invoke private methods, behaviors that are normally disallowed. | Access specifiers should only be changed by a privileged class using arguments that an attacker cannot set. All occurrences should be examined carefully. |
| 29 | Android Bad Practices: Missed Exported Flag or Component Permission | Any application can access public components that are not explicitly assigned access permission in their manifest definition. Android content provider are exported by default for applications that set either android:minSdkVersion or android:targetSdkVersion to “16” or lower. For applications that set either of these attributes to “17” or higher, the default is “false”. The default value of the exported attribute for the activity, receiver and service components in an Android application depends on the presence or absence of an intent-filter. Presence of an intent-filter implies, the component is intended for external use, thus setting the exported attribute to true. This component is now accessible to any other applications on the Android platform and sensitive data might get exposed to other applications. | If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false in the application manifest. Otherwise, set the android:exported attribute “true” to allow other apps to access the stored data. |
| 30 | Android Bad Practices: Mixed Component Functionality and Unnecessary Exposure | System broadcasts can be sent to private components. Components need to be public to receive non-system broadcasts from third-parties. By registering to receive both system and non-system broadcasts in a single component, some of the functionality of the component (the system portion) is unnecessarily exposed to third parties. The components that are only expected to receive broadcast messages from the system and no other components, it should be private (inaccessible to other components.) | To reduce the exposed surface of the application, the component should be divided into two parts so that the system broadcast portion can be private. It is recommended to separate the functionality that handles system messages from the functionality that handles other messages by configuring the <receiver> component in the manifest. To allow the component to receive system broadcasts but not third-party broadcasts (regardless of explicit or implicit message status), set the android:exported flag to ‘false’ and the android:enabled flag to ‘true’. |
| 31 | Insecure Transport | The application configuration should ensure that SSL is used for all access controlled pages to guarantee confidential communication with client browsers. If the mobile app transmits personally identifiable information or other sensitive information like session cookie to an endpoint via non-secure channels instead of over SSL, the confidentiality of any privacy-related data between the mobile app and the endpoint can be compromised. | It is recommended to use secure protocols such as HTTPS to exchange data with the server. |
| 32 | Privilege Management: Unnecessary Permissions | AndroidManifest.xml file presents essential information about your app to the Android system which are must have before the system can run on any of the app’s code. From a security perspective, the file is most interesting because it defines the permissions the application must have to other applications or protected parts of the API. | It is recommended to define permissions to the application based on requirement and business purposes. |
| 33 | Missing Check for Null Parameters | It is important to check the return value of the function to avoid unexpected states and conditions. | It is recommended to check the return values of the function for unexpected states and values such as null parameters etc. |
| 34 | Improper Error Handling | Improper error handling happens when • The detailed internal error messages such as stack traces, database dumps, and error codes are displayed to the user (hacker). These messages reveal implementation details that should never be revealed. Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users. • Ignoring an exception with empty catch blocks can cause the program to overlook unexpected states and conditions. • The catch block handles a broad swath of exceptions, potentially trapping dissimilar issues or problems that should not be dealt with at this point in the program. | It is recommended to • Return a simple error message to the user and redirecting to common error page when the error occurs. • Provide the user with diagnostic information (e.g., data validation errors), but do NOT provide developer level diagnostic/debug information. • Properly handling the errors and exceptions by implementing catch block and by not throwing broader exceptions. |
| 35 | Test Files are present in the application | Old, backup, Test and unreferenced files present various threats to the security of a web application: • Test files may disclose sensitive information that can facilitate a focused attack against the application; for example include files containing database credentials, configuration files containing references to other hidden content, absolute file paths, etc. • Unreferenced pages may contain powerful functionality that can be used to attack the application; for example an administration page that is not linked from published content but can be accessed by any user who knows where to find it. • Test files may disclose the source code for pages designed to execute on the server. | It is always recommended to remove all the test pages / dead codes / commented codes / unused pages in the directory before going to production environment. |
| 36 | Improper Resource Shutdown/Release | When a resource is created or allocated, the developer is responsible for properly releasing the resource as well as accounting for all potential paths of expiration or invalidation, such as a set period of time or revocation. Improper release or shutdown of resources is the result of improper error handling or insufficient resource tracking. Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, it may be possible to launch a denial of service attack by depleting the resource pool. | Resources should be closed in finally clause. Ensure that all code paths properly release resources. |
| 37 | Privacy Violation | Privacy violations occur when: 1. Private user information enters the program. 2. The data is written to an external location, such as the console, file system, or network. | To enforce good privacy management, develop and strictly adhere to internal privacy guidelines. The guidelines should specifically describe how an application should handle private data. If your organization is regulated by federal or state law, ensure that your privacy guidelines are sufficiently strenuous to meet the legal requirements. Even if your organization is not regulated, you must protect private information or risk losing customer confidence. |