Application security issues to consider

Question

I am working on the design of a high security application (involving financial information, personal information etc). I need to identify what security measures (application level) will be implemented. The application will involve sending data to and from a database, user login, import export to csv, txt files, and print function.

What security features do I need to consider for such an application. (SQL injection for starters) ?

Also, if I want to ensure that a legit user is moving from page to page, do I have to check on every page if (UserLogin.IsValid) etc? That might require a few too many server hits I am guessing.

Answer 1

Few initial thoughts:

• Use minimum privilege for all SQL operations (i.e accounts)
• Use the proper HTMLDecode/URLDecode on any form submitted data
• Encrypt the all web config
• Check the environment securely
• Check/think about social engineering (hacking) possibilities
• Consider insider security operations, i.e security from developers

My links on security suggest you read:

1. http://msdn.microsoft.com/en-us/library/ms998375.aspx
2. http://msdn.microsoft.com/en-us/library/bb355989.aspx
3. http://www.cyphersec.com/
4. http://msdn.microsoft.com/en-us/library/aa302426.aspx
5. http://msdn.microsoft.com/en-us/magazine/dd347546.aspx#id0070044
6. http://weblogs.asp.net/scottgu/archive/2006/08/12/Tip_2F00_Trick_3A00_-Show-Detailed-Error-Messages-to-Developers.aspx

Answer 2

You mentioned SQL injection attacks. The most sure fire way to avoid SQL injection attacks are to make any and all calls to the database within your application via stored procedures, and only call these procedures through parameters. Make sure that your stored procedures do NOT use dynamic SQL in any place, as this also opens the door to SQL injection. Also be certain LINQ to SQL also provides security against attacks.

EDIT: When I talked of dynamic SQL, I didn't mean in your source code since that would implicitly violate my LINQ recommendation. I meant don't construct a SQL statement inside your stored procedure and execute it dynamically, since this leaves the door open for injection attacks even if the parameters to the procedure itself are scrubbed.

Answer 3

You must test everything. The first step would be to use a vulnerability scanner in your software development. You should run scans periodically during development, this will identify problems as they emerge and you can hold the developer responsible for the flaws in hopes they don't write it again.

Problems will always slip though the cracks. Make sure you higher a penetration tester. I can tell you from being a pen tester in the field that this is the most effective means of preventing your system from getting owned in the real world.

Answer 4

The referenced link to http://stackoverflow.com/questions/72394 is a good start. However, you will need to go further.

Specifically, encrypt ALL data at all levels. In transit via ssl (I'd say a 4KB key length minimum). At rest via encrypted file system AND encrypted database. For example MS SQL Server allows you to encrypt the entire database, not just passwords.

Do NOT use inline sql, stick with stored procedures. I don't care if you are properly escaping things. Inline sql means that you have a password in the open somewhere (generally in a config file) which allows the application to execute pretty much any sql call it wants. In the event your web app is cracked, they will have full access.

By limiting your web site to only execute stored proc's will increase difficulty in doing mass select's/delete's/whatever. Further, you can enforce your security model in side the s'procs themselves by first checking credentials passed in as parameters before executing anything. This let's the database protect itself and implies that you don't even trust your own webserver.

Ensure your server is physically protected. I've seen boxes go dark and when someone checked they found a blank spot where the server was. Secure access with video monitoring will help.

Also, log EVERYTHING. Who accessed what, what ip was used on login attempts, etc. It's nice when a client calls and asks "what happened to record X?" and I say "according to the log Bill Smith deleted it on April 3 from his house."

Next, research intrusion detection systems. These monitor the traffic coming in, parse it for the type of traffic, and can generally alert you when funny things are going on like failed login attempts to the sql server.

Test for replay attacks, also known as session hijacking. Put a token in the cookie value that gets confirmed on each post. Once confirmed, change the token to a non-guessable value. Repeat until user logs off. Whenever you see mismatched tokens, have the app scream loudly.

Make sure server to server communication is also encrypted. If on windows, this means setting good domain policies that enforce kerberos encryption on the line. I've been at several places where I brought up cain and able and could easily sniff everything from database and email passwords to actual sql transactions and responses going over the wire. Along these lines, make sure any routers involved are properly configured. As a side note, showing a CEO his email password 15 minutes into an audit is one way to prove a security audit was needed.

Finally, when you're done and ready to deploy hire an outside and reputable company (like IBM) to do a full security audit including PEN (penetration) testing. I don't now, nor have ever worked for IBM. However, I've seen some of the reports they've compiled. They are thorough.

Answer 5

The first thing to do is build a threat model. Only once you understand:

• what are the resources being protected?
• what are the vulnerabilities of those resources that expose them to attack?
• what are the motivations of attackers?
• what threats do the attackers pose?

can you reasonably start to craft a solution. For example, if the resource is my television, the vulnerability is an open window, the attackers have financial gain as a motive, and the threat they pose is the theft of my television, then I can start to craft a solution.

Consider the multi-pronged solution that becomes apparent once you have a list of resources, vulnerabilities, motivations and threats. I can:

• Make the vulnerability harder to exploit: close and lock the window, get an alarm, get unbreakable glass
• Make the resource less valuable to the attacker, thereby demotivating them: buy a cheaper, heavier television
• Make the loss of the resource less costly to me: buy insurance
• And so on.

Notice that a good solution has defense in depth. Don't just stop there. Look for more vulnerabilities. Look for more ways to demotivate attackers. Look for more ways to lower the cost of a successful attack. But all of this depends on having an accurate threat model, so do that first.

Here's some resources to get you started:

http://www.microsoft.com/security/sdl/getstarted/threatmodeling.aspx