Vulnerability Name | Description |
Cross Site Scripting | Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page. |
Missing input validation | Input Validation is the most effective and important technique to prevent most of the vulnerabilities. It can mitigate numerous vulnerabilities like cross site scripting, various forms of injections, and buffer overflows etc. Input validation is something more than checking form field values. By input validation, we mean checking the user input against some predefined conditions. Each and every user input should be validated first; thereafter it should be used for further processing. |
Cross Frame Scripting | 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 “Click jacking” 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. |
Secure cookie attribute not set | Secure attribute tells the browser to send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. |
Banner Grabbing | It is a technique used to remotely gain information about the web server (version, Technology used, underlying OS, vendor etc.). By identifying the HTTP server the attacker can determine known vulnerabilities related to the web server and the appropriate exploits for the same. |
Improper Browser Cache Management | Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored. Therefore, we need to check that the application does not leak any critical data into the browser cache. For instance, if it’s an e-commerce application, we should be aware that all pages that contain a credit card number or some other financial information, all those pages enforce the no-cache directive. The exact location where that information is stored depends on the client operating system and on the browser that has been used. For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. |
Remember Password | Mechanism to “remember my password” may be implemented with by allowing the “cache password” feature in web browsers or storing the password in a permanent cookie. When the mechanisms are enabled attacker can gain information from the browser cache. If an attacker can gain access to the victim’s browser (e.g. through a Cross Site Scripting attack, or through a shared computer), then they can retrieve the stored passwords. It is not uncommon for browsers to store these passwords in a fully retrievable manner, but even if the browser were to store the passwords encrypted and only retrievable through the use of a master password, an attacker could retrieve the password by visiting the target authentication portal web site, entering the victim’s username, and letting the browser to enter the password. |
User name stored in browser/Autocomplete enable | Storing the user names in browser makes it very easy for anyone, to get the user name or id using the same client machine, and in the given context as there is no account lock out it is possible to brute force. |
Clear TextStorage of data in browser memory | The browser remembers all the GET and POST requests it has made until it is open. So, the POST request on the Login page containing the username and password of the user is also stored in the memory. The browsers memory can be read using memory-reading tools like WinHex. An adversary with access to the users open browser, after logout, can thus steal the password from the memory. |
Improper Error Handling | 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 |
Certificate Host Name Discrepancy | This policy states that any area of the website or web application that contains sensitive information or access to privileged functionality such as remote site administration requires that the certificate used by the server is the same host as the server hostname. |
Cross Site Request Forgery | CSRF is an attack which forces an end user to execute unwanted actions on a web application .The attack leverages the trust placed by the application on the user actions due to lack of mechanism to verify the source of origin of the action being performed. CSRF takes advantage of the fact that the browser automatically sends information which is used to identify a user session with any further request directed to site. So in cases where a victim gets tricked into clicking malicious links, the malicious request sent then is assumed to be valid by application and gets executed without the knowledge of the victim leading to compromise of end user data and user operations. |
Session ID value not changed on authentication | The application does not assign a new “PHPSESSID” value on authentication |
Insecure transport layer protection – Weak SSL Cipher Supported | A weak encryption scheme can be subjected to brute force attacks that have a reasonable chance of succeeding using current methods and resources. An attacker may be able to execute a man-in-the-middle attack which would allow them to intercept, monitor and tamper with sensitive data. |