String length conflation

Using a length value from an NSString in a String, or a count from a String in an NSString, may cause unexpected behavior including (in some cases) buffer overwrites. This is because certain unicode sequences are represented as one character in a String but as a sequence of multiple characters in an NSString. For example, a 'thumbs up' emoji with a skin tone modifier (👍🏿) is represented as U+1F44D (👍) then the modifier U+1F3FF.

This issue can also arise from using the values of String.utf8.count, String.utf16.count or String.unicodeScalars.count in an unsuitable place.

Recommendation

Use String.count when working with a String. Use NSString.length when working with an NSString. Do not mix values for lengths and offsets between the two types as they are not compatible measures.

If you need to convert between Range and NSRange, do so directly using the appropriate initializer. Do not attempt to use incompatible length and offset values to accomplish conversion.

Example

In the following example, a String is converted to NSString, but a range is created from the String to do some processing on it.

func myFunction(s: String) {
	let ns = NSString(string: s)
	let nsrange = NSMakeRange(0, s.count) // BAD: String length used in NSMakeRange

	// ... use nsrange to process ns
}

This is dangerous because, if the input contains certain characters, the range computed on the String will be wrong for the NSString. This will lead to incorrect behaviour in the string processing that follows. To fix the problem, we can use NSString.length to create the NSRange instead, as follows:

func myFunction(s: String) {
	let ns = NSString(string: s)
	let nsrange = NSMakeRange(0, ns.length) // Fixed: NSString length used in NSMakeRange

	// ... use nsrange to process ns
}

References

• Swift String vs. NSString
• Common Weakness Enumeration: CWE-135.

Predicate built from user-controlled sources

Predicates represent logical conditions that can be used to check whether an object matches them. If a predicate is built from user-provided data without sufficient sanitization, an attacker may be able to change the overall meaning of the predicate.

Recommendation

When building a predicate from untrusted data, you should either pass it to the appropriate arguments parameter during initialization, or as an array of substitution variables before evaluation. You should not append or concatenate it to the body of the predicate.

Example

In the following insecure example, NSPredicate is built directly from data obtained from an HTTP request. This is untrusted, and can be arbitrarily set by an attacker to alter the meaning of the predicate:

let remoteString = try String(contentsOf: URL(string: "https://example.com/")!)

let filenames: [String] = ["img1.png", "img2.png", "img3.png", "img.txt", "img.csv"]

let predicate = NSPredicate(format: "SELF LIKE \(remoteString)")
let filtered = filenames.filter(){ filename in
    predicate.evaluate(with: filename)
}
print(filtered)

A better way to do this is to use the arguments parameter of NSPredicate's initializer. This prevents attackers from altering the meaning of the predicate, even if they control the externally obtained data, as seen in the following secure example:

let remoteString = try String(contentsOf: URL(string: "https://example.com/")!)

let filenames: [String] = ["img1.png", "img2.png", "img3.png", "img.txt", "img.csv"]

let predicate = NSPredicate(format: "SELF LIKE %@", remoteString)
let filtered = filenames.filter(){ filename in
    predicate.evaluate(with: filename)
}
print(filtered)

References

• Apple Developer Documentation: NSPredicate
• Common Weakness Enumeration: CWE-943.