While working on my capstone project, which is an Android application, I consulted various how-to's posted online. While looking at these how-to's I noticed a huge amount of security flaws. People were recommending extremely insecure methods to accomplish something, and provided code to demonstrate it. Most of the pages I was looking at showed up on the first page of Google when using simple search terms. This means that there are probably a ton of web applications using code that was basically copied and pasted from these guides, which is incredibly insecure.
I created a list of some of the most common errors that I found, and a section on how to properly remediate them. This article is mainly focused on Android development, but it applies to other categories as well.
Passwords and account management
On the first page of Google results for how to implement a login system, there is not a single mention of password encryption for storing user's passwords. The posts also did not suggest any strictions for the users passord length or complexity. Most of the guides that I saw were recommending storing users passwords as plaintext in the database. This horrifies me. This would mean that the database owner could access the database and view all of the passwords. Also, if the database was compromised, an attacker would have access to all users accounts.
Luckily, using Android makes this a lot easier. The developer can use Google Play services to pass this work off to Google. In this case, the phone authenticates with the application instead of the user authenticating. Obviously this won't work for all apps, such as Facebook, but when it is applicable it works great. Since phones are usually tied to one user, it is easy to tie the account to the phone.
There is an excellent guide that explains how to implement this found on Android Developers Blog that can be found by clicking the link below.
Verifying Back-End Calls from Android Apps
Input validation and sanitization
You should never trust the input that is given to you by a user. The input should always be validated. If you don't do this, a user may accidentally or intentionally submit code that will cause your program to not perform as expected. If you are building a SQL query by taking the users input, and you don't sanitize it, you could potentially be vulnerable to SQL Injection. Attackers can utilize SQL Injection to bypass authentication, access unauthorized information, as well as create, read, update, or delete information in the database.
All input should be sanitized before it is executed. Using prepared statements is the easiest way to help mitigate against SQL Injection. You should also remove all unexpected characters. If the field requests a phone number, remove all symbols and characters. You only need to store the 10 digits that make up the phone number.
Also, all validation input should be performed on the server. It is trivial to bypass client side verification.
You should also sanitize your output. If you don't sanitize your output you could potentially be serving code that causes your app or website to function in way that maliciously affects the user.
Use SSL for all communication
All communication should be done over SSL/TLS to ensure that the data is not compromised or modified. If data is sent over an insecure communication it can be picked up by someone intercepting traffic. When you use SSL/TLS the user knows that the data they are sending to you is sent securely. They also know that the information you provide them came from you, and hasn't been tampered with.
On an Android (or iPhone) application users have no way of easily verifying that their credentials are being sent over secure communication. This doesn't excuse the developer from using SSl/TLS for all communications. The application should ensure that it is only accepting information sent over a secure channel. It should also only send information, such as usernames and passwords over HTTPS.
Verbose error messages
Most of the guides I saw included code that displayed verbose error messages. This is very useful for debugging, and most applications do this by default. However, an attacker can use these error messages to learn about your application or server. They can provide information about what technologies are used, and how the system functions. An attacker can then use this information to perform a more educated attack.
To fix this, create standarized error messages. Do not print out the error message returned by a third party application (such as MySQL or PHP). Instead, just inform the user that something went wrong.
When a user fails to log in, do not tell them if it was their username or password that was incorrect. An attacker could use this knowledge to enumerate valid usernames for accounts on the system.
