SY0-501 Section 4.1-Explain the importance of application security controls and techniques.

Fuzzing

Fuzz testing or Fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion.

Let’s consider an integer in a program, which stores the result of a user’s choice between 3 questions. When the user picks one, the choice will be 0, 1 or 2. Which makes three practical cases. But what if we transmit 3, or 255? We can, because integers are stored a static size variable. If the default switch case hasn’t been implemented securely, the program may crash and lead to “classical” security issues: (un) exploitable buffer overflows and DoS. Fuzzing is the art of automatic bug finding, and its role is to find software implementation faults, and identify them if possible.

Security coding concepts

Error and exception handling

Correct handling of errors and exceptions is important for correct broker operation. You should be aware of this, and understand how and when your user-defined extension needs to handle errors and exceptions.

The message broker generates C++ exceptions to handle error conditions. These exceptions are caught in the relevant software layers in the broker and handled accordingly. However, programs written in C cannot catch C++ exceptions, and any exceptions thrown, by default, bypass any C user-defined extension code and be caught in a higher layer of the message broker.

Utility functions, by convention, normally use the return value to pass back requested data; for example, the address or handle of a broker object. The return value sometimes indicates that a failure has occurred. For example, if the address or handle of a broker object could not be retrieved, then zero (CCI_NULL_ADDR) is returned. Additionally, the reason for an error condition is stored in the return code output parameter, which is, by convention, part of the function prototype of all utility functions. If the utility function completed successfully and returnCode was not null, returnCode contains CCI_SUCCESS. Otherwise, it contains one of the return codes described below. The value of returnCode can always be tested safely to determine whether a utility function was successful.

Types of exception and broker behavior

The broker generates a set of exceptions that can be passed to a user-defined extension. These exceptions can also be generated by a user-defined extension when an error condition is encountered. The exception classes are:

Fatal

Fatal exceptions are generated when a condition occurs that prevents the broker process from continuing execution safely, or where it is broker policy to terminate the process. Examples of fatal exceptions are a failure to acquire a critical system resource, or an internally-caught severe software error. The broker process terminates following the throwing of a fatal exception.

Recoverable

These are generated for errors, which, although not terminal in nature, mean that the processing of the current message flow has to be ended. Examples of recoverable exceptions are invalid data in the content of a message, or a failure to write a message to an output node. When a recoverable exception is thrown, the processing of the current message is aborted on that thread, but the thread recommences execution at its input node.

Configuration

Configuration exceptions are generated when a configuration request fails. This can be because of an error in the format of the configuration request, or an error in the data. When a configuration exception is thrown, the request is rejected and an error response message is returned.

Parser

These are generated by message parsers for errors,which prevent the parsing of the message content or creating a bit stream. The broker treats a parser exception as a recoverable exception.

Conversion

These are generated by the broker character conversion functions if invalid data is found when trying to convert to another data type. The broker treats a conversion exception as a recoverable exception.

User

These are generated when a Throw node throws a user-defined exception.

Database

These are generated when a database management system reports an error during broker operation. A database exception is treated as a recoverable exception by the broker.

Input validation

Web applications are notorious for taking practically any type of input, assuming that it’s valid, and processing it further. Not validating input is one of the greatest mistakes that Webapplication developers can make. This can lead to system crashes, malicious database manipulation, and even database corruption.

Input attacks

Several attacks can be run against a Web application that insert malformed data — often, too much at once — which can confuse, crash, or make the Web application divulge too much information to the attacker.

Cross-site scripting prevention

Using a client-side scripting language, it is possible for an attacker to trick a user who visits the site into having code execute locally. When this is done, it is known as cross-site scripting (XSS). Let’s look at an example. UserA gets a message telling him that he needs to make changes to his XYZ account, but the link in the message is not really to the XYZ site (aphishing ploy). When he visits the site, a script routine begins to run on his machine with his permissions and can begin doing such things as running malevolent routines to send, delete, or alter data.

Cross-Site Request

Forgery—also known as XSRF, session riding, and one-click attack— involves unauthorized commands coming from a trusted user to the website. This is often done without the user’s knowledge, and it employs some type of social networking to pull it off.

For example, assume that Evan and Spencer are chatting through Facebook. Spencer sends Evan a link to what he purports is a funny video that will crack him up. Evan clicks the link, but it actually brings up Evan’s bank account information in another browser tab, takes a screenshot of it, closes the tab, and sends the information to Spencer. The reason the attack is possible is because Evan is a trusted user with his own bank. In order for itto work, Evan would need to have recently accessed that bank’s website and have a cookie that had yet to expire. The best protection against cross-site scripting is to disable the running of scripts (and browser profiles).

Application Configuration Baseline (proper settings)

Base lining always involves comparing performance to a metric. That metric is a historical measurement that you can point to and identify as coming before a configuration change, before the site became busy, before you added new services, and so on. Baselining can be done with any metric, such as network performance or CPU usage, as well as with applications.

Application Hardening

A good way to begin securing a network is to make sure that every system in the network is up-to-date and to verify that only those protocols you need are enabled. Unfortunately, these steps aren’t enough. Your servers and workstations also run applications and services. Server services (especially web, email, and media servers) are particularly vulnerable to exploitation and attack. These applications must also be hardened to make them as difficult as possible to exploit.

Application Patch Management

Just as you need to keep operating system patches current, as they often fix security problems discovered within the OS, you need to do the same with application patches. Once an exploit in an application becomes known, an attacker can take advantage of it to enter or harm a system. Most vendors post patches on a regular basis, and you should routinely scan for any available ones.

A large number of attacks today are targeted at client systems for the simple reason that clients do not always manage application patching well. When you couple that with the fact that most clients have many applications running, the odds of being able to find a weakness to exploit are increased dramatically.

Server-side vs. Client-side validation

Some attacks, such as SQL injection, depend entirely on unfiltered input being sent through a web application. OWASP recommends that all data input by a user be validated before it is processed. There are two primary ways to do input validation: client-side validation and server-side validation.

Client-side validation usually works by taking the input that a user enters into a text field and, on the client side, checking for invalid characters or input. This process can be as simple as verifying that the input does not exceed the required length, or it can be a complete check for SQL injection characters. In either case, the validation is accomplished on the client web page before any data is sent to the server. Server-side validation involves validating data after the server has received it. This process can include checking business logic to see if the data sent conforms to expected parameters. It is unusual to have just server-side validation. You may have systems with only client-side validation, but server-side validation is normally done in conjunction with client-side validation.