Home > Articles

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Logical Attacks

The Logical Attacks section focuses on the abuse or exploitation of a web application’s logic flow. Application logic is the expected procedural flow used in order to perform a certain action. Password recovery, account registration, auction bidding, and eCommerce purchases are all examples of application logic. A web site may require a user to correctly perform a specific multi-step process to complete a particular action. An attacker may be able to circumvent or misuse these features to harm a web site and its users.

Abuse of Functionality

Abuse of Functionality is an attack technique that uses a web site’s own features and functionality to consume, defraud, or circumvent access control mechanisms. Some functionality of a web site, possibly even security features, may be abused to cause unexpected behavior. When a piece of functionality is open to abuse, an attacker could potentially annoy other users or perhaps defraud the system entirely. The potential and level of abuse will vary from web site to web site and application to application.

Abuse of Functionality techniques are often intertwined with other categories of web application attacks, such as performing an encoding attack to introduce a query string that turns a web search function into a remote web proxy. Abuse of Functionality attacks are also commonly used as a force multiplier. For example, an attacker can inject a Cross-site Scripting snippet into a web-chat session and then use the built-in broadcast function to propagate the malicious code throughout the site.

In a broad view, all effective attacks against computer-based systems entail Abuse of Functionality issues. Specifically, this definition describes an attack that has subverted a useful web application for a malicious purpose with little or no modification to the original function.

Abuse of Functionality Examples

Examples of Abuse of Functionality include

  1. Using a web site’s search function to access restricted files outside of a web directory.
  2. Subverting a file upload subsystem to replace critical internal configuration files.
  3. Performing a DoS by flooding a web-login system with good usernames and bad passwords to lock out legitimate users when the allowed login retry limit is exceeded.

Other real-world examples are described in the following sections.

Matt Wright’s FormMail

The PERL-based web application "FormMail" was normally used to transmit user- supplied form data to a preprogrammed email address. The script offered an easy-to-use solution for web sites to gather feedback. For this reason, the FormMail script was one of the most popular CGI programs online. Unfortunately, this same high degree of utility and ease of use was abused by remote attackers to send email 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 a URL that supplied the desired email parameters and perform an HTTP GET to the CGI, such as the following:

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. Because no security mechanisms existed for this version of the script, the only viable defensive measure was to rewrite the script with a hard-coded email address. Barring that, site operators were forced to remove or replace the web application entirely.

Macromedia’s Cold Fusion

Sometimes basic administrative tools are embedded within web applications that can be easily used for unintended purposes. For example, Macromedia’s Cold Fusion by default has a built-in module for viewing source code that is universally accessible. Abuse of this module can result in critical web application information leakage. Often these types of modules are not sample files or extraneous functions, but critical system components. This makes disabling these functions problematic since they are tied to existing web application systems.

Smartwin CyberOffice Shopping Cart Price Modification

Abuse of Functionality occurs when an attacker alters data in an unanticipated way in order to modify the behavior of the web application. For example, the CyberOffice shopping cart can be abused by changing the hidden price field within the web form. The web page is downloaded normally, edited, and then resubmitted with the prices set to any desired value.

Apache Countermeasures for Abuse of Functionality

Prevention of these kinds of attacks depends largely upon designing web applications with core principles of security. Specifically this entails implementing with the least-privilege principle: web applications should only perform their intended function, on the intended data, for their intended customers, and nothing more. Furthermore, web applications should also verify all user-supplied input to ensure that proper parameters are being passed from the client.

Many web sites are vulnerable to Abuse of Functionality threats. They rely solely on security through obscurity for protection. We strongly recommended that the functionality and purpose of each web application be clearly documented. This will allow implementers and auditors to quickly identify functions that could be subject to abuse before bringing these systems online.

With specific regard to Apache, utilizing the CIS Apache Benchmark Scoring Tool will assist with locking down the web server and applying the principle of least privilege by restricting the capabilities of the Apache user account, disabling un-needed modules, and updating permissions on directories and files.

References

Denial of Service

Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity. DoS attacks, which are normally applied to the network layer, are also possible at the application layer. These malicious attacks can succeed by starving a system of critical resources, vulnerability exploit, or abuse of functionality.

Many times, DoS attacks will attempt to consume all of a web site’s available system resources such as CPU, memory, disk space, and so on. When any one of these critical resources reaches full utilization, the web site will normally be inaccessible.

