Channels ▼


Security Issues in Swift: What the New Language Did Not Fix

Format String Attack

Severity: High
Likelihood of Exploit: Very High

If an input from an untrusted source is being displayed, the developer needs to be careful not to use the received string for format processing. For example, the code below shows how the syslog standard C library function is used to write a received HTTP request to the system log. Because the syslog function processes format strings, it will process any format strings included in the input packet:

/* receiving http packet */
int size = recv(fd, pktBuf, sizeof(pktBuf), 0);
if (size) {
	syslog(LOG_INFO, "Received new HTTP request!");
	syslog(LOG_INFO, pktBuf);

Many format strings can cause problems for applications. For example, suppose an attacker passes the following string in the input packet:


This string retrieves eight items from the stack, assuming that the format string itself is stored on the stack. This might effectively move the stack pointer back to the beginning of the format string. Then the %n token would cause the print function to take the number of bytes written so far and write that value to the memory address stored in the next parameter, which happens to be the format string.

Thus, assuming a 32-bit architecture, the AAAA in the format string itself would be treated as the pointer value 0x41414141, and the value at that address would be overwritten with the number 76. This situation can enable the attacker to write arbitrary data into any location. To prevent format string attacks, input data should never be used as a format string. For example, the following code is vulnerable:


But when written like this, it is safe:

printf("%s", buffer)

The remedy is to use string literals for format strings and route all inputs to substitution parameters. Swift has a new language feature called string interpolation. This is a way of constructing a new String value from a mix of constants, variables, literals, and expressions by including their values inside a string literal. Each item that you insert into the string literal is wrapped in a pair of parentheses, prefixed by a backslash:

let m = 3
let message = "\(m) times 2.5 is \(Double(m) * 2.5)"
// message is "3 times 2.5 is 7.5”

Because interpolation is only available for string literals, there is no risk of untrusted input being processed for interpolation.

In sum,Swift inherits the format string vulnerability from Objective-C. However, Swift introduces the new string interpolation feature, which is safe from format string attacks.

The Rest

We have found that Swift behaves no differently than Objective-C regarding the rest of the vulnerabilities described in the Apple Secure Coding Guide. These include:

  • Invalidated Input
  • Race Conditions
  • Interprocess Communication
  • Insecure File Operations
  • Access Control Problems
  • Secure Storage and Encryption
  • Social Engineering
  • Cross-Site Scripting (XSS) and Injection Attacks

This is due to the fact that these vulnerabilities are not related to language, but originate from the library that Swift inherits from the older Objective-C.


Taking the aforementioned parameters into consideration, we can see that the security standards in Swift are only somewhat better than those found in Objective-C. This is due to the fact that numerous vulnerabilities were located in the Swift classes that enabled calling the Objective-C interfaces. This means that even Swift development needs to be done with security in mind.

Following safe coding practices and employing the use of security solutions is mandatory for both Objective-C and Swift. A Static Application Security Testing solution, such as Checkmarx's Source Code Analysis (SCA) or Sonar, are good ways to identify and eliminate the vulnerabilities mentioned in this article. Penetration (Pen) Testing is also an effective means of testing the robustness of the software.

The vulnerability ratings mentioned in this article were taken from the OWASP portal.

Denis Krivitski is a Senior iOS Security Expert at Checkmarx, a leading developer of software solutions that enable organizations to introduce security into their Software Development Lifecycle (SDLC).

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.