• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

Abuse of Functionality

Page history last edited by Robert Auger 11 years, 8 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-42

 

 

Abuse of Functionality

Abuse of Functionality is an attack technique that uses a web site's own features and functionality to attack itself or others. Abuse of Functionality can be described as the abuse of an application's intended functionality to perform an undesirable outcome. These attacks have varied results such as consuming resources, circumventing access controls, or leaking information. The potential and level of abuse will vary from web site to web site and application to application. Abuse of functionality attacks are often a combination of other attack types and/or utilize other attack vectors.

 

Examples

Some examples of Abuse of Functionality are:

  • Abusing Send-Mail Functions
  • Abusing Password-Recovery Flows
  • Abusing functionality to make unrestricted proxy requests

 

 

Abusing Send-Mail Functions

Web Applications that send mail must be careful to not allow the user complete control over message headers and content. If an attacker can control the From, To, Subject, and Body of a message and there are no anti-automation controls in place email functions can be turned into spam-relay vehicles.

 

FormMail

The PERL-based web application "FormMail" was normally used to transmit user-supplied form data to a preprogrammed e-mail address. The script offered an easy to use solution for web site's to gather feedback. For this reason, the FormMail script was one of the most popular CGI programs on-line. Unfortunately, this same high degree of utility and ease of use was abused by remote attackers to send e- mail to any remote recipient. In short, this web application was transformed into a spam-relay engine with a single browser web request.

 

An attacker merely has to craft an URL that supplied the desired e- mail parameters and perform an HTTP GET to the CGI, such as:

 

http://example/cgi-bin/FormMail.pl? recipient=email@victim.example&message=you%20got%20spam

 

An email would be dutifully generated, with the web server acting as the sender, allowing the attacker to be fully proxied by the web- application. Since no security mechanisms existed for this version of the script, the only viable defensive measure was to rewrite the script with a hard-coded e-mail address. Barring that, site operates were forced to remove or replace the web application entirely.

 

 

Abusing Password Recovery Flows

Password recovery flows can often be abused to leak data about accounts that would otherwise be secret. Although usernames on many websites are public knowledge, many sites such as online banks do not reveal a username except to the owner of that account.

Some password recovery flows perform the following steps:

  1. Ask user for username/email
  2. Message the user that a mail has been sent to their account
  3. Send user a link allowing them to change their password

 

In these types of recovery flows there can be information leakage in step-2 by confirming that the user entered a valid email address and/or account name. This can be avoided by having generic messaging on this flow or requiring more specific information about the account before sending a reset email.

 

 

Unauthorized Proxy Requests

Some services such as Google Translate can be abused to act as open proxy servers. Google Translate request functionality allows it to be used as an open proxy server and anonymizer. This google issue was first described by Sergey Gordeychik and 3APA3A in 2004.

 

References

"FormMail Real Name/Email Address CGI Variable Spamming Vulnerability"

[1] http://www.securityfocus.com/bid/3955

 

"MX Injection : Capturing and Exploiting Hidden Mail Servers"

[2] http://www.webappsec.org/projects/articles/121106.shtml

 

"CVE-1999-0800"

[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0800

 

"Bypassing Client Application Protection Techniques"

[4] http://www.securiteam.com/securityreviews/6S0030ABPE.html

Comments (0)

You don't have permission to comment on this page.