It is reasonable to implement security in a web app after implementing its main features?

Question

Excuse me if this seems too vague to be posted on Stackoverflow.

My company hired three developers to implement a classified ads system, using PHP and MySQL. They’ve been working for little more than a month, without using a framework (they argued against using one) and basic functionality has been implemented (user registration and authentication, ads listing and filtering, etc). However, a cursory testing shows that the system is vulnerable to common malicious exploits (CSRF, XSS, local file inclusion).

After examining the code, I realized they didn’t implement data validation procedures on the server side (they merely use a regex for validating a mail address and mysqli_real_escape_string() to sanitize strings against SQL injections). They implemented some validation routines but on the client side, with JavaScript. Obviously, that’s part of the UI and doesn’t offer any kind of security against malicious users.

They argue that since three developers are insufficient for developing a full webapp from scratch (I agree), they’re going to implement features first and then securing them properly, in order to meet certain deadlines. I’m not an experienced programmer by any measure, but I believe is going to take longer to implement security a posteriori. Moreover, if they manage to do it somehow, it’s going to be subpar compared to data sanitization routines implemented from the beginning.

So, my questions are: (i) it is reasonable to implement security (ie, implement at least proper sanitization routines) after implementing features? (ii) If the answer for (i) is “no”, what bibliography, security frameworks (but I guess they’re embedded in web frameworks as such), etc. would you recommend for managing projects where security was poorly handled?

Answer 1

No it's not acceptable to implement security after the project is done for multiple reasons. First, as has already been mentioned, whoever is footing this bill is unlikely to continue paying to implement the security features when they already have the product they want. The second reason is because it will take them much longer to go through and try to find the all the security vulnerabilities than it would be to code it correctly the first time and implement any security measures as you're writing that code. Doing it this way would also be easier to do because you can write security libraries which will do things like escape data for you so that it just becomes fluid to write the code by doing a simple call to the escape function/method. The third reason is because there is absolutely no way that they will be able to find all of the vulnerabilities by looking back through the code. It's hard enough (see near impossible) to write the code without security bugs, let alone to go back through it and find all of those security vulnerabilities.

As for a suggested framework, I really don't have one as I never used frameworks either, only the libraries I've written in the past to use. This however comes down to just finding good developers and not ones who say they can get it done for a super low price. The PHP developer pool is filled with these half-assed developers, and I'd say a fair number of them prefer pre-made frameworks. The trick is to just find some good ones from the start. The only option you really have for securing an application written poorly like this is to get a WAF (web application firewall) and have it filter any malicious content being sent to the server. This isn't a silver bullet though for poorly written code. I wouldn't even call it a band-aid, more of a hail-mary.

One final thing is that I very much disagree that they are understaffed with 3 people writing this. I wrote something similar 4 years ago by myself (well ok there was an html guy) in under 3 months. Two of those 3 months were completely rewriting sections because the client would change his mind once it was complete plus writing in side features that turned it into more of a social network than a classified site. If I could do most of that myself in that amount of time, they should easily be able to get it done (and secure) in a month and a half with 3 people.

Answer 2

It's really not reasonable to implement security later.

It may not take any longer or be sub par, it might be faster and better. The problem is that it to probably won't be done at all as the project will be late and over budget.

I'm surprised at th decision to not use a framework, that looks like a 1 person-week job using Rails, Symfony or Django and the security would have been baked in.

Answer 3

Security should be taken into account all the time in development phases, if it is over seen/neglected then improvements to the API in development should be constructed on the first availabe instance.

The last thing you want to do is release a script to the public with many security/malicious holes within the code structure its' self.

So I would recommend informing these developers to take a look over their work and make appropriate changes to the already made API to increase security.

The project might be finished late and over budget if the security aspect is overlooked and not modified.. It's best to approach this head on before it's too late (when you've released to the public traffic and face longer down time than expected)

overall point.. Nail it in the butt before it becomes a serious problem.

Answer 4

It's not unreasonable to deal with security matters at the later stage of development, as long as it's merely an issue of implementation and not a fundamental deficiency in design. There is no such thing as "more secured" or "less secured." Either a system is secured or it's not. One has to consider the behavior of an application as a whole. As such, it's not all that profitable to handle security while the codebase is still in flux. While it's fashionable to say that security should be integral to the entire development process, in a world where resources are finite, such an approach is more academic than practical. Having sufficient time for quality assurance prior to delivery will in all likelihood yield better returns.

Answer 5

just to add what everyone else suggested, you must embrace security from day one.

not doing this will only be prone to errors and bugs in the code.

have a look at the Microsoft Secure Development Lifecycle:

http://www.microsoft.com/security/sdl/default.aspx

Also, I would recommend you to review the code / pentest it to identify any potential issues.

Thanks Fabio @fcerullo