Is it worth mitigating security risks in every application

Question

As web developers our applications are vulnerable to a number of security holes (xss, sql-injects,etc...). I'm a firm believer that if you're writing an app it should be protected from all of these well known vulnerabilities. However, I'm having a hard time convincing my team (and management) that it's worth the effort.

This leads me to wonder under what conditions should one fight the security fight? What are the factors that should be considered when deciding what security vulnerabilities to mitigate and which to ignore?

Answer 1

Of course you should fix security problems. The only reason this should ever be a lower priority is if you "trust" the users of the software (eg. nothing that accepts user input is public facing), but it still needs to be done because people can exploit some security holes by accident.

Answer 2

A full security analysis is not only analyzing the threats, but also what they could cause. Let's take an Example, SQL Injection. What if your database access acount is only able to READ but never to write to the database? Now, SQL Injection can not harm your Database. However, you still have the problem that the SELECT Queries can be manipulated to gain access to more results that required. Is that a problem? Probably yes, but it's a different problem to tackle because you could jsut filter data on output somehow.

This is not a good example of how it should be done, but it is one example of how is sometimes unfortunately has to be done due to time and budget constraints. Essentially: Look at all Threats, find the ones that can really mess up stuff, and eliminate them.

One other example: On Stackoverflow, i think i am able to insert arbitary HTML into this Answer box, like an Input Box or possibly some JavaScript, but no one but me will see the text box. The server will strip it out, and I can not forge a link that will fill the answer box for other users. In short: I can only shoot myself into the foot, so this is not a security issue Jeff should care about.

Answer 3

This is always a really tough question. I'd say it depends on the accessibility of the web site. If it is going to have a wide audience it is best to secure all of the standard items - xss, sql injects, etc. In addition to that one should seriously look at what other methods can be locked down with minimal cost. If a site is low traffic with a minimal amount of accessibility then I wouldn't be too concerned unless their is sensitive information.

It really depends. If you seriously think that security will be an issue then pick something that you know will be used for an attack and build defenses against it - outside of work if need be. Then monitor the site for that security attack. When an attack is made, report it and state that damage was prevented because you did something about it proactively. Add to that what would have happened - possibly stating it before telling anyone that the attack was prevented. If you think it isn't worth the time, then it probably isn't worth doing and you might want the bosses and team to just live and learn. When the proverbial poo hits the fan, let it fall and help fix things.

Answer 4

Your company should probably have Privacy and Data Protection policies in place, regardless of whether you're baking bread or developing web applications, and that should form the basis of your approach.

Personally, I'd work on the basis of "What's the worst that could happen?", and act accordingly. If the 'worst' is that your intranet site gets taken down by a malicious internal user, then that maybe a risk worth living with. If the "worst" is that your customers unencrypted financials details are exposed, well...

Answer 5

Unfortunately, I think the answer is that it is not worth it in every application. And that is why we have generally lousy security. Take a look at what security expert Bruce Schneier has said on this.

Answer 6

Properly, one should do a risk/return estimate for any security programming effort. However, of the three major aspects of computer security (confidentiality, integrity, and availability), you are really only thinking of confidentiality. That is, preventing unauthorized user access.

If you include data integrity and system availability, you find that the return on most security programming efforts is much greater than that solely from confidentiality. Proper secure design also catches a surprisingly large amount of non-malicious errors, leading to better application uptime and data integrity.

What's the cost of downtime, not necessarily due to an attacker? What's the reputational cost of presenting incorrect data that could easily have been detected as bad? Add that to the calculation, and following secure programming practices is worth it in nearly every case. Security precautions should not be thought of as additional effort, but should be part of every application design and implementation. If you do that, the additional effort becomes very small, and the return, in terms of more reliable operation and application trust, is very large.

Answer 7

Don't mitigate vulnerabilities, fix them.

If you've got an SQL injection, that's because your database access layer is wrong. Putting a mitigation strategy such as filtering out parameters with keywords like 'SELECT' or '; DROP DATABASE' is the wrong thing to do. Instead move to a method of database access that automatically escapes incoming parameters in the appropriate way for the database involved. Then you not only fix the problem but also ensure the application works correctly when faced with an "O'Reilly" or other problem data.

If you've got an HTML injection leading to XSS, your templating strategy is encouraging you to blindly output unescaped text. Don't try to mitigate the situation by detecting and rejecting '<' in data, you will miss some fields and you don't know about all the special cases, not to mention that someone might have a valid reason for entering a '<'. Instead fix it by changing your templating system or style so that any time you output text you always HTML-escape it as a matter of course, even if the data "can't" contain special characters.

As for what security issues you can get away with ignoring, that depends on your business and how much customers are relying on it. There are, in general, four levels of compromise affecting web applications (which I assume you're talking about as you mention SQL injection and XSS):

1. Server-level compromise. Typically from badly-protected shell and FTP accounts, but also escalated application-level compromises. Applications running system() with user-supplied data often get compromised this badly, as well as SQL injections where the database is a poorly-configured SQL Server (using xp_cmdshell). The attacker can get shell access on the server and can happily send out a load of spam and hacking attempts on other servers. This is not acceptable for any business.

2. Application-level compromise. Typically SQL injection. Attacker can read or delete any customer information from the database and otherwise interfere with the operation of the application. This is acceptable if it's pretty much a toy application and your customers will accept their data dying, or if access to the application is closed, only available to selected trusted parties/customers.

3. Data-level compromise. Typically HTML injection to XSS. Attacker can put an iframe on your site pointing to a browser security exploit putting malware on the machines of people viewing the page with out-of-date software. This is acceptable if you don't give a fig about your customers' security, or, again, if the application is closed to general access.

4. User-level compromise. Typically unverified action forms leading to cross-site-request-forgery attacks. Acceptable if your application is not likely to be of enough interest to attackers to bother to try this on.

In general the industry is at the moment somewhere around level 3. Applications enabling level 1 attacks are rare now; level 2 holes are more common but are problems most authors are aware of and know they should fix. Level 3 holes are very common and the tactics for avoiding all possible HTML injections are not widely followed. Level 4 holes affect probably a majority of web apps today.

Answer 8

A pragmatic approach is to do proper input validation and in www case - proper output escaping.

For each variable You get as input, apply the most strict filtering rules that make sense: If You get an id of a page, then an is_integer(myvariable) && myvariable >0 ; is a proper check.

Security process is a risk management process that goes along these lines:

1) Examine the use-case;

2) Think of all risks that apply;

3) Choose which risks to eliminate (by secure coding or other means), which risks to mitigate by compensating controls (e.g. a threat to sue or user policy) and which risks to accept (because they are so remote or too expensive to counter). Don't forget to monitor those risks though.

So, juxtaposing the two paragraphs above, we come to the conclusion that a programmer writing a request handler for web should always be aware of possible risks and take the decision to eliminate/mitigate/accept them. As the programmer has limited time on his hands, he should apply fascist input validation and don't rely on the data source to have sanitized data, as he might not be the only one using same database.

On a side note, if You just think of OWASP Top Ten, you have done your due diligence.