1) HttpOnly
When cookies are not marked as “HttpOnly”, potential perpetrator could exploit this by sending malicious code (such as cross-site scripting) to retrieve cookie information, and using that information to conduct further exploitation on the affected service or request.
It is recommended to modify the web application to set the “HttoOnly” attribute for all cookies to reduce the risk of cross-site scripting exploit.
You can set this under “tomcat/conf/context.xml” and change to <Context useHttpOnly="true">
2) Charset
The non-standard characters in the response may cause the browser to interpret the content using different character set, this might cause unexpected results such as cross-site scripting vulnerability, in which non-standard encodings (e.g UTF-7) can be used to bypass the application's defensive filters.
It is recommended to review the application, for every response containing HTML content the Content-type header must be returned and specify the standard recognized character set (e.g charset=ISO-8859-1)
3) Content-type
If the specified type is an image format, then the browser will usually detect the anomaly and will analyze the actual content and attempt to determine its MIME type. Either case can lead to unexpected results, and if the content contains any user-controllable data may lead to cross-site scripting or other client-side vulnerabilities.It is recommended that, for every response containing a message body, the application should include a single Content-type header (e.g application/json) which correctly and unambiguously states the MIME type of the content in the response body.
4) Clickjacking
It might be possible for a web page controlled by an attacker to load the content of this response within an iframe on the attacker’s page. This may enable a "clickjacking" attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.It is recommended to review the application and ensure that it should return a response header with the name X-Frame Options and the value DENY (e.g "X-FRAME-OPTIONS", "DENY") to prevent framing altogether or the value SAMEORIGIN to allow framing only by pages on the same as the response itself.
5) Insecure HTTP methods
Depending on the types of allowed methods, an attacker can plan and launch direct attacks against the server. For example, PUT and DELETE methods would enable the attacker to upload or delete files and resources from the server. With more advanced crafted attack, there is a possibility for the attacker to take over the server; therefore the impact of finding is rated “High”. The likelihood is rated “High” because it is very easy to query the server from client’s side, using different HTTP methods. For instance, it would only take one line of HTTP query (OPTIONS / HTTP/1.1) to discover what HTTP methods are supported by remote web server.It is recommended to disable support for the above-mentioned HTTP methods. Only allow the standard GET, POST & HEAD methods unless there is a specific requirement. Even so, it is recommended to provide strong check on it and ensure proper mitigations are in place.
6) Non-generic / runtime error messages
Error messages give very useful information to an attacker about the application and is usually the first stepping stone to help carry out an attack. Error messages in .NET can give out the following information: The language it was developed in, such as c# or vb.net, the stack trace of the program that failed, the version numbers for the .NET framework and ASP.NET, development class names and object structures. With the source codes being available to the attacker, they will be able to understand how the code works and craft specifics attack to exploit it.It is recommended to put validate all user inputs at server-side. In addition, proper exception handling should be incorporated into the application to catch exception that could possibly occur during the processing of user input. A generic error page should be displayed if there is unexpected error encountered. The error page should not reveal information such as paths, variables, file names, row and columns, table names in databases and database specific errors codes that may help perpetrator to plan for future attack.
7) SSL certificate pinning bypass
The information leakage of the backend infrastructure could play critical role in revealing known vulnerabilities for exploitation.It is recommended to implement anti-debugging strategies (code obfuscation) into the secure design of mobile application. This is applied to IOS application.
8) Password autocomplete
If this function is enabled, then credentials entered by the user are stored on their local computer and retrieved by the browser and future visits to the same application. The stored credentials can be captured by an attacker who gains access to the computer, either locally or through some remote compromise. Further, methods have existed whereby a malicious website can retrieve the stored credentials for other applications, by exploiting browser vulnerabilities or through application level cross domain attacks.
It is recommended to prevent browsers from storing credentials entered into the HTML forms, the attribute "autocomplete=off" should be included within the FORM tag to protect all form fields or within the relevant INPUT tags such as password fields.