As today’s web application environments include a web server, database server, and an authentication server, DoS at the application layer may target each of these independent components. Unlike DoS at the network layer, where a large number of connection attempts are required, DoS at the application layer is a much simpler task to perform.

DoS Example

For this example, the target is a healthcare web site that generates a report with medical history. For each report request, the web site queries the database to fetch all records matching a single social security number. Given that hundreds of thousands of records are stored in the database (for all users), the user will need to wait three minutes to get his medical history report. During the three minutes of time, the database server’s CPU reaches 60 percent utilization while searching for matching records.

A common application layer DoS attack will send 10 simultaneous requests asking to generate a medical history report. These requests will most likely put the web site under a DoS-condition as the database server’s CPU will reach 100% utilization. At this point, the system will likely be inaccessible to normal user activity.

There are many different targets for a DoS attack:

  • DoS targeting a specific user. An intruder will repeatedly attempt to login to a web site as some user, purposely doing so with an invalid password. This process will eventually lock out the user.
  • DoS targeting the database server. An intruder will use SQL injection techniques to modify the database so that the system becomes unusable (e.g., deleting all data, deleting all usernames, and so forth).
  • DoS targeting the web server. An intruder will use Buffer Overflow techniques to send a specially crafted request that will crash the web server process, causing the system to be inaccessible to normal user activity.

Apache Countermeasures for DoS Attacks

As listed previously, web-based DoS attacks may take on many forms, as the target of the attack may be focused at different components of the web server or application. In order to mitigate the effects of a DoS attack, we therefore need to implement multiple solutions.

DoS Targeting a Specific User

Apache does not have a built-in capability to lock user accounts due to failed login attempts. This process is normally handled by the authentication application; in this scenario, perhaps the user is being authenticated with credentials that are stored in a database. This means that the lockout procedures would reflect the policies of the database authentication mechanism.

The best way to approach this with Apache is to rely on the Mod_Dosevasive settings to identify when an attacker is using automated means to authenticate to numerous accounts. In this attack scenario, we have two different triggers for identification: first are the alerts generated by Mod_Dosevasive if the attacker sends data over our threshold, and the second are the 401 Unauthorized status code alerts for the failed logins that are generated by the use of CGI scripts. With either of these alerting mechanisms, we could identify the source IP of the attack and implement access control directives to deny further access.

DoS Targeting the Database Server

In order to combat this type of attack, we must implement proper input validation filtering so that an attacker is not able to successfully pass SQL statements within the URL to the back-end database. Please refer to the previous section on SQL Injection for example security filters.

DoS Targeting the Web Server

We previously discussed tuning the configuration of the HTTP connection to help mitigate the effects of a DoS attack with updated settings for KeepAlives, KeepAliveTimeouts, and so on. In addition to these Apache directives, we also rely on Mod_Dosevasive to respond to these DoS attacks. As I mentioned in the previous chapter, I have made some updates to the Mod_Dosevasive code so that I run more efficiently in my environment. An additional technique that I use to lessen the impact of a DoS attack is to change the default status code returned by Mod_Dosevasive. The default status code is 403 Forbidden. This causes resource consumption issues in my environment since I utilize CGI alerting scripts for the 403 status codes. These scripts will present the attacker with an html page and also email security personnel. The overhead associated with spawning these CGI scripts and calling up sendmail exacerbates the effects of a DoS attack against my site. How can we fix this issue?

I decided to update the Mod_Dosevasive code to change the status code, but the question was "What should I change it to?" Preferably, I needed a status code that won’t trigger a CGI script and only returns the HTTP response headers. This lack of a response message body will help to reduce the network consumption. I therefore edited the mod_dosevasive20.c file and changed all status code entries from HTTP_FORBIDDEN to HTTP_MOVED_TEMPORARILY.

