Example - 1

This code listens on a port for DNS requests and sends the result to the requesting address.

break
data = sock.recvfrom(1024)if not data:(requestIP, nameToResolve) = parseUDPpacket(data)record = resolveName(nameToResolve)sendResponse(requestIP,record)sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)sock.bind( (UDP_IP,UDP_PORT) )while true:

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.

Example - 2

This data prints the contents of a specified file requested by a user.

// //read file into string// 

echo $file;return true;
echo 'You are not authorized to view this file';
$file = file_get_contents($filename);if ($file && isOwnerOf($username,$filename)){}else{}return false;function printFile($username,$filename){}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.

Example - 3

The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

<?xml version="1.0"?><!DOCTYPE MaliciousDTD [<!ENTITY ZERO "A"><!ENTITY ONE "&ZERO;&ZERO;"><!ENTITY TWO "&ONE;&ONE;">...<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">]><data>&THIRTYTWO;</data>

Example - 4

This example attempts to check if an input string is a "sentence" [REF-1164].

var test_string = "Bad characters: $@#";var bad_pattern  = /^(\w+\s?)*$/i;var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

var test_string = "Bad characters: $@#";var good_pattern  = /^((?=(\w+))\2\s?)*$/i;var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.

Example - 5

An adversary can cause significant resourceconsumption on a server by filtering the cryptographicalgorithms offered by the client to the ones that are themost resource-intensive on the server side. Afterdiscovering which cryptographic algorithms are supportedby the server, a malicious client can send the initialcryptographic handshake messages that contains only theresource-intensive algorithms. For some cryptographicprotocols, these messages can be completelyprefabricated, as the resource-intensive part of thehandshake happens on the server-side first (such as TLS),rather than on the client side. In the case ofcryptographic protocols where the resource-intensive partshould happen on the client-side first (such as SSH), amalicious client can send a forged/precalculatedcomputation result, which seems correct to the server, sothe resource-intensive part of the handshake is going tohappen on the server side. A malicious client is requiredto send only the initial messages of a cryptographichandshake to initiate the resource-consuming part of thecryptographic handshake. These messages are usuallysmall, and generating them requires minimal computationaleffort, enabling a denial-of-service attack. Anadditional risk is the fact that higher key sizeincreases the effectiveness of the attack. Cryptographicprotocols where the clients have influence over the sizeof the used key (such as TLS 1.3 or SSH) are most atrisk, as the client can enforce the highest key sizesupported by the server.