Examining the benefits and drawbacks of Apple's latest programming language, Swift.
Last week brought us a new programming language created by Apple called Swift. ...Many iOS developers were performing somersaults and cartwheels when hearing about the creation of the new language …While others were wondering what took Apple so long. I was confused because I thought there was already a programming language called Swift. (And there is.) I would have called the new language “iScript” or “iCode”, but that’s another story. Let’s discuss what security features I like about the language and what I wish Apple would have included. Here’s are a few pros that I’m glad were included:
Pro: Managing Memory Automatically
A feature that I believe that many Objective C developers will be enjoying soon is that Swift will manage memory automatically. This will take care of some serious coding vulnerabilities like the annoying and potentially very dangerous “use after free” coding error. But developers often take memory management, or garbage collection, for granted without thinking about the repercussions. In our instructor led classes here at Safelight, we make sure that developers understand that when they are storing sensitive data in a variable, they should not rely on garbage collection from removing that sensitive data from memory when they are finished processing it. Sensitive data must be stored within a mutable object so that it can be “zeroed out” as soon as processing is finished instead of relying upon garbage collection to make it “magically disappear”. This will help to reduce the window of opportunity for memory scraping malware or a bug like Heartbleed to steal/expose sensitive data in memory. Managing memory is a great feature as long as developers are aware that they cannot rely on garbage collection to protect their sensitive data.
Pro: Arrays and Integers are Checked for Overflow Conditions
Another feature that helps make Swift much more secure than Objective C is the fact that arrays and integers are checked for overflow conditions, reducing opportunities for attackers to take advantage of buffer, heap, and integer overflow vulnerabilities. But this is a feature that all modern programming languages should be expected to implement, so I’m having a hard time getting excited about Apple including it. …It’s like being excited that a new 2014 model of a vehicle comes with airbags. It would be odd if it didn’t come with that safety feature. I may be acting overly “grumpy” about this, and that could be because my coffee hasn’t quite kicked in yet, but I would have liked to see more security features like this…but I’ll get to that in a bit.
Pro: Variables are Initialized Upon Creation
The final feature that I like within Swift is that variables are initialized upon creation. This mitigates the “uninitialized variables” vulnerability that I wrote consistently when I first started writing C code 20 years ago. Back then, however, I had no idea that I could possibly be allowing attackers to control the value of an uninitialized variable. Even though this should be standard secure coding practice by developers, I like that Swift is taking that responsibility away from the developers so they can continue in their mad rush to create new functionality. But there are some other features I would have like to have seen Swift take away from the developers to protect themselves from themselves. …And here are the cons:
Con: Taint Checking
The Perl and Ruby programming languages have a feature that I really like called “taint checking”. In these languages, any variable that has the possibility of being changed by a user is considered a potential security risk. In the classes that I teach, this is where I perform a 20-minute soliloquy called “Input Validation…Read It, Learn It, Live It.” Taint Checking helps developers stay aware of which variables are controlled by input from outside the application in the hopes that they will handle that data in a secure fashion. I would have loved to see Swift implement this feature, thus demonstrating to us that Apple takes security seriously.
Con: Query Parameterization Primitive
The other security feature that I would have liked to see implemented within Swift is a query parameterization primitive. Command Injection is the most common security vulnerability today according to OWASP. It would have been nice to see Apple helping developers by highly encouraging them to use query parameterization. Java has the PreparedStatement object within their standard library. But I was unable to learn how to create a prepared statement using Swift. Now, this may be possible using the SQLite library, but since SQL Injection is only one of the many forms of the Command Injection vulnerability, I wish that Apple created a query parameterization primitive to help mitigate the risk of this common vulnerability. Now that I’m finished moaning and groaning about Swift and Apple, I do want to say that I am looking forward to teaching Secure Swift Coding when the opportunity arises. I feel that Swift is a definite upgrade from Objective C in the sense that developers will not be as likely to write security vulnerabilities. …But it would have been nice to see Apple go a step further with helping developers write more secure code as they have done with helping developers write functional code more quickly
