Leakage and Improper Error Handling in Web applications

[FaD KiNG]

I have read that the information leakage and improper Error Handling is one of important vulnerabilities in Web applications. I am not having much idea about this point. I have got some ideas from another thread which is Some vulnerabilities in Web applications. So I thought to post my query soon, so that members having ideas about vulnerabilities in web applications would help me too. Any more vulnerabilities in Web applications would also be grateful. So, I am hoping that you members will provide some detailed notes about it soon as possible.

[Jannat]

Web applications can inadvertently detailed information about the structure of the application or software versions reveal - for example on technical errors that appear directly in the browser of the user. Such errors can provoke an attacker aware of. Each system produces its own errors, the conclusions about functions and features allow the web application, but only the developers should be reserved. The most common abuse is to identify software versions currently used: If an attacker, they will know whether he can under certain circumstances, their vulnerabilities to exploit. For the operator of a Web application, this vulnerability is risky, because the launch can be based on further attacks.

[BoanHed]

When are exchanged in a Web application access, special care should be taken. Access and session information (session tokens) are often not well protected against hackers. For the latter session tokens are particularly interesting because they give access to restricted areas under the name and the rights of a legitimate user. Vulnerabilities in the default authentication mechanism are not always the easiest point of attack. Instead, hackers focus on vulnerabilities in additional functions such as authentication function logout, password reminder, or "Secret Questions" takes you to access to information. The faulty handling of session tokens can be exploited using XSS and man-enter-the-middle attacks in the possession of the session token and thus take over the session (session hijacking). Users and operators thereof are equally affected, since compromise can find user accounts and administrators.

[Wilbur]

In many web applications missing cryptographic functions or are poorly implemented. Here, the encryption of sensitive data such as access and credit card information, or non-predictability of such session tokens important mechanisms for securing a web application. However, cryptographic functions does not necessarily ensure that data and tokens are really protected. Sometimes self-developed, weak (such as MD5 or SHA-1) or incorrectly implemented algorithms are used which can be broken and thus offer no protection. In addition, the cryptographic keys are often stored (for example in the downloadable application) in unsafe places, making the security of the encryption mechanism is repealed.

[RogerFielden]

In insecure communications type of vulnerability of sensitive data transmitted over an insecure communication channel in plain text or only partially encrypted or insecure. In these cases, a passive eavesdropping by an attacker or a man-access in-the-middle attack on the transferred data. Especially for transmitting confidential information such as access, payment or customer data, it is necessary to encrypt the data communication. However, there are web applications that manage the replacement of the login information via a secure transmission channel and the subsequent communication can be encrypted. It is often forgotten that to be transferred to the following questions safety information such as session authentication tokens. This allows the attacker to sniff unencrypted tokens and to authenticate the foreign identity on the web application.

[Fragman]

Critical information in a Web application are often protected only by the fact that the URL an unauthorized user will not be shown or not known. For an attack that can be exploited by the URL is accessed directly. The best known method of attack that abuses this gap is called "forced browsing" The attacker tried to identify through systematic "testing" unprotected page content or application functionality and access. The goal is often to make hidden files or URLs identified that were overlooked in the implementation of the permissions. For the operator of a Web application such weaknesses are particularly controversial, since an attacker gaining information as to their form and structure, or even gets access to administrative functions of the site.