In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

  static public byte[] EncryptWithRSA(byte[] plaintext, RSAParameters key) {
    try {
      RSACryptoServiceProvider rsa = new RSACryptoServiceProvider();
      rsa.ImportParameters(key);
      return rsa.Encrypt(plaintext, false);
    }
    catch(CryptographicException e) {
      Console.WriteLine(e.Message);
      return null;
    }
  }

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

  void encrypt_with_rsa(BIGNUM *out, BIGNUM *in, RSA *key) {
    u_char *inbuf, *outbuf;
    int ilen;
    ...
    ilen = BN_num_bytes(in);
    inbuf = xmalloc(ilen);
    BN_bn2bin(in, inbuf);
    if ((len = RSA_public_encrypt(ilen, inbuf, outbuf, key, RSA_NO_PADDING)) <= 0) {
      fatal("encrypt_with_rsa() failed");
    }
    ...
  }

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key using the PKCS#1 v1.5 padding scheme:

...
import "crypto/rsa"
...
plaintext := []byte("Attack at dawn")
cipherText, err := rsa.EncryptPKCS1v15(rand.Reader, &k.PublicKey, plaintext)
...

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

+ (NSData *) encryptData:(NSData *) plaintextData withKey:(SecKeyRef *) publicKey {
    CFErrorRef error = nil;
    
    NSData *ciphertextData = (NSData*) CFBridgingRelease(
        SecKeyCreateEncryptedData(*publicKey,
                                  kSecKeyAlgorithmRSAEncryptionPKCS1,
                                  (__bridge CFDataRef) plaintextData,
                                  &error));
    
    if (error) {
        // handle error ...
    }
    
    return ciphertextData;
}

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

  function encrypt($input, $key) {
    $output='';
    openssl_public_encrypt($input, $output, $key, OPENSSL_NO_PADDING);
    return $output;
  }

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

...
from Crypto.PublicKey import RSA

message = 'Attack at dawn'
key = RSA.importKey(open('pubkey.der').read())
ciphertext = key.encrypt(message)
...

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

require 'openssl'
...
key = OpenSSL::PKey::RSA.new 2048
public_encrypted = key.public_encrypt(data) #padding type not specified
...

In Example 1OpenSSL::PKey::RSA#public_encrypt is only called with a string, and does not specify the padding type to use. The padding defaults to OpenSSL::PKey::RSA::PKCS1_PADDING.

In practice, encryption with an RSA public key is usually combined with a padding scheme. A padding scheme can prevent attacks on RSA that only work when the encryption is performed without padding.

Example 1: The following code performs encryption using an RSA public key without using a padding scheme:

func encrypt(data plaintextData:Data, publicKey:SecKey) throws -> Data {
    var error: Unmanaged<CFError>?
    guard let ciphertextData = SecKeyCreateEncryptedData(publicKey,
                                                         .rsaEncryptionPKCS1,
                                                         plaintextData as CFData,
                                                         &error) else {
        throw error!.takeRetainedValue() as Error
    }
    return ciphertextData as Data;
}

Class CL_ABAP_RANDOM (or its variants) should not be initialized with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values produced by calls to methods including but not limited to: GET_NEXT, INT, FLOAT, PACKED.

Functions that generate random or pseudorandom values (such as rand()), which are passed a seed (such as srand()); should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to the pseudorandom number generator.

Functions that generate pseudorandom values, such as ed25519.NewKeyFromSeed(), should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and then can predict the sequence of values produced by calls to the pseudorandom number generator.

Random.setSeed() should not be called with a tainted integer argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to Random.nextInt(), Random.nextLong(), Random.nextDouble(), or returned by Random.nextBoolean(), or set in Random.nextBytes(ByteArray).

Functions that generate pseudorandom values (such as random.randint()); should not be called with a tainted argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and hence be able to predict the sequence of values (usually integers) produced by calls to the pseudorandom number generator.

Random.setSeed() should not be called with a tainted integer argument. Doing so allows an attacker to control the value used to seed the pseudorandom number generator, and therefore predict the sequence of values (usually integers) produced by calls to Random.nextInt(), Random.nextShort(), Random.nextLong(), or returned by Random.nextBoolean(), or set in Random.nextBytes(byte[]).

When a third party application or wewbview uses a URL to communicate with your application, the receiving application should verify that the sender matches an allow list of applications that are expected to communicate with it. The receiving application has the option to verify the origin of the calling URL using the UIApplicationDelegate application:openURL:options: or UIApplicationDelegate application:openURL:sourceApplication:annotation: delegate methods.

Example 1: The following implementation of the UIApplicationDelegate application:openURL:options: delegate method fails to verify the sender of the IPC call and just processes the calling URL:

    func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
        return processCall(url)
    }

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is repeated. Additionally, attackers can exploit any regular expression that contains alternate subexpressions that overlap one another. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is repeated. Additionally, attackers can exploit any regular expression that contains alternate subexpressions that overlap one another. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. Attackers can use this defect to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1: If the following regular expressions are used in the identified vulnerable code a denial of service could occur:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

Example of problematic code relying on a flawed regular expressions:

NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
  //do something
}

Most regular expression parsers build Nondeterministic Finite Automaton (NFA) structures when evaluating regular expressions. The NFA tries all possible matches until a complete match is found. Given the previous example, if the attacker supplies the match string "eeeeZ" then there are 16 internal evaluations that the regex parser must go through to identify a match. If the attacker provides 16 "e"s ("eeeeeeeeeeeeeeeeZ") as the match string then the regex parser must go through 65536 (2^16) evaluations. The attacker may easily consume computing resources by increasing the number of consecutive match characters. There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations which are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating repeating and alternating overlapping of nested and repeated regex groups. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

(e+)+
([a-zA-Z]+)*

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.
Example 1:

  (e+)+
  ([a-zA-Z]+)*
  (e|ee)+

There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

There is a vulnerability in implementations of regular expression evaluators and related methods that can cause the thread to hang when evaluating regular expressions that contain a grouping expression that is itself repeated. Additionally, any regular expression that contains alternate subexpressions that overlap one another can also be exploited. This defect can be used to execute a Denial of Service (DoS) attack.

Example 1: If the following regular expressions are used in the identified vulnerable code a denial of service could occur:

(e+)+
([a-zA-Z]+)*
(e|ee)+

Example of problematic code relying on a flawed regular expressions:

let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
  //do something
}

Most regular expression parsers build Nondeterministic Finite Automaton (NFA) structures when evaluating regular expressions. The NFA tries all possible matches until a complete match is found. Given Example 1, if the attacker supplies the match string "eeeeZ" then there are 16 internal evaluations that the regex parser must go through to identify a match. If the attacker provides 16 "e"s ("eeeeeeeeeeeeeeeeZ") as the match string then the regex parser must go through 65536 (2^16) evaluations. The attacker may easily consume computing resources by increasing the number of consecutive match characters. There are no known regular expression implementations that are immune to this vulnerability. All platforms and languages are vulnerable to this attack.

NSPredicate instances specify how a collection should be fetched or filtered from sources such as CoreData persistent storage system, an array and a dictionary. Its query language provides an expressive language similar to SQL to define logical conditions on which the collection should be searched.

An attacker able to influence the predicate may be able to change its meaning in order to, for example, leak data, bypass security controls or impersonate other users.

Example 1: The following example shows how an NSPredicate is used as an authentication factor to access some data stored by the application. Since users can provide arbitrary PIN values, they will be able to use a wildcard character (*) to bypass the PIN protection.

let pin = getPinFromUser();
let predicate = NSPredicate(format: "pin LIKE '\(pin)'", argumentArray: nil)