How to Review an Open Source App for Security

TL;DR

Review an open source application by examining its architecture, source code, black box behavior, and development process together. For the In Your Hood application, the review found strong data-type whitelisting and safe client certificate handling, but also exposed location logging, unnecessary personal-data collection, weak password controls, single-pass MD5 hashing, unlimited authentication attempts, and avoidable database design risks.

Transcript

Just a few notes before we get things started. I feel like I have to somehow justify where our slides went. Hmm. Jacob will find them for me. Extreme makeover. Why are we doing this? There it is. There's the really big font I wanna justify. First of all, I'll say, uh, uh, most people who get up here on stage feel a real need to try and please every... Read More

Key Insights

• Data-type validation is applied through the data access layer, where whitelisting defines what input is permitted rather than attempting to enumerate forbidden values. Because validation is associated with data types, application code receives this protection largely automatically whenever those types are used.
• Client-side certificate validation is designed to fail safely because the iPhone application performs no special SSL handling. If the client does not trust a certificate, it gives up instead of continuing the connection, and the reviewed server supported SSLv3 and TLS with a 2,048-bit certificate.
• User location is exposed unnecessarily because NSLog debugging calls appear throughout the client without compilation guards. In the reviewed code, location information would therefore be written to the device log even in the version intended for publication through the App Store.
• Personal information is collected without a clearly established purpose because the phone-book application requires authentication and stores user location on the server. The reviewer questioned why users must supply a user ID, password, address, and location merely to find contact information for a nearby business.
• Password authentication is weak because passwords may contain only four characters, have no complexity requirements, and face no account lockout policy. The server accepted a password consisting of four ones, and repeated login attempts could continue indefinitely without locking the targeted account.
• Password storage is vulnerable to offline recovery because the database value is produced by applying MD5 once to the concatenated password and salt. If an attacker recovers the password table, it contains the password hashes and salts needed to begin attempting password recovery.
• Custom database protection creates avoidable risk because the application uses PHP MySQL escape functions and a newly invented SQL templating language instead of established parameterized statements. Although the application also protects against the new injection opportunity, the custom mechanism is not an appropriate architectural fit.
• Architecture documentation is the foundation for improving the application because diagrams can identify components, trust zones, and validation boundaries. Those diagrams can support threat modeling that lists assets, relevant threats, and possible compromises, while a data catalog records each element's purpose, format, and storage decision.

Questions & Answers

Q: How should an open source application security review be structured?

An open source application security review should examine the architecture, source code, black box behavior, and development process. For In Your Hood, the reviewers divided those responsibilities among specialists. When architecture diagrams were unavailable, the architectural review proceeded from the source code and a process interview, then examined API usage, stored information, privacy implications, and threats from the inside out.

Q: What security controls did In Your Hood implement well?

In Your Hood implemented proper data-type validation and whitelisting through its data access layer, allowing permitted formats to be defined and applied largely automatically. Passwords entered the database salted and hashed. The iPhone client also handled certificates safely by relying on normal trust checks and abandoning connections with untrusted certificates. The reviewed server supported SSLv3 and TLS and used a 2,048-bit certificate.

Q: Why was location logging a privacy problem in the iPhone application?

Location logging was a privacy problem because NSLog debugging statements were used throughout the iPhone client without guards that would remove or disable them in a published build. The reviewed version logged the user's location to the device. Debug logging may be useful during development, but leaving location statements active means sensitive information remains recorded when the application is prepared for App Store distribution.

Q: Why should an application justify every personal data element it collects?

An application should justify each personal data element because collection and storage create privacy concerns even when the information is not necessary for the main service. In Your Hood stored user location on the server and required a user ID, password, and address, although its purpose was to find nearby business contact information. The reviewer could not identify why all of that user information was needed.

Q: What password and authentication weaknesses were found?

The application allowed passwords as short as four characters and imposed no password complexity requirements. The server accepted a password made from four repeated ones. It also had no account lockout policy, so an attacker could continue making authentication attempts indefinitely. Together, short passwords, unrestricted composition, and unlimited attempts made user authentication one of the review's high-severity concern areas.

Q: Why was the password hashing design considered insufficient?

The password hashing design used a single MD5 operation on the password concatenated with its salt. Although the database stored salted hashes, an attacker who recovered the password table would also obtain all the material needed to attempt password recovery. The design did not require the attacker to acquire a separate secret key from source code or a configuration file before attacking the stored credentials.

Q: Why were the custom SQL protections questioned?

The application relied heavily on PHP MySQL escape functions rather than parameterized statements and included many hard-coded MySQL calls. It also introduced a new SQL templating language intended to prevent SQL injection, which created a new potential form of injection that then required its own protection. The reviewer recommended using a framework such as PDO that supports prepared or parameterized statements instead of maintaining a custom mechanism.

Q: How can architecture diagrams and threat modeling improve application security?

Architecture diagrams can identify an application's components, its trust zones, and the boundaries where data should be validated. Those diagrams can then support threat modeling by documenting important assets, the threats directed against them, and the actions those threats could take to compromise the assets. The review also recommends cataloging every data element, including why it exists, whether it should be stored, and its required format.

Summary & Key Takeaways

• The panel evaluates In Your Hood, an open source phone-book application with an Objective-C iPhone client and a PHP server. Because formal architecture diagrams were unavailable, the architectural reviewer worked from the source code and a process interview, examining API usage, stored information, privacy implications, trust assumptions, and potential threats.

• Several controls were implemented well. The data access layer applies data-type validation and whitelisting throughout the application, passwords are stored with a salt and hash, and the iPhone client relies on normal certificate validation so that untrusted certificates cause failure. The server offered SSLv3 and TLS with a 2,048-bit certificate.

• The review recommends documenting components and trust zones, using those diagrams for threat modeling, and cataloging every handled data element. Each item should have a defined purpose, storage decision, and expected format. The application should also strengthen authentication, stop production location logging, and replace custom SQL protections with parameterized statements through an appropriate framework.