Web Application Security

Web Application Security Here I will exaplain about some of the vulnerabilities in web applications. The objective is to show the need to secure the applications as they allow attackers to compromise a web server or network over the legitimate port of entry and buffer overflows.

Web based application security is diffrent from general web security. In the general context, usually an IDS and firewall give some security. However in the case of web applications, the session takes place through the allowed defult port 80. If encryption is used, it only encrypts the transport protocol and in the event of an attack, the attacker's session will just be encrypted in nature. Encryption does not stop the attack.
Attacking web applications is one of the most common way hackers penetrate any systems. This is true for today's corporate applications where many of them are custom made. Nobody notices this, until serious damage has accured. To the end user the application may be functioning as programmed to. At the organization level, complacency settles in as the organization considers itself secure due to strong networking security.
[Some common Web Application vulnerabilities] are (Reliability of Client-Side Data), It's important that the web application rely on server side data for critical operations rather than the client side data, especially for input purposes. (Special Characters that have not been escaped) Often this aspect is overlooked and special characters that can be used to modify the instructions by the attackers are found in the web application code. For example,"<" and ">", several popular browsers recognize these as the start and end of a tag. (HTML Output Character Filtering) Output filtering helps a developer build an application which is not susceptible to cross site scripting attacks. When information is displayed to users, it should be escaped. HTML should be rendered inactive to prevent cross site scripting attacks. (Root accessibility of web applications) Ideally web applications should not expose the root directory of the web server. Sometimes, it is possible for the user to access the root directory if he can change the input or the URL. (Lack of User Authentication) An obvious security hole is where restricted area access is given without proper authentication, re-use of authentication cache or poor logout procedures. These applications can be vulnerable to cookie based attacks. (Allowing ActiveX/JavaScript) Client side scripting languages are vulnerable to attacks such as cross side scripting.
Penetrating web servers is no different from attacking other systems when it comes to the basic methods. Attackers begin with information gathering and discovery. This can be anything from searching for particular file types / banners on search engines like google. For examples, searching for "index/" may bring up unsuspecting directories on interesting sites where one may find information that can be used for penetrating the web server.
Another important action is identifying the nature of the web application and going over the site map to detect weak areas. This may be a link with another site or a link to the intranet itself. The attacker can go over the source code and find links to other pages, form fields that are vulnerable. Apart from this, forcing the application to return errors can help in fingerprinting and identifying the host. This exercise can also reveal vulnerabilities that can be exploited.
File and application pull ups can be done through forced browsing, discovering hidden files, vulnerable CGIs and sample Files.
Penetration can be carried out through input or output manipulation on the client side.