There are many aspects of application security and these cover processes, architecture, infrastructure, code, etc. The whole topic is extremely big and versatile and there are some books written to cover all its possible verges. I will touch just a small piece which is related to something which is in area of developer’s responsibility – code and application architecture. Also, I assume that that reader mostly works on web applications implemented on Java or similar platform.
I disagree that creation of secure code is hard work; I would say it’s just a question of some knowledge and discipline. Here are several guidelines which developer has to follow to cover the most of application security vulnerabilities. Of course list is not complete and mostly covers just protection of customer’s data.
Always hash user passwords
The worst thing you can do is do not hash user passwords and store then as clear text. Less bad thing is to encode them, but it’s still naughty. You do not need to know your customers’ password, let you know, better you sleep.
I can’t imagine scenario where application has to have an access to user passwords, but easily can imagine what would happen if someone will get an access to such treasure. Thus, user’s password must be hashed, preferably using salted hash and good hash function like SHA-2.
And be always suspicious about websites, which are able to send you your password by mail.
Always encrypt sensitive data
If application operates with sensitive data, e.g. password for connecting to legacy backend systems or credit card numbers, that password mustn’t be in clear text and must be encrypted. The most of the data has to be encrypted just in storage, but some also on runtime. There is very small chance that someone will get an access to your memory dump, that chance is really-really small, but for very critical data it shouldn’t be ignored.
Of course, encryption has to be done with proper cipher, AES should be fine. The only problem is that to encrypt something you need to have a secret, which has to be unencrypted and if attacker will get it, the whole system will be compromised. So that secret has to be protected properly, e.g. with help of HSM, or at least it has to be protected on OS level with proper permissions.
Logging
Logging mustn’t have user-related or any other type of sensitive information. Examples can be credit card details, bank details, personal messages, etc. Be very careful with “toString” implementation of classes which contain sensitive information. Always keep in mind that logs can fall into somebody’s dirty hands.
Always use strong ciphers and hashes
There is no much sense to use hash or cipher if it can be easily compromised. Thus, application has to use the best available set. Another thing developer has to remember is the fact, that even the best things will become trash in the face of tomorrow. It means that must be a way to change algorithm in future. For instance, hashed password may have prefix with algorithm name at the beginning, so as soon new algorithm is available it can be used. Here is an example of such hash:
Of course old passwords will remain the same, but it’s better than nothing. The similar principle applies to encrypted values with only difference that encrypted values can be recovered and re-encrypted.
Acceptable choice of algorithms at this moment (05.2010) is SHA-2 for hashing and AES for symmetric cryptography. There are not many choices of asymmetric algorithms, RSA is the best known and wide used example. Apart from algorithm have a thought about hash/key size – bigger is better for security.
Use Prepared Statement
That’s just a must. Always use PreparedStatement or equivalent and never build SQL statement by concatenating arguments which with high probability will be cause of SQL injection problem. Let database driver think about that problem.
Hide implementation details from the user
It doesn’t matter who are your users, it can be another system or real person, you have to tell them as less as you can about your system. That knowledge can help attacker to recognize products you use or give some information how you system is build. All it can give some idea how application can be hacked. For example, printing exception stack trace into browser window, which is happening on some websites, provides almost all information about libraries, used products, architecture, etc.
Validate user input
Anything which comes externally must be validated. Any value has to have boundaries. The most convenient way to archive that is using regular expressions. This protects against XSS and related problems.
Shield output
Do not trust to anything and your own system is not exception. Before output any data to customer, it has to be shielded to remove any invalid characters. And again it can be base for XSS and related attacks.
Re-create session after authentication
It is possible that session id was compromised or used in session fixation attack. Thus, using the same session id after authentication will open the system to attacker, so it has to be re-generated.
Use authorization
You should explicitly authorize uses on every layer; otherwise there is too much space for the holes in application. That is specifically important for web applications where sometimes all authorization is based on just URL principle, which is dangerous practice.
Use auditing
Would be funny if someone will attack your system and you will not have any tracks of it. Therefore, developer has to have some sort of log for recoding activities performed by the system. That logs shouldn’t be confused with logs used for debugging and troubleshooting, latter contain debug information which help to developer to look for and fix bugs (although they can contain relevant information as well and can be used for tracking attacker actions as well). Auditing logs, on other hand, contain events raised on performing certain activities, e.g. login attempts, payments, etc.
In conclusion, I would remind that it’s not complete list, there are much more things which you can do to protect your application. For ones who are interested in making their application more secure, I would recommend following links:
- PCI DSS. This is more about payments and protecting card details, but do not forget that card details are just another piece of information.
- Wikipedia application security page. Has lots of good links for further reading.
- OWASP website. Lots of information about vulnerabilities and how to avoid them and about web application security in general.
Reference: Some hints for writing secure code from our JCG partner Stanislav Kobylansky at the Stas’s blog
Related Articles :
- 2011: The State of Software Security and Quality
- Single Sign On for the cloud: SAML & OpenId
- Securing GWT apps with Spring Security
- Basic and Digest authentication for a RESTful Service with Spring Security 3.1, part 6
- Securing a RESTful Web Service with Spring Security 3.1, part 3
- Apache Shiro : Application Security Made Easy