Besides a resource consumption attack, an attacker may be able to take advantage of a vulnerability with the web server software to cause the web server to hang or crash. A good example of this situation was the Chunked-Encoding Vulnerability from June 2002 (http://www.cert.org/advisories/CA-2002-17.html). With this vulnerability, an attacker could send a request that included the "Transfer-Encoding: chunked" header along with payload data that could potentially crash the server or cause code execution. eEye Security released a tool that would automatically check a web server to verify if it was vulnerable: http://eeye.com/html/Research/Tools/apachechunked.html. The resulting HTTP request looked like this:

**************Begin Session****************
POST /EEYE.html HTTP/1.1
Host: www.EEYE2002.com
Transfer-Encoding: chunked
Content-Length: 22

4
EEYE
7FFFFFFF
[DATA]
**************End Session******************

Besides updating Apache with the appropriate patch, you could also implement a Mod_Security filter to block all client requests that submit the Transfer-Encoding header:

SecFilterSelective HTTP_TRANSFER_ENCODING "!^$"

Besides specific Apache mitigation options, you should monitor your web site’s resources. Isolating different critical resources and simulating DoS scenarios using stress tools is an excellent way to test overall system integrity. When "hot spots" are detected, try to review your design or add more resilient resources. Additional network architecture solutions include server fail-over and threshold-based load sharing, balancing, or redundancy.

References

Insufficient Anti-Automation

Insufficient Anti-Automation occurs when a web site permits an attacker to automate a process that should only be performed manually. Certain web site functionalities should be protected against automated attacks.

Left unchecked, automated robots (programs) or attackers could repeatedly exercise web site functionality attempting to exploit or defraud the system. An automated robot could potentially execute thousands of requests a minute, causing potential loss of performance or service.

Insufficient Anti-Automation Example

An automated robot should not be able to sign up 10,000 new accounts in a few minutes. Similarly, automated robots should not be able to annoy other users with repeated message board postings. These operations should be limited only to human usage.

Apache Countermeasures for Insufficient Anti-Automation

There are a few solutions that have been used in the past to determine if a web request is from a person or a robot, but the most telling characteristic is the speed of the requests. Therefore, the best mitigation option for Apache is to leverage Mod_Dosevasive to monitor the connection thresholds.

References

Insufficient Process Validation

Insufficient Process Validation occurs when a web site permits an attacker to bypass or circumvent the intended flow control of an application. If the user state through a process is not verified and enforced, the web site could be vulnerable to exploitation or fraud.

When a user performs a certain web site function, the application may expect the user to navigate through a specific order sequence. If the user performs certain steps incorrectly or out of order, a data integrity error occurs. Examples of multi-step processes include wire transfer, password recovery, purchase checkout, account signup, and so on. These processes will likely require certain steps to be performed as expected.

For multi-step processes to function properly, web sites are required to maintain user state as the user traverses the process flow. Web sites will normally track a user’s state through the use of cookies or hidden HTML form fields. However, when tracking is stored on the client side within the web browser, the integrity of the data must be verified. If not, an attacker may be able to circumvent the expected traffic flow by altering the current state.

Insufficient Process Validation Example

An online shopping cart system may offer to the user a discount if product A is purchased. The user may not want to purchase product A, but product B. By filling the shopping cart with product A and product B, and entering the checkout process, the user obtains the discount. The user then backs out of the checkout process, and removes product A, or simply alters the values before submitting to the next step. The user then reenters the checkout process, keeping the discount already given in the previous checkout process with product A in the shopping cart, and obtains a fraudulent purchase price.

Apache Countermeasures for Insufficient Process Validation

A term commonly used in these scenarios is Forceful Browsing, which is a technique used by attackers when they attempt to access URLs in an order that is unexpected by the application. These types of logical attacks are the most difficult for Apache to address, as it does not have the knowledge of the expected process flow of the application. The best way to approach this is to document the desired application flow and then implement various Mod_Security filters to verify that the client came from the correct URL when they access the current URL. For instance, say that you have a login page and then a page for resetting your account password. You could implement Mod_Security filter like this:

SecFilterSelective SCRIPT_FILENAME "/account/passwd.php" chain
SecFilterSelctive HTTP_REFERER "!/account/login.php"

Another possible process flow validation would be to use Mod_Security to verify portions of a session ID or cookie. If your application sets or updates the session ID in response to certain actions, you could possibly validate portions of the cookie. For instance, say that your application sets this cookie when a client is attempting to update their account information:

Set-Cookie:
Account=pCqny0PnAkGv22QSIZUIHfF5PHIvsai1W03%2BfrKhJxgyJsKalgubbMBrwkI%3D%3DG2G3%0D; 
path=/account/update.php; expires=Fri, 06-May-2005 09:11:43 GMT

The cookie includes the "path=" parameter. We can implement some Mod_Security filters to verify that the path parameter is reflecting the proper locations during certain application functions.

SecFilterSelective SCRIPT_FILENAME "/account/passwd.php" chain
SecFilterSelective COOKIE_Account "!path\=/account/update\.php" 
redirect:http://host.com/account/login.php

These directives will redirect a client back to the login process if the path parameter in the Account cookie is not set appropriately.

References

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020