Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Web Application Security--The Next Evolution : Page 2

Web applications enable companies to conduct business with customers and partners, delivering highly valuable, and often confidential, information across enterprise barriers. However, the value of Internet communications cannot be realized until users have confidence that Internet channels are secure.


advertisement
How a System Is Attacked Through an Application
To fully utilize an application, a user must be granted operating system, network, and database privileges. The application will not function without them, but these privileges normally are hidden from the user by the application interface.

Once Web site applications begin interfacing with a browser, hackers can begin to feel the system out, trying known techniques to determine how the application responds. Once the hacker has successfully bypassed the firewall and IDS—which see his activity as "legitimate"—he can carry out a number of relatively easy application-layer attacks.

IT Infrastructure Vulnerabilities and Misconfigurations
Exploiting IT infrastructure vulnerabilities is probably the easiest way to attack an application. Thousands of known vulnerabilities exist in the basic components commonly used to set up integrated Internet environments. Attackers, keeping themselves up to date with such announced vulnerabilities, often find taking advantage of them extremely easy.



For example, in environments where Apache and PHP 3 serve the Web interface, a hacker can view confidential information in the application by sending the following HTTP request:

GET http://target/index.php3.%5c../ ..%5cconf/httpd.conf

In environments where the Web server uses IIS 4.0, a hacker browsing the application can retrieve the physical location of the Web servers by sending the following HTTP request:

GET http://target/me.idq

Third-party and Customized Software Vulnerabilities
Creating and maintaining a well-secured HTTP-based application is a tedious task that requires constant quality assurance and security analysis. Even if such procedures are implemented, human error or lack of specialized knowledge still might leave numerous programming errors that attackers can exploit.

Service providers often implement third-party software and customize it to their specific needs. As a result, they are exposed to both errors made by their software vendor and to "holes" created during the customization process.

For example, in any system where standard Internet development methods are used, any user can manually change hidden parameters in HTML documents and then submit the modified values to the remote server using a simple text editor or a Web browser source viewer. If the backend system does not validate input, the changes made will be accepted and updated on the server.

Executing the following URL would change the book price parameter from the original price:

http://target/book.cgi?price=$1.30

In any system where remote users can send HTTP requests, a remote attacker can use any Web browser to cause a shutdown by sending an HTTP message large enough to overflow the remote Web server input buffer.

Database Manipulation and Vulnerabilities
The database is the heart of most systems and typically the most attractive target for attack. While the database itself is usually secured, it is also open to the application using it. Because in most cases applications need to perform both read and write operations, the application is usually authorized to interact freely with the database.

In a simple system, this problem can be addressed by carefully defining access rights, but it is almost impossible to resolve in complex systems. The multitude of interfaces and maintenance applications accessing the same database make designing a fail-safe system basically unfeasible.

For example, in environments where Web applications have access to a database, intruders can identify database fields by looking at the URL parameter names. Using any Web browser, intruders can modify these parameter values and use standard SQL commands to delete, modify, or retrieve unauthorized database records.

Other Common Threats

  • Data encoding—using different data encoding standards such as Unicode UTF-8 and UTF-16 to send requests

  • Protocol piggyback—modifying the application protocol structure

  • Hidden fields manipulation—modifying state information stored inside hidden fields

  • Parameter tampering—modifying parameters in the HTML document and submitting the modified values to the remote server

  • Cookie poisoning—changing the cookie's content

  • Stealth commanding—planting Trojan horses in text fields that cause the Web application to perform commands for which it is not intended

  • Backdoor and debug options—exploiting vulnerabilities left open in internally developed code


  • Comment and Contribute

     

     

     

     

     


    (Maximum characters: 1200). You have 1200 characters left.

     

     

    Sitemap